RE: Requirements Document

> > 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?'
No. Protocols don't remind users of anything. We aren't even
defining a protocol, but merely an object. The real issue is that
UI choices are all implementation issues, and it is not a good idea
to force anything on a UI. How well do you appreciate a warning
shoved under your nose every time you login? My net administration
forces that on me. I think it is a supremely BAD idea, and much
more likely to engender apathy than compliance.

I want geopriv to stay OUT of anything having to do with UI
with the possible exception of some advice in the security
considerations section.

>
> 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 don't have a bandwidth problem, I have a security and protocol/device
design problem. As a product designer I object to standards bodies
telling me how to design the user experience. You can tell me what
you think a secure system should do, but it's up to me to control
the user experience.

BTW, I AM designing a product, and I AM picky, very picky about the
user experience. I'm spending $Ms on the user experience, and I'm
not about to let you tell me what UI mechanisms I'm to use,
when I'm to use them, and what choices I offer. The hardest
part about UIs is knowing when NOT to offer choices.
This particular product will offer location only in some limited
circumstances (of which E911 is one), and I'm satisfied that
we will have excellent user consent controls, thank you.
If users don't agree, they won't buy my product :(
 
> 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.
There is no precedence for this in any other IETF standards
track document (using words "must" "choice" and "notice".
Rarely do we even talk about "users", since we have devices
that don't have users.

What if I want to use the protocol to locate robots on the playing
field of robot soccer? Who is the user? Do you want me to have
to give consent for every position update for every robot?

How about locating routers in a network?

There is no way to discuss "users" in a general sense. Again,
we can offer (limited) advice.

>
> > 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? ;)
>
No, I think it's acceptable to have some advice to implementers.
I think it is unacceptable to have any kind of requirement about
notice or consent.

We can lead the horse to water....
We can specify mechanisms to facilitate...

but we can't write requirements that have direct impact on user experience.

Brian
Received on Mon Aug 20 16:02:54 2001