Web Policy

Users hold widely varying preferences on web tracking.¹ Some don’t mind the practice. Some object to it entirely. Many trust certain organizations to follow them around the web.

Do Not Track accomodates these divergent preferences in two ways. First, browsers and other user agents include an option for universally signaling a preference against tracking (“DNT: 1”). Firefox, Internet Explorer, and Safari have all integrated this feature, and Chrome will support it by the end of the year. Second, a user can configure exceptions to the universal signal. Some websites may choose to build a proprietary “out-of-band” exception mechanism, using ordinary web technologies, that trumps the “DNT: 1” signal. The Do Not Track Cookbook includes an example of how a Facebook out-of-band exception mechanism might appear.

The W3C Do Not Track standard will provide another option: a simple JavaScript interface that allows a website to request an exception, paired with a signal that some tracking is allowed (“DNT: 0”).

There are many benefits to managing Do Not Track exceptions through the browser.

• Avoids Duplication of Effort. Browser vendors implement an exception mechanism once. Websites can then take advantage of the mechanism with just a few lines of code.
• Persistence. A user is unlikely to accidentally clear browser-based exceptions, in contrast to cookies and other out-of-band exception storage mechanisms.²
• Centralized Management. Users can adjust all their Do Not Track preferences in one place. Out-of-band exceptions might be scattered across the web.³
• Consistent User Interface. The Do Not Track exception user interface will be the same across sites and integrated into the browser’s privacy controls.
• Design Quality. Browser vendors employ some of the brightest minds in user interface design.
• Usability Incentives. Web browsers compete on usability and frequently iterate with user interface improvements. Browser development teams are, for the most part, incentivized to provide users with adequate information about and control over a Do Not Track exception. A website that seeks a Do Not Track exception, on the other hand, is incentivized to push the boundaries of acceptable notice and choice to get that exception.⁴

In order to better understand the technical challenges associated with browser-based Do Not Track exceptions, I implemented a prototype as a Firefox add-on.

The source is available on GitHub. I want to emphasize that this is a prototype: it does not conform to the current W3C specification draft and it is insecure, buggy, and slow.

I learned several lessons from the project.

• Browser-based exceptions are not very difficult to implement. The Firefox prototype required only a couple days of straightforward development.
• Browser-based exceptions are markedly more difficult to implement than the “DNT: 1” header. As a very rough comparison, my reference “DNT: 1” Chrome extension is 9 lines of code, while my prototype Firefox exceptions extension is already 521 lines. Furthermore, implementing “DNT: 1” is largely a systems engineering project, while an exception mechanism necessitates both systems and user interface effort.
• The Do Not Track exception user interface is hard to get right. After several iterations, the user interface in my prototype still leaves much room for improvement. I expect Do Not Track will, like other browser features, benefit from long-term user interface evolution.

The prototype add-on validates what Do Not Track proponents have long recognized: Do Not Track is not a crude on/off switch. Rather, it begins a conversation between websites and users about privacy preferences. Browsers will play a central role in facilitating that conversation.

Thanks to Arvind Narayanan for comments on a draft.

1. A number of surveys have reflected mixed consumer preferences on web tracking. See, e.g., Pew Internet 2012, TRUSTe/Harris Interactive 2011, USA Today/Gallup 2010, McDonald and Cranor 2010, and Turow et al. 2009.

2. If a website maintains user accounts, associating an out-of-band exception with an account can greatly reduce the risk of accidental clearing.

3. This problem could be somewhat mitigated with a browser scripting interface for registering an out-of-band exception mechanism. I proposed the approach last year, and there was renewed interest at a recent W3C working group meeting.

4. See Leon et al. 2011 for a usability analysis of current online advertising user control mechanisms.