W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2010

Re: Response to Last call comments from CDT

From: Matt Womer <mdw@w3.org>
Date: Fri, 5 Mar 2010 10:17:03 -0600
Message-Id: <3E25DBEA-9296-4BE9-96F1-6434E4856BE1@w3.org>
To: John Morris <jmorris@cdt.org>
Cc: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation <public-geolocation@w3.org>, "Angel (amachin) Machin" <angel.machin@vodafone.com>
Hi John,

I am sure others will have things to say on your comments, but with  
regard to the Team, Director and process questions, I'll get back to  
you after I get feedback from some others.

Thanks,

-Matt Womer

On Mar 3, 2010, at 2:48 PM, John Morris <jmorris@cdt.org> wrote:

> To follow up on CDT’s last call comments and the WG chairs’  
> response to them, let me first apologize for my great delay in respo 
> nding.  It was not my intention to stall the process at all, but unf 
> ortunately I have been overwhelmed by other commitments.
>
> In responding to our last call comments, the chairs ask whether we  
> are “satisfied with the working group's response to your  
> comment.”  The short answers are “yes” with regard to our  
> comment 1.2, and “no” with regard to our comments 1.1., 2.1, and  
> 2.2.
>
> As I understand the W3C process, we could appeal the disposition of  
> these comments to the Director, which would in turn delay the final  
> publication of the 1.0 version of the specification.  I am hopeful  
> that the W3C team will allow a deviation from this normal sequence,  
> as explained below.
>
> I do believe that both the process and the substantive result of  
> this WG are something that the Director, and the W3C as a whole,  
> should carefully evaluate.  I believe that the process was deeply  
> flawed, and that the substantive result represents a missed  
> opportunity for the W3C to live up to the high standards that it  
> previously sought to achieve.
>
> But, at this point, it seems completely pointless for the W3C to  
> delay the publication of the 1.0 version of the specification.  The  
> browser makers long ago deployed their implementations of the  
> specification, and much of the WG effort was essentially to “standar 
> dize” functionality they had already decided upon.  Moreover, the ma 
> ker of one of the world’s most popular mobile devices made crystal c 
> lear in WG discussions that it had little intention of conforming it 
> s technical offerings to the final W3C specification if the spec dev 
> iated from what that maker was already doing.[1]  In light of that a 
> pproach to the WG output, there seems little point to delay issuing  
> the 1.0 version of the spec.
>
> Thus, to be clear, we think that the W3C should proceed to finalize  
> the 1.0 version of the specification.  But – and here is where we ho 
> pe the W3C Team will accommodate a variation on the normal process – 
>  we believe that the W3C Director should ALSO carefully review and e 
> valuate the objections we have raised.  Our goal is not to delay the 
>  specification, but instead is to seek guidance from the W3C as to w 
> hether both the process and substantive output of this WG meet the c 
> urrent standards of the W3C.  If they do – and they may well –  
> then that guidance would factor into my organization’s evaluation of 
>  its continued involvement in the W3C.
>
> Director review would also, I think, be constructive because (as the  
> chairs note in their response to our LC comments), in the view of  
> this WG, privacy protections were omitted from the Geolocation API  
> itself and were deferred to the more generic privacy and security  
> framework that the Device API WG was (in part) chartered to  
> address.  I think that the DAP effort would benefit from the W3C’s b 
> roader assessment of the outcome of this group.  Already some over i 
> n the Device API WG are saying that “it was already decided in Geolo 
> cation that we can/should not do privacy” in a certain manner, and i 
> t would be helpful to know if the Team agrees with those assertions.
>
> In case there is to be further review of the process and output of  
> this WG by the Director or others, let me briefly recap and somewhat  
> expand on the concerns we raised.  (I have also pasted below our  
> full original LC comments, followed by the chairs’ full response.)
>
> On process:  In our LC comments, we raised three process concerns,  
> but only requested a response from the chairs on the third, relating  
> to intellectual property commitments.  On the IP issues, we disagree  
> with the chairs’ dismissal of our concerns, but at the end of the da 
> y, my organization neither has a patent portfolio nor is deploying p 
> roducts that implement the spec – and the IP and Patent Policy probl 
> ems that emerged in this group are not a key focus of our work.  If  
> other W3C members who either do have a portfolio or who will face IP 
>  risk are not concerned about the process and output of this WG, the 
> n we will defer to them.
>
> The primary other process problems that we raised – that the WG was  
> intent on standardizing what was already deployed, and that the WG f 
> ailed to fulfill its charter requirement that it address privacy in  
> the design of the API itself – should concern the W3C more broadly.  
>  When this WG was first proposed, there was concern expressed on the 
>  Advisory Committee list that it was important that privacy be a cen 
> tral focus of the WG, and the AC was assured that that would happen. 
>   Privacy, however, was an afterthought.  The majority of the spec w 
> as developed before the first word on privacy was drafted.  The API  
> itself is totally silent on privacy, and although the privacy sectio 
> n ended up with good language, the exhortations in the spec have not 
>  translated into meaningful privacy protection for users (as discuss 
> ed below).  If the process this WG followed is the new W3C norm, the 
> n the value of participating in W3C groups drops dramatically, at le 
> ast for my organization.
>
> On privacy:  It is broadly accepted that the privacy-policy-based  
> approach to privacy on the Web has not protected users’ privacy.[2]  
>  When websites disclose what they do with users’ information buried  
> in a lengthy document of fine print, no real notice happens, and no  
> real consent is given.   When in 2008 the W3C undertook to enable th 
> e distribution of potentially highly sensitive data – one’s  
> physical location – it had a choice: to either simply rely on websit 
> e privacy policies, or to attempt to address privacy in the design o 
> f the W3C API itself.  Although we believe that the charter of the G 
> eolocation WG called on the WG to undertake the latter approach, the 
>  WG rejected two proposals that would have done that, and instead ad 
> opted a spec that relies largely on the privacy policy approach.  Th 
> e spec does include some very good, strong language about privacy, b 
> ut much of the language is essentially an exhortation to websites to 
>  respect privacy.
>
> Initial academic research, however, reveals that almost all websites  
> implementing the W3C Geolocation API are largely ignoring the  
> exhortations in the spec, and are providing little (if any) notice  
> or control to users regarding information about the users’ locations 
> .[3] Likewise, UAs implementing the spec are not doing so with the r 
> obust sorts of user controls that sensitive location information dem 
> ands.[4] Thus, at the end of the day, the specification is contribut 
> ing to the privacy problem, and is failing to be part of the solutio 
> n.  The academic analysis at [3] provides a good overview of the WG’ 
> s efforts and missed opportunities to address and improve the privac 
> y situation on the web.
>
> Going forward, [3] suggest some possible ways that the Geolocation  
> API could be improved in a “v2” version, and notes the  
> possibility that the Device API and Policy WG could take steps to ad 
> dress the privacy problems on the Web.  We support these ideas, but  
> ultimately and more broadly, the W3C needs to decide whether it want 
> s to move the ball forward for privacy on the Web, or whether it wan 
> ts to reinforce the inadequate status quo.  Historically, of course, 
>  the W3C has been a leader in seeking to craft technological approac 
> hes to social policy issues, but the Geolocation WG was a missed opp 
> ortunity to continue that leadership.  The Device API WG may present 
>  a second chance.
>
> We believe that the W3C should consider carefully whether it is  
> interested, willing, and able to assume a leadership position in the  
> effort to protect privacy on the web.  We are hopeful that – even th 
> ough we are not asking the Director to delay publication of the Geol 
> ocation specification – that the W3C will carefully consider the iss 
> ues raised here (and more fully discussed below in our original LC c 
> omments).
>
> John Morris
> CDT
>
> [1] http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0106.html 
> .
> [2] http://www.nytimes.com/2010/02/28/technology/internet/28unbox.html
> [3] http://www.escholarship.org/uc/item/0rp834wf?display=all
> [4] http://www.cdt.org/blogs/alissa-cooper/dawn-location-enabled-web
>
> ============
> Original last call comments:
>
>> CDT has been actively involved in the geolocation working group,  
>> and appreciates the group’s hard work on this specification. Our l 
>> ast call comments address two topics --  privacy and process -- ra 
>> ising two issues on each of these two topics.
>>
>> 1.  Privacy
>>
>> According to its charter, the objective of this working group was  
>> "to define a secure and privacy-sensitive interface for using  
>> client-side location information in location-aware Web  
>> applications."  Although we appreciate that the security and  
>> privacy considerations section of the specification is greatly  
>> improved from early proposed text, we believe that the charter  
>> called on the WG to build privacy-protecting features into the  
>> specification itself, rather than simply include instructions and  
>> requirements to be followed by implementors.  The WG has failed to  
>> meet this charter requirement.
>>
>> By not actually building privacy into the specification, the W3C  
>> has both missed a significant opportunity to improve user privacy  
>> on the Web, and it has harmed the efforts of another standards body  
>> -- the IETF -- to protect location privacy and to improve the  
>> privacy paradigm for Internet services.
>>
>> On privacy, we set out below two questions for last call -- the  
>> question of the adoption of the IETF Geopriv standard, and a  
>> question seeking confirmation of our understanding of the privacy  
>> considerations in the specification.
>>
>> On the first question, we of course appreciate that the Geopriv  
>> proposal has been much discussed within the WG, and that the WG has  
>> rejected a number of proposals that would bring the W3C API into  
>> compliance with Geopriv. Although we believe that the W3C is making  
>> a serious mistake in this regard, we realize that this WG will not  
>> reconsider its decisions at this stage of the process.
>>
>> 1.1.  Geopriv
>>
>> There is broad consensus in the privacy community (and most  
>> observers outside of this WG) that the prevailing web privacy  
>> paradigm does not adequately protect web users.  All of the power  
>> and authority lies with the website or service provider, and users  
>> are offered privacy policies on a take-it-or-leave-it basis.  In  
>> 2001, the IETF decided to alter that relationship for a  
>> particularly sensitive type of information -- location information  
>> -- and it created its Geopriv working group.  That group produced  
>> the Geopriv specifications that give users the ability to set rules  
>> about the use of information about their location.
>>
>> The WG has discussed and considered Geopriv extensively, and we  
>> will not attempt in this document to revisit all of the features  
>> and advantages of that approach.  We believe, however, that the WG  
>> has made a serious mistake in not adopting either of two Geopriv- 
>> compatible approaches. We will only briefly summarize our  
>> objections here.
>>
>> Geopriv provides a suite of protocols for the conveyance of both  
>> location information and privacy rules applicable to the  
>> information.  It is designed to provide a privacy framework that  
>> can be implemented in a broad range of protocols and applications,  
>> and the IETF has, for example, standardized the expression of  
>> Geopriv location objects using XML.  The key Geopriv documents are  
>> available here.[1]  A recently released broad overview of the  
>> Geopriv architecture is available in draft here.[2]  Geopriv also  
>> includes a robust capability to express civic locations (e.g.,  
>> street addresses), which the IETF has developed with extensive  
>> effort over the past eight years.
>>
>> The core privacy requirement in the Geopriv effort is that any  
>> piece of location information MUST be inextricably bound together  
>> with the privacy rules that apply to the location information.   
>> Thus, for example, the same object that carries location also must  
>> carry rules about (a) how long the location info can be retained,  
>> and (b) whether it can be retransmitted.  The critical value of  
>> this binding of location to privacy rules is that no recipient of  
>> the location information can claim to “not know” that the  
>> information is covered by rules.  By forcing the user’s  
>> “expectation of privacy” to be conveyed along with the location  
>> information, Geopriv greatly increases the likelihood that the pri 
>> vacy expectation will be honored, and it creates an opportunity fo 
>> r legal forces (such as data protection commissioners or, in the U 
>> .S., the Federal Trade Commission) to bring legal actions against  
>> entities that do not adhere to users’ privacy instructions.
>>
>> This approach is the opposite from how things have “always” been  
>> on the Web -- and as such, it would be a game-changer in terms of  
>> privacy.  By empowering users to specify rules to govern the use o 
>> f their information, the Geopriv approach -- if adopted by the W3C 
>>  -- would begin a long overdue realignment of power on the Web, an 
>> d would appropriately place users in greater control over their in 
>> formation.  Although the Geopriv approach does not by itself (usin 
>> g technical means) force recipients to honor users’ privacy rules, 
>>  both market and legal forces would be able to react strongly to t 
>> hose who violate users’ rules.
>>
>> Proponents of the Geopriv approach presented two separate Geopriv- 
>> compliant versions of the Geolocation API. Prior to the London face- 
>> to-face meeting in December 2008, we submitted a version that fully  
>> implemented Geopriv.[3]  In the API itself, Geopriv would only  
>> require a few additional fields of data (but it would require the  
>> user agent to obtain privacy instructions from users).  Earlier  
>> this year, Geopriv co-chair Richard Barnes submitted a revised  
>> version[4] that could be adopted without requiring UAs to alter  
>> their existing deployed products.  Both were rejected by the WG.
>>
>> As noted, we do not expect the WG to change its position on Geopriv  
>> at this stage of the process, but as a formal matter on last call  
>> we request that the group adopt the Geopriv implementation  
>> submitted in Fall 2008, or failing that, the implementation  
>> submitted in Spring 2009.
>>
>> 1.2  Current security and privacy considerations
>>
>> In our view, the geolocation API provides a substantial set of  
>> normative requirements for both implementors of the API and Web  
>> sites that use the API to access location.  Although we obviously  
>> prefer the Geopriv approach discussed above, we appreciate the  
>> privacy requirements set out in the current specification.  In this  
>> last call comment, we seek to confirm that our understanding of the  
>> requirements is correct.
>>
>> We assume that if either an implementor of the API or a Web site  
>> using the API were to violate one of the privacy requirements set  
>> out in the specification, the implementation or Web site would be  
>> considered “non-conformant.”  In other words, our understanding  
>> is that the specification imposes normative privacy requirements o 
>> n recipients of location information, and a failure to comply with 
>>  those requirements means that the recipient is not in conformance 
>>  with the specification. If this is the understanding that the wor 
>> king group has of conformance, we would like the group to confirm  
>> that. If not, we would like to know what the group’s understanding 
>>  is and why.
>>
>> In addition, the security and privacy considerations section  
>> describes three separate instances that require the “express permi 
>> ssion” of the user: sending location information to Web sites, ret 
>> aining location information longer than is needed for the task for 
>>  which it was collected, and retransmitting location information.  
>> It is our view that the “express permission” requirement means  
>> that the user would need to take an affirmative action (click a bu 
>> tton or accept a dialog box, for example) in order for a Web site  
>> to be able to take any of these three actions in conformance with  
>> this specification. Merely visiting a Web site that discloses its  
>> intent to take any of these three actions, without soliciting affi 
>> rmative consent from the user, would not suffice to meet the requi 
>> rement of “express permission.”
>>
>> If our understanding of how to interpret the “express  
>> permission” requirements matches the working group’s  
>> understanding, we would like to have that confirmed by the group.  
>> If the working group’s understanding is different, we would like t 
>> o know how it differs and why.
>>
>> 2.  Process
>>
>> The specification advanced to last call by this WG was originally  
>> developed outside of the W3C prior to the formation of this working  
>> group.  This has created a number of serious issues and  
>> frustrations within the WG’s efforts, including:
>>
>> -- the WG was extremely resistant to any changes to the pre- 
>> existing API, and WG members argued repeatedly on the mailing list  
>> against changes to the API because such changes would deviate from  
>> implementations already deployed in the field.
>>
>> -- because of the overriding focus on having the W3C adopt a  
>> standard that was consistent with previously developed and deployed  
>> technology, the WG did not use the W3C WG charter as a guiding  
>> document, and thus failed to meet the requirement that it build an  
>> API that directly addressed privacy.
>>
>> -- prior and current contributors to the specification have not  
>> joined the working group or made the required W3C IPR commitments,  
>> creating significant intellectual property concerns.
>>
>> Although we believe that the first two of these problems should  
>> concern all W3C members, there is nothing the WG can do at this  
>> time (short of starting over) to address these concerns.  Our last  
>> call comments relating to process focus on the third point, and  
>> raise two specific IPR-related issues.  We raised these concerns  
>> informally prior to submitting these last call comments, and we  
>> understand there have been some efforts to resolve the issues we  
>> raise below.
>>
>> 2.1  Spec author not joining the WG
>>
>> It appears as though the original version of the specification was  
>> written prior to the formation of the WG, but that at least one of  
>> its principal authors, Skyhook Wireless, never joined the WG or  
>> made any non-member IPR commitments. The CEO of Skyhook, in an  
>> article published this month, flatly asserted that his company  
>> wrote the initial API. According to Ted Morgan, the “reason Skyhoo 
>> k is familiar with the [W3C] spec is that we actually wrote it, th 
>> e original one. We have been pushing this for years.”[5]  The dire 
>> ct involvement of Skyhook in the API development has also been con 
>> firmed within the W3C WG process.  At the face-to-face meeting in  
>> December 2008, for example, it was mentioned that certain features 
>>  had been removed from a prior version of specification at the req 
>> uest of Skyhook (see the face-to-face minutes[6] documenting a par 
>> ticipant describing how “we had reverse geo in the first version o 
>> f the spec, but forgot to take out the use case ... we took it out 
>>  due to pushback from skyhook”). However, Skyhook never joined the 
>>  group (and is not a W3C member), leaving open the possibility for 
>>  Skyhook to pursue intellectual property infringement actions agai 
>> nst any implementors of this specification in the future (includin 
>> g web sites that utilize the API), and potentially threatening the 
>>  W3C’s ability to publish the geolocation specification as a Recom 
>> mendation on a viable Royalty-Free basis.[7]
>>
>> We request that the working group address this situation before  
>> moving to the Candidate Recommendation stage. Given Skyhook’s cont 
>> ributions, the working group should explain how the specification  
>> could be issued as a Recommendation on a Royalty-Free basis and wh 
>> at shields implementors from potential infringement liability.
>>
>> 2.2  Spec contributor not joining the WG
>>
>> It is standard practice for W3C members to make IPR commitments as  
>> required by the W3C Patent Policy when they join a WG. Apple has  
>> been an active member in this working group (and may have been  
>> involved in the pre-W3C development of the API). However, as the  
>> chairs noted in June, Apple has not agreed to the same intellectual  
>> property commitments as the rest of the group members. The chairs  
>> decided that Apple’s contributions were not “significant”  
>> enough to require it to make the IPR commitments, noting that many 
>>  of its contributions were “suggestions” or “opinions.”[8]   
>> However, the chairs’ analysis failed to describe the effects that  
>> those suggestions and opinions have ultimately had on the API. Con 
>> trary to the chairs’ conclusion, Apple’s participation in fact  
>> had a quite significant impact on the outcome of the specification.
>>
>> Within the WG process, Apple repeatedly advocated for and against  
>> certain aspects of the API, and in several instances its arguments  
>> resulted in alterations being made (or not made) to the  
>> specification. For example, Apple advocated for the use of a native  
>> geolocation API,[9] in favor of an error code which was later  
>> incorporated,[10] in support of civic location,[11] and -- most  
>> importantly to us -- against addressing privacy in the  
>> specification.[12] On numerous occasions, Apple also cited its own  
>> Webkit code as evidence for why the geolocation API should or  
>> should not incorporate a particular feature.[13] Moreover, Apple  
>> used the popularity of the iPhone as a threat against the API.  
>> Apple suggested that if the API were to differ from Apple’s existi 
>> ng geolocation implementation, users of the API would suffer from  
>> the discrepancy, and conversely that the group’s decision to match 
>>  the API to Apple’s implementation would lend particular credence  
>> to the API.[14] A holistic assessment of Apple’s contributions --  
>> including both features that were incorporated into the specificat 
>> ion and those that were not, based on Apple’s advocacy -- shows th 
>> at they were indeed “significant.”
>>
>> The direct impact that Apple’s WG participation had on the API is  
>> inconsistent with its refusal to become a group member.  Apple’s p 
>> articipation in the WG is particularly inappropriate in light of t 
>> he fact that at least one W3C member -- a company that for the pas 
>> t eight years has been an active participant in the IETF Geopriv a 
>> nd related working groups -- stayed out of the W3C WG because (as  
>> we understand it) it was unable to make the intellectual property  
>> commitments required to be a WG participant.  Thus, a company stee 
>> ped in Geopriv stayed out of the WG because of IPR concerns, while 
>>  at the same time Apple participated in the WG process, spoke stro 
>> ngly against using Geopriv, and then declined to join the WG becau 
>> se of IP concerns.  Under the W3C’s IPR rules, a WG cannot allow a 
>>  W3C Member to significantly influence a WG product without making 
>>  the necessary intellectual property commitments, while at the sam 
>> e time those rules keep other W3C members out of the WG.
>>
>> We request that the working group rectify this situation before  
>> moving to the Candidate Recommendation stage. The chairs’ conclusi 
>> on that Apple’s contributions have not been “significant” is  
>> not supported by the record of Apple’s participation in the WG.  A 
>> ll active participants must join the group and make the normal IPR 
>>  commitments of group members.
>>
>> 3.  Conclusion
>>
>> We believe that all of the above last call comments are generally  
>> related.  The API was initially developed outside of the W3C  
>> process (leading to the issue discussed in 2.1 above), and then  
>> within the WG the leading contributors were extremely focused on  
>> quickly standardizing the existing API. This caused the group to  
>> resist making significant changes, including those such as the  
>> Geopriv proposals that would have allowed the API to best comply  
>> with the charter requirement that it be “privacy-sensitive.”  We  
>> understand that the WG will not at this time go back and meet this 
>>  charter requirement, but we do seek confirmation of our understan 
>> ding of the privacy requirements that are in the API.  We also bel 
>> ieve that the IPR issues must be resolved before the specification 
>>  progresses.
>>
>> [I have limited connectivity over the next week, and so will be  
>> slow in responding to discussions on the list.]
>>
>> John Morris
>>
>> [1] http://www.ietf.org/html.charters/geopriv-charter.html.
>>
>> [2] http://tools.ietf.org/html/draft-ietf-geopriv-arch-00 (this  
>> document is a work in progress).
>>
>> [3] http://www.w3.org/2008/geolocation/drafts/API/spec-source- 
>> CDT.html
>>
>> [4] http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0098.html
>>
>> [5] “The Browser Geolocation Wars: Skyhook’s CEO on Why Google  
>> Maps is Misreading Your Location,” Xconomy, July 10, 2009, http://www.xconomy.com/boston/2009/07/10/the-browser-geolocation-wars-skyhooks-ceo-on-why-google-maps-is-misreading-your-locatio 
>> n/.
>>
>> [6] http://www.w3.org/2008/12/08-geolocation-minutes
>>
>> [7] http://www.w3.org/Consortium/Patent-Policy-20040205/
>>
>> [8] http://lists.w3.org/Archives/Member/member-geolocation/2009Jun/0000.html
>>
>> [9] http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0011.html
>>
>> [10] http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0088.html
>>
>> [11] http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0113.html
>>
>> [12] http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0004.html;http://lists.w3.org/Archives/Public/public-geolocation/2009May/0078.html
>>
>> [13] About error codes: http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0088.html,http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0096.html 
>> ; About lastPosition:http://lists.w3.org/Archives/Public/public- 
>> geolocation/2008Nov/0151.html;
>>
>> [14] http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0106.html;http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0025.html 
>> ;
>
>
> ============
> Response to last call comments:
>
> On Oct 28, 2009, at 6:30 PM, Lars Erik Bolstad wrote:
>
>> Dear John,
>>
>> Thank you for your comments. We appreciate your spending time on  
>> reviewing the specification.
>> Please find our detailed responses to your comments below.
>>
>> 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
>>
>>
>> John Morris wrote:
>>> CDT has been actively involved in the geolocation working group,  
>>> and appreciates the group’s hard work on this specification. Our 
>>>  last call comments address two topics -- privacy and process -- 
>>>  raising two issues on each of these two topics.
>>>
>>> 1. Privacy
>>>
>>> According to its charter, the objective of this working group was  
>>> "to define a secure and privacy-sensitive interface for using  
>>> client-side location information in location-aware Web  
>>> applications." Although we appreciate that the security and  
>>> privacy considerations section of the specification is greatly  
>>> improved from early proposed text, we believe that the charter  
>>> called on the WG to build privacy-protecting features into the  
>>> specification itself, rather than simply include instructions and  
>>> requirements to be followed by implementors. The WG has failed to  
>>> meet this charter requirement.
>>>
>>> By not actually building privacy into the specification, the W3C  
>>> has both missed a significant opportunity to improve user privacy  
>>> on the Web, and it has harmed the efforts of another standards  
>>> body -- the IETF -- to protect location privacy and to improve the  
>>> privacy paradigm for Internet services.
>>>
>>> On privacy, we set out below two questions for last call -- the  
>>> question of the adoption of the IETF Geopriv standard, and a  
>>> question seeking confirmation of our understanding of the privacy  
>>> considerations in the specification.
>>>
>>> On the first question, we of course appreciate that the Geopriv  
>>> proposal has been much discussed within the WG, and that the WG  
>>> has rejected a number of proposals that would bring the W3C API  
>>> into compliance with Geopriv. Although we believe that the W3C is  
>>> making a serious mistake in this regard, we realize that this WG  
>>> will not reconsider its decisions at this stage of the process.
>>>
>>> 1.1. Geopriv
>>>
>>> There is broad consensus in the privacy community (and most  
>>> observers outside of this WG) that the prevailing web privacy  
>>> paradigm does not adequately protect web users. All of the power  
>>> and authority lies with the website or service provider, and users  
>>> are offered privacy policies on a take-it-or-leave-it basis. In  
>>> 2001, the IETF decided to alter that relationship for a  
>>> particularly sensitive type of information -- location information  
>>> -- and it created its Geopriv working group. That group produced  
>>> the Geopriv specifications that give users the ability to set  
>>> rules about the use of information about their location.
>>>
>>> The WG has discussed and considered Geopriv extensively, and we  
>>> will not attempt in this document to revisit all of the features  
>>> and advantages of that approach. We believe, however, that the WG  
>>> has made a serious mistake in not adopting either of two Geopriv- 
>>> compatible approaches. We will only briefly summarize our  
>>> objections here.
>>>
>>> Geopriv provides a suite of protocols for the conveyance of both  
>>> location information and privacy rules applicable to the  
>>> information. It is designed to provide a privacy framework that  
>>> can be implemented in a broad range of protocols and applications,  
>>> and the IETF has, for example, standardized the expression of  
>>> Geopriv location objects using XML. The key Geopriv documents are  
>>> available here.[1] A recently released broad overview of the  
>>> Geopriv architecture is available in draft here.[2] Geopriv also  
>>> includes a robust capability to express civic locations (e.g.,  
>>> street addresses), which the IETF has developed with extensive  
>>> effort over the past eight years.
>>>
>>> The core privacy requirement in the Geopriv effort is that any  
>>> piece of location information MUST be inextricably bound together  
>>> with the privacy rules that apply to the location information.  
>>> Thus, for example, the same object that carries location also must  
>>> carry rules about (a) how long the location info can be retained,  
>>> and (b) whether it can be retransmitted. The critical value of  
>>> this binding of location to privacy rules is that no recipient of  
>>> the location information can claim to “not know” that the inform 
>>> ation is covered by rules. By forcing the user’s “expectation of 
>>>  privacy” to be conveyed along with the location information, Ge 
>>> opriv greatly increases the likelihood that the privacy expectat 
>>> ion will be honored, and it creates an opportunity for legal for 
>>> ces (such as data protection commissioners or, in the U.S., the  
>>> Federal Trade Commission) to bring legal actions against entitie 
>>> s that do not adhere to users’ privacy instructions.
>>>
>>> This approach is the opposite from how things have “always” been 
>>>  on the Web -- and as such, it would be a game-changer in terms  
>>> of privacy. By empowering users to specify rules to govern the u 
>>> se of their information, the Geopriv approach -- if adopted by t 
>>> he W3C -- would begin a long overdue realignment of power on the 
>>>  Web, and would appropriately place users in greater control ove 
>>> r their information. Although the Geopriv approach does not by i 
>>> tself (using technical means) force recipients to honor users’ p 
>>> rivacy rules, both market and legal forces would be able to reac 
>>> t strongly to those who violate users’ rules.
>>>
>>> Proponents of the Geopriv approach presented two separate Geopriv- 
>>> compliant versions of the Geolocation API. Prior to the London  
>>> face-to-face meeting in December 2008, we submitted a version that  
>>> fully implemented Geopriv.[3] In the API itself, Geopriv would  
>>> only require a few additional fields of data (but it would require  
>>> the user agent to obtain privacy instructions from users). Earlier  
>>> this year, Geopriv co-chair Richard Barnes submitted a revised  
>>> version[4] that could be adopted without requiring UAs to alter  
>>> their existing deployed products. Both were rejected by the WG.
>>>
>>> As noted, we do not expect the WG to change its position on  
>>> Geopriv at this stage of the process, but as a formal matter on  
>>> last call we request that the group adopt the Geopriv  
>>> implementation submitted in Fall 2008, or failing that, the  
>>> implementation submitted in Spring 2009.
>>
>>
>>
>> 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 
>> ).
>>
>>
>>
>>>
>>> 1.2 Current security and privacy considerations
>>>
>>> In our view, the geolocation API provides a substantial set of  
>>> normative requirements for both implementors of the API and Web  
>>> sites that use the API to access location. Although we obviously  
>>> prefer the Geopriv approach discussed above, we appreciate the  
>>> privacy requirements set out in the current specification. In this  
>>> last call comment, we seek to confirm that our understanding of  
>>> the requirements is correct.
>>>
>>> We assume that if either an implementor of the API or a Web site  
>>> using the API were to violate one of the privacy requirements set  
>>> out in the specification, the implementation or Web site would be  
>>> considered “non-conformant.” In other words, our understanding i 
>>> s that the specification imposes normative privacy requirements  
>>> on recipients of location information, and a failure to comply w 
>>> ith those requirements means that the recipient is not in confor 
>>> mance with the specification. If this is the understanding that  
>>> the working group has of conformance, we would like the group to 
>>>  confirm that. If not, we would like to know what the group’s un 
>>> derstanding is and why.
>>
>>
>>
>> Yes, that is correct. The group decided that the privacy  
>> considerations both for implementors of the API and for recipients  
>> be made normative. In order to be conformant with this  
>> specification a web site must comply with the privacy  
>> considerations under section 4.2.
>>
>> In order for a UA to be conformant with the specification, the  
>> "express permission" of the user needs to take the form of an  
>> *affirmative action* on the part of the user (active consent)  
>> before location data are transmitted, when location data are  
>> retained for longer than "needed", and before retransmitting  
>> location data.
>>
>>
>>>
>>> In addition, the security and privacy considerations section  
>>> describes three separate instances that require the “express per 
>>> mission” of the user: sending location information to Web sites, 
>>>  retaining location information longer than is needed for the ta 
>>> sk for which it was collected, and retransmitting location infor 
>>> mation. It is our view that the “express permission” requirement 
>>>  means that the user would need to take an affirmative action (c 
>>> lick a button or accept a dialog box, for example) in order for  
>>> a Web site to be able to take any of these three actions in conf 
>>> ormance with this specification. Merely visiting a Web site that 
>>>  discloses its intent to take any of these three actions, withou 
>>> t soliciting affirmative consent from the user, would not suffic 
>>> e to meet the requirement of “express permission.”
>>>
>>> If our understanding of how to interpret the “express permission 
>>> ” requirements matches the working group’s understanding, we wou 
>>> ld like to have that confirmed by the group. If the working grou 
>>> p’s understanding is different, we would like to know how it dif 
>>> fers and why.
>>
>>
>> In order to be conformant with this specification a user agent must  
>> acquire the user's "express permission" via a user interface to  
>> transmit location data, unless a prearranged trust relationship  
>> exists. In order to be conformant with this specification  
>> recipients of location data must have the user's "express  
>> permission" to retransmit the location data or to retain the  
>> location data for longer than what is needed to complete the task  
>> for which it was provided to them. The specification does not  
>> specify how the express permission should be acquired for  
>> retransmitting and retaining location data.
>>
>>
>>>
>>> 2. Process
>>>
>>> The specification advanced to last call by this WG was originally  
>>> developed outside of the W3C prior to the formation of this  
>>> working group. This has created a number of serious issues and  
>>> frustrations within the WG’s efforts, including:
>>>
>>> -- the WG was extremely resistant to any changes to the pre- 
>>> existing API, and WG members argued repeatedly on the mailing list  
>>> against changes to the API because such changes would deviate from  
>>> implementations already deployed in the field.
>>>
>>> -- because of the overriding focus on having the W3C adopt a  
>>> standard that was consistent with previously developed and  
>>> deployed technology, the WG did not use the W3C WG charter as a  
>>> guiding document, and thus failed to meet the requirement that it  
>>> build an API that directly addressed privacy.
>>
>>
>> The starting point for the API specification was the Geolocation  
>> API implemented in Google Gears. Based on discussions on the public  
>> mailing list and the f2f meeting a number of changes have been made  
>> to the API since the initial proposal. The chairs do not agree with  
>> the claim that the working group was extremely resistant to changes  
>> to the API.
>> It is furthermore an important success criterion for this working  
>> group that the resulting API specification is widely adopted and  
>> that several interoperable implementations of the API exist. It is  
>> therefore not problematic per se that existing implementations that  
>> have already found a certain adoption in the market influence  
>> decisions made on the API level in this specification.
>>
>>
>>>
>>> -- prior and current contributors to the specification have not  
>>> joined the working group or made the required W3C IPR commitments,  
>>> creating significant intellectual property concerns.
>>
>>
>> Please see below for a detailed response to this claim.
>>
>>
>>>
>>> Although we believe that the first two of these problems should  
>>> concern all W3C members, there is nothing the WG can do at this  
>>> time (short of starting over) to address these concerns. Our last  
>>> call comments relating to process focus on the third point, and  
>>> raise two specific IPR-related issues. We raised these concerns  
>>> informally prior to submitting these last call comments, and we  
>>> understand there have been some efforts to resolve the issues we  
>>> raise below.
>>>
>>> 2.1 Spec author not joining the WG
>>>
>>> It appears as though the original version of the specification was  
>>> written prior to the formation of the WG, but that at least one of  
>>> its principal authors, Skyhook Wireless, never joined the WG or  
>>> made any non-member IPR commitments. The CEO of Skyhook, in an  
>>> article published this month, flatly asserted that his company  
>>> wrote the initial API. According to Ted Morgan, the “reason Skyh 
>>> ook is familiar with the [W3C] spec is that we actually wrote it 
>>> , the original one. We have been pushing this for years.”[5] The 
>>>  direct involvement of Skyhook in the API development has also b 
>>> een confirmed within the W3C WG process. At the face-to-face mee 
>>> ting in December 2008, for example, it was mentioned that certai 
>>> n features had been removed from a prior version of specificatio 
>>> n at the request of Skyhook (see the face-to-face minutes[6] doc 
>>> umenting a participant describing how “we had reverse geo in the 
>>>  first version of the spec, but forgot to take out the use case  
>>> ... we took it out due to pushback from skyhook”). However, Skyh 
>>> ook never joined the group (and is not a W3C member), leaving op 
>>> en the possibility for Skyhook to pursue intellectual property i 
>>> nfringement actions against any implementors of this specificati 
>>> on in the future (including web sites that utilize the API), and 
>>>  potentially threatening the W3C’s ability to publish the geoloc 
>>> ation specification as a Recommendation on a viable Royalty-Free 
>>>  basis.[7]
>>>
>>> We request that the working group address this situation before  
>>> moving to the Candidate Recommendation stage. Given Skyhook’s co 
>>> ntributions, the working group should explain how the specificat 
>>> ion could be issued as a Recommendation on a Royalty-Free basis  
>>> and what shields implementors from potential infringement liability.
>>
>>
>> The initial API specification was based on the Google Gears  
>> implementation. We have found no evidence that Skyhook Wireless  
>> contributed to the design or implementation of the Geolocation API  
>> in Google Gears. Skyhook Wireless was participating in the public  
>> mailing list discussions prior to the formal establishment of the  
>> working group, but never formally joined the working group, nor has  
>> the company made a formal commitment to the W3C licensing terms.
>> The decision was made early on to set up a public mailing list and  
>> invite comments also from non-members. The chairs are of the  
>> opinion that Skyhook Wireless made only non-significant  
>> contributions to the specification. Implementors of the  
>> specification are shielded from member patents only.
>>
>>
>>>
>>> 2.2 Spec contributor not joining the WG
>>>
>>> It is standard practice for W3C members to make IPR commitments as  
>>> required by the W3C Patent Policy when they join a WG. Apple has  
>>> been an active member in this working group (and may have been  
>>> involved in the pre-W3C development of the API). However, as the  
>>> chairs noted in June, Apple has not agreed to the same  
>>> intellectual property commitments as the rest of the group  
>>> members. The chairs decided that Apple’s contributions were not  
>>> “significant” enough to require it to make the IPR commitments,  
>>> noting that many of its contributions were “suggestions” or  
>>> “opinions.”[8] However, the chairs’ analysis failed to  
>>> describe the effects that those suggestions and opinions have ul 
>>> timately had on the API. Contrary to the chairs’ conclusion, App 
>>> le’s participation in fact had a quite significant impact on the 
>>>  outcome of the specification.
>>
>>
>> The chairs stand by the conclusion reached previously. Please find  
>> a detailed response to each of the claims below.
>>
>>
>>>
>>> Within the WG process, Apple repeatedly advocated for and against  
>>> certain aspects of the API, and in several instances its arguments  
>>> resulted in alterations being made (or not made) to the  
>>> specification. For example, Apple advocated for the use of a  
>>> native geolocation API,[9]
>>
>>
>> [9] Re: DOM based API (http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0011 
>> )
>>
>> By that date the group was not formed. It was a response from  
>> Maciej Stachowiak to a generic concern from Mark Baker about using  
>> the DOM instead of extending Javascript. It is very generic, not  
>> specifically related to Geolocation (which is not mentioned in the  
>> message).
>>
>>
>>> in favor of an error code which was later incorporated,[10]
>>
>>
>> [10] PositionError Requests (http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0088 
>> )
>>
>> It is not clear how proposing an error code could be seen as a  
>> "significant contribution" concerning IP.
>>
>>
>>
>>> in support of civic location,[11]
>>
>>
>> [11] V2 discussion (http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0113 
>> )
>>
>> This post is related to the next version of the spec (V2). Greg is  
>> discussing a use case, analyzing a scenario where lat/long or civic  
>> address is needed.
>>
>>
>>
>>> and -- most importantly to us -- against addressing privacy in the  
>>> specification.[12]
>>
>>
>> [12]
>> Re: w/r/t Privacy (http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0004 
>> )
>> Re: Additional security and privacy considerations? (http://lists.w3.org/Archives/Public/public-geolocation/2009May/0078.html 
>> )
>>
>> The first message refers to some experiences developing privacy  
>> policy for CoreLocation on the iPhone at the time of the post,  
>> which is NOT the same as the geolocation API.
>> The second message is a statement of opinion.
>>
>>
>>> On numerous occasions, Apple also cited its own Webkit code as  
>>> evidence for why the geolocation API should or should not  
>>> incorporate a particular feature.[13]
>>
>>
>> [13]
>> PositionError Requests (http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0088.html 
>> )
>> Re: synchronous error handling (http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0096.html 
>> )
>> Re: Drop lastPosition from Geolocation? (http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0151.html 
>> )
>>
>> Greg has written code to implement support for the W3C Geolocation  
>> API within the Open Source project WebKit (https://bugs.webkit.org/show_bug.cgi?id=21475 
>> ) and he has made comments from the point of view of a developer  
>> implementing and, what is more relevant, testing the spec.
>> The first of these was a proposal for a new error code (see above),  
>> the second was a request to have the intended behaviour clarified,  
>> and the third a comment on how a particular behaviour was  
>> implemented in WebKit.
>>
>> With the possible exception of the requested new error code, we do  
>> not share your interpretation of these comments.
>>
>>
>>> Moreover, Apple used the popularity of the iPhone as a threat  
>>> against the API. Apple suggested that if the API were to differ  
>>> from Apple’s existing geolocation implementation, users of the A 
>>> PI would suffer from the discrepancy, and conversely that the gr 
>>> oup’s decision to match the API to Apple’s implementation would  
>>> lend particular credence to the API.[14]
>>
>>
>> [14]
>> Re: geolocation privacy statement strawman (http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0106 
>> )
>> Re: updated editor's draft of the Geolocation API specification (http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0025.html 
>> )
>>
>> The second comment simply states that the iPhone implementation  
>> supports heading and speed, as defined in the Geolocation  
>> specification.
>> The first message was posted in the context of the discussion  
>> around the wording of the privacy considerations part of the  
>> specification.
>> At that time the working group had already concluded that privacy  
>> information should not be part of the API, and Greg's opinion about  
>> the significance of any discrepancy between the W3C Geolocation API  
>> and the iPhone implementation can not be said to have influenced  
>> the working group's decision on this matter.
>>
>>
>>> A holistic assessment of Apple’s contributions -- including both 
>>>  features that were incorporated into the specification and thos 
>>> e that were not, based on Apple’s advocacy -- shows that they we 
>>> re indeed “significant.”
>>>
>>> The direct impact that Apple’s WG participation had on the API i 
>>> s inconsistent with its refusal to become a group member. Apple’ 
>>> s participation in the WG is particularly inappropriate in light 
>>>  of the fact that at least one W3C member -- a company that for  
>>> the past eight years has been an active participant in the IETF  
>>> Geopriv and related working groups -- stayed out of the W3C WG b 
>>> ecause (as we understand it) it was unable to make the intellect 
>>> ual property commitments required to be a WG participant. Thus,  
>>> a company steeped in Geopriv stayed out of the WG because of IPR 
>>>  concerns, while at the same time Apple participated in the WG p 
>>> rocess, spoke strongly against using Geopriv, and then declined  
>>> to join the WG because of IP concerns. Under the W3C’s IPR rules 
>>> , a WG cannot allow a W3C Member to significantly influence a WG 
>>>  product without making the necessary intellectual property comm 
>>> itments, while at the same time those rules keep other W3C membe 
>>> rs out of the WG.
>>>
>>> We request that the working group rectify this situation before  
>>> moving to the Candidate Recommendation stage. The chairs’ conclu 
>>> sion that Apple’s contributions have not been “significant”  
>>> is not supported by the record of Apple’s participation in the W 
>>> G. All active participants must join the group and make the norm 
>>> al IPR commitments of group members.
>>
>>
>>
>> The chairs contacted Apple's representative in W3C, David Singer,  
>> asking him to sign the IPR commitments. He responded that Greg was  
>> participating mostly to ask clarifying questions and as a general  
>> developer. So the chairs considered that the level of involvement  
>> of Apple in the spec didn't justify signing the IPR commitments and  
>> this decision was communicated to the group on the member mailing  
>> list on June 1 2009.
>>
>>
>>>
>>> 3. Conclusion
>>>
>>> We believe that all of the above last call comments are generally  
>>> related. The API was initially developed outside of the W3C  
>>> process (leading to the issue discussed in 2.1 above), and then  
>>> within the WG the leading contributors were extremely focused on  
>>> quickly standardizing the existing API. This caused the group to  
>>> resist making significant changes, including those such as the  
>>> Geopriv proposals that would have allowed the API to best comply  
>>> with the charter requirement that it be “privacy-sensitive.” We  
>>> understand that the WG will not at this time go back and meet th 
>>> is charter requirement, but we do seek confirmation of our under 
>>> standing of the privacy requirements that are in the API. We als 
>>> o believe that the IPR issues must be resolved before the specif 
>>> ication progresses.
>>>
>>> [I have limited connectivity over the next week, and so will be  
>>> slow in responding to discussions on the list.]
>>>
>>> John Morris
>>>
>>> [1] http://www.ietf.org/html.charters/geopriv-charter.html.
>>>
>>> [2] http://tools.ietf.org/html/draft-ietf-geopriv-arch-00 (this  
>>> document is a work in progress).
>>>
>>> [3] http://www.w3.org/2008/geolocation/drafts/API/spec-source-CDT.html
>>>
>>> [4] http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0098.html
>>>
>>> [5] “The Browser Geolocation Wars: Skyhook’s CEO on Why Google M 
>>> aps is Misreading Your Location,” Xconomy, July 10, 2009, http://www.xconomy.com/boston/2009/07/10/the-browser-geolocation-wars-skyhooks-ceo-on-why-google-maps-is-misreading-your-locatio 
>>> n/.
>>>
>>> [6] http://www.w3.org/2008/12/08-geolocation-minutes
>>>
>>> [7] http://www.w3.org/Consortium/Patent-Policy-20040205/
>>>
>>> [8] http://lists.w3.org/Archives/Member/member-geolocation/2009Jun/0000.html
>>>
>>> [9] http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0011.html
>>>
>>> [10] http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0088.html
>>>
>>> [11] http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0113.html
>>>
>>> [12] http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0004.html 
>>> ; http://lists.w3.org/Archives/Public/public-geolocation/2009May/0078.html
>>>
>>> [13] About error codes: http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0088.html 
>>> , http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0096.html 
>>> ; About lastPosition: http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0151.html 
>>> ;
>>>
>>> [14] http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0106.html 
>>> ; http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0025.html 
>>> ;
>>>
>>>
>>
>>
>>
>
>
>
Received on Friday, 5 March 2010 16:18:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:46 GMT