Re: Additional security and privacy considerations?

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