- From: Doug Turner <doug.turner@gmail.com>
- Date: Wed, 27 May 2009 07:58:59 -0700
- To: Thomas Roessler <tlr@w3.org>
- Cc: Andrei Popescu <andreip@google.com>, Greg Bolsinga <bolsinga@apple.com>, Rigo Wenning <rigo@w3.org>, public-geolocation <public-geolocation@w3.org>
After thinking about this a bit more.... I believe adding text, normative or not, that talks about a fictional UI will add confusion. I can imagine questions like "how come this UA didn't follow the w3c spec when it concerns UI?" As Greg said, "This spec is about getting a location, not how it is implemented." We should instead cite this thread as part of the considerations and drop having any recommended UI design related to points 1, 2, and 3 in this specification. Doug On May 27, 2009, at 7:26 AM, Thomas Roessler wrote: > 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:59:42 UTC