- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 06 Jul 2010 10:47:31 +0200
- 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 UTC