- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Mon, 27 Oct 2008 16:42:16 -0700
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: "Andrei Popescu" <andreip@google.com>, "public-geolocation" <public-geolocation@w3.org>, public-geolocation-request@w3.org
- Message-ID: <OF47C57F4A.B6C60200-ON882574EF.007FB47D-882574EF.008236B6@us.ibm.com>
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
"Thomson, Martin"
<Martin.Thomson@a
ndrew.com> To
Sent by: Jon Ferraiolo/Menlo Park/IBM@IBMUS,
public-geolocatio "Andrei Popescu"
n-request@w3.org <andreip@google.com>
cc
"public-geolocation"
10/27/2008 04:00 <public-geolocation@w3.org>
PM Subject
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
Inactive hide details for "Andrei Popescu" <andreip@google.com>"Andrei
Popescu" <andreip@google.com>
"Andrei
Popescu"
<andreip@googl
e.com>
Sent by: To
public-geoloca
tion-request@w public-geolocation
3.org <public-geolocation@w3
.org>
10/27/2008 cc
01:55 PM
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]
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic32307.gif
- image/gif attachment: ecblank.gif
Received on Monday, 27 October 2008 23:43:08 UTC