Re: Additional security and privacy considerations?

Thomas,

I share your concern for user's privacy.  When a user grants  
permission to a website for geolocation, or for other device apis,  
there should be a very easy way for them to revoke that permission,  
view other permissions granted to that site, and clear all permissions  
to all sites.

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:

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.

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/ 
).

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!".

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).

I hope this helps,
Doug Turner


On May 11, 2009, at 2:37 PM, Thomas Roessler wrote:

> Hello,
>
> we had some discussion of the recent editor's drafts within the Team.
>
> The latest one has this language on permissions:
>
>> Those permissions permissions that are acquired through the user  
>> interface and that are preserved beyond the current browsing  
>> session (i.e. beyond the time when the browsing context  
>> [BROWSINGCONTEXT] is navigated to another URL) must be revocable  
>> and User Agents must respect revoked permissions.
>
> Now, it's fairly clear that preserving permissions makes sense for a  
> number of reasons (ranging from the turn-by-turn navigation use case  
> to users actually trusting sites).  The worry is, though, that the  
> current text assumes a world in which permissions are either made  
> persistent, or not; that assumption also seems to drive  
> implementations.  In the text, there's also a lack of consideration  
> for the likelihood that conditioned users will grant authorization  
> erroneously.
>
>
> Here's a scenario for how things are likely to go wrong: A user  
> grants permission to collect their location to some location-based  
> social service, and makes that permission persistent.  The location- 
> based service turns out to not be trustworthy, and is connected to  
> an advertising network that starts collecting user location through  
> iframes spread all across the Web.  Without the user noticing, the  
> advertising network can now build a fairly thorough profile of the  
> user's movements.
>
>
> This scenario illustrates two fundamental concerns:
>
> 1. It is not necessarily transparent to the user when their location  
> information is transmitted to a Web site and when it isn't.  That  
> implies that users have no good way to discover what the effect of  
> their authorization is, and will therefore rarely (if ever) revoke  
> an authorization.  Since there is a reasonably clearly distinguished  
> situation in which a privacy risk exists (some web application has  
> registered a callback for position updates, or has recently asked  
> for location information using the one-shot interface), it should  
> actually be possible to come up with some kind of indicator.  I  
> don't know what that should look like (perhaps a slowly pulsating  
> crosshair?), but would be curious whether implementors have useful  
> ideas.  The specification should have clear guidance on the presence  
> of an indicator, and perhaps some examples what it could look like.
>
> I've seen one recent implementation of the API that seems to conform  
> with the spec, but requires jumping through three levels of rather  
> obscure menus in order to revoke a permission.  That seems  
> unacceptable from a usability and security perspective; an indicator  
> that goes on when a site is actually collecting information would be  
> a good hook for a revocation UI.
>
> 2. The specification doesn't scope "permanent" authorizations in  
> time.  That means that a single mistaken authorization exposes a  
> user to location tracking for as long as their user agent  
> configuration lives -- and that can be a really long time.  That,  
> too, strikes me as not very acceptable.  I'd like to see the group  
> investigate the possibility to limit the lifetime of an  
> authorization (perhaps 1h, perhaps 8h, perhaps a day -- but not much  
> more), to further reduce the impact of an erroneous authorization.   
> The specification should discuss that kind of scenario, and provide  
> guidance on the lifetime.
>
>
> We're concerned that not addressing these aspects will lead to a  
> significant backlash against both the specification and its  
> implementation from a privacy perspective; that kind of backlash  
> might very well have unpleasant side effects on the deployability of  
> location based services on the Web.
>
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>

Received on Tuesday, 12 May 2009 04:11:35 UTC