- From: Lars Erik Bolstad <lbolstad@opera.com>
- Date: Mon, 18 May 2009 23:33:30 +0200
- To: Thomas Roessler <tlr@w3.org>
- CC: Rigo Wenning <rigo@w3.org>, Doug Turner <doug.turner@gmail.com>, public-geolocation@w3.org
Thomas Roessler wrote: > <add> > > Persistent permissions can lead to privacy leaks due to a number of > effects: Users are known to sometimes grant permissions erroneously > and unintentionally. Domain names change owner, business practices > change, web sites are subverted. In all of these scenarios, the > ability to easily revoke permissions can be critical to the user's > safety and privacy; likewise, it becomes critical for users to > understand what data are revealed during their ongoing interaction > with Web applications. Therefore, user agents must take steps to > limit the risk of inadvertent location disclosure, even after > permission to share location has been granted by the user: > > > 1. User agents must inform the user when Web applications acquire > location information based on a consent granted previously. > > Example: A user agent shows a specific icon in the status bar when > the web application that the user currently interacts with has > acquired location information. > > 2. When location information is passed to a web application, a user > interface for revoking the relevant permissions must be easily and > obviously available. > > Example: By clicking on a status bar indicator for location > information, the user gets access to a dialogue that permits > revocation of the location authorization. > > 3. User agents should limit the scope of authorizations in time by > asking for re-authorization in certain intervals. As a general > guideline, authorizations related to location information should not > be considered valid for more than one week. Often, a shorter time will > be appropriate. > > </add> Thomas, I think these are very good proposals for privacy protection on the UI level. I personally think we should leave out specific examples of *how* this could be implemented in user agents, that should be left to the creativity of the implementors. I also agree with hixie that the "must"s in the first two requirements should be "should"s. Lars Erik
Received on Monday, 18 May 2009 21:34:13 UTC