- From: Alan Chapell <achapell@chapellassociates.com>
- Date: Thu, 02 Feb 2012 12:17:25 -0500
- To: Jonathan Mayer <jmayer@stanford.edu>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
I agree with much of what Shayne said - but will add the followingŠ. It seems like much of the discussion (on this topic at least) is a bit one-sided. If we're going to ask industry to granularly explain why certain data uses pass Jonathan's Compelling need test, then it seems fair to ask Jonathan (and/or others) to be able to granularly demonstrate (for example) how and to what extent client side frequency capping approaches work. The Stanford team has clearly done some fantastic work here, but a test using a relatively small game network may or may not translate perfectly outside of the testing environment. And I think its fair to ask for a clear demonstration of how these concepts can be applied by both the MSFT's and Googles, as well as tier 2 and tier 3 companies. On that note, I'm concerned that much of what we're talking about implementing will create all kinds of technical and logistical issues for companies who don't have the resources of a Yahoo or Adobe. Has the group considered bringing in some invited experts from the long-tail of industry to help ensure that this is something that they can implement without hiring an army of tech consultants? Cheers, Alan Chapell Chapell & Associates 917 318 8440 On 2/1/12 9:45 PM, "Jonathan Mayer" <jmayer@stanford.edu> 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 Thursday, 2 February 2012 17:18:01 UTC