Re: Super Cookies in Privacy Browsing mode

> On Jan 15, 2015, at 12:31 , Nick Doty <npdoty@w3.org> wrote:
> 
> 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?

Yes.

Here’s an example.  A couple of years ago I used ‘private browsing’ on our home computer to look for my wife’s present. Yes, all the history, cookies etc. were cleared of the history.

But when I checked ‘search history’ on Google, of course, there was all the data! Servers are currently unaware that the user is currently trying to do something private; I am suggesting this as a way that they can be aware and nice, without actually impacting their business.

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

I am not trying to be anonymous when I am asking to be private; that’s secrecy and is much much harder.

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

But the server can still think “same UA, same IP address, same OS, same fingerprint => same user who’s just cleared their cookies”. We want the server to think “I should segregate this”.

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

The benefit is being nice to their users, and respecting their wish for privacy. The cost is an increase in the number of ‘users’ (the cheapest way to support this is to treat each persona as separate).

> 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?

No, that’s the problem. At least for us, private browsing mode doesn’t “put you in a green field” or restrict what you can do.  Indeed, *entry* to private browsing might do no more than snapshot the local state.  It’s *exit* that discards the current state and reverts to the prior saved snapshot.  For the server, exit gets you back to your ‘anonymous’ persona. Hence the permission to initialize any server state from the anonymous persona, but activity adds to the records under the named persona.

> 
> Thanks for sharing ideas,

Thanks for discussing!

> Nick

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 16 January 2015 00:35:54 UTC