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

Last call comments from CDT

From: John Morris <jmorris@cdt.org>
Date: Fri, 31 Jul 2009 00:29:26 -0400
Message-Id: <CB390E5C-4101-4807-8D02-6A6A9B93FBF1@cdt.org>
To: public-geolocation@w3.org
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  

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  

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  

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  

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 
Received on Friday, 31 July 2009 04:30:00 UTC

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