Re: Super Cookies in Privacy Browsing mode

> On Jan 17, 2015, at 22:58 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I agree privacy does not require secrecy. Actually I think confusing them could lead to a catastrophic collision, creating a bad result for everyone; see http://blogs.wsj.com/digits/2015/01/16/obama-sides-with-cameron-in-encryption-fight/
> 
> But some form of anonymity could be a useful way forward. Not totally invisible anonymity but a way to operate with user managed identity, which is why I am interested in your Persona header.

OK, I would enjoy proposals that attack this question — how to be anonymous online — but this suggestion (persona) is about control over information and where it’s visible, not about anonymity.  I’d rather not mix the two.

Have you looked at the TAG draft, which (IMHO) also tries to mix ‘private browsing session’ with anonymity?

> 
> In my opinion police should be able to identify and monitor wrong doers (with a proper warrant targeting individuals not whole populations) but users should be able to present multiple identities in different contexts. You may be prepared to share a low entropy audience identity to advertisers (e.g. "aging male geek currently resident in the UK"), but not your Facebook account or friends list to thousands of unknown companies. The user should always be in full control of who gets data about them, but not by being invisible to the rule of law.

OK, again, my suggestion does not contain any element of secrecy or anonymity. The same information flows are happening, and the recording of information remains controlled by othe rfactors — protocols, laws, agreements, and so on.

> 
> I like the potentiality of the Persona concept but not the UUID bit.

OK.  The UUID came from realizing that setting a boolean ‘I am in private mode’ (which has been suggested), results in unpleasant outcomes:
* perhaps you only have two personae — the private one and the public one. That’s not nice; the more private browsing you do, the larger the dataset behind that persona becomes, and it contains unrelated topics and parts of your life.
* perhaps in private browsing mode there are attempts to make you more untraceable, and so on.  But that’s likely to get in the way of ‘normal operation’ on the web

I selected UUID because they are easily made, and yet provide for continuity of a session.  I realize that they work against trying to make me less traceable, as they (anotehr) unique identifier.  But as I say, I think we’ll need to work on anonymous browsing separately (and it’s a much harder problem).


> 
> 
> 
>> -----Original Message-----
>> From: David Singer [mailto:singer@apple.com]
>> Sent: 16 January 2015 00:35
>> To: Nicholas Doty
>> Cc: Mike O'Neill; public-privacy (W3C mailing list)
>> Subject: 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.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (MingW32)
> Comment: Using gpg4o v3.4.19.5391 - http://www.gpg4o.com/
> Charset: utf-8
> 
> iQEcBAEBAgAGBQJUu1mUAAoJEHMxUy4uXm2J0OoIAMiJAMwa8tahJkVUdW0H2lk6
> ifgpVbGGQzrnB2jD8ztYuvAuyB3SAS4TSBrRKZu9NgbfAZz6OL8g2xD2DCx4W4DH
> k/5bAWBWtz1OrOjVsH4laCLb2ewYHv6B3LwKoOrE93uFjz8Jx83kH0cXT//yALAo
> kCHUw46TOyAPtlaQ9K9BxykJ8CnSumF0dvK9hy9wHLtiOjNICsh3l5qhQ2+J7Gyn
> j+NApWEOcABF4muno4qw54vFurMGG15wxnIVlLE8zAch/dNR6NxqalkzcMRdTS2T
> zMKfY4yBwzyZVWtH0wLDkGuhzp5lIZYssS0wpZ4xsQhD2Ra42FLco0q+WsHPpTQ=
> =FukM
> -----END PGP SIGNATURE-----
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Sunday, 18 January 2015 18:14:48 UTC