- From: Matt Womer <mdw@w3.org>
- Date: Fri, 5 Mar 2010 10:17:03 -0600
- 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 UTC