RE: geolocation privacy statement strawman

Hi Doug,

It would be really nice if the statement could be so simple.  For all the reasons you cite, I think that in practice, something truly simple wont work.  Ideally, all that is needed is:

"
Privacy of users is super important.  User agents must not reveal private information, unless expressly permitted to do so.  Sites must only use private information for the task for which it was provided to them and must dispose of it once completed, unless expressly permitted to do so.
"

Let the smart UA designers decide what constitutes express permission.  Let the smart site authors decide what uses were intended by users in conveying the private information.  

The problem is that you need to be very clear in communicating intent, both from the UA and from the site so that a user is able to make the right decision.  That's not easy, particularly without established conventions.

We've been on this particular merry-go-round for a long time now.  A superficial treatment of privacy doesn't work.  Not because designers aren't smart, but because they aren't motivated to care.

There need to be really clear, well-established behaviours defined.  In part, this is the responsibility of the UA designer, but the specification plays a rule in establishing expectations.  This work breaks new ground.  Failing to set expectations early only makes it easy for sites to casually disregard privacy.

Cheers,
Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Doug Turner
> Sent: Friday, 6 March 2009 3:36 PM
> To: Henning Schulzrinne
> Cc: public-geolocation@w3.org
> Subject: Re: geolocation privacy statement strawman
> 
> Hi Henning,
> 
> good idea.  however, i do not think in practice it will work out.
> Also, this is what the geopriv people wanted to do -- send some extra
> info with every single geolocation request which says "only retain
> this for x time".  We hashed over this topic at great length at the
> face to face meeting we had in Dec 08.  The notes of that meeting are
> publically avialable (and if they aren't they should be as we agreed).
> 
> In summary, the problem with allowing the user to specify something
> like retention (and retransmission) is:
> 
> 1) in general, users do not know what they should be set.  if they set
> it too low, they could break functionality; if set to high, they give
> up too much privacy (?).
> 
> 2) websites can implement this already using existing standards by
> asking the user "how long can we persist this data".
> 
> 3) it is not enforceable by the user agent.  how do we ensure that the
> site really does what it says it is going to do? clearly, we can't.
> 
> 4) because it isn't enforceable, it sets the wrong user's expectation.
> 
> 5) different regional laws.  For example, what should the default
> actually be for a region.  Maybe the default in one area is too high
> for a more restrictive region.
> 
> I hope this helps.
> 
> Doug Turner
> 
> 
> On Mar 5, 2009, at 8:20 PM, Henning Schulzrinne wrote:
> 
> > This seems like a good beginning, but why not allow users to state
> > how long the information can be retained? "As long as required" is
> > pretty vague. Required by what or whom?
> >
> > On Mar 5, 2009, at 10:56 PM, Doug Turner wrote:
> >
> >> I posted a strawman of the privacy statement here:
> http://dougt.wordpress.com/2009/03/05/my-airmozilla-geo-talk/

> >>
> >> I do not think that this should be included in the draft as-is.  It
> >> is not an official position of Mozilla.  Rather, it is being used
> >> to discuss privacy and geolocation both internally, and in the
> >> community.  I thought it would also be useful here.
> >>
> >> Doug Turner
> >> Mozilla
> >>
> >>
> >
> 
> 

------------------------------------------------------------------------------------------------
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 Monday, 9 March 2009 03:04:30 UTC