Re: E911 and appliances

If you don't include user information in the location information,
then you create an ugly set of cross-protocol privacy attacks, where I
freely reveal my "anonymised" location, and then reveal my phone
number, and it turns out the same cookie is attached to both.

Adam

On Mon, Aug 20, 2001 at 02:30:03PM -0400, Rosen, Brian wrote:
> 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

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume