Re: wording for the privacy section

I have been thinking about this a bit:
http://dougt.wordpress.com/2008/10/14/fuzzing-a-geolocation/

But I am note sure we need to spec out this area.  It is pretty  
specific to the application's privacy concerns.

Regards,
Doug


On Oct 28, 2008, at 8:09 AM, Chris Butler wrote:

> Hi Doug.
>
> If we feel that we need to have levels of privacy shouldn’t we add  
> the ability to return a boundary rather than a point?
>
> This still has the issue that as you pass between boundaries you  
> leak information, but this is much better than adding random noise  
> to the point…
>
> Thanks.
>
> Chris
> From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org 
> ] On Behalf Of Doug Turner
> Sent: Tuesday, October 28, 2008 12:09 AM
> To: Thomson, Martin
> Cc: Jon Ferraiolo; Andrei Popescu; public-geolocation
> Subject: 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]
>