Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

In the interest of keeping things readable, here's a consolidation of issues on the thread and my responses.

1) Without broad exceptions, Do Not Track will be difficult for millions of small publishers to implement.

Shane:
> [W]e have ~1 million web sites around the globe that will need to implement DNT, ranting from the very large . . . to the very small (small bloggers who are reliant on ad revenue to pay their mortgage and will feel the impact of revenue loss more acutely) . . . .


Mike Zaneis:
> [W]e cannot ask millions of websites (certainly well over the conservative estimate Shane gave of approximately 1 million) to reconfigure their servers to meet the W3C standard.

I see very little implementation burden on publishers, large or small.  The group has already agreed that first parties (including publishers) will only be prohibited from circumventing the standard through deliberate data sharing.  Backend data sharing is uncommon, and frontend data sharing can be easily prevented by third parties.  In fact, at least two large advertising data providers already stop their frontend data sharing when they receive a Do Not Track header—and they found implementation trivial.  I do not believe there is substantiation for the technical claim that current proposals would require "millions of websites . . . to reconfigure their servers."


2) If we call for complex privacy-preserving technologies, Do Not Track will be a flop like P3P.

Shane:
> As part of the community attempting to implement P3P, it failed due to difficultly to implement (no flexibility, no response structure, etc.).


Alan:
> Given that one of the chief criticisms of the P3P standard was that its complexity made it difficult to implement correctly, I think its worth asking the question whether or not we are at risk of repeating those mistakes.

I'm certainly sensitive to complexity of all kinds, but I don't think the P3P analogy holds up.  P3P was "complex" in that it required significant legal, business, and technology customization for each website.  Privacy-preserving technologies, on the other hand, are "complex" in that they require carefully designed algorithms and carefully engineered software.  But, once built, a privacy-preserving technology can be deployed on many sites.  There are great JavaScript libraries for DOM manipulation (e.g. JQuery), browser support (e.g. Modernizr), and many other common purposes.  Do Not Track should encourage similar initiatives for privacy-preserving advertising, whether from an open source community, a self-regulatory group, or a trust provider.

Moreover, unlike P3P's technology mandates, Do Not Track would not require a third-party website to deploy a privacy-preserving technology.  If it finds the implementation onerous, it can simply forego the benefit of that technology.  Whatever the challenge of the privacy-preserving technology, stopping data collection is quite straightforward.

A final point: while P3P was a failure for first-party websites, the relevant population for Do Not Track is third-party websites—where P3P is widely implemented.  See Leon et al.'s paper "Token Attempt: The Misrepresentation of Website Privacy Policies Through the Misuse of P3P Compact Policy Tokens."


3) P3P did/did not adequately protect user privacy.

Jeff:
> None of the leading privacy groups at the time, with a few exceptions, saw P3P as an effective way to address data tracking, targeting.

Shane:
>  [P3P] absolutely protected privacy when implemented correctly.


Whatever the merits of the technical design, I think all agree that P3P as currently deployed does not provide users with adequate privacy controls.


4) We should not include technology-specific exceptions.

Sean:
> I would say that my more general point (which is perhaps more useful) is that we should not be prescribing technologies that have not been tested at scale in the context of the compliance doc.


Instead of calling for a specific technology, an exception could delineate a set of design guidelines.  That would be completely fine by me.


5) Let's start with blanket use-based exceptions and work our way towards privacy-preserving technologies.

Shane:
> Hopefully the conversation will continue from here and we'll figure out a way to start at use-based exceptions and develop a process by which technology solutions become the best practice as soon as they're available at scale.


I'm very skeptical that third-party websites will develop new privacy-preserving technologies.  As an empirical matter, I am unaware of a single privacy-preserving technology that has been deployed by the third-party display advertising industry (writ large) in its fifteen or so years of existence.  The general trend has been, on the contrary, towards more collection and use of personal information.  It doesn't take much imagination to see why; there's perceived value in personalization and market understanding, while privacy-preserving technologies require valuable R&D resources and don't contribute to the bottom line.  I don't mean this as a slight against online advertising businesses; they're in a competitive and growing industry, with countless other priorities.

Even if the incentives were there, I don't believe there are fundamental discoveries in privacy-preserving technology waiting around the corner.  Researchers have identified a fairly small and stable set of building blocks for privacy-preserving technologies (including client-side storage, dropping data, crypto, and query-response APIs).  While the permutations of the building blocks can vary substantially between proposals, current objections are targeted at the building blocks—and therefore go to all possible designs.

Taking the objections that have been raised at face value—I would reiterate that I don't believe there are nearly so significant implementation challenges as some have claimed—I see two paths forward for "operational purpose" exceptions.  First, we can nix the exceptions altogether, as I discussed in an earlier email.  That seems an unnecessarily bad outcome.  Second, for certain "operational purposes" we can give privacy-preserving design parameters and establish a path to adoption for privacy-preserving technology.  That path could involve a grandfathering period or other creative policies.  But it has to include incentives for developing privacy-preserving technologies, and it has to account for the very likely eventuality that better alternatives will not be found.


6) Privacy advocates are arguing that local storage is a non-starter.

Shane:
> There are many privacy advocates that have argued leveraging local stores . . . are NOT consumer privacy protective.


I'm unsure whom this refers to.  I have heard the claim from advertising companies before (Google in particular), but not privacy advocates, let alone many privacy advocates.  Could you provide some pointers Shane?


7) Where's the privacy problem if we prevent profiling?

Shane:
> [W]hat are the counter arguments . . . for allowing the already stated exceptions?  Especially since none of these allow the profiling (tracking) of a user's activities into a profile for use to alter the user's experience.


Roy:
> I am not following the part where it is assumed server-side frequency capping cannot be done while preserving privacy. If we are assuming that the server is a good actor, then there should be ways to store the data such that it is no more of a privacy concern than using the network.


I believe a third party's collection of a user's browsing history across unrelated websites poses serious privacy risks to users.  From the group's conversations, it's clear that I'm far from alone in that assessment.


8) I'm refusing to compromise.

Shane:
> If Jonathan's approach is the end of the compromise process, I'm afraid W3C's DNT is DOA.


Nonsense.  My focus on privacy-preserving technologies has had the very purpose of achieving compromise.  I greatly appreciate that Sean recognized as much.