Re: wording for the privacy section

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