The state of Do Not Track

It's time to take stock of the last two months in Do Not Track. Since the White House announcement in February, a lot has happened, both in the policy conversations that surround the work in the W3C Tracking Protection Working Group, and in the working group itself.

Late last fall, the W3C Tracking Protection Working Group had published extended outlines of the Tracking Preference Expression and Tracking Compliance and Scope specifications as First Public Working Drafts. Tracking Preference Expression is the specification that lays the technical groundwork for a Do Not Track header, and related JavaScript APIs, to permit users to express a preference not to be tracked online. The Tracking Compliance and Scope specification says what the tracking preference actually means, and what Web sites are expected to do when they encounter a user with a preference to not be tracked.

After the group's meeting in late January in Brussels, we followed up with a more substantive second round of drafts.

Since then, we've seen vigorous discussion of what Do Not Track should be, both within the Working Group, and on the policy stage. The White House's announcement of the US government's privacy initiative in February, and the publication of the FTC's report on Protecting Consumer Privacy were the most prominent events to call out the importance of Do Not Track for the future of privacy online. And in Europe, the debate about the "Cookie Directive" has been heating up, as we approach the end of Neelie Kroes' one year challenge for industry to agree on Do Not Track.

The Tracking Preference Expression specification has been on a steady path toward completion since the beginning of the Group. We have agreement that the group is pursuing an approach that permits three different Do Not Track states: A user has explicitly consented to tracking; a user has explicitly chosen not to be tracked; and, a user has expressed no preference. With this approach, the expected site behavior when users have not expressed a preference would not be covered by the specifications developed by the W3C Tracking Protection Working Group. In the absence of regulatory, legal, or other requirements, servers may interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances.

And we now have the definition of a mechanism that can be used by sites to tell user agents whether they comply with Do Not Track, and we have worked out most of a JavaScript API that permits sites and users to communicate about Do Not Track.

For the Compliance and Scope specification, we came out of Brussels with no fewer than five competing proposals on core aspects of the work.

Fast forward to the outcomes of the group's latest face-to-face meeting (minutes) in Washington, DC -- thanks, Microsoft, for hosting 60 people on K Street! The momentum of the conversation is now focused on two proposals, and we are seeing tentative agreements on a number of important topics:

• The fundamental shape of first and third parties (think publishers and advertisers). First parties will have fewer responsibilities out of Do Not Track than third parties.
• How the specification deals with service providers that act on behalf of another party.
• The basic idea that certain data can be collected even with Do Not Track active, to support essential business needs.
• The basic notion that server logs can be held in raw form for a limited amount of time.
• Data that's not linked to a person or their user agent (e.g., the collective behavior of a sufficiently large set of people) can be used.

But some important disagreements remain for the group to work through: What is the exact extent of a party? And, for permitted uses of data, what exact mechnanisms are permissible?

Finally, some areas that will be important for the real-life shape of Do Not Track are out of scope for W3C's work. Particularly noteworthy: The Tracking Protection Working Group's charter explicitly rules user interface out of scope. UI is an area in which different browser vendors differentiate within the marketplace, and at times, it will depend on localization and other choices well outside the realm of what is suitably discussed in a standards working group.

Next up, then, hard work for everybody involved, and agreements on the remaining issues. We look forward to more agreements, resolutions, and progress over the months of May and June, leading up to the group's next meeting in late June.