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

Re: Super Cookies in Privacy Browsing mode

From: David Singer <singer@apple.com>
Date: Mon, 12 Jan 2015 15:08:12 -0800
Cc: W3C Privacy IG <public-privacy@w3.org>
Message-id: <AB00FC4B-D03D-4FD8-89DB-464C670E922C@apple.com>
To: Mike O'Neill <michael.oneill@baycloud.com>

> On Jan 10, 2015, at 4:00 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> Hash: SHA1
> Hi David,
> I am definitely interested in these ideas, can you give a summary?
> Mike

sure.  try this.

The user-agent can send an optional HTTP header ‘Persona:’ whose value is a suitable machine-generatable distinct identifier (e.g. a UUID). If the header is absent, the user is operating under their default (unlabeled) persona, which is distinct from all the identified personas, which in turn are also distinct from each other.  A user and their user-agent may return to a persona at any time, or continue using a persona for any length of time. A persona identifier is expected to be universally unique, not contextualized to the current user-agent or device.

Servers respecting this are requested to ensure that the labeled personas leave no trace or influence on each other or on the unlabeled persona.  For example, activity under one persona should not affect the ads shown under a different persona; any history records that the user can see should be distinct for each persona; and so on. (It’s OK for your unlabeled persona to be reflected in labeled ones, but optional; if servers wish, they can initialize a named persona from the default, un-named one, when they first see it.)

Server implementers may choose how long they retain records relating to separate personas, just as they do for today’s default persona.

This is NOT a request to stop tracking or keeping records; that is an orthogonal question that is covered by activities such as do-not-track, cookie directives, and so on. This is about giving users control of their privacy by controlling what gets linked to what, and exposed when.

We do not think it is particularly necessary or valuable to have a machine-readable means of discovery over whether servers support this feature.  Any support that they provide is an improvement on today’s experience, where servers are unaware that users are trying to be private. Claims of support for this feature are probably better conveyed in advertising or other human-readable ways.

This feature might also be valuable for shared terminals; for example, in libraries, airline lounges, internet cafes and the like, a new persona can be minted each time the terminal is unlocked for a new session.  Libraries might tie the persona to the library card, so users returning get re-linked to their online history and so on. It might also be a lightweight replacement of logging-in, for browsers on shared devices  — a browser might have a simple way of saying which family member it is right now (e.g. a pull-down menu).

* * * *

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

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.

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.

David Singer
Manager, Software Standards, Apple Inc.
Received on Monday, 12 January 2015 23:08:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 12 January 2015 23:08:42 UTC