RE: Super Cookies in Privacy Browsing mode

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The trouble with fixed UUIDs for this is that they will be used for tracking, cross-domain to boot. Being origin invariant will make it unpopular with brand sites and publishers also, because their customer data will be leaked to any third-party. I know the persona identifier will be mutable and under user control, but most people will not bother to change it or forget to, so it will become permanent for most.

I think making the UA responsible for personae (if that’s the plural) is interesting, because it helps user control, and maybe eventually the abolition of server initiated (and user unaware) tracking.

I do not think it would be hard to come up with a non-trackable persona, i.e. one that varies between requests, using asymmetric crypto. Concatenating a per-request nonce with the UUID then encrypting it with a user specific key, so only those party to the decryption key could determine the UUID, and making the header value different for every request. This would give absolute user control over tracking and cross-party secrecy for sites.


Mike



> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 12 January 2015 23:08
> To: Mike O'Neill
> Cc: W3C Privacy IG
> Subject: Re: Super Cookies in Privacy Browsing mode
> 
> 
> > On Jan 10, 2015, at 4:00 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.4.19.5391 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUt9aoAAoJEHMxUy4uXm2JKf4IALUcqSXigTcAjzVqiy2P0B3I
kQtehja2DAAEyswuRMRjwU3j+NDu4rTpLdBtRYJm9IvpfQnZrUbZjUcElvHpHCFz
US67AwD+bPdMEp8UcnRyuCdtbeeQKmIHbkOdh9Dm3m5xoYtSPZ87cCBtcTTsHMMI
qNIkMi7mGAkij8neRc2cUCc6bPfQzbkUz8SAZ6EStMdd/l+U49UWrpI/qRMWyF/l
ywciLEMr9qvYEDHQrOrwZH/mh56ts+qWvTfvc4ztYAIzh42C9G+8v5L1b6P2jqrU
79DO7+KHE4WKrJKBq6vmvU55rax24jHUURHCsAFy2NAegc2asm61eIMiLPSEUdQ=
=vD4Z
-----END PGP SIGNATURE-----

Received on Thursday, 15 January 2015 15:04:16 UTC