RE: E911 and appliances

From: Rosen, Brian ^lt;Brian.Rosen@marconi.com>
Date: Mon Aug 20 2001 - 14:30:03 EDT

Wouldn't you say that user identity information is NOT in the domain
of geopriv, and should be explicitly declared out of scope for
inclusion in the object itself? You might have to provide
user information to authenticate entities, but that is
ancilliary to providing it in the location object.

Brian

-----Original Message-----
From: Christopher Sipes [mailto:CSipes@Forrester.com]
Sent: Monday, August 20, 2001 2:26 PM
To: Adam Shostack
Cc: andrew@daviel.org; geopriv@mail.apps.ietf.org; hgs@cs.columbia.edu
Subject: Re: E911 and appliances

Perhaps, in answer to the question regarding one's anonimity, while still
being able to provide geographical location information, that the
implementation by default of this tool provides only the caller's three
dimensional location. Then, as an increased security measure, in areas
where it may be necessary, the option of providing caller/user information
will then be appended to the data packet. My thinking is, that, there
should be some implied consent/responsibility when dialing an emergency
number, though not so many standards such that individuals may be detered
from reporting a situation. If necessary, we simply limit the information
provided to what might be most important, being specific location of the
call.

   || Chris Sipes | Web Developer | Forrester Research, Inc. | 400
Technology Square | Cambridge, MA 02139 | email: csipes@forrester.com |
617.613.6009 ||

Adam Shostack <adam@zeroknowledge.com>
08/20/2001 01:39 PM
        
        To: Henning Schulzrinne <hgs@cs.columbia.edu>
        cc: Andrew Daviel <andrew@daviel.org>,
geopriv@mail.apps.ietf.org
        Subject: Re: E911 and appliances

On Fri, Aug 17, 2001 at 01:23:56PM -0700, Henning Schulzrinne wrote:
>
>
> Adam Shostack wrote:
> >
> > On Fri, Aug 17, 2001 at 11:47:42AM -0700, Henning Schulzrinne wrote:
> > > In terms of the discussion here, I suspect that we'll see more choices
> > > as to how locations are being reported. However, given that people
> > > dialing 911 are often not exactly in the clearest state of mind, I
have
> > > a hard time picturing a device that requires a user to make detailed
> > > choices in a scroll-down menu as to the location accuracy while the
> > > house is on fire.
> >
> > In terms of interface, I would see as reasonable a menu choice to
> > not reveal information, which after 30 seconds or so (and perhaps a
> > voice prompt), would default to revealing exact location. That allows
> > for informed choice without comprimising safety.
>
> Yes, good idea, but that's a user interface issue, not a protocol issue
> (as long as the information is available locally on the end system). As
> far as I know, user interfaces aren't specified by the IETF. We can (and
> should) say that user interfaces should be designed to allow such
> choices, but I don't expect this to have much effect beyond making us
> feel good about having protected privacy. Look how much effect the
> warnings in the MIME spec about asking users about executable content
> have had.

Stephen Kent continues to argue that a security "protocol is not just
syntax, it's the processing part too." (Message to Robert Muskowitz
and saag-wg, last Friday) While my own interpretation is closer to
yours than his, I believe that we can specify that a user must be
given a choice, unless such a thing is forbidden by local law. As to
will engineers implement such a thing? I think that the more support
we can give to good implementation, the better off everyone will be.
I could argue that, given the number of poor prngs out there, RFC1751
was a waste of electrons. Rather, I try to ensure the standards I'm
involved in address the issues as best they can, and then pressure
people to follow them.

> > I can clearly see cases in which I want to summon emergency services
> > without revealing that I'm the one doing so. For example, if I'm in
> > Amsterdam's red light district, I may want privacy, and be able to
> > report a street address.
>
> Yes, that's clearly a useful feature. Note, however, that reporting
> caller identity is not only used for speeding responses, but also to
> discourage prank 911 calls or, more sinister, to use 911 to lure law
> enforcement into a trap. Rumor has it, for example, that the NYPD is
> very careful about following 911 calls from payphones in certain areas,
> as these have been used to get officers ambushed. Thus, as usual, there
> are multiple conflicting and legitimate objectives. Weighing such
> trade-offs is done by politicians, not IETF standards, as these are not
> technical issues. At best, we can provide the means to make good choices
> easier.

There are many places where we are asked to make these choices in the
design of our protocols. The IETF and IAB have been fairly clear on
on the issues of security and privacy, and that protocol design for
the global internet should not be constrained by the laws of
individual countries, especially where laws vary substantially from
country to country.

Asking politicians to answer the question of how they trade off with
their counterparts in other countries is going to prevent us from
standardising in time for the Phase 2 that you've referred to. We
need to, and are able to, make intelligent choices about these issues.

(See in particular RFCs 1984, 2804)

Adam
Received on Mon Aug 20 14:29:40 2001

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST