- From: Henning Schulzrinne <hgs@cs.columbia.edu>
- Date: Sun, 8 Mar 2009 23:22:27 -0400
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: "Doug Turner" <doug.turner@gmail.com>, <public-geolocation@w3.org>
Agreed. I admit that I find the reasons offered to be less than convincing. A user-requested value is no more (or less) enforceable than the various privacy statements that are written in ten-page legalese, can be changed by the site at any time and no user reads. The "breaks functionality" objection is also dubious: It's very easy for the web site to return an error message "Sorry, we need your data for at least 3 days, otherwise our system won't work". That way, users know exactly what they are getting into and can either increase the retention permission or go elsewhere. Obviously, a web site can discard data earlier, so the "set too high" argument is not terribly convincing. I don't see the need for regional defaults - users pick what they want, and the upper limit is min(user choice, local regulations, provider privacy statement). That seems pretty easy to understand and provides protection at least equal to the data protection laws governing the transaction today. In many circumstances, asking is difficult (limited UI devices, API- based services that don't have web interfaces, or language issues). The whole point of having very basic rules is that the user does not have to answer this question again and again for each service. It is pretty clear that users care about data retention - see the recent Facebook debacle. Doug, has anybody actually *asked* users what they want? During our earlier discussions, we had extensive exchanges with people who deal with privacy issues professionally, so I put some stock in their recommendations. I'd really like to do better than whatever is most convenient for developers, given that the industry track record on privacy isn't all that exemplary. (You can read about the Verizon example of "sneaking in" disclosure on Slashdot today, if you care.) Henning On Mar 8, 2009, at 11:03 PM, Thomson, Martin wrote: > 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:23:08 UTC