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

Jonathan,

#1 - I've responded to #1 in a separate chain.

#2 - I believe the "complexity" is similar between DNT and P3P but across different dimensions of business and site operations.

#3 - I agree that P3P didn't solve all privacy issues but did address automation of user choice when implemented correctly.  Its only when viewed through an expansive view of "all privacy issues" where I'd agree P3P failed, but I'd also suggest that attempting to leverage DNT as a solution for "all privacy issues" is similarly limited in view (and will also result in failure).

#4 - Technology design guidelines?  And you really feel the implementation of DNT will not be complex with this addition?

#5 - I understand your skepticism that industry will engage on privacy-preserving technologies and would suggest we leverage W3C in a separate forum to move these efforts fast forward.  Holding this working group hostage with this agenda doesn't feel like a good outcome for anyone - especially if success is measured by the rate of implementation of DNT across the globe.

#6 - It'll take me time to go back and dig up the many articles that explored LSOs in the middle of the Flash Cookie media run over a year ago (hopefully many on this chain have already seen many of those).  It was in these articles that consumer advocates felt leveraging client-side storage as unfavorable to consumer privacy.

#7 - What privacy risks?  When we remove the use of cross-site data collection to modify a user's experience, can you state a few examples of real-world harms in this area?  Is there an example where this information was used in legal proceeding?  What is the rate of misuse of this information in relation to its presence today?  Anyone can play the "what if" game, but I'd ask that you provide real-world examples where anonymous information that could have been used for online behavioral advertising has ever been used to harm a user in some other context.

#8 - I appreciate you and Sean (and the rest of the working group).  I believe the continued push for forced implementation of untested privacy-preserving technologies will render DNT un-implementable by most web site operators in the world.  I'd like all of our effort in this working group to result in mass adoption across the planet so my focus remains on setting up this outcome and finding the appropriate balances along the way.

- Shane

From: Jonathan Mayer [mailto:jmayer@stanford.edu]
Sent: Monday, February 06, 2012 5:56 PM
To: public-tracking@w3.org (public-tracking@w3.org)
Subject: 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.