- 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: http://ec.europa.eu/justice_home/fsj/privacy/docs/wpdocs/2005/wp115_en.pdf 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. Best, Rigo
Received on Wednesday, 17 June 2009 20:45:03 UTC