Re: Additional security and privacy considerations?

Thomas and Rigo, thanks for getting this discussion going. The goals  
of ensuring that users have the ability to revoke location permissions  
and have the ability to know when their location is being shared are  
certainly worth pursuing in my opinion.

I would be remiss to not point out the link between this discussion  
and some of the discussions the WG had back in the fall. Thomas  
suggested the following:

> 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.

In the fall we discussed having the user indicate to the web  
application how long he wants to have his location information  
retained. It seems to me that if it's a good idea for authorizations  
for location collection to be time-limited, it should correspondingly  
be a good idea for the user to be able to indicate that location  
retention should be time-limited. In the example that Thomas gave in  
his original email in this thread, the user is motivated to de- 
authorize a location-based service at some point, perhaps after  
realizing that the service is actually able to track him over time.  
But the current spec is mute about how that de-authorization affects  
previously collected location (if it has any affect). Had the user  
been able to indicate from the outset that he only wanted his location  
retained for a day or a week, he could both de-authorize prospective  
collection and have some greater chance that location collected  
retrospectively had been deleted. This would address the privacy risk  
from both directions, and if we're talking about one it seems sensible  
to talk about the other.

Alissa

On May 13, 2009, at 1:24 PM, Thomas Roessler wrote:

> 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 18:51:20 UTC