Re: Geopriv compromise proposal

On Fri, 12 Jun 2009, Richard Barnes wrote:
>
> In advance of the Last Call, I wanted to make one more pass at trying to 
> arrive at a compromise on the Geopriv idea of including rules alongside 
> a position object.  A proposed update to the draft, and a diff, are 
> posted at the following URLs: 
> <http://geopriv.dreamhosters.com/w3c/spec-source-priv.html> 
> <http://geopriv.dreamhosters.com/w3c/spec-source-diff.html>
> 
> The only change that these documents make is to add a "rules" element to 
> the "Position" interface that allows the user to make additional grants 
> of permission, beyond what the Privacy Considerations allow.  For 
> example, the rules element can specify that it's ok for the recipient to 
> retransmit a location or store it.

This seems to suffer from the same problem as the proposal that was voted 
against previously, namely, it gives the user a false sense of security.

I think this is *very* dangerous from both a privacy and security 
standpoint. I understand that you want to provide the user with more 
control and help the user get more privacy, but I firmly believe that this 
proposal would do nothing but worsen the current situation.

Specifically, if browsers do implement what you describe, then they would 
end up showing the user an interface that appears to be a user-agent 
enforced privacy preference panel, but the user agent would have _zero_ 
ability to enforce these privacy settings. Most well-intentioned sites, 
and _all_ evil sites (the ones where privacy leakage is an issue in the 
first place) would just ignore the user's requests, but the user, if burnt 
in this way, would end up blaming the _user agent_ instead of the site, 
because it was the user agent that offered to protect the user's privacy.

And this brings us to the security danger: this proposal would undermine 
the user's trust in the user agent, which would lead to the user ignoring 
TLS certificate warnings, phishing detection warnings, warnings regarding 
security elevation requests, and so forth. User agents would find their 
users dramatically more frequently exposed to highly hostile content and 
would find their ability to protect the user from this content effectively 
neutralised.

I cannot emphasise enough how harmful this would be.


> The most important thing to note about this proposal is that it is 
> purely optional for both UAs and recipients: UAs don't have to set 
> privacy rules (if the user is OK with the default privacy 
> considerations)

Which UAs are interested in implementing this? We need two complete 
non-experimental implementations of the spec for the spec to exit the 
Candidate Recommendation stage; who has committed to implementing this?


> and recipients don't have to look for privacy rules (if they're willing 
> to stay within the existing privacy considerations).

Realistically, recipients don't have to look for privacy rules at all, 
even if they're going to totally ignore the spec. An evil site could 
totally just keep the user's information forever and sell it at $10 a user 
to the highest bidder on the black market along with the user's credit 
card details (this happens today).

And non-evil sites that have no interest in harming the user in any way 
might take extreme precautions with the data and still store it forever, 
in a manner that is usable by the user only, for instance. Sites could 
decide they don't need to ask for permission, without being evil -- for 
instance, a site could decide that it's in the user's best interests to 
reuse the information for a purpose the user wasn't aware of: e.g. the 
user could be expecting his location information to be used just for 
geotagging photographs, but the site could also use it to theme the 
aplication's look and feel to match the user's location.


> All the software out there that conforms to the current spec also 
> conforms with the modified spec.

This just further guarantees that it will be ignored. If a site is faced 
with some browsers that expose this permissions UI and others that don't, 
then they won't use it. They'll either ask the user directly themselves 
(which is all they have to do anyway and provides no less privacy, and 
more security on the long run, than having the user agent do it), or 
they'll just assume the user is ok with it implicitly.


> These rules just offer another avenue for users to provide permissions 
> to web sites.

What's wrong with the sites just asking the users directly? What more does 
this add?


> The major benefit of these rules is to save new sites (or newly 
> geo-enabled sites) the effort of crafting extensive privacy policies and 
> interfaces, while still allowing them to do more interesting things than 
> the default privacy considerations allow.

Offering a checkbox and maybe a dropdown to say how long information can 
be stored is not much effort. This is a false economy.


> Given the minimal impact of these changes, and the large possible 
> benefit, I would like to propose that the changes be incorporated into 
> the current draft before last call.

Personally, I strongly reject this proposal on the grounds described above 
-- that this would dramatically damage the trust users have in user agents 
and would on the long term lead to a significantly worsened user 
experience in surfing the Web in terms of privacy and security.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 12 June 2009 17:52:51 UTC