Additional security and privacy considerations?

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 Monday, 11 May 2009 21:37:32 UTC