- From: Jonathan Mayer <jmayer@stanford.edu>
- Date: Fri, 3 Feb 2012 16:17:28 -0800
- To: Matthias Schunter <mts@zurich.ibm.com>
- Cc: Jeffrey Chester <jeff@democraticmedia.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Here are a few exceptions that I believe could clear the hurdle. -Content serving -Contextual personalization -Outsourcing -Protocol logs for debugging -Unidentifiable data (including aggregated data and client-side frequency capping) -View fraud prevention through a stepped response On Feb 2, 2012, at 7:06 AM, Matthias Schunter wrote: > Hi Jonathan/Jeff, > > what exeptions do you see at this point that are likely to satisfy this > catalogue? > what are viable candidates where only more data/input/answers is needed? > > Regards, > matthias > > > > > |------------> > | From: | > |------------> >> -----------------------------------------------------------------------------------------------------------------------------------------| > |Jeffrey Chester <jeff@democraticmedia.org> | >> -----------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> >> -----------------------------------------------------------------------------------------------------------------------------------------| > |Jonathan Mayer <jmayer@stanford.edu>, | >> -----------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Cc: | > |------------> >> -----------------------------------------------------------------------------------------------------------------------------------------| > |"public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org> | >> -----------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> >> -----------------------------------------------------------------------------------------------------------------------------------------| > |02/02/2012 03:34 PM | >> -----------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Subject: | > |------------> >> -----------------------------------------------------------------------------------------------------------------------------------------| > |Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49) | >> -----------------------------------------------------------------------------------------------------------------------------------------| > > > > > > I agree with Jonathan's thoughtful discussion of the exemption issue. I > recognize this is a delicate matter, and it will require continued dialogue > to properly balance the goal's of DNT with traditional digital marketing > (and advertising generally) business practices. I believe that if we > follow Jonathan's outline, we can achieve our collective goals. > > Jeff > > On Feb 1, 2012, at 9:45 PM, Jonathan Mayer wrote: > > The working group has made great progress on the broad contours of > the definition document, and the conversation is shifting to specific > exceptions. With that in mind, now seems an appropriate time to > articulate my views on when and how exceptions should be granted. > > At a high level, we all agree that exceptions reflect a delicate > balance between consumer privacy interests and commercial value. > There are, no doubt, substantial differences in opinion about where > that balance should be struck. I hope here to clarify my approach > and help others understand why I find recent proposals for blanket > exceptions to be non-starters. > > In my view, any exception must satisfy this rigorous six-part test. > > 1) Specifically defined. An exception must clearly delineate what > data may be collected, retained, and used. If a proposed exception > is purely use-based, that needs to be extraordinarily explicit. > > 2) No special treatment. We should grant or deny an exception on the > merits of how it balances privacy and commerce, not a specific > business model. > > 3) Compelling business need. A bald assertion that without a > specific exception Do Not Track will "break the Internet" is not > nearly enough. I expect industry stakeholders to explain, with > specificity, what business purposes they need data for and why those > business purposes are extraordinarily valuable. > > 4) Significantly furthers the business need. I expect industry > participants to explain exactly how and to what extent a proposed > exception will further the compelling business needs they have > identified. In some cases cases, such as security and fraud > exceptions, this may call for technical briefing. > > 5) Strict minimization. If there is a privacy-preserving technology > that has equivalent or nearly equivalent functionality, it must be > used, and the exception must be no broader than that technology. The > burden is on industry to show that a privacy-preserving alternative > involves tradeoffs that fundamentally undermine its business needs. > In the context of frequency capping, for example, I need to hear why > - specifically - client-side storage approaches will not work. In > the context of market research, to take another example, I would need > to hear why statistical inference from non-DNT users would be > insufficient. > > 6) Balancing. There is a spectrum of possible exceptions for any > business need. At one end is a pure use-based exception that allows > for all collection and retention. At the other end is no exception > at all. In between there are infinite combinations of collection, > retention, and use limits, including exceptions scoped to > privacy-preserving but inferior technologies. In choosing among > these alternatives, I am guided by the magnitude of commercial need > and consumer privacy risk. I am only willing to accept an exception > where the commercial need substantially outweighs consumer privacy > interests. > > I understand example exceptions may be helpful in understanding my > thinking, so here are a few from the IETF Internet-Draft. > > 3. Data that is, with high confidence, not linkable to a > specific > user or user agent. This exception includes statistical > aggregates of protocol logs, such as pageview statistics, > so long > as the aggregator takes reasonable steps to ensure the > data does > not reveal information about individual users, user > agents, > devices, or log records. It also includes highly > non-unique data > stored in the user agent, such as cookies used for > advertising > frequency capping or sequencing. This exception does not > include > anonymized data, which recent work has shown to be often > re- > identifiable (see [Narayanan09] and [Narayanan08]). > 4. Protocol logs, not aggregated across first parties, and > subject > to a two week retention period. > 5. Protocol logs used solely for advertising fraud detection, > and > subject to a one month retention period. > 6. Protocol logs used solely for security purposes such as > intrusion > detection and forensics, and subject to a six month > retention > period. > 7. Protocol logs used solely for financial fraud detection, > and > subject to a six month retention period. > > > I would add, in closing, that in difficult cases I would err on the > side of not granting an exception. The exemption API is a policy > safety valve: If we are too stringent, a third party can ask for a > user's consent. If we are too lax, users are left with no recourse. > > Best, > Jonathan > > > > >
Received on Saturday, 4 February 2012 00:18:01 UTC