At today’s hearing of the Subcommittee on Intellectual Property, Competition and the Internet of the House Judiciary Committee, I referred to an attempt to “sabotage” the forthcoming Do Not Track standard. My written testimony discussed a number of other issues as well, but Do Not Track was clearly on the Representatives’ minds: I received multiple questions on the subject. Because of the time constraints, oral answers at a Congressional hearing are not the place for detail, so in this blog post, I will expand on my answers this morning, and explain why I think that word is appropriate to describe the current state of play.
For years, advertising networks have offered the option to opt out from their behavioral profiling. By visiting a special webpage provided by the network, users can set a browser cookie saying, in effect, “This user should not be tracked.” This system, while theoretically offering consumers choice about tracking, suffers from a series of problems that make it frequently ineffective in practice. For one thing, it relies on repetitive opt-out: the user needs to visit multiple opt-out pages, a daunting task given the large and constantly shifting list of advertising companies, not all of which belong to industry groups with coordinated opt-out pages. For another, because it relies on cookies—the same vector used to track users in the first place—it is surprisingly fragile. A user who deletes cookies to protect her privacy will also delete the no-tracking cookie, thereby turning tracking back on. The resulting system is a monkey’s paw: unless you ask for what you want in exactly the right way, you get nothing.
The idea of a Do Not Track header gradually emerged in 2009 and 2010 as a simpler alternative. Every HTTP request by which a user’s browser asks a server for a webpage contains a series of headers with information about the webpage requested and the browser. Do Not Track would be one more. Thus, the user’s browser would send, as part of its request, the header:
The presence of such a header would signal to the website that the user requests not to be tracked. Privacy advocates and technologists worked to flesh out the header; privacy officials in the United States and Europe endorsed it. The World Wide Web Consortium (W3C) formed a public Tracking Protection Working Group with a charter to design a technical standard for Do Not Track.
Significantly, a W3C standard is not law. The legal effect of Do Not Track will come from somewhere else. In Europe, it may be enforced directly on websites under existing data protection law. In the United States, legislation has been introduced in the House and Senate that would have the Federal Trade Commission promulgate Do Not Track regulations. Without legislative authority, the FTC could not require use of Do Not Track, but would be able to treat a website’s false claims to honor Do Not Track as a deceptive trade practice. Since most online advertising companies find it important from a public relations point of view to be able to say that they support consumer choice, this last option may be significant in practice. And finally, in an important recent paper, Joshua Fairfield argues that use of the Do Not Track header itself creates an enforceable contract prohibiting tracking under United States law.
In all of these cases, the details of the Do Not Track standard will be highly significant. Websites’ legal duties are likely to depend on the technical duties specified in the standard, or at least be strongly influenced by them. For example, a company that promises to be Do Not Track compliant thereby promises to do what is required to comply with the standard. If the standard ultimately allows for limited forms of tracking for click-fraud prevention, the company can engage in those forms of tracking even if the user sets the header. If not, it cannot. Thus, there is a lot at stake in the Working Group’s discussions.
Internet Explorer and Defaults
On May 31, Microsoft announced that Do Not Track would be on by default in Internet Explorer 10. This is a valuable feature, regardless of how you feel about behavioral ad targeting itself. A recurring theme of the online privacy wars is that unusably complicated privacy interfaces confuse users in ways that cause them to make mistakes and undercut their privacy. A default is the ultimate easy-to-use privacy control. Users who care about what websites know about them do not need to understand the details to take a simple step to protect themselves. Using Internet Explorer would suffice by itself to prevent tracking from a significant number of websites.
This is an important principle. Technology can empower users to protect their privacy. It is impractical, indeed impossible, for users to make detailed privacy choices about every last detail of their online activities. The task of getting your privacy right is profoundly easier if you have access to good tools to manage the details. Antivirus companies compete vigorously to manage the details of malware prevention for users. So too with privacy: we need thriving markets in tools under the control of users to manage the details.
There is immense value if users can delegate some of their privacy decisions to software agents. These delegation decisions should be dead simple wherever possible. I use Ghostery to block cookies. As tools go, it is incredibly easy to use—but it still is not easy enough. The choice of browser is a simple choice, one that every user makes. That choice alone should be enough to count as an indication of a desire for privacy. Setting Do Not Track by default is Microsoft’s offer to users. If they dislike the setting, they can change it, or use a different browser.
Microsoft’s move intersected with a long-simmering discussion on the Tracking Protection Working Group’s mailing list. The question of Do Not Track defaults had been one of the first issues the Working Group raised when it launched in September 2011. The draft text that emerged by the spring remains painfully ambiguous on the issue. Indeed, the group’s May 30 teleconference—the day before Microsoft’s announcement—showed substantial disagreement about defaults and what a server could do if it believed it was seeing a default Do Not Track header, rather than one explicitly set by the user. Antivirus software AVG includes a cookie-blocking tool that sets the Do Not Track header, which sparked extensive discussion about plugins, conflicting settings, and explicit consent. And the last few weeks following Microsoft’s announcement have seen a renewed debate over defaults.
Many industry participants object to Do Not Track by default. Technology companies with advertising networks have pushed for a crucial pair of positions:
- User agents (i.e. browsers and apps) that turned on Do Not Track by default would be deemed non-compliant with the standard.
- Websites that received a request from a noncompliant user agent would be free to disregard a DNT: 1 header.
This position has been endorsed by representatives the three companies I mentioned in my testimony today: Yahoo!, Google, and Adobe.
Thus, here is an excerpt from an email to the list by Shane Wiley from Yahoo!:
If you know that an UA is non-compliant, it should be fair to NOT honor the DNT signal from that non-compliant UA and message this back to the user in the well-known URI or Response Header.
Here is an excerpt from an email to the list by Ian Fette from Google:
There’s other people in the working group, myself included, who feel that since you are under no obligation to honor DNT in the first place (it is voluntary and nothing is binding until you tell the user “Yes, I am honoring your DNT request”) that you already have an option to reject a DNT:1 request (for instance, by sending no DNT response headers). The question in my mind is whether we should provide websites with a mechanism to provide more information as to why they are rejecting your request, e.g. “You’re using a user agent that sets a DNT setting by default and thus I have no idea if this is actually your preference or merely another large corporation’s preference being presented on your behalf.”
And here is an excerpt from an email to the list by Roy Fielding from Adobe:
The server would say that the non-compliant browser is broken and thus incapable of transmitting a true signal of the user’s preferences. Hence, it will ignore DNT from that browser, though it may provide other means to control its own tracking. The user’s actions are irrelevant until they choose a browser capable of communicating correctly or make use of some means other than DNT.
Pause here to understand the practical implications of writing this position into the standard. If Yahoo! decides that Internet Explorer 10 is noncompliant because it defaults on, then users who picked Internet Explorer 10 to avoid being tracked … will be tracked. Yahoo! will claim that it is in compliance with the standard and Internet Explorer 10 is not. Indeed, there is very little that an Internet Explorer 10 user could do to avoid being tracked. Because her user agent is now flagged by Yahoo! as noncompliant, even if she manually sets the header herself, it will still be ignored.
A cynic might observe how effectively this tactic neutralizes the most serious threat that Do Not Track poses to advertisers: that people might actually use it. Manual opt-out cookies are tolerable because almost no one uses them. Even Do Not Track headers that are off by default are tolerable because very few people will use them. Microsoft’s and AVG’s decisions raise the possibility that significant numbers of web users would be removed from tracking. Pleasing user agent noncompliance is a bit of jujitsu, a way of meeting the threat where it is strongest. The very thing that would make Internet Explorer 10’s Do Not Track setting widely used would be the very thing to “justify” ignoring it.
But once websites have an excuse to look beyond the header they receive, Do Not Track is dead as a practical matter. A DNT:1 header is binary: it is present or it is not. But second-guessing interface decisions is a completely open-ended question. Was the check box to enable Do Not Track worded clearly? Was it bundled with some other user preference? Might the header have been set by a corporate network rather than the user? These are the kind of process questions that can be lawyered to death. Being able to question whether a user really meant her Do Not Track header is a license to ignore what she does mean.
Return to my point above about tools. I run a browser with multiple plugins. At the end of the day, these pieces of software collaborate to set a Do Not Track header, or not. This setting is under my control: I can install or uninstall any of the software that was responsible for it. The choice of header is strictly between me and my user agent. As far as the Do Not Track specification is concerned, websites should adhere to a presumption of user competence: whatever value the header has, it has with the tacit or explicit consent of the user.
Websites are not helpless against misconfigured software. If they really think the user has lost control over her own computer, they have a straightforward, simple way of finding out. A website can display a popup window or an overlay, asking the user whether she really wants to enable Do Not Track, and explaining the benefits disabling it would offer. Websites have every opportunity to press their case for tracking; if that case is as persuasive as they claim, they should have no fear of making it one-on-one to users.
This brings me to the bitterest irony of Do Not Track defaults. For more than a decade, the online advertising industry has insisted that notice and an opportunity to opt out is sufficient choice for consumers. It has fought long and hard against any kind of heightened consent requirement for any of its practices. Opt-out, in short, is good enough. But for Do Not Track, there and there alone, consumers allegedly do not understand the issues, so consent must be explicit—and opt-in only.
It is time for the participants in the Tracking Protection Working Group to take a long, hard look at where the process is going. It is time for the rest of us to tell them, loudly, that the process is going awry. It is true that Do Not Track, at least in the present regulatory environment, is voluntary. But it does not follow that the standard should allow “compliant” websites to pick and choose which pieces to comply with. The job of the standard is to spell out how a user agent states a Do Not Track request, and what behavior is required of websites that choose to implement the standard when they receive such a request. That is, the standard must be based around a simple principle:
A Do Not Track header expresses a meaning, not a process.
The meaning of “DNT: 1” is that the receiving website should not track the user, as spelled out in the rest of the standard. It is not the website’s concern how the header came to be set.
No means no, and Do Not Track means Do Not Track.