RE: wording for the privacy section

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/
<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]