Re: Super Cookies in Privacy Browsing mode

Hi David,

> On Jan 12, 2015, at 3:08 PM, David Singer <singer@apple.com> wrote:
> 
> 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.)

I think it’s definitely an interesting idea. I think there may be similar thinking behind the advertising identifier proposals, although I’m not sure the exact details on those.

I share some of Mike’s concerns. Even if some servers could use a change in Persona header to help users separate their shopping activity and help them avoid seeing ads they wouldn’t like, other servers (intentionally or unintentionally) would use the new unique and persistent user identifier to conduct tracking the user might not want. That could (*could*) undermine work done to prevent passive fingerprinting of users without their knowledge.

The use case seems very relevant though. Personally, I use private browsing modes more than anything as a way to get a new, short-term cookie jar. "What does this site look like when I’m not logged in?" "I’m using my friend’s computer but don’t want to be logged into their Facebook account while I’m browsing.” “Can I log into my email for a minute on your computer?” etc.

Are there cases where a Persona identifier header would be more useful than just clearing or separating the “cookie jars” or other stores of local state? As in the case reported in the Ars Technica article, the implemented fix was just treating HSTS records as state that shouldn’t be persisted into private browsing mode. As in previous “evercookie” cases, user agents that can clear all (or most) state mechanisms simultaneously can mitigate the concern. I think HSTS is a more difficult case because persisting the HSTS records is typically a way of increasing the user’s security against downgrade attacks.

> 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).

Yeah, I think these are good use cases. Again, I expect that some of these are implemented now by clearing cookies / local state when a new guest logs in. Firefox has a “profiles” feature that can be used for that purpose (it also separates the add-ons, bookmarks, etc. between different users of the same machine): https://developer.mozilla.org/en-US/docs/Mozilla/Multiple_Firefox_Profiles <https://developer.mozilla.org/en-US/docs/Mozilla/Multiple_Firefox_Profiles>

To your earlier point:
> I have some ideas around codifying ‘private browsing mode’ and how to communicate ‘heh, I am trying to be private here!’ to servers.  Is this a topic of interest to others?

Would servers see a benefit from an indication that the user is in a private browsing mode (however defined, but in this case, particularly for the mode of not persisting state on the local machine)? Maybe they could avoid downloading files or storing certain types of state — rather than asking users to check a box when they’re on a public computer, if they’re in guest/private mode the site would know that this wasn’t going to be a device with persistence for the user. Related: are private browsing modes in user agents observable by servers today?

Thanks for sharing ideas,
Nick