- From: David Singer <singer@apple.com>
- Date: Thu, 15 Jan 2015 10:19:59 -0800
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: W3C Privacy IG <public-privacy@w3.org>
Hi Mike Briefly, more inline: I think you misunderstand the proposal. Not all privacy concerns secrecy, and this is an idea that explicitly doesn’t attempt to keep anything *secret* but instead asks to control its *exposure*. > On Jan 15, 2015, at 7:03 , Mike O'Neill <michael.oneill@baycloud.com> wrote: > > -----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. You are assuming that UUIDs will be shared between devices and re-used, and while that’s neither expected nor forbidden — it’s something a group of user-agents may do. Yes, a user’s UUID set could be shared and named, so that on another device they can say “resume searching for my partner’s birthday present” but that’s a choice. In the simple case, a new UUID would be coined each time ‘private browsing’ is enabled. > Being origin invariant will make it unpopular with brand sites and publishers also, because their customer data will be leaked to any third-party. Not sure what you mean here. To enable the re-use case above, my suggestion is that the IDs are not ‘within the context of a single UA’ but instead globally unique, but that’s all. > 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. No, exactly the opposite of what I expect: when you turn on ‘private browsing’ a new persona is made, and that persona ID is forgotten at the end of that private browsing session and not re-used. > > 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. This is completely orthogonal to whether the user is being tracked, deliberately so. This is not a request ‘please don’t track me’, this is a request ‘please keep this activity separate’. ‘Please don’t track me is, I believe, being worked on in another WG’. :-( > > 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. Not a goal of mine. I’d rather attack the tracking question and the privacy-of-a-session question independently. Indeed, I think that we tend too easily to fall into the ‘to get privacy I need secrecy’ trap, whereas there are aspects of privacy — when is this data exposed?, what and who is it linked to? — which are about other aspects of privacy that deserve more attention. > 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----- > > David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 15 January 2015 18:20:28 UTC