Re: Additional security and privacy considerations?

Hi Thomas,

Thanks a lot for the proposal, it looks good!

On Wed, May 27, 2009 at 9:58 AM, Thomas Roessler <tlr@w3.org> wrote:
>
> So, I'll leave it to you to invent a section heading and to add something
> that indicates that the text is non-normative.  But here's a proposal (edits
> welcome; additional mitigation techniques more than welcome):
>

I propose we add a subsection to the "Privacy considerations for
implementors of the Geolocation API" section:

//------------------
Optional implementation considerations

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:

//------------------
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:16:21 UTC