W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2009

Re: Geopriv compromise proposal

From: Rigo Wenning <rigo@w3.org>
Date: Wed, 17 Jun 2009 22:44:19 +0200
To: public-geolocation@w3.org
Cc: Thomas Roessler <tlr@w3.org>
Message-Id: <200906172244.26502.rigo@w3.org>
On Wednesday 17 June 2009, Maciej Stachowiak wrote:
> This is part of the reason we have been hesitant to implement P3P
> in   Safari. It does not provide any substantive privacy
> protection, and may give the user a false sense of security. Our
> only requests to support P3P have been from sites that would like
> to do things we may consider privacy-violating (they would like us
> to also relax our default third-party cookie policy for sites that
> use P3P).

P3P delivers information. You say displaying this information creates 
a false sense of security. HTML delivers information. Thus it could 
create a false sense of security by providing convincing lies. TLS is 
transport security and the padlock created a false sense of security, 
you shouldn't have implemented TLS and remove HTML from your codebase.

Hm, the concept of "third party cookies" is a pure IE invention and is 
not part of P3P. But you can't judge whether a cookie is good or bad 
until you know what it is used for. Large sites invested a lot in 
making their cookies work again. That's most probably why you were 
approached by those sites to have Safari's behavior aligned with IE. 
There was a huge benefit for privacy in having sites enable P3P as 
they had to rethink all their processes and make them privacy friendly 
in order not to look too bad. Just blocking 3rd party cookies is 
killing cookies and pushing the tracking techniques into other methods 
like web bugs (yes a good P3P agent would detect them, Safari still 
doesn't) and cookie-values in URIs.

The "lack of enforcement" is just some mantra from ages ago, 
neglecting legal consequences of lying to people. Lying to people can 
be very expensive. Not only in sanctions and fines, but even more so 
in loss of reputation. And P3P was pretty good at helping to detect 
those lies. 

But I'm not arguing about P3P, I argue about extensibility and the 
policy languages that will come.

I just suggested to introduce a single element/attribute that would 
allow to extend the privacy features in the future without obligation 
to implement now. So my goal is to help you avoid privacy clashes by 
implementing this specification. I also wanted to help you with this:


If the group thinks that this is all rubbish and that the API can just 
do with some lukewarm privacy statements as a fig leave, I can't help 
anymore and Process and social reaction and reality will prove you or 
me right. 



Received on Wednesday, 17 June 2009 20:45:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC