Re: Additional security and privacy considerations?

On 12 May 2009, at 06:10, Doug Turner wrote:

> As much as I share your concern in this area, I do feel some of this  
> is out of the scope of this working group as it specifies the UI for  
> UA.  In any case, I would like to point out a few items:

The key point is that *some* of this is out of scope, not all.  The  
specification makes it fairly clear that its security model is purely  
based on user interaction.  When that is the case, guidance on how to  
make that interaction fail in a safe way (or at least contain the  
effects of errors) is surely within the scope of the spec -- while  
concrete UIs (like flashing crosshairs or little maps or glowing blue  
dots or annoying ping noises, or whatever else) are certainly out of  
scope.

The purpose of my note is to tease out the parts that are within the  
scope of the spec, and see them go into the spec -- I'm not interested  
in Johnath's job. ;-)

The meta point here is that we'd rather see the folks close to the  
technology think about the user interaction and security *now*, and  
document the results of that, than have a bunch of privacy  
commissioners design UI and pass a law about it -- we've had that with  
the "cookie directive" in the EU; I'd rather not see a repetition of  
that for location and other device APIs.

> First is that Firefox 3.5 will allow users to view geolocation  
> permissions directly in Page Info (http://dougt.wordpress.com/2009/05/06/geolocation-page-info-in-firefox-35/ 
> ).  It is very easy to go from any page to that page's informational  
> page.

Easy perhaps -- but there's no reason for the user to go there during  
their everyday tasks, which means that this mechanism is going to be  
ineffective in a scenario like the one I had given in my initial note.

> Second, in our experience ambient indicators don't work -- Either  
> too ambient no one notices or too in-your-face to be usable.  Simply  
> consider the list of "lucky charms" that were in older versions of  
> Firefox.  We have been actively streamlining the user interface to  
> remove such clutter (http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/ 
> ).

... and the padlock is back in the latest beta, in the status bar.   
So ...

> Thirdly, although anecdotal, the "remember this decision" is meant  
> to stop having the browser ask this decision.  Anything less than  
> this (remembering only for one day or something similar) brings  
> terrible memories of the j2me permissions dialogs to mind.  The  
> backlash from user's will be "Stop asking me already!".

I'm not suggesting to bring the j2me dialogs back -- the dichotomy  
you're implying is a false one.

As Martin Thomson pointed out already, there are lots of other UIs  
that might cause user interaction based on an assessment of risk --  
for example every other login screen, when your IP address changes, or  
when you haven't visited the site for a while.  The trick is to make  
the interaction rare enough that people don't feel like they were had  
when they clicked "remember this decision", but to make it frequent  
enough that the effects of a user error are contained.  The trick for  
the specification is going to be to find the right balance between  
describing the basic approach and not prescribing the detailed  
heuristics.

> Lastly, we have been experimenting with not requiring the user to  
> explicitly set the "remember" checkbox when they go to a site.   
> Instead, the preference would stick after a series of decisions were  
> made.  For example, if you visit maps.google.com 5 times and always  
> said "yes", then we would not ask again).

That's an interesting approach for making the consent piece go more  
smoothly.

HOWEVER (and that unfortunately goes for your entire note), none of  
this addresses containing user error.  One important lesson to take  
into account is that users will make unwise decisions in order to  
accomplish a task.  They will make errors.  And they will forget what  
they've done (if they ever knew in the first place).

That means that "if we're told to remember, we shouldn't forget" (as  
you said in another note to this list) will be spun into "blaming the  
user" -- I don't think that's a statement that anybody here wants to  
be seen to make, even implicitly.


So, back to my original point:  Let's try to get to a slightly more  
nuanced discussion of (a) making location acquisition transparent to  
users even when they have given agreement, and (b) having a credible  
story together that explains what happens when that agreement might be  
in error, and how these errors don't lead to a complete breakdown of  
location privacy.  (As I said, I don't know what the answer is in  
terms of precise UI, or whether it's expiry, not revocation.  That  
answer is yours to find, but the group's to document once you've found  
it.)

I think that Martin's latest points into a useful implementation  
direction for the points I made:

> If you want precedent, I ask Google to remember my gmail login - and  
> it does. However, after a little while (I'm not sure exactly how  
> long) it asks me to re-authenticate.  It's not so much of a chore as  
> long it's not too frequent.  Finding out just how frequent is the  
> trick.
>
> As for the notification, you still use the status bar for a discreet  
> notification. I don't think that what is being proposed needs to be  
> highly visible, just accessible.

... the key phrase being "what is being proposed [doesn't need] to be  
highly visible, just accessible."

The specification would just have to say that an indicator must be  
shown in UI as long as a browsing context interacts with a page that  
has acquired location, and that interaction with this indicator must  
enable a revocation of location permissions for that site.

The specification should also say that consent must not be considered  
to last for longer than two days.

Simply not addressing this (I think) would be a serious error.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 12 May 2009 09:29:50 UTC