Re: wording for the privacy section

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]
> Sent: Tuesday, 28 October 2008 10:42 AM
> To: Thomson, Martin
> Cc: Andrei Popescu; public-geolocation; 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" <Martin.Thomson@andrew.com>
>
>
> "Thomson, Martin" <Martin.Thomson@andrew.com>
> Sent by: public-geolocation-request@w3.org
> 10/27/2008 04:00 PM
>
> <image003.png>
> To
> <image004.png>
> Jon Ferraiolo/Menlo Park/IBM@IBMUS, "Andrei Popescu" <andreip@google.com 
> >
> <image003.png>
> cc
> <image004.png>
> "public-geolocation" <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/
>
> From: 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; 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" <andreip@google.com>
>
> "Andrei Popescu" <andreip@google.com>
> Sent by: public-geolocation-request@w3.org
> 10/27/2008 01:55 PM
>
> To
>
> public-geolocation <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]