W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2009

Re: Last call comments from GEOPRIV

From: Alissa Cooper <acooper@cdt.org>
Date: Wed, 11 Nov 2009 21:39:11 +0900
Cc: Richard Barnes <rbarnes@bbn.com>, public-geolocation Group WG <public-geolocation@w3.org>
Message-Id: <B87C9D43-08F2-4620-8128-6361C02DD7F8@cdt.org>
To: Lars Erik Bolstad <lbolstad@opera.com>
Dear Lars Erik,

Thank you for responding to our comments.   While we continue to  
disagree with the technical decisions of the WG (especially with  
regard to privacy), we understand that you have reached the end of the  
W3C process for addressing our concerns.

Richard Barnes and Alissa Cooper

On Oct 29, 2009, at 7:20 AM, Lars Erik Bolstad wrote:

> 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, 11 November 2009 12:40:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:56 UTC