W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2010

Re: Geolocation privacy implementation

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 06 Jul 2010 10:47:31 +0200
Message-ID: <4C32EDA3.9060203@opera.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
CC: public-geolocation <public-geolocation@w3.org>


On 7/6/10 4:09 AM, Richard L. Barnes wrote:
> Back when we were discussing whether to add language for what sorts of
> privacy options a UA should implement alongside the Geolocation API, the
> argument was made that this was a UI issue, and that different UAs would
> implement things differently. Now that we have production Geolocation
> support in 4 of the major browsers (IE, where are you?), I thought we
> might take a look at how these browsers have implemented privacy UI. To
> first order, pretty much the same way:
> <http://geopriv.dreamhosters.com/w3c/w3c-geolocation-implementation.gif>
>
> There are some small differences ("remember for this site", 24-hour
> limit), and some more major differences in how the list of authorized
> sites is managed after the initial permission is given. But in broad
> terms, all these approaches are pretty similar.
>
> It seems like it could be helpful to users if this group could discuss
> some of these areas where there are differences, and maybe produce a BCP
> for how they should be resolved (probably in the form of some privacy UI
> recommendations in the API spec).

I agree. Even agreeing on common a geolocation indicator (icon) would be 
a great step forward - and the placement of that indicator in the 
address bar or some other suitable location. Also, and agreement on 
language seems pretty critical too ("tracking" vs "wants to know", etc.).

So, off the top of my head, my wish list would be for consistency in:

1. Indicator (icon) - as we have consistency with the padlock
2. Request dialog (with some access to a standard set of advanced 
controls, such as time limit, and fuzziness)
3. Revocation control, per site, and per embedded site
4. Access to provider, including privacy policies (the fact that these 
are decoupled should be addressed somehow)
5. End-user control over provider (i.e., having the ability to change 
provider). Or possibly even the ability provide their own static location.
6. requirement for strong protection over the choice of provider, so 
that third parties cannot change this without significant consequences 
(e.g., telling the user that their browser may have been compromised). 
Also, the choice of granting access to a site must be bound to the 
provider, so if an end-user changes provider, then all granted access 
rights are revoked.

Kind regards,
Marcos

-- 
Marcos Caceres
Opera Software
Received on Tuesday, 6 July 2010 08:48:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:50 GMT