- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 13 May 2009 19:24:09 +0200
- To: Rigo Wenning <rigo@w3.org>, Doug Turner <doug.turner@gmail.com>
- Cc: public-geolocation@w3.org
Rigo wrote: > Location is extremely sensitive data (think of crime, embarrassment > etc). Imagine for a second your preferred VIP being caught with a > partner other than the spouse thanks to this location information. > Imagine, this happens because the device was tracking location > invisibly. I would not want to get that heat from that story. To put some more meat to this discussion, here are some proposed edits for the "privacy considerations for implementors of the Geolocation API": > User Agents must not send location information to Web sites without > the express permission of the user. User Agents must acquire > permission through a user interface, unless they have prearranged > trust relationships with users, as described below. The user > interface must include the URI of the document origin Isn't that supposed to be the domain name part of the origin? http://lists.w3.org/Archives/Public/public-geolocation/2009Apr/0069.html > [DOCUMENTORIGIN]. Those permissions permissions Strike one instance of "permissions". > that are acquired through the user interface and that are preserved > beyond the current browsing session (i.e. beyond the time when the > browsing context [BROWSINGCONTEXT] is navigated to another URL) must > be revocable and User Agents must respect revoked permissions. <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> Now, as I said earlier, I'm not here to dive into detailed UI design; The key point is really to have a credible story about users' ability to control their location information *in* *the* *spec* (and preferably in code too -- but that's ultimately in the implementors' responsibility, as Rigo noted earlier today). > Some User Agents will have prearranged trust relationships that do > not require such user interfaces. For example, a Web browser will > present a user interface when a Web site performs a geolocation > request. However, a VOIP telephone may not present any user > interface when using location information to perform an E911 function. Additional points: - Add: "In some circumstances, use of sensor data (GPS, wireless networks, GSM/CDMA cell information) to acquire location data might be inappropriate. Conforming implementations of this specifications may use other mechanisms to acquire location data, including prompting users for location data that is then made available through the API specified here." - In the privacy considerations for recipients, replace "use of HTTPS is encouraged" by "use of encryption is encouraged" Regards, -- Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 13 May 2009 17:24:21 UTC