RE: geolocation update

I'm still not clear, even after your message, about how the GeoPriv and GeoLocation use cases are so significantly different.

Why would a  "policy authorization interface" be any more difficult for GeoLocation than it is for IETF GeoPriv? And won't almost all the devices supporting GeoLocation APIs also support GeoPriv services? Are there any examples of devices that wouldn't have both?

Is the scope of the GeoLocation API explicitly limited to only be applicable to the where they are only ever used for "the user controlled piece of a browser"? I understand that the GeoLocation use cases are more limited, but unless the domain of applicability is clearly limited, shouldn't the security and privacy requirements address all of the likely uses, and not just the scenarios illustrated by use cases? Wouldn't the same API also be used for devices and services that are not the "user controlled piece of a browser"?  

Larry
-- 
http://larry.masinter.net


-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Thomas Roessler
Sent: Saturday, June 13, 2009 2:29 AM
To: www-tag@w3.org
Cc: Matt Womer; Rigo Wenning
Subject: geolocation update

Copying Matt Womer, who serves as Team Contact on the geolocation WG.
   http://www.w3.org/2008/geolocation/

The TAG had asked for a quick update on the geolocation situation.


1. There was a liaison statement from the IETF concerning priacy and  
security concerns with the geolocation specification.  Part of these  
concerns was the lack of integration of the IETF's geopriv  
specification.


2. The geopriv specification is mostly motivated by emergency calling  
use cases:  E.g., a DHCP server on a local network indicates where  
that network is physically located, a VOIP device picks up on the  
location data, and might then include the location information as  
metadata as calls are made.  The geopriv specification enables the  
DHCP server to add basic policy information to the location data, in  
particular whether the location information can be forwarded to third  
parties, and how long it might be stored.

You'll notice that the use case is conspicuously different from the  
geolocation API's:  The API is designed to sit right on a trust  
boundary, between the user controlled piece of a browser, and the web  
application that wants to consume the location data.  Therefore, the  
Working group chose to build its security considerations on user  
authorization:

> 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  
> [DOCUMENTORIGIN]. Those 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.


There are additional explicit considerations for the recipients of  
location information, which ask for further user consent whenever data  
are passed on.

In December 2008, the Working Group considered a closer coupling to  
the geopriv WG's design, and rejected it, on the basis that it would  
require user agent implementers to include policy authoring UI (which  
is known to be a chronically difficult problem in user facing  
situations), in a situation in which the Web application in question  
can actually ask for user consent easily and directly (it's a web  
application, after all!).  Input from the geopriv WG was further  
considered at the W3C device API workshop (also in December 2008,  
actually held in the same room as the WG meeting, just a day later).   
Among those in the room, there seemed to be relatively little interest  
in picking up on the geopriv WG's design for the purposes of this API.

There were numerous other times the proposals were considered as well,  
both off and on-list; most recently last week.


3. Over the last month or so, some in the Team (largely Matt, Rigo and  
I) have reached out to various participants in the IETF, and discussed  
the difference in scenario between the geopriv WG's use cases and the  
use cases that are in scope for the geolocation WG.  Additionally, the  
WG has sent a formal answer to the liaison note, explaining some of  
the steps above, and noting that the WG has decided to not build its  
specification on the product of the geopriv Working Group.

We've also advocated for more extensive security and privacy  
considerations, to cover some situations in which the current  
specification material might lead to insufficient protection (based,  
e.g., upon user error).  The Working Group is apparently going to  
include some of that material in the specification.  We specifically  
haven't pushed for any changes to the API signatures.

The remaining contention is whether to call out relatively specific  
mitigation patterns in the specification; the WG seems disinclined.


At this point, I suspect that the place where related architectural  
issues will come up is going to be the device API Working Group.   
Issues are likely to include what shape and form a policy expression  
language should take, and what deviations from the existing browser  
security model are acceptable (a proposal that might help to mitigate  
some threat scenarios is to only permit "dangerous" APIs from top- 
level frames)

Hope this helps,
--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Sunday, 21 June 2009 01:07:27 UTC