Basically +1… more inline
29.01.2015, 16:48, "Robin Wilton" <>:
Hi folks - just catching up on this very interesting thread after a few days off. I think Joe raises two important questions below, under (a) and (c ).
Some comments inline... 

On 26 Jan 2015, at 18:38, Joe Hall <> wrote:

On Mon, Jan 26, 2015 at 4:33 AM, David Singer <> wrote:
Oh dear, I am clearly explaining this badly.

Thanks much for this, David. I definitely see it clearly now.

I think it’s interesting in a number of respects:

a) it’s an improvement on the status quo, where servers are completely unaware of any attempt to be private

I guess traditional client privacy tools see the servers as potential
adversaries, [...] This makes me wonder if existing
tools to segregate "persona"-like elements (accounts on an OS,
profiles for something like Mozilla products) don't do that enough? or
maybe they're too heavy?

Do you see a need for a server-side personae compliance spec, David?
(Or am I thinking too far ahead or making this too complicated?)
Right - David is suggesting, if I understand it correctly, that users should be able to associate an identifier with a given private browsing persona - such that any private browsing sessions initiated under that persona share the same identifier. 
Having thought about this for a while, I think there is a use case for a server-side compliance spec.
Although I think it should aim to be very simple.
Effectively, if the server advertises that it will respect the request, the user might drop out of "private" mode to "persona" mode. This actually allows for more tracking in some ways. But it represents a statement from the server that it won't *unite* two personae which it sees as one, so in practice you get treated as the persona.
It's a bit like having a doctor who happens to be a priest who hears your confession. In each role there is a very strong obligation for confidentiality. Except your average advertising server can be programmed to separate things more easily than a human can.
(That may sound contrived, and it is an extreme analogy. But my *school* doctor was a priest - and taught us…) 
So - as Joe suggests below - I might use persona A when browsing a job vacancies site, and persona B when *cough* ‘looking at content online’… 
My initial reaction was that adding an identifier for each persona just increases the linkability of data gathered by the server. But then, I guess, if the server is recording browser-independent identifiers like IP address, then the “per-persona” identifier does not make things much worse.
b) it’s not asking for *secrecy* at all; servers are at liberty to remember as much as before; there are very few privacy proposals that don’t slide into trying to be secret, and this is one. Privacy is also about where information is exposed, what it is linked to, and so on.

Interesting, would servers be at liberty to simply link all the
personas they identify as likely the same user? (e.g., using fancy
analytics like typing analysis, etc. to tell if two different persona
are in fact the same person) That would seem to be a good part of the
bargain to have here... and perhaps this isn't as complicated in terms
of server compliance as TPWG/DNT?
That is my assumption. I.e. you get a bunch of data that people are otherwise not giving (i.e. value for the server). You don't need very fancy analysis to unify two personae.
But even multiple private browsing sessions are not that complex to tie to the single person behind them, unless the individual goes to a *lot* of effort to defeat it. 
c) it recognizes that privacy is not a binary state — it’s not an either-or (you have it or you don’t); it’s a spectrum, and it’s about perception and control and exposure as much as it is about recording and so on.

Forgive me again... are you saying that by being able to have as many
persona as I can keep track of that I'm "articulating" (a social
science term of art, sorry) different aspects of my being that I'd
rather servers not link together?
That's my take on the approach.
That is rather interesting. For
example, you could have a persona for activities that you want privacy
of a certain level (say me looking at job candidate websites online)
and another persona for activities of a higher level (say, if I'm
looking at content online that I'd rather not have linked to my
not-so-private self)?
I think this kind of persona ‘articulation’ is key to online privacy. It is intimately linked with the way we understand privacy in real life. We represent ourselves differently to, say, our doctor, our employer, our spouse, our children (NB - this is not deception; it’s selectivity. Representing oneself differently according to context does not imply a lack of integrity on the part of the individual).  If users cannot selectively represent subsets of their attributes online, then privacy really is dead. Or at least in a possibly-reversible coma. However, as above, we have to be mindful of the fact that persona separation at the client side can only achieve so much. If servers are able to “re-connect” personas that the user is trying to keep separate (for instance, by linking identifiers over which the user has no control), then the goal of "privacy through persona separation" is at risk. 
What you have is indeed privacy like in the real world - as in "please respect our privacy at this time". People might know more about you than you told them, but they also know that it is bad form to act on that knowledge, or to embarass you with it in front of a third party.
This won't solve the issue of keeping genuine secrets that other people cannot discover. But it potentially does something that many real people actually want.
Charles McCathie Nevile - web standards - CTO Office, Yandex - - - Find more at