RE: Requirements Document

Huh, now I'm the one with more ambition wrt privacy than you.

I believe we CAN provide a reasonable degree of privacy
to location information within the bounds of my current problem.

For example, I think we CAN require strong authentication
prior to transmission of location information in nearly every
case I'm aware of.

On the other hand, I'm pretty pessimistic about what real
privacy controls you can put assuming next generation devices.
The problem, as I see it, is that there is no way the
sender can know if the receiver will respect its wishes.
All of the controls you want seem to be hints sent by the
sender to the receiver telling the receiver what you hope
it will do with the data.

Good guys will behave, bad guys won't. It's always true
that if you tell someone a secret, you can't depend on him
keeping the secret. I don't see any drawbacks in trying
to write requirements that will give decent capability to
users where the receiver is well-behaved, but I don't see
that you get to claim much more than a prayer. Certainly,
out of band mechanisms are as good, if not better than
that, since they can either explicitly or implicitly create
a contract, where a protocol mechanism cannot.
A well designed consent form is a much more effective
privacy control than any protocol mechanism could ever be.

The real problem though is that there is no way to test
conformance to the requirements you seem to want to write,
since there is no observable protocol behavior difference
between a conforming and a non-conforming implementation.

Brian
  

> -----Original Message-----
> From: John W Noerenberg II [mailto:jwn2@qualcomm.com]
> Sent: Friday, August 24, 2001 2:15 PM
> To: Rosen, Brian
> Cc: 'Randy Bush'; geopriv@mail.apps.ietf.org
> Subject: RE: Requirements Document
>
>
> At 8:29 AM -0400 8/24/01, Brian Rosen wrote:
> >I wrote this before I saw your mail on your interpretation
> >of the charter. So, from your point of view, this is mostly
> >meaningless, but I think you are incorrect, so I offer it anyway.
>
> We're struggling to come to a common understanding. That isn't
> necessarily easy, and I apologize for letting my frustration show.
>
> >
> >I don't really understand how you intend to accomplish our
> >goals. We are defining the requirements for an object.
>
> Yes, that's part one.
>
> > We aren't defining a protocol,
>
> No, this is mistaken. We have to define a protocol to carry the
> object. Recall that is one of the milestones for this WG. There are
> a couple of different ways to accomplish this. a) We could create a
> brand spanking new language to deliver the object from sender to
> receiver. b) We could take an existing protocol -- like SIP or HTTP
> -- and propose extensions which enable them to carry the object. "b"
> is likely the more preferable route. I've been down the "a" road
> before, and it's a bumpy ride.
>
> > and FOR SURE, we are going to
> >use this object in existing protocols with existing devices.
> >SIP and HTTP are examples, on existing phones and PCs at a minimum.
> >Sure, new devices with new capabilities will come along;
> >I'm working on some :), but whatever we do, it has to WORK
> >on a "black" phone connected to a SIP gateway, or a current
> >technology WAP phone, or the first gen 3GPP phones, and, believe
> >it or not, the first level ethernet switch in the closet near
> >you.
>
> The best we can hope for with existing devices (excepting the PC, and
> perhaps 1st generation 3G devices), is the protocol results in the
> knowledge by the users of senders and receivers of these messages
> there is NO privacy associated with the location messages exchanged.
>
> That doesn't mean we can't set the ground so that succeeding
> generations can negotiate the degree and limit of the information
> revealed in the location messages.
>
> >
> >A critical need, my first application of this object, is to
> >reveal location in an emergency call. Please tell me what
> >SIP messages you want me to send and receive in order to
> >send location. Yes, we can if needed, modify SIP, although
> >it might be hard to totally redefine the protocol.
>
> This is essentially what I propose we do.
>
> >
> >Please keep in mind the current bandwidth available to a 3GPP
> >telephone for signalling (around 4Kbits), and the current processor
> >available to run cryptographic operations.
>
> It is for these reasons it is unrealistic to expect current
> generation devices can assure any degree of location privacy.
>
> > I don't care what the future will bring if the
> REQUIREMENTS must be met
> >by current technology. What REQUIREMENTS are you placing
> >on my current problem?
>
> The requirement I seek is devices exchange the object. It is
> reasonable to say the attributes defining access limits may be set to
> indicate there is no limitation on the use of the information, but
> doing so provides no assurance the information will not be used in
> contexts beyond the current transaction.
>
> If limitation on the use of the information is desired by the users,
> senders and receivers must be capable of setting other values for
> these attributes.
>
> >
> >Hmmm, I just listed several requirements. Let me restate them:
> >1. The solution must be retrofitable into existing protocols such
> >as HTTP and SIP.
> >2. The solution must function on existing technology SIP gateways
> >existing WAP-style mobile devices, first generation 3GPP handsets
> >current generation PC technology, and existing first level manageable
> >LAN switches. Software upgrades are acceptable.
> >3. The solution must function on low bandwidth (e.g. kilobit-range)
> >links with reasonable response times.
> >5. The solution must support unattended devices
>
> With the bounds I've set, I think these are all attainable. Bear in
> mind the application of the protocol in these circumstances likely
> won't improve the control over location information -- which is
> essentially the situation we have today.
>
> >4. The solution must support high-update-frequency tracking
>
> This probably is unattainable because of bandwidth and
> capacity limitations.
>
> best,
>
> --
> john noerenberg
> jwn2@qualcomm.com
> --------------------------------------------------------------------
> Setting out on the voyage to Ithaca
> you must pray that the way be long,
> full of adventures and experiences.
> -- C.P. Cavavy, "Ithaca", 1911
>
> --------------------------------------------------------------------
>
Received on Fri Aug 24 14:47:36 2001