- From: Perry Tancredi <ptancredi@quova.com>
- Date: Wed, 27 May 2009 10:22:04 -0700
- To: "Rigo Wenning" <rigo@w3.org>
- Cc: "Doug Turner" <doug.turner@gmail.com>, "Thomas Roessler" <tlr@w3.org>, "Andrei Popescu" <andreip@google.com>, "Greg Bolsinga" <bolsinga@apple.com>, "public-geolocation" <public-geolocation@w3.org>
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