Re: Last call comments from GEOPRIV

Dear Alissa and Richard,

Thank you for your comments. We appreciate your spending time on 
reviewing the specification.

Your comments raise two main issues:
1. The lack of support for location formats (location semantics) other 
than geodetic location
2. The lack of privacy protection in the Geolocation API

With respect to the first issue, the working group has decided to 
postpone the inclusion of civic location to version 2 of the specification:
http://www.w3.org/2008/geolocation/track/issues/3

Regarding privacy protection in the Geolocation API:
As you are aware, the original and modified Geopriv proposals were 
extensively discussed over a period of several months before, during, 
and after the f2f meeting in December 2008. Both proposals met 
significant resistance in the working group and the decision was taken 
not to adopt either of them.

The discussions and conclusions were tracked here:
Should the Geolocation API include privacy information? : 
http://www.w3.org/2008/geolocation/track/issues/2
GEOPRIV WG proposal for privacy within the API : 
http://www.w3.org/2008/geolocation/track/issues/4

The fact that the working group decided not to adopt the Geopriv 
proposals does not mean that the group didn't manifest concerns about 
users' privacy. The intense discussions around this issue did contribute 
significantly to the wording of the privacy considerations section of 
the specification. The working group concluded that privacy protection 
does not belong in the Geolocation API itself, but is better handled as 
part of a more generic privacy and security framework for device access. 
The recently formed Device API and Policy Working Group is chartered to 
develop precisely such a framework 
(http://www.w3.org/2009/05/DeviceAPICharter).

Please acknowledge receipt of this email to public-geolocation@w3.org by 
November 12 2009.
In your acknowledgment please let us know whether or not you are 
satisfied with the working group's response to your comment.

On behalf of the W3C Geolocation Working Group,
Lars Erik Bolstad, Angel Machin


Alissa Cooper wrote:
> In response to a request from the chairs of the W3C Geolocation WG to 
> provide last call comments, we have reviewed the Geolocation API 
> specification in our roles as co-chairs of the IETF GEOPRIV working 
> group. Overall, we find that the API specification itself is 
> reasonably technically sound, but we have deep concerns that it lacks 
> stong privacy controls for geolocation information.
>
> By way of background, the GEOPRIV working group has developed a "tool 
> chain" for geolocation and privacy on the Internet.  This tool chain 
> includes a suite of protocols for configuring Internet hosts with 
> geolocation information (and transmitting it to other hosts) combined 
> with mechanisms for managing the privacy of that information.  In 
> principle, the Geolocation API should fit naturally into this tool 
> chain: A host that receives location information via GEOPRIV protocols 
> should be able to provide it to web sites via the Geolocation API, and 
> web sites that obtain geolocation via the API should be able to use it 
> in GEOPRIV protocols.
>
> It is in the interest of the Web (and the Internet more broadly) to 
> maintain consistency between the existing tool chain and the 
> Geolocation API, both technically and in terms of user experience.  
> There are two main gaps between the current draft Geolocation API and 
> the GEOPRIV tool chain: (1) the expressiveness of the API's location 
> semantics, and more critically, (2) the privacy protections that the 
> API makes available to users.  We believe the former has been 
> addressed to our satisfaction through discussions with the Geolocation 
> WG, but the current document is still deficient with respect to the 
> latter.
>
> With respect to location semantics, in developing protocols to carry 
> geolocation, GEOPRIV has been careful to maintain equal support for 
> three forms of location that are commonly used:
> 1. Location as a geometric object (geodetic location)
> 2. Location as an address (civic location)
> 3. Location as a URI (location by reference)
>
> Essentially all GEOPRIV protocols are able to convey location in all 
> three of these forms, making it likely that an HTTP UA will have 
> access to each form at some point.  On the other hand, the current 
> Geolocation API includes only geodetic location, in a very limited 
> form, so UAs will not be able to provide civic location or location by 
> reference via the API.  The Geolocation WG has agreed to explore the 
> inclusion of other forms of location in the second version of its API, 
> and we encourage the group to maintain that goal.  While we would have 
> liked to have seen support for these forms of location in the current 
> version of the API, we do not believe that at this stage of the 
> process, the lack of these extensions should delay the current API 
> specification.
>
> The issue that should not be delayed until the next version is the 
> need for the API to include privacy protections for the geolocation 
> information it provides.  Information about users' geolocation is 
> critically sensitive: its disclosure to unauthorized parties can 
> expose users to risks ranging from embarrassment to physical danger.  
> Geolocation information shared through the Geolocation API is at even 
> higher risk than other forms of personal information on the Web (e.g., 
> credit card numbers), because it is provided automatically to web 
> pages by the UA, and may not even require user intervention.  This 
> fact motivates the use of machine-readable privacy rules, and makes it 
> critical that the API explicitly incorporate user preferences.
>
> The IETF has for several years taken the approach of making privacy 
> policies a central part of geolocation standards. The protocols and 
> data formats produced by GEOPRIV help to protect location information 
> by ensuring that whenever location is transmitted, privacy policy 
> information is transmitted too. GEOPRIV standards allow users to 
> express their preferences about how their location information is 
> handled -- both in terms of which entities can receive it and in terms 
> of how those entities are permitted to use it. The framework includes 
> a standard format for conveying these preferences together with 
> location information (the Presence Information Data Format-Location 
> Object described in RFC 4119) and a lightweight policy language for 
> expressing privacy preferences.  The common framework allows for 
> interoperability along a chain of tools involved in geolocation 
> conveyance.
>
> This model differs from the paradigm for privacy protection that has 
> long prevailed on the Web -- mostly site-specific privacy warnings, 
> where users can either grant access to location (and accept all the 
> site's terms), or withhold location entirely. In contrast, the GEOPRIV 
> model empowers users to express their own privacy preferences to sites 
> with which they share their location.
>
> In order to provide sufficient privacy protections in this API, we 
> propose two changes to the current document:
>
> 1. To enable users to provide their privacy preferences to web sites, 
> a 'rules' object should be added as an attribute of the Position 
> object, in which the user can provide information about how the 
> recipient should use the location information in the Position object.  
> These rules should correspond to the PIDF-LO rules in RFC 4119, 
> including at a minimum constraints on retention and retransmission of 
> geolocation information.
>
> 2. At a minimum, UAs that receive privacy rules should be obligated to 
> apply those rules to location requests they receive in order to 
> determine whether the requests are authorized. For authorized 
> requests, UAs should use the 'rules' object to transmit rules to 
> location recipients. Ideally, UAs should also allow users to set rules 
> directly to control access to location from within the UA.
>
> GEOPRIV participants have submitted to the Geolocation WG two 
> documents that specify changes to the API that would accomplish these 
> goals:
> http://www.w3.org/2008/geolocation/drafts/API/spec-source-CDT.html
> http://geopriv.dreamhosters.com/w3c/spec-source-priv.html
>
> In conclusion, we support the Geolocation WG's efforts to enable the 
> Web to be location-aware, but we have strong reservations about the 
> current approach to privacy.  We hope that the group will follow 
> through on the goal of maintaining compatibility between location 
> formats within the geolocation tool chain, and we urge the group to 
> enable the API to provide strong privacy protections for geolocation 
> information. The GEOPRIV WG will be glad to provide any help we can in 
> harmonizing the W3C Geolocation API with the broader Internet tool 
> chain for geolocation information.
>
> Richard Barnes and Alissa Cooper
> GEOPRIV Co-Chairs
>
>
>
>
>
>
>

Received on Wednesday, 28 October 2009 22:21:19 UTC