Re: Requirements Document

On Mon, Aug 20, 2001 at 03:07:23PM -0400, Rosen, Brian wrote:
> > > Do you object to a requirement that it must be possible to
> > > deploy the geopriv object in a standards based manner
> > > such that authorization to reveal location information is
> > > handled out of band (by contract for example), rather than
> > > by explicit user action at the point of use?
> >
> > Are you asking about only out-of-band, or setting up a default
> > out-of-band with in-band control? I would have no problem with the
> > latter, I would have a problem with the former, there may well be
> > times when I'd like to change my setting for a single call.
> I claim that's an implementation issue. We can offer some advice,
> but we can't require that such an option be made available.
>
> >
> > > I have no objection to the object having advice to implementers
> > > on how to provide explicit user consent. I strongly object
> > > to requiring its use in all cases.
> >
> > There is a set of times (e.g., US e911) where the information must be
> > revealed in order to comply with local law. Clearly, in that case,
> > you can't require consent. Are you using the term "explicit user
> > consent" to mean that the user takes some GUI action per request, or
> > in some other sense? If you're saying that you object to the user
> > being required to take action for each location request, then that's ok
> > by me. I have no problem with setting up consent settings that
> > usually work. If your objection is to the idea of explicit consent
> > when I reveal my location, and such revelation is not required by law,
> > I'd like to understand why you object to that.
> I mean explicit consent at the point of use. I see three possible
> ways to consent:
> 1. Out of band - no protocol action at all
> 2. Prior consent - action completed by some protocol mechanism that has
> some lifetime (could be infinite)
> 3. Consent at the point of use

Could we ammend 1 to say 'Out of band - protocol reminds end device
that choice has been made?'

This would allow me as an implementor to debug a possible error, adds
audit points, etc. It does have a cost in bandwidth, and I know how
sensitive mobile folks are to that, but I expect that we can do this
with fairly few bits.

> I object to having any requirements other than all of these should be
> possible. I think there are valid deployment scenarios where consent
> at the point of use is a bad idea, and deployment scenarios where
> it is a good idea. I don't object to a discussion in the security
> considerations section where it discusses when consent MIGHT be
> appropriate, but I don't believe there is any good reason why
> we should go beyond offering such advice.

I don't see how we can assess privacy requirements without saying that
you must give choice and notice (amongst other things) to the
users.

> Consent at the point of use implies things about available UIs.
> I may not HAVE a suitable UI at the point of use. That is my objection.
> I also think the IETF has stayed away from any kind of UI discussions.
> I think we should also.

Its a valid objection, and I understand where you're coming from. I
don't see how to reconcile privacy with the idea that I have no
ability to turn off tracking. Are you suggesting ECRUSHEDBYAHAMMER as
a protocol response? ;)

Adam

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