Re: Response to Last call comments from CDT

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 responding.  It  
was not my intention to stall the process at all, but unfortunately 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 “standardize”  
functionality they had already decided upon.  Moreover, the maker of  
one of the world’s most popular mobile devices made crystal clear in  
WG discussions that it had little intention of conforming its  
technical offerings to the final W3C specification if the spec  
deviated from what that maker was already doing.[1]  In light of that  
approach 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 hope  
the W3C Team will accommodate a variation on the normal process – we  
believe that the W3C Director should ALSO carefully review and  
evaluate the objections we have raised.  Our goal is not to delay the  
specification, but instead is to seek guidance from the W3C as to  
whether both the process and substantive output of this WG meet the  
current 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 broader assessment of  
the outcome of this group.  Already some over in the Device API WG are  
saying that “it was already decided in Geolocation that we can/should  
not do privacy” in a certain manner, and it 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 day, my  
organization neither has a patent portfolio nor is deploying products  
that implement the spec – and the IP and Patent Policy problems 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, then 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  
failed 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  
central focus of the WG, and the AC was assured that that would  
happen.  Privacy, however, was an afterthought.  The majority of the  
spec was developed before the first word on privacy was drafted.  The  
API itself is totally silent on privacy, and although the privacy  
section ended up with good language, the exhortations in the spec have  
not translated into meaningful privacy protection for users (as  
discussed below).  If the process this WG followed is the new W3C  
norm, then the value of participating in W3C groups drops  
dramatically, at least 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 the  
distribution of potentially highly sensitive data – one’s physical  
location – it had a choice: to either simply rely on website privacy  
policies, or to attempt to address privacy in the design of the W3C  
API itself.  Although we believe that the charter of the Geolocation  
WG called on the WG to undertake the latter approach, the WG rejected  
two proposals that would have done that, and instead adopted a spec  
that relies largely on the privacy policy approach.  The spec does  
include some very good, strong language about privacy, but 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 robust  
sorts of user controls that sensitive location information demands.[4]  
Thus, at the end of the day, the specification is contributing to the  
privacy problem, and is failing to be part of the solution.  The  
academic analysis at [3] provides a good overview of the WG’s efforts  
and missed opportunities to address and improve the privacy 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 address the privacy  
problems on the Web.  We support these ideas, but ultimately and more  
broadly, the W3C needs to decide whether it wants to move the ball  
forward for privacy on the Web, or whether it wants to reinforce the  
inadequate status quo.  Historically, of course, the W3C has been a  
leader in seeking to craft technological approaches to social policy  
issues, but the Geolocation WG was a missed opportunity 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  
though we are not asking the Director to delay publication of the  
Geolocation specification – that the W3C will carefully consider the  
issues raised here (and more fully discussed below in our original LC  
comments).

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 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 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 privacy expectation will be  
> honored, and it creates an opportunity for 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 of  
> their information, the Geopriv approach -- if adopted by the W3C --  
> would begin a long overdue realignment of power on the Web, and  
> would appropriately place users in greater control over their  
> information.  Although the Geopriv approach does not by itself  
> (using technical means) force recipients to honor users’ privacy  
> rules, both market and legal forces would be able to react 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.
>
> 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 on  
> 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  
> working 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  
> permission” of the user: sending location information to Web sites,  
> retaining 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 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 conformance with this  
> specification. Merely visiting a Web site that discloses its intent  
> to take any of these three actions, without soliciting affirmative  
> consent from the user, would not suffice 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 would  
> like to have that confirmed by the group. If the working group’s  
> understanding is different, we would like to 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 Skyhook 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 been  
> confirmed 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  
> request of Skyhook (see the face-to-face minutes[6] documenting 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, Skyhook never joined the  
> group (and is not a W3C member), leaving open the possibility for  
> Skyhook to pursue intellectual property infringement actions against  
> any implementors of this specification in the future (including web  
> sites that utilize the API), and potentially threatening the W3C’s  
> ability to publish the geolocation 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  
> contributions, the working group should explain how the  
> specification could be issued as a Recommendation on a Royalty-Free  
> basis and what 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. Contrary 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 existing  
> 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 specification and  
> those that were not, based on Apple’s advocacy -- shows that 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  
> 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 because (as we  
> understand it) it was unable to make the intellectual 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 process, 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 commitments, while at the  
> same 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’ conclusion  
> that Apple’s contributions have not been “significant” is not  
> supported by the record of Apple’s participation in the WG.  All  
> 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 understanding of the  
> privacy requirements that are in the API.  We also believe 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-location/ 
> .
>
> [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 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 privacy expectation will be  
>> honored, and it creates an opportunity for 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 of  
>> their information, the Geopriv approach -- if adopted by the W3C --  
>> would begin a long overdue realignment of power on the Web, and  
>> would appropriately place users in greater control over their  
>> information. Although the Geopriv approach does not by itself  
>> (using technical means) force recipients to honor users’ privacy  
>> rules, both market and legal forces would be able to react 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 is  
>> that the specification imposes normative privacy requirements on  
>> 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  
>> working 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.
>
>
>
> 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  
>> permission” of the user: sending location information to Web sites,  
>> retaining 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 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 conformance with this specification. Merely visiting a Web site  
>> that discloses its intent to take any of these three actions,  
>> without soliciting affirmative consent from the user, would not  
>> suffice 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 would  
>> like to have that confirmed by the group. If the working group’s  
>> understanding is different, we would like to know how it differs  
>> 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 Skyhook  
>> 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 been  
>> confirmed 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  
>> request of Skyhook (see the face-to-face minutes[6] documenting 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, Skyhook never joined the  
>> group (and is not a W3C member), leaving open the possibility for  
>> Skyhook to pursue intellectual property infringement actions  
>> against any implementors of this specification in the future  
>> (including web sites that utilize the API), and potentially  
>> threatening the W3C’s ability to publish the geolocation  
>> 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  
>> contributions, the working group should explain how the  
>> specification 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 ultimately had on the API. Contrary  
>> to the chairs’ conclusion, Apple’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 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]
>
>
> [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 those  
>> that were not, based on Apple’s advocacy -- shows that 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  
>> 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 because (as  
>> we understand it) it was unable to make the intellectual 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 process, 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 commitments, while at  
>> the same 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’  
>> conclusion that Apple’s contributions have not been “significant”  
>> is not supported by the record of Apple’s participation in the WG.  
>> All active participants must join the group and make the normal 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 this charter  
>> requirement, but we do seek confirmation of our understanding of  
>> the privacy requirements that are in the API. We also believe 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-location/ 
>> .
>>
>> [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 Wednesday, 3 March 2010 20:49:11 UTC