RE: Additional security and privacy considerations?

Hi Rigo,

My main point is that notification does not (necessarily) equal user
choice.  Suggesting that notification be provided without also
suggesting that the UA give the user the ability to take action is bad
guidance.  

Microsoft IE used to do this with their certificate UI.  You could
choose high, medium, or low security for your private key.  High meant
the key was protected with a password, low meant no password, and medium
was notification only.  Users with medium security would get a dialogue
box letting them know that their private key was being accessed, but no
mechanism to prevent it (i.e. a cancel button).  If the only guidance is
that UAs may notify users that their location is being shared, some
implementations will do simply that without giving the user the ability
to prevent/cancel the sharing.

The reason I say that notification isn't necessary is because 1) I agree
with all the comments about not prescribing a UI and the spec being
potentially applicable to applications that may not be able to notify,
and 2) because users should be able to have a seamless experience
without interruption.  Using your cookie example, it's near impossible
to browse if you choose to be prompted every time a cookie is being set,
accessed or updated (some browsers don't even let you do that anymore).
It would be a mistake to suggest that UAs should notify because it is
very possible that location will become as ubiquitous as cookies are
today.

Perry 


-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Wednesday, May 27, 2009 2:18 AM
To: Perry Tancredi
Cc: Doug Turner; Thomas Roessler; Andrei Popescu; Greg Bolsinga;
public-geolocation
Subject: Re: Additional security and privacy considerations?

Hi Perry, 

I share your concern and push it a bit further. How would a user know
that she can revoke a permission, if she is not aware that location is
actually shared? 

If we do not say anything about notice, it will not happen.

======More details and detailed argumentation below==============

To use a right/possibility one has to be aware of it in the first place.
If you don't know that you can revoke a contract concluded online in the
EU within the first two weeks, you won't even try it.

But awareness is a problem of UI and it is a part of the human right of
privacy (yes, human right and not some smallish nuisance). The paradigm
of data self determination needs first of all knowledge what is shared.
This first step is even part of the weak US model of "notice & choice". 

What I see here is people saying: Yeah, choice is fine, but we won't
give any notice if only option #3 is in the spec. In this case, the
choice is worthless and the goal of privacy is not achieved at all. 
And putting some fig leave by requiring a choice (only) that isn't
discoverable at the right moment won't help against that diagnosis.

Let's take cookies for a (not really fitting) example: Surf the web for
one month to all major news sites and social networks. Now you are asked
to revoke all permissions given during your visits to example.com. Do
you remember that this visit also made your browser store cookies from
a.com, b.com and c.com? And look into your browser's preferences how
many cookies you've received. Now review them all whether you still want
to give them permission. You will not remember and it will take you half
a day to go through all those cookies. With location permissions, it
will be the same.

Having an indicator for location sharing and connecting that indicator
to the revocation makes the revocation a real informed choice of the
user that will be context dependent and convenient. This would be a real
privacy feature and would even satisfy EU regulations. Remember, this is
all scoped to _personal data_. So if no natural person is involved, the
requirement is not applicable at all. An implementer could do anything
with the data collected. But _if_ a natural person is involved, there is
normally some sort of UI. (Perhaps less so for electronic bracelets for
home assigned offenders, but the allusion to bracelets gives you an idea
of what we are talking about)

Let me give you another comparison: In most western countries, secretly
recording the voice of somebody is criminal offense. I predict that if
we only give choice without notice, we'll see grave scandals that will
lead to governments issuing laws that will make secret recording of
location data a criminal offense. Because today, mainly governments and
large operators with corporate governance have access to location data.
And they are normally highly regulated. In the future location
information will be potentially available to everyone. The user must
have an adequate means of protection in this scenario.

So while a specification shouldn't do user interface design, it should
at least clearly and normatively set the goals. This may not be simple,
but it is feasible. The goal is an informed choice by the user. This
requires at least notice and choice at times of data transfer. Going
beyond (revocation) may not be legally required in the US, but it is in
the EU and is actually reasonable and helpful. 

Now why some guidance about UI? Today, if you get into a car, you are
near to instantly capable of driving it. Why? Because the important
stuff in the cockpit is placed in well known locations. There is a
recognition/recall value. It is part of me trusting a device that I find
controls where I expect them. Not saying anything will lead to wildly
fragmented user experiences. As we are talking about the protection of a
human right (privacy) it may be worthwhile allowing the user to feel in
known territory while using geolocation services. 
Again, the spec can remain general enough to still allow for good
competition (and we should take care that it does)

Best, 

Rigo



On Wednesday 27 May 2009, Perry Tancredi wrote:
> I agree with #3 and Doug's suggested wording below.
>
> Also, we all agree that users must be able to revoke sticky 
> permissions.
>
>
> I wonder, however, if we still have a problem in the case that a user 
> who wants to revoke permissions to specific application won't know 
> which permissions to revoke because they don't where the permissions 
> where inherited from.
>
> The goal, as stated earlier, isn't that "Users must be able to tell 
> when location is shared," it really is that "Users must be able to 
> revoke permissions to any application."  If a user can't figure out 
> which permission to revoke, then we've done a disservice to users and 
> applications because some users will feel forced to revoke all 
> permissions.
>
> Actively informing users is not the answer.  Allowing users to 
> discover which permissions a specific application is relying on may 
> make revoking permissions more meaningful, but some platforms may find

> providing that information too challenging.
>

Received on Wednesday, 27 May 2009 17:22:41 UTC