W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2015

Re: Super Cookies in Privacy Browsing mode

From: Rigo Wenning <rigo@w3.org>
Date: Mon, 19 Jan 2015 21:46:03 +0100
To: David Singer <singer@apple.com>
Cc: public-privacy@w3.org
Message-ID: <3428138.XnGAGSgzu7@hegel>
On Monday 19 January 2015 10:35:53 David Singer wrote:
> > It is yet another signal. Ok, it is not DNT, but it follows the same
> > paradigm. I understand the branding issue, so let's call it BND (Be Nice
> > Don’tprofile)

This was a joke as BND is the acronym of the German secret service... 

> But that’s not what it is.  It is NOT asking “don’t profile” it’s asking
> “segregate records”.

This is much better done on the client side. We had nearly running code for 
this in the PrimeLife project. You can see remains here:


There, the architecture is used to track the trackers. But the underlying 
architecture and ideas were basically inspired by user centric identities 
management. So all this was usable in the same way for personae. And of course 
there was also data handling and sticky policies that allowed for data 
segregation. AFAIK SAP implemented it and you can have it as a module. 

> >> b) Unless you are paranoid, you don’t need the feedback. Anything they do
> >> is an improvement on today, and I don’t expect there to be much in the
> >> way of conformance rules, since the details of the handling are very
> >> much specific to the nature of the service.
> > 
> > Nothing to do with being paranoid. "Denn nur was ihr schwarz auf weiss
> > besitzt, könnt ihr getrost nach Hause tragen" says Goethe. And he is right
> > :)
> OK, I don’t mind a general statement of “we support this feature”, and you
> can make this machine-readable if you think it’ll result in any action by
> the UA.  I rather suspect that having it human-readable is enough, that’s
> all.

If only the UA would remember where somebody said he would follow and didn't 
and we could use the feedback as evidence.

As soon as you allow for human-readable declarations, you get a declaration 
from lawyers that they "may" offer the feature (in 22 pages and have their 
fingers crossed behind their back). So the technical reduction of semantics is 
a feature (like having only 140 characters in twitter)

Secondly, you have to define what "segregation" means. If it just means that 
my website is less stupid so that your wife won't find out about the gifts you 
ordered online, than this is rather intelligent web design than a new feature. 
All you need is stateful interaction. 

> > Because, without feedback, you're in non-binding hand waving.
> There is a difference between saying that, for users to know that a server
> supports the feature, they need to say so somehow, and in requiring that
> that statement of support be machine-readable.

In times when ugly cookie - banners trump smart technology like DNT, you'll 
have to offer an added value (legal certainty) in order to get anything. And I 
also think that hardcoding the personae into the one use case is too little. 

> > At this level
> > and point, a cookie would do. And if you're concerned about the cookie
> > being ephemeral, use a super-cookie. It is the feedback message, that
> > changes the nature of protocol and message value, legally…
> Cookies are useless here; cookies are specific to a domain, and this request
> is quite general.  One would need infinite numbers of cookies.

Why? We already have an infinite number of cookies (have you looked? :) 
Because I want to be one person to one site and another person to another 
site. This isn't rocket science at all AFAICT. 

There should be a forget my profile after N days, not a "don't annoy me with 
your stupid revelations from my profile". Data segregation alone is just 
diminishing the annoyance factor, but doesn't add any user control or risk for 
democracy (the values that are behind privacy/data protection)

So having only one persona and human readable declaration is kind of 1996. But 
I know that sadly enough, we are walking backwards. 


Received on Monday, 19 January 2015 20:46:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 January 2015 20:46:46 UTC