Re: Intended usage notification

I also agree that more information is better. A user interface can  
provide a "Details" button, if necessary, so that users that don't  
care don't see the information. This certainly beats the usual 26-page  
6-point legalese that passes for privacy disclosures these days. I  
just don't see the harm. I can only speak for myself, but I do care  
whether my location information is simply used to draw a map or is  
used to profile me for ad delivery by the location service or  
"affiliate" ad delivery networks. I'm fine with generic, bland ads,  
thank you much.

In the end, we cannot force services to offer meaningful information,  
so if this is truly useless, we're no worse off, since everybody will  
just put there "please see our privacy statement" or nothing. But if  
we don't have that option, we effectively prevent more detailed  
disclosure.

One question is whether it makes sense to try to define this as  
structured information (plus explanatory text) or just plain English.  
I would find the former better, as it makes multi-lingual interfaces  
much easier, but this depends on whether there is a small set of  
definable features that can be defined precisely enough.

Henning

On Apr 8, 2009, at 1:22 AM, Nick Doty wrote:

> Hello all,
>
> I'd like to add my voice as one that would hope for some intended  
> usage notification in the API.  As a web developer, I definitely  
> want some standard way to let my users know what I'm going to be  
> doing with their location information and to have that promise in  
> front of them at the time they're making that decision.  A dialog  
> that pops up without any context on what my site will do with a  
> user's location information will make my users uncomfortable.  Given  
> the potentially widely varying ways that the User Agents may  
> implement asking the user for permission, there may be no way for me  
> to consistently get my intended usage information to the user so  
> that they can make an appropriate decision.
>
> To return to "good guys" and "bad guys", I think that really  
> distracts us from the point.  I'm a "good guy" and I'm not going to  
> sell my users' location information to the mafia or anything like  
> that. But it's still certainly relevant to my users' decision to  
> give me their location information how long I'm planning on storing  
> the data, who I'm sending it to or what I'm using it for.  And if I  
> can let them know at the very moment I'm asking for this sensitive  
> data, then I'm a lot less likely to get complaints from them after  
> the fact or to get in legal/PR/regulatory trouble later on.
>
> As I currently understand it, the API suggests that the User Agent  
> provide the user just with the URI of the document requesting  
> access.  Does the working group believe that the URI is the only  
> relevant piece of information for the user in deciding whether to  
> reveal their location?  If the web really is made up of good guys  
> and bad guys, then the URI might be sufficient information, but  
> again, I don't think that's the situation here.  The URI is  
> certainly relevant, but not the only thing that's relevant.
>
> I'd love to hear more about the experience from Gears -- did you see  
> evidence that malicious sites were able to trick users with the  
> notification text?  I would think (though this is certainly out of  
> my realm of experience) that the User Agent could somehow  
> distinguish between what the User Agent is telling me and what the  
> site is telling me, though it seems others on this list disagree.   
> Has Google chosen to remove this notification from subsequent  
> versions of Gears?
>
> Thanks,
> Nick
>
> On Mar 26, 2009, at 6:35 PM, Andrei Popescu wrote:
>
>> Hi,
>>
>> For what it's worth, we implemented this in Gears. The reasoning was
>> similar to what you described. Our experience with this is that it
>> does provide a modest benefit for good sites that can add more  
>> context
>> to the permission dialog. The downside is that this feature allows  
>> bad
>> sites to add text that may detract the user's attention from the
>> actual URL of the site that's asking for permission. Bad sites can  
>> add
>> their own URL go the snippet (in ways that are hard to detect) making
>> matters even more confusing to the users. So, in retrospect, I am not
>> sure this really improved anything. In any case, as an API
>> implementer, I would certainly not like to be forced to implement
>> something like this, hence I don't think this should be in the spec.
>>
>> Andrei
>>
>> On Thu, Mar 26, 2009 at 10:17 PM, Thomson, Martin
>> <Martin.Thomson@andrew.com> wrote:
>>> Trust is not a binary operation on all aspects.
>>>
>>> The thought process goes thus:
>>>
>>> - I trust this site not to lie.
>>>
>>> - This site just asked me if I wanted to be advertised at based on  
>>> my location: reject.
>>>
>>> - This site just asked me if I wanted to display a map of my  
>>> vicinity: allow.
>>>
>>> What the current arrangement does is forces users to have a  
>>> reasonably good conceptual model of what is going on in the web  
>>> page in order to make an informed decision when the prompt is  
>>> offered.  I don't believe that an average user is capable of  
>>> building a useful model.
>>>
>>> The current model leads to users to think: ``the last time I  
>>> clicked "reject" the site didn't work.''  This has the effect of  
>>> training users to blindly click accept.
>>>
>>> I'm merely suggesting a low-cost improvement to this training  
>>> problem.
>>>
>>> Cheers,
>>> Martin
>>>
>>>> -----Original Message-----
>>>> From: Ian Hickson [mailto:ian@hixie.ch]
>>>> Sent: Thursday, 26 March 2009 3:06 PM
>>>> To: Thomson, Martin
>>>> Cc: Greg Bolsinga; Doug Turner; public-geolocation@w3.org
>>>> Subject: RE: Intended usage notification
>>>>
>>>> On Thu, 26 Mar 2009, Thomson, Martin wrote:
>>>>>
>>>>> This is not intended to be binding, so liars will be free to do  
>>>>> that.
>>>>
>>>> Then what's the point?
>>>>
>>>> The good sites aren't the ones that are going to be a privacy  
>>>> risk for
>>>> users. The ones that are the problem are the malicious sites that  
>>>> are
>>>> going to, I dunno, sell the location of rich people using their  
>>>> site to
>>>> organised thieves. And those are the very sites who will lie.
>>>>
>>>> In other words, there are two kinds of sites, and two kinds of  
>>>> prompts:
>>>>
>>>>                    Prompts that are honest    Prompts that are lies
>>>>
>>>>   Sites that are   The prompt doesn't         Won't happen, since
>>>>  trustworthy and   matter, since the user     the sites are honest
>>>> won't do anything   won't be screwed           (by definition)
>>>> bad with the data   either way
>>>>
>>>>  Sites that want   Won't happen, since        The prompt doesn't
>>>>    to abuse your   the sites are dishonest    matter, since it is
>>>>    location data   (by definition)            a lie
>>>>
>>>>
>>>>
>>>>> This establishes a common expectation from users.
>>>>
>>>> That's the problem. It leads users to believe a prompt that can  
>>>> just as
>>>> easily be a lie.
>>>>
>>>> It would be the equivalent of teaching users to give their credit  
>>>> cards
>>>> to
>>>> random strangers based purely on the excuse the strangers give,  
>>>> instead
>>>> of training users to look for other clues, such as the reputation  
>>>> of
>>>> the
>>>> site, to make their decision.
>>>>
>>>> --
>>>> Ian Hickson               U+1047E                )\._.,--....,'``.
>>>> fL
>>>> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
>>>> \  ;`._
>>>> ,.
>>>> Things that are impossible just take longer.   `._.-(,_..'-- 
>>>> (,_..'`-
>>>> .;.'
>>>
>>> ------------------------------------------------------------------------------------------------
>>> 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]
>>>
>>
>
>
>
>

Received on Wednesday, 8 April 2009 13:23:12 UTC