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

Re: Geopriv compromise proposal

From: Andrei Popescu <andreip@google.com>
Date: Wed, 17 Jun 2009 22:44:41 +0100
Message-ID: <708552fb0906171444r32d53c5lb837b24c517df67d@mail.gmail.com>
To: Rigo Wenning <rigo@w3.org>
Cc: public-geolocation@w3.org, Thomas Roessler <tlr@w3.org>, Maciej Stachowiak <mjs@apple.com>
On Wed, Jun 17, 2009 at 9:44 PM, Rigo Wenning<rigo@w3.org> wrote:
> 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.

Rigo, I will file an issue tomorrow to mark the fact that we had this

Given the feedback in this thread, as well as the discussion we had in


I have not incorporated into the spec the changes that you requested.
I think the Chairs should now review the feedback and decide on this
issue or let us have the vote as Doug requested. We really need to
move on.

Received on Wednesday, 17 June 2009 21:45:21 UTC

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