- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 27 May 2009 16:26:57 +0200
- To: Andrei Popescu <andreip@google.com>
- Cc: Greg Bolsinga <bolsinga@apple.com>, Doug Turner <doug.turner@gmail.com>, Rigo Wenning <rigo@w3.org>, public-geolocation <public-geolocation@w3.org>
On 27 May 2009, at 16:15, Andrei Popescu wrote: > I propose we add a subsection to the "Privacy > considerations for > implementors of the Geolocation API" section: > > //------------------ > Optional implementation considerations That makes the guidance sound more feeble than it actually is. "Additional implementation considerations" would be fine; also, it's already clear that the section is non-normative. Putting "optional" here means overdoing it a bit. > This section is non-normative. > > <your suggested wording here> > //------------------ > >>> Implementors should consider the risk of users granting >>> authorization >>> inadvertently, and provide mechanisms to limit users' exposure to >>> privacy >>> risks due to such errors. Such mechanisms include: >> > > For clarity, I would propose avoiding RFC2119 keywords in this > section. We could instead say: I'm not particularly happy with that step, in particular since the section is already clearly labelled as non-normative, and since the phrase in question puts a burden on implementors -- instead of listing a requirement that implementations should conform to. > //------------------ > Further to the requirements listed in the previous section, > implementors of the Geolocation API are also advised to consider the > risk of users inadvertently granting permission to the User Agent to > give their location to Web sites. Implementors could provide > mechanisms that limit the users' exposure to privacy risks due to such > errors. Such mechanisms include (but are not limited to): > > * User interface cues that indicate whether location data is currently > being disclosed to a Web site, and facilitate easy revocation of > previously granted permissions. For example, a Web browser in a > typical desktop environment could display a visual indicator when the > user interacts with a site that has been authorized to acquire > location information and that site has used the Geolocation API during > the current browsing session. A mouse click on this indicator could > allow the user to access the user interface for revoking geolocation > permissions. > > * Expiry of user consent. Implementations could reset the permission > state for a given origin after a certain amount of time. For example, > the permission state could be reset at time intervals that increase on > a scale of a few days up to a few weeks. > //------------------ > > Thanks, > Andrei >
Received on Wednesday, 27 May 2009 14:27:05 UTC