Last call comments from Cisco

Cisco manufactures systems for locating mobile wireless devices, locating
devices on IP networks, and applications that consume location information.
The lack of suitable attributes for policy control in the API proposed by
this WG make the proposed API unusable for many applications. Cisco strongly
agrees with issue #1 as cited by CDT.  Privacy of location data is of huge
concern to us and we ask the WG to provide a solution that allows transfer
of users privacy preferences.

As to issue #2 in the CDT text, we believe the W3C should perform
detailed investigation into the possible IPR issues surrounding this work to
ensure protection of W3C members.

Marc Linsner
Consulting Engineer, Office of the CTO
Cisco Systems, Inc.


On 7/31/09 6:29 AM, "John Morris" <jmorris@cdt.org> 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.
> 
> 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
> ;
> 
>

Received on Friday, 31 July 2009 07:47:18 UTC