- From: John Morris <jmorris@cdt.org>
- Date: Tue, 28 Oct 2008 20:52:26 -0400
- To: Doug Turner <doug.turner@gmail.com>
- Cc: "Thomson, Martin" <Martin.Thomson@andrew.com>, "Jon Ferraiolo" <jferrai@us.ibm.com>, "Andrei Popescu" <andreip@google.com>, "public-geolocation" <public-geolocation@w3.org>
To not mince words, I believe that the proposed language and the broader suggestion to leave it to the UA to figure out privacy are a whitewash of the privacy concerns, and are pointing this WG effort down a very, very problematic path. My words below are blunt not because I want to scuttle this effort, but because I strongly believe that (a) the WG is going down a path that is NOT what the W3C more broadly expects or what it will ultimately accept, and (b) now is the time to stop and figure out a game plan that will get us down a better path. I believe that the goal of the charter is desirable and achievable, but I believe that the current trajectory of this WG is heading toward a train wreck - one that, if we turn now, we can avoid. I am very hopeful that we can work together on the list and in London to develop a good game plan. My main points are: Point 1: The current direction of this WG is NOT what is specifically set out in the charter or what at least some (and I predict most) W3C members expect. According to the charter, the objective of this WG is "to define a SECURE AND PRIVACY-SENSITIVE INTERFACE for using client-side location information in location-aware Web applications." To simply assert in a spec that any implementation MUST take privacy into account while being silent on HOW to do so accomplishes nothing, and will do absolutely nothing to change the norm - which is to wholly ignore privacy. It is crystal clear from both the charter and the list discussion that that the spec being proposed will be used in broad diversity of use cases (not just manual user input of location), and simply waiving a privacy wand over the whole effort does not constitute a "secure and privacy-sensitive interface." It constitutes business-as-usual by leaving privacy for someone else to worry about (and ultimately for the end user to lose out on). When this WG was first proposed to the W3C Advisory Committee (I am CDT's AC rep), there were few comments, but most stressed the importance of addressing privacy. One said, for example: "The privacy and security issues are incredibly important and, however it's done, the end user MUST remain in control of their location data." The responses from the W3C team were vague, but they did promise that privacy would be an important part of this WG's mission (and indeed, it appears in the charter to be a central component of the mission). Unfortunately, the current spec and the proposed language on privacy do not come even remotely close to delivering on the promise that privacy would be an important focus of this WG. At the end of the day, I think most W3C members did not pay sufficient attention to the creation of this WG, but I think that a majority of those members - when confronted with the question in the future - will agree that privacy is an important point that must be a focal point of this WG. Point 2: This WG could well do serious harm to the uptake of more-privacy protecting efforts such as the IETF's Geopriv, and I seriously doubt that the W3C will want as part of its legacy serious harm to the goal of location privacy on the Internet. As I detailed a few days ago [1], the IETF's Geopriv WG has spent 7 years grappling with and largely solving most (but not all) of the questions this group is setting out to work on. And the output of that group is a standard that seeks to FORCE developers to deal directly with privacy (or to consciously choose to ignore privacy by ignoring an essential element of the IETF standard). If developers implement Geopriv to facilitate location info conveyance, they cannot claim to be compliant with the IETF standard if they do not address privacy. Now comes the W3C with a WG that substantially overlaps with Geopriv, and this WG is pretty clearly headed toward making no serious attempt to address privacy other than one sentence in a "security considerations" section that most developers will ignore. (Indeed, some here argue that privacy is essentially out of scope.) I think it is beyond question that a great percentage of developers - when faced with a choice of Geopriv (which requires effort to address privacy) or the W3C output (which as currently proposed will not) - will choose the easy way out and will opt to leave privacy for someone else to think about (and thus, as is very common, location privacy will never get addressed, or will only get addressed in paragraph 43 of a 8 page privacy policy). And so, on top of whatever expectation the W3C has about this WG (as noted in point 2 above), I think many W3C members will not support something that blows a gaping hole in the privacy protections created by another SDO's efforts in this space. I certainly could be wrong, and it is certainly possible that the W3C leadership or membership in fact will not care about privacy. But given the W3C's long track record on being out front on efforts to promote privacy (with P3P for example), my guess is that privacy will at the end of the day be deemed to be important. Point 3: This WG effort appears to be reinventing the wheel, and does not even appear to be trying to do as robust a job as the existing wheel. Although I agree with the list traffic saying that this WG has a somewhat different purpose than Geopriv, I also think that the Geopriv effort has worked through (successfully to my mind) many of the questions that this WG appears to want to address. One can see this, for example, in the list traffic discussing terminology - what is of course a starting point for "standardization." Geopriv developed a detailed terminology years ago - it may not be perfect or complete, but it is a good starting point. As another example, on the list we are now just beginning to discuss the idea of "fuzzing" of location info (which is important for privacy). [2] But Geopriv grappled with - and came up with workable approaches to - fuzzing location years ago. It strikes me that a key threshold question this WG needs to answer (after defining requirements, as discussed below) is whether Geopriv offers a workable foundation on which this WG can build. Rather than just starting out with new terminology and new standards for expressing and conveying location, we should try if possible to build on what already exists. This is especially true because the entire structure of Geopriv is to facilitate OTHER protocols and other SDO efforts to build on top of Geopriv. In other words, if there are indeed things that the W3C wants to accomplish that Geopriv does not (and I assume that there are such things), then Geopriv provides a clear framework to build extensions into the core location AND privacy conveyance that Geopriv already provides. So I believe an important discussion (after we define requirements) is to see what is already done in Geopriv - so that we can then figure out what this WG needs to do in addition. The flexibility of Geopriv (both as an extensible standard, and in the flexibility it offers developers in a range of its features) will, I think, really enable a broad standardization of location/privacy conveyance, while allowing a very high degree of flexibility of technical and business models. I think the W3C would do a disservice to the goal of interoperable standards for this WG to try to reinvent the wheel adopted by the IETF (as well as a number of other SDOs that are looking to use Geopriv). Moreover, I think this effort can both learn from and benefit from the work that the Geopriv WG has already done. As one example, the current spec offers the following as the second proposed "use case": >Annotating content with location information >A group of friends is hiking through the Scottish highlands. Some of >them write short notes and take pictures at various points >throughout the journey and store them using a Web application that >can work offline on their hand-held devices. Whenever they add new >content, the application automatically tags it with location data >from the Geolocation API (which, in turn, uses the on-board GPS >device). Every time they reach a town or a village, and they are >again within network coverage, the application automatically uploads >their notes and pictures to a popular blogging Web site, which uses >the geolocation data to construct links that point to a mapping >service. Users who follow the group's trip can click on these links >to see a satellite view of the area where the notes were written and >the pictures were taken. This is a fine idea, but Geopriv offers tools today to make it much better. To change the hypothetical just a bit, assume that I am traveling with my family (including my 12 year old daughter) to the U.S. state of Maine (as I do every year), and I want to write notes and take pictures of my family and geotag them - just as the use case suggests. I may be happy to tell the world that I am visting Maine, but I can guarantee you that - from a child safety perspective - there is no way that I want to tell the world EXACTLY where in Maine my daughter and I are. But I DO want to tell the grandparents exactly where the family is. So I want one set of privacy rules for "everyone" and a different set (allowing more info) for my extended family. And Geopriv allows exactly this flexibility. If we don't the flexibility offered by Geopriv, then I ask "why not"? If we do want the flexibility offered by Geopriv, then I ask "why do we have to invent it again"? Point 4: This WG appears to be putting the cart before the horse, by teeing up a proposed "solution" before we have defined the problems we are trying to solve. This WG does not seem to be approaching its mission in the best order. In my experience, a "requirements" document is a good starting point, not a draft spec. Unless the whole point of this effort is to put a W3C rubber stamp on an existing draft spec, then I think we should set aside the current documents and start at square one. That pesky charter suggests (at least to me) that a core mission is to achieve a "secure and privacy-sensitive" result. I don't think we can achieve that mission without first defining what exactly we are trying to accomplish here, and then identifying the security and privacy considerations raised by those goals. We seem to be putting the cart before the horse. On a related process concern, the charter plainly states that we will create liaison relationships with five different SDOs - the first of which happens to be Geopriv. I would suggest that an early and important task for this WG is to create those relationships, find out what those other groups are doing already, and THEN figure out where, if anywhere, the W3C can add value. I suggest that we work quickly to see if we can get formal input in London from these five other SDOs. I know that there is some overlap between this WG and those other SDOs, but we should open up a formal liaison relationship and ask for input. ***** Notwithstanding my lengthy concerns voiced above, I readily accept that this WG can indeed add value, and can do so in a "secure and privacy-sensitive" manner, as our charter requires. As blunt as my views are, I think it is in everyone's interest that we figure this out now, rather than after much effort that largely ignores privacy. As is obvious, I come to the table thinking that we should carefully look at Geopriv as a starting point, but it is also obvious that others come with very different starting points. I think we can work together to achieve the objectives of this WG, but as suggested in point 4, I think we should slow down the rush to refine a spec and should instead look at our charter, and develop a good game plan to fulfill that charter. I am very glad that we have an early face-to-face meeting in about a month. I hope that we will be able to constructively move forward on our charter mission. My colleague Alissa Cooper and I look forward to meeting everyone in London. John Morris [1] http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0055.html [2] http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0078.html At 12:09 AM -0700 10/28/08, Doug Turner wrote: >Hi Martin, > >I think that the UA is in the best position to to make decisions >about the privacy of their users. It is hard to define what the UX >should be across varying applications and I believe this work is >outside our scope. > >Could you elaborate on how the current specification is not >providing adequate privacy and security considerations? What can we >do to mitigate the risks you see? > > >Also, do we want to point out that transport should also be >identified as a means that will leak geolocation data? > >Doug > > > >On Oct 27, 2008, at 5:34 PM, Thomson, Martin wrote: > >>Hi John, >> >>I think that the problem is that you are confusing acquisition of >>permission to prompting the user. The text, as proposed, does not >>assume or imply that prompting a user is necessary, all it states >>is that user permission be acquired prior to release of the >>information. As I said, permission can be acquired in many ways. >>In the embodiments seen thus far, a user prompt is indeed the means >>by which permission is acquired, but that doesn't preclude other >>means of acquiring permission. >> >>In your use case, permission could be express or implied by the >>installation or use of the application (or in the terms of an >>employment contract for that matter, if the application is related >>to that employment). I personally don't favour implied permission, >>but I don't see any way that a specification can enforce that >>explicit permission be necessary - that's a matter for local >>jurisdictions. >> >>My view is that any specification without adequate privacy and >>security consideration is incomplete. W3C would do itself a >>disservice if it released such an incomplete specification. >> >>As far as OMA and OMTP are concerned, I have no prejudice against >>either. I have participated in OMA-LOC, and participated in a few >>meetings. If this were a mobile-specific API, I'd be less likely >>to disagree with you, but it is not. >> >>Cheers, >>Martin >> >>From: Jon Ferraiolo [<mailto:jferrai@us.ibm.com>mailto:jferrai@us.ibm.com] >>Sent: Tuesday, 28 October 2008 10:42 AM >>To: Thomson, Martin >>Cc: Andrei Popescu; >>public-geolocation; <mailto:public-geolocation-request@w3.org>public-geolocation-request@w3.org >>Subject: RE: wording for the privacy section >> >>Martin, >>I think you misunderstood my comments. I think privacy protection >>and other security concerns are extremely important. However, I >>don't think it is appropriate for a W3C spec to dictate particular >>security policies. The world is a very complex place and there are >>lots of use cases. In many use cases, sure, the user should be >>prompted, but in other use cases, it would be wrong to ask the >>user. I gave an example of one of those use cases in my previous >>email. Do you disagree that in my scenario it would be wrong to ask >>the user? >> >>Secondly, there are many people in the security field who feel that >>asking the user to make a decision is often a bad idea. Users just >>say yes to everything, so the argument is that making the user >>respond to a prompt is equivalent to simply granting permission to >>the application. Therefore, I think it is incorrect to cast in >>stone within the geolocation spec that the user must be asked >>permission, no matter whether the prompt happens many times or just >>once. In many cases, sometimes there are more effective ways of >>protecting the user's privacy than prompting. Perhaps in the future >>the community will develop a privacy manifesto which defines >>groundrules by which an application can use location data safely, >>such as a web site agrees to not store the location persistently on >>its own servers or share location information with other >>organizations. Then in the future phones could automatically share >>location information with organizations that agree to those >>groundrules. I realize this scenario is all made-up and might never >>happen, but maybe it could happen. Because something like this has >>a chance of happening, I think it would be wrong to dictate a >>particular behavior on user agents within the specification. >> >>Third, I don't understand your comment about OMA and OMTP as being >>"inappropriate forums". Is there something wrong with those >>organizations? They seem like solid standards organizations to me. >>Or are you just saying that you think that W3C should address >>security issues itself, versus delegating to other organizations? >>If it is the latter, then let me explain why I think W3C should >>delegate the formulation of security policy to other industry >>groups. The thing is that W3C serves the broadest set of >>constituents with its specs across many different usage scenarios, >>whereas OMA and OMTP are more focused on particular usage scenarios >>(mobile phones in both cases). W3C is most effective when it >>defines technical specifications for component technologies. For >>example, W3C defines the component technology known as HTML, but >>does virtually nothing to define the security policies around the >>usage of HTML (e.g., the same-domain policy did not come out of a >>W3C spec). Those security policies grew organically out of the >>experience of the browser developers. Regarding geolocation and >>other similar device APIs, it makes sense to once again have the >>W3C focus on the technology specification and let other standards >>organization (and oftentimes the vendors) to figure out what >>security policies work best for users. >> >>Jon >> >> >><image001.gif>"Thomson, Martin" >><<mailto:Martin.Thomson@andrew.com>Martin.Thomson@andrew.com> >> >>"Thomson, Martin" >><<mailto:Martin.Thomson@andrew.com>Martin.Thomson@andrew.com> >>Sent >>by: <mailto:public-geolocation-request@w3.org>public-geolocation-request@w3.org >> >>10/27/2008 04:00 PM >> >><image003.png> >>To >><image004.png> >>Jon Ferraiolo/Menlo Park/IBM@IBMUS, "Andrei Popescu" >><<mailto:andreip@google.com>andreip@google.com> >><image003.png> >>cc >><image004.png> >>"public-geolocation" >><<mailto:public-geolocation@w3.org>public-geolocation@w3.org> >><image003.png> >>Subject >><image004.png> >>RE: wording for the privacy section >> >><image004.png> >><image004.png> >> >> >>Hi Jon, >> >>I have to strongly disagree with your comments. I think that the >>text is a good start. It provides the most elementary privacy >>protection: opt-in. >> >>If you want to settle for loose wording or vague statements with no >>teeth, you have underestimated how seriously people take privacy >>for location. >> >>If your concern is user annoyance, there are many different ways of >>obtaining permission. The text does not imply any particular >>method. For instance, gaining long term permission is as simple as >>providing a checkbox with a "Remember my decision" label. If you >>are concerned about a specific application gaining permission, then >>such permission can be a condition on installation. >> >>OMA or OMTP are inappropriate forums to push the work to. By >>failing to address these concerns in the W3C, by producing an >>incomplete specification, there is a greater chance of the >>specification failing. There's more to be done here, not pushed >>off. P3P currently doesn't do location properly, for instance. >>Besides, to categorize this standard as applicable only to mobile >>devices is short sighted. I refer you to introduction of [1]. >> >>Regards, >>Martin >> >>[1] <http://www.azarask.in/blog/post/geolocation-in-firefox-and-beyond/>http://www.azarask.in/blog/post/geolocation-in-firefox-and-beyond/ >> >>From: <mailto:public-geolocation-request@w3.org>public-geolocation-request@w3.org [<mailto:public-geolocation-request@w3.org>mailto:public-geolocation-request@w3.org] On >>Behalf Of Jon Ferraiolo >>Sent: Tuesday, 28 October 2008 8:55 AM >>To: Andrei Popescu >>Cc: public-geolocation; <mailto:public-geolocation-request@w3.org>public-geolocation-request@w3.org >>Subject: Re: wording for the privacy section >> >>Hi, >>Sorry I haven't followed the security issues very closely lately, >>but I'll pipe in now to say that I don't think you want to say MUST >>NOT. I'm not even sure you should say SHOULD NOT, but certainly not >>MUST NOT. >> >>There are many different usage scenarios where the geolocation APIs >>might be used. Suppose you have a company intranet application that >>uses location information, and that application is installed as a >>widget onto a mobile phone (that the company buys for its >>employees), with appropriate digsig information that confirms that >>the application comes from the right company. In this case (and >>likely in many others), there is no reason why the implementation >>should ask user permission before the application can access the >>location APIs. >> >>I would propose that the specification include loosely worded text >>that talks about the importance of privacy concerns and suggests >>that in many common scenarios the implementation should gain >>explicit user permission before allowing an application to gain >>access to this APIs. >> >>My general model for security in W3C specs is that the spec should >>highlight the security concerns and suggest possible ways for >>implementations to address those concerns, and nothing else. It is >>better to leave the definition of explicit security policy (e.g., >>"MUST prompt the user") to the rest of the industry. In the mobile >>space, OMTP or OMA are better places for establishing security >>policies. (Believe me, W3C committees will be much more enjoyable >>and fast-moving if you can push security policy questions off to a >>different consortium.) >> >>Jon >> >> >> >><image001.gif>"Andrei Popescu" >><<mailto:andreip@google.com>andreip@google.com> >> >>"Andrei Popescu" <<mailto:andreip@google.com>andreip@google.com> >>Sent >>by: <mailto:public-geolocation-request@w3.org>public-geolocation-request@w3.org >> >>10/27/2008 01:55 PM >> >>To >> >>public-geolocation >><<mailto:public-geolocation@w3.org>public-geolocation@w3.org> >>cc >><image004.png> >>Subject >> >>wording for the privacy section >> >> >> >><image004.png> >><image004.png> >> >> >> >>Hello, >> >>Regarding the privacy issues, I'd like to propose the following wording: >> >>"A conforming implementation MUST NOT allow an application to use this >>API to obtain geolocation data without user permission. A conforming >>implementation MUST allow the user to revoke the permission to an >>application that is allowed to use this API to obtain geolocation >>data." We'd also have to define what a "conforming implementation" is >>(i.e. one that implements all the interfaces in the specification, and >>satisfies all other MUST-, REQUIRED- and SHALL-level criteria.) What >>do you think? >> >>Thanks, >>Andrei >> >> >> >> >> >> >>------------------------------------------------------------------------------------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------------------------ >>[mf2]
Received on Wednesday, 29 October 2008 00:53:45 UTC