RE: Additional security and privacy considerations?

Hi Thomas,

This all sounds like good feedback, and practical.

One thing that has concerned me greatly about this specification is the maturity of the interface.  Without a well understood means for establishing (and managing) the contract between user and site, I fear the same repercussions you allude to.

I'm not sure how this translates into text for the specifications, but I'd hope that we'd be able to do something.  Ideally, this encourages the development of a standard usage paradigm.  Such a thing would help reinforce user confidence in their ability to protect their own privacy.

A discreet notification that a page as requested (and maybe received) location information might go a long way.  By keeping the information visible, users no longer have the maze to negotiate.  This might be similar to the notification that a popup has been blocked, or that the site has been authenticated.  Not to malign Doug's fine work in any way or to pick on Firefox in particular, but using the latest Firefox beta there isn't any feedback once the initial permission is granted.

(As a design aesthetic point, I don't like the idea of animation unless it is to indicate current activity; limiting any animation to times that location information is generated or sent might be a good idea.  A static image other times would suffice.)

As for permission expiration, it might make sense to provide configuration to limit the time.  I doubt that it would be an imposition to acquire permission on a regular basis.  To me, daily would be a chore, I am lazy enough to appreciate the use of cookies and authentication that persists for several days.  Of course, we should be careful to ensure that this form of laziness does not turn into users granting an open licence.  The scenario you cite is one I'd be very keen to prevent.  With this in mind I'd be OK with a default of a day, but I might be inclined to bump the value up to about a week if I could.

--Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Thomas Roessler
> Sent: Tuesday, 12 May 2009 7:37 AM
> To: public-geolocation@w3.org
> Cc: Rigo Wenning
> Subject: 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>
> 
> 
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Tuesday, 12 May 2009 04:04:41 UTC