RE: wording for the privacy section

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



 "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





Subject


wording for the privacy section

 







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]