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.

Background

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:

DNT: 1

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.

The Pushback

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.

The Problem

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.

Now What?

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.

Totally agree with everything you’ve said above. The protocol (if you can even call it that) as it stands at the moment is unenforceable, and amounts to barely even plugin status. As you say above - a cynic might construe that it is so “by design”, so that we can continue with business as usual on the web (tracking).

For this protocol to actually mean something there must be a communication method back to the user IF the server spots something that is “invalid” (or that thinks is invalid). Once the users meaning has been “accurately” determined then everything can continue on.

However this presents a HUGE issue for the AD industry. The very logic above forces the server to send a message to the user that they may be tracked. This will INCREASE the likelihood of the user opting-out.

And that’s not good for business.

Peter

The real problem with do-not-track is that it’s unenforceable. With do-not-call, you can immediately detect a violation when the phone rings and it’s a telemarketer. But with do-not-track, how can you tell? Suspiciously appropriate ads? Short of intrusive discovery into an ad network’s databases, or whistle blower testimony, you can’t.

The FTC understands these issues perfectly well and may well rule that DNT means DNT, no second guessing, but I just don’t see it doing any good.

Sending “DNT: 1” does not, in any way, improve privacy. It’s sole purpose and action is to indicate a user preference. It is not a light switch. It does not turn anything on or off. All it does is tell the server something useful: that this user has chosen the following preference. The companies are not promising to honor DNT — they are promising to honor the user’s preference. It is the user’s preference that tells them to voluntarily disengage tracking.

It is impossible for such a user preference to be expressed if the browser installed by default by an operating system vendor makes the decision for the user. It breaks the promise, it breaks the protocol, and it removes the primary motivation for companies to honor DNT.

If you think users should have a default chosen for them, then you should be advocating for “do not track” to be the default in the absence of any signal, just as prior consent is the default in Europe. That is what legislation can do, in contrast to voluntary standards. It makes absolutely no sense, both technically and socially, to advocate that we should send an extra eight bytes via HTTP by default when the sole purpose of those bytes is to express a non-default choice.

Sending “DNT: 1” does not, in any way, improve privacy. It’s sole purpose and action is to indicate a user preference.

So far we agree. But “user preferences” exist along a continuum, and it is a mistake for the standard to stake out a position at one extreme of that continuum — explicit, informed choice about the Do Not Track header in the context of a specific user agent — and say that this is the only kind of “preference” that matters.

It is not a light switch. It does not turn anything on or off. All it does is tell the server something useful: that this user has chosen the following preference.

Agreed — but again, you are advocating for writing an extreme and narrow interpretation of “chosen” into the standard.

The companies are not promising to honor DNT — they are promising to honor the user’s preference. It is the user’s preference that tells them to voluntarily disengage tracking.

If companies decide that they wish not to honor a DNT header because they do not think it reflects user preference, that is their choice to make, and I wish them the best of luck explaining that choice to users, the public, and regulators. But it is not appropriate to write into the standard a mechanism to say “I reject your DNT and substitute it with my own” on the basis of skepticism about the “true” user preference. That is a hall of mirrors that undermines the clarity of the standard and the reliability of expressed user preferences.

_It is impossible for such a user preference to be expressed if the browser installed by default by an operating system vendor makes the decision for the user.

It it not “impossible”: that preference is expressed in the choice to use the browser or the operating system, to work at a company which sets the header in the browsers it installs on employee computers, to install a generally privacy-protecting security tool, or to visit a cybercafe whose owners have set the browsers to use Do Not Track. The “preference” or “consent” involved is far less attenuated than the notice-and-opt-out-based “consent” to tracking that is currently industry standard.

It breaks the promise, it breaks the protocol, and it removes the primary motivation for companies to honor DNT.

The fundamental “promise” in DNT is not from user to website; it is from website to user: “I will not track you because you have requested not to be tracked.” The protocol is concerned with how the preference is conveyed and with the meaning of what constitutes prohibited “tracking” should a website choose to honor a DNT request, not with the mechanics of configuring user agents.

If you think users should have a default chosen for them, then you should be advocating for “do not track” to be the default in the absence of any signal, just as prior consent is the default in Europe.

I do not think they should; I am just advocating for them to have a fair choice among tools that do and do not set defaults. That is what you are arguing against: you are denying users the ability to use tools that take care of these complex issues simply and automatically.

That is what legislation can do, in contrast to voluntary standards. It makes absolutely no sense, both technically and socially, to advocate that we should send an extra eight bytes via HTTP by default when the sole purpose of those bytes is to express a non-default choice.

The purpose of DNT is not “to express a non-default choice”: it is to express consent to tracking or a request not to be tracked. I understand that you would like to limit its use to a small set of cases involving specific user interactions with their user agent, but that is a matter for companies choosing how to respond to DNT headers, not for the DNT standard.

there’s a real impedence mismatch between what real people and silicon valley/Madison avenue want here… http://www.zdnet.co.uk/blogs/500-words-into-the-future-10014052/privacy-dnt-microsoft-the-ftc-and-silicon-valley-10026371/

If you don’t like the definition of the header field, then feel free to suggest a change to its meaning. I can tell you with some authority (being the editor of both TPE and HTTP) that it doesn’t mean what you think it does, and therefore your comments are misleading.

The specification does not require servers to disregard DNT from broken user agents. That has never even been proposed by industry. As a factual matter, industry is not required to implement a voluntary standard; they are required by regulators to be consistent in their statements to the public about compliance. Nobody is suggesting that those statements would ever be allowed to be inconsistent.

If Congress wishes to pass legislation about DNT, then they should do so based on facts, not imagined posturing, and they should make it apply to all users by default, not just those who use broken browsers.

why should the onus be on the user to opt out rather than on the advertiser to get us to opt in? personal data is the new oil; they should have to work for the right to drill my data. with a DNT default the user can always turn it OFF again; if they didn’t do that, there’s a reason.

Mary, the onus is on the user to express a preference because we are working on a voluntary standard. I agree that it would have made far more sense to define a tracking default without needing a preference, but everyone agreed (including all of the privacy advocates) that DNT would not be deployable as a voluntary standard otherwise.

Nothing the W3C group defines prevents our representative government from legislating a different default for the absence of a DNT header field, just like they have in Europe. In other words, the default for what companies are allowed to track without explicit consent. That is why DNT is defined the way it is: no DNT header field means that the default is set by regional law and the user’s context.

That does not change the fact that sending a DNT header field by default makes no sense whatsoever; we don’t need a DNT field if “do not track” is the default.

Roy, you are conflating “do not track” as a default requirement established by law with “do not track” as a default request made by a user agent. The former is a universal default, and in that context, a further “do not track” header is redundant and pointless. The latter is not, since some user agents will set it by default and some will not. There, the website really does need a DNT header, since it would be unduly burdensome to require websites to infer a DNT value from the User-Agent header or some other external information.

Also, I have never argued that the standard as being discussed will require websites to disregard DNT from what you call “broken” user agents. (Since the current TPE draft defines a user agent’s ability to set a default in terms of whether “a specific tracking preference is implied by the decision to use that agent,” the only thing that will distinguishes “broken” from non-“broken” user agents in some cases will be their names, marketing, or other wholly extrinsic factors.) My complaint is that the standard, as you and others are pushing for it, will permit websites to disregard DNT from user agents whose bona fides they question. They may choose to do so. But that decision belongs outside of the standard.

My complaint is that the standard, as you and others are pushing for it, will permit websites to disregard DNT from user agents whose bona fides they question.

I don’t know where you got that impression. I have no desire to include anything about non-compliant user agents in the standard, nor would I allow the WG’s opinion regarding non-compliant user agents to sway how my servers interpret their messages. It is not, and has never been, subject to WG consensus any more than the WG can require deployment.

I’ve been going from your emails to the list, particularly the June 14 email I quoted above:

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.

I have now repeated that same statement, in various ways, over half a dozen times. It would be nice if we could stop wasting the group’s time over a question that is not subject to working group consensus. …

Deployment of a recommendation is voluntary, and it is absolutely reasonable for one condition of server deployment to be that the user agent does not make false statements in the protocol. I think the question of how a rejection might be communicated to the user is within scope, but should be discussed on a new thread.

I took that to mean that you believe:

1. Some browsers will be non-compliant with the standard.
2. Some servers will decline to honor DNT: 1 headers from browsers they deem non-compliant.
3. Those servers will be compliant with the standard.
4. The standard could, perhaps should specify a mechanism for the servers to indicate that the browser’s non-compliance is the reason the server declines to honor header.

You seemed emphatic about the the first two, at least. Perhaps I am misunderstanding your view or missing an important distinction, but your explanation seemed clear on its face.

The mistaken assumption is (3): compliance with the protocol standard is based on receiving a valid expression of the user’s preference (as defined by the working group).

If a server says “I will comply with DNT when it is sent from a compliant user agent, but not when it is sent from MSIE 10.0beta” and consistently reports that to the user, then it is making a true statement when it ignores the DNT header field sent by MSIE 10.0beta and points the user instead to an out-of-band consent mechanism. It is not the server’s fault that it cannot distinguish a valid user’s preference because of the browser vendor’s decision. The standard cannot say that the server is compliant or non-compliant in that instance because the protocol is no longer applicable.

Again, this tristate definition of the DNT header field was agreed to last October, by the entire working group, including Microsoft and all of the privacy advocates. DNT has always been defined as communicating the user’s preference. Saying that insisting on user agent compliance with the protocol as specified by the working group is somehow working to sabotage the protocol is a gross misstatement of the facts.

If someone wants to change the protocol to a different definition, they should do so within the consensus process. If, however, one company chooses to send false statements using the protocol just to screw with the revenue stream of one of their market competitors, then I will view that as an attack on open standards. In that case, Apache (not Adobe) will respond accordingly, since Apache has been protecting HTTP from exactly this kind of proprietary abuse since 1995.

compliance with the protocol standard is based on receiving a valid expression of the user’s preference (as defined by the working group

If compliance is defined in terms of the server’s behavior when it receives a “valid expression of the user’s preference,” then whether a server is receiving a “valid expression” is not something the server can know, because it is not based solely on observable properties of the server’s interactions with a user agent. It depends on out-of-band facts that in many cases will not be available to the server, even in theory.

The server, therefore, will have to guess at whether it is seeing a “valid expression.” Any non-trivial guessing algorithm will generate both false positives (invalid expressions deemed valid) and false negatives (valid expressions deemed invalid). The former can be disregarded, but the latter are problematic.

By your definition, the server that has treated a valid expression as invalid is now in a state where its compliance with the standard is on the line. Your response to this point is that this mistake is not the server’s fault. In a causal sense, this is true: the server really can’t tell which expressions are “valid” and which are not, due to factors out of its control. But under your definition of server compliance, that isn’t relevant, since the server is still receiving some valid expressions from users.

Another response to default-on user agents would be to say that, per the working group’s definition, no DNT: 1 header set by them will be deemed to be a “valid expression.” Under this approach, a user agent’s failure to conform to the standard’s requirements in other respects will mean that even an explicit, informed user choice to set the user agent’s DNT header to 1 is not a “valid expression.” (I don’t understand this to be your position, but please correct me if I’m wrong.)

But under this approach, I think my (3) is still an accurate statement of the state of affairs. The server that declines to honor all DNT: 1 headers from the default-on user agent will be in overall compliance with the standard. Its obligations under the standard with respect to the default-on user agent are trivial: it has no obligations, so therefore no matter what it does (including declining all DNT: 1 requests), it will meet them. Full compliance is the absence of violations; ∀ = ¬ ∃ ¬

So if the server’s compliance with the standard is limited to “valid expressions” of user preference where validity depends on UI features of the user agent, then one of two things is true. Either servers will sometimes be noncompliant because they disregard valid preferences, or my (3) is the case because the servers that blanket-disregard the default-on user agent’s DNT requests are not committing any violations of the standard.

The server is not guessing. The server owner would have made a decision not to comply for that user agent and would have deliberately configured the server accordingly. They are under no obligation to comply unless they have told the user that they would comply.

Because the server does not implement the protocol for that user agent, it cannot comply for that user agent. It does not comply for the scope of that request. Unlike some protocols, it is not possible to comply with DNT without implementing its requirements because we do not want existing servers, which do not implement the protocol at all, to be considered compliant. This does not prevent the server from complying with the protocol when sent by other user agents, nor does it prevent the server owner from making factual statements about that selective compliance to users.

Whether or not the received DNT header fields were deliberately chosen by the user for that user agent is irrelevant: the server is not participating in the protocol.

Any other approach would allow user agents to disregard the protocol semantics with impunity, which is ultimately harmful to users because it removes the incentive for good server owners to implement the protocol at all. As mentioned before, if it had been possible to voluntarily deploy “do not track” without an explicit expression of user preference, then we would have done so immediately by making it the default for everyone. The DNT header field only exists because servers will not turn off tracking voluntarily unless the user asks them to or legislation compels them to do so.

Todays’s Sinfest is appropriate here ;)

Thank you for your continued engagement with me here, Roy; my normative views aren’t much changed, but the discussion is providing some useful clarity.

My disagreement with you over how to describe the relationship of the sever to the protocol is mostly a matter of labels. If the server “does not implement the protocol for that user agent,” then it would follow that it should not set the Tk header in its response. Anything else would be “participating in the protocol,” But I don’t see us differing in our understanding of what actually happens in the exchange of messages between user agent and server.

And to respond to your last point, I think we simply disagree about the appropriate actions of a standards body in this type of situation. Many industry participants have set an ill-defined UI constraint on which DNT requests they are willing to honor. Writing that constraint into the standard makes the standard’s ambit ill-defined. I would say it would be better to make the standard agnostic on user agent UI, and to find ways to meet industry’s concerns within the protocol, so that both user agent and server, in all of these scenarios, are “participating in the [TPE] protocol.” That makes the protocol better-defined and useful for a wider range of websites, user agents, and regulatory environments.

Please select your privacy preference:

[ ] Give me a browser that is already configured 
    for privacy and don't bother me with any more 
    details!

[ ] Force me to manually configure my browser's 
    privacy preferences, so that it is clearer 
    that the Do Not Track header reflects my  
    personal privacy preference and is not merely 
    sent by default.

[ ] Force me to manually specify which web sites 
    should receive the Do Not Track header, so 
    that it is even clearer that the Do Not Track
    header sent to each site really does reflect 
    my personal privacy preference FOR THAT SITE, 
    and is not merely sent to all web sites.

[ ] For every stinking HTTP request, force me to
    manually specify whether or not the browser
    should send the Do Not Track header, so that
    it is totally, 100%, crystal clear to the
    receiver that every Do Not Track header I
    send reflects my actual personal privacy 
    preference and cannot be ignored on the
    grounds that it was sent automatically.

I appreciate the write-up about what is happening with DNT. It’s quite interesting. I only have a brief comment on your excellent post. I am sad to say that the opt-out cookies offered by websites are worse than you describe them.

You state: By visiting a special webpage provided by the network, users can set a browser cookie saying, in effect, “This user should not be tracked.”

Unfortunate, this is not the case. The industry groups responsible for self-regulation require only that users with these cookies not be shown targeted ads. The companies are free to continue tracking those users. About half of advertising companies stop tracking users who have opted-out, but many continue to do so. You can read much more about this here:

AdChoices? Compliance with Online Behavioral Advertising Notice and Choice Requirements

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.

I find this persuasive. What were the authors of https://tools.ietf.org/id/draft-mayer-do-not-track-00.txt (now expired)thinking when they only allowed opt-out or no preference to be defaults? Presuming user competence, the following addition to David Booth’s menu should be fine:

[ ] Give me a browser that is already configured to say I want to be tracked!

I wouldn’t select such a browser; I finally bothered to set DNT in Firefox after reading this post. But it ought be OK, and relatedly, it is somewhat disappointing to find that Firefox, through preferences and about:config, treat DNT as a boolean, with no option to send DNT: 0.

‘Meaning, not a process’? What on earth does that mean?

Of course it’s a process. The entire internet isn’t going to go to waste just because Microsoft failed in the internet, wants its OS to be another XBox and wants to get back at Google. What philistine does away with frequency capping, ip geotargeting, ip click fraud prevention, ip spam protection when all of that is just Microsoft trying to close up the internet, screw websites with a global appeal, and make its OS appshop all the more worthy.

Chairman Mao and the Red Spring comes to mind.

Joe, frequency capping and click fraud prevention are both being discussed by the Working Group as “permitted uses” that ad networks could still engage in even if the DNT: 1 header is set and the networks honors those requests. Geolocation information at the level of postal codes is in the current working draft as a permitted use, as well. And as for spam, a website is a first party that can retain its own logs, so it can monitor its traffic for suspicious patterns. Targeted attacks on ad networks would potentially also fall within the scope of the security exception.

Whoever the Maoist philistines that want to eliminate these practices are, they’re not the Working Group. So when Microsoft turns on Do Not Track by default in IE, it’s not disabling click fraud detection, or ad geotargeting, etc.

Some of you keep going on about ‘Broken Agents’, I would like to know how the server is going to know whether the presence of a DNT header is because of a user preference or not, unless the agent in question is known to ignore the users wishes (by bug or design)?

Ultimately I don’t think it will matter what happens (voluntary or otherwise) because companies, especially the big ones, will do what they want any way and that will be to record all they can.

I think we simply disagree about the appropriate actions of a standards body in this type of situation.

The W3C continues to fail spectacularly. A company that aspires to do the right thing by default is made to appear to do the wrong thing by committee consensus.

The parallels with the so-called IETF censorship code are striking. Sites that are in violation of copyright laws and profit significantly by that are defended by framing a means to block with a censorship title (451). In effect, it is increasingly impossible for vendors of product on the web to defend their legal rights from the web.

This is not a shiny day for the W3C and as non-W3C originated means come on line, one can expect users and vendors to look elsewhere for remedies. Sad but so.

My thoughts:

Firstly, DNT obviously has no future. It’s never gonna work if websites can control this. And, it’s near impossible to force website owners (millions!) to update their old websites to comply.

Cookies were not meant to be used by ads. They were mainly meant to store information about user preferences on A website. “Do you want to stay logged in?”

But the cookies have been abused, raped, stolen, cracked, shared between domains and companies, etc. So much, that cookies are now generally evil. (insert rotten cookie picture here)

Suggestion #1: Enforce strict cookie laws. At the browser level. Cookies shall NOT be shared between ANY two domains. Ever. I know it adds limitations, but it’s the price to pay when so many people have been naughty.

Suggestion #2: Forced cookie expiration. At the browser level, again. No cookie shall be allowed to live more than [user setting], default max value 1 month for example.

Browsers that do not follow these standards will be considered rogue, uncommercial.

Location detection is another pain: how do you hide where you are coming from when you need to connect to a server? That one really is a pain. My crappy suggestion for this: IIS and alike, web server programs are built by companies; they could be forced to include functionality that reads the DNT, and does NOT allow the website to read any location, browser (,etc..) information.

…Maybe the only efficient way is to let these spammers (sorry, adverti… Nah, spammers was correct.) do whatever they want, and let neutral anti spammers do their thing: adblock, ghostery, whatever comes next. And they will keep improving. (PS: they are winning. I live on an ad fee internet thanks to them.) When these anti spammers have become ESSENTIAL to our safe use of computers (I believe they already are), maybe then, the ad makers will regret going too far and realize that if they behaved better, users would not block everything.

A quick clarification of len’s comment: the 451 error code is a proposal that one person (Tim Bray) sent to the IETF, not something the IETF has endorsed.

DNT has been defeated before it ever got off the ground. Its unenforceable, unreliable, and therefore simply another way to mislead the user. This is harsh, but everybody involved should admit failure and move on.

You can’t trust people with a finnancial interest in invading users’ privacy, and a track record of trying to maximize that invasion, to honor a piece of information asking that they do not, especially if there’s no way for users, or law enforcement, to verify whether a company tracks users or not. The sites that matter most, won’t implement, or won’t repsect, DNT. Any thoughts to the contrary were pure folly from the very beginning. Therefore, the BEST that DNT can ever achieve is to give users a false sense of privacy. Users would be better helped by not providing that.

If I set DoNotTrack and the site ignores it am I free to resend my request with DoNotTrack back to the site until it complies with my wishes? Maybe thousands of times a minute? And what if millions of people do the same? It’s not a Denial of Service atack, just millions of trys to get the site to accept my preferences.

Personally, I don’t mind targeted advertising and wish it would start spilling over into TV as well. If I have to see ads, I would prefer to see relevant products. As 60ish folks, why do we have watch baby food and tampon ads during our programs? We have the option of paying for higher tiered TV that has less advertising but ads are generally a fact of life and a huge facet of a free enterprise culture.

What I don’t see here from you is a way to implement DNT standards without killing the free enterprise model, revenue producing sites and the livelihoods of countless citizens.

It appears doomed to be a ‘throw out the baby with the bath water solution’ Or put another way, ‘we have cured the disease, unfortunately the patient didn’t survive’. It would officially sink many small businesses like ours. And have a huge impact on revenue of large businesses too. The economy cannot take the loss that would be the result of this folly. Has anyone offered the law makers numbers on that?

The abusers have to dealt with but crippling e-commerce. causing business implementation nightmares is not the route to take. This could be the ‘straw that broke’ the economy’s back if it becomes a reality.

Bill, I am not arguing against targeted ads. I am asking to give consumes a fair, unbiased choice of whether to see them. They can decide whether the benefits of better targeting — which include fewer ads, more relevant ads, and being able to access some services at all — are worth it to them. I have no doubt that many people, like you, will choose the targeting.

That’s exactly what DNT allows: this choice. If users come to the site with DNT:1 set, websites can explain to users how much better the experience would be if users turned on targeting. The sites can ask for exceptions — that’s going to be in the standard, too. That’s free enterprise at work. And so is Microsoft’s choice to turn on DNT: 1 by default in its browser.

I guess it would be suitable to break into the offending companies serverroom, claiming the locks on the door were the architects choice not the companies… and then, since no sign says “Don’t put the servers on fire” you were not explicitly disallowed to do it….

I’ve been reading and trying to digest all of this at once. From a user standpoint, consider this, and convince the typical non-technical user that voluntary compliance works: I turned on DNT in Firefox when I first installed it, before doing any web surfing. I also installed a plugin for firefox called DNT+: in less than a month, it shows over 3000 attempts to track me EVEN WITH DNT turned ON. Where is the voluntary compliance? I have ore that 1500 attempts from Google Ad services to track me. I think that the workinbg group needs to set out a clear and consistent policy for DNT, and we as citizens should then push our congress for legislation to give it muscle so that we as free citizens can have some assurance that our desire for privacy is a little more protected. I’m not so naive as to believe that one word from congress, and it will all disappear; there will always be some miscreants, and we will always have malware. Hopefully, the honest businesses will strictly follow the letter of the law, if for no other reason, then to prevent bad publicity.

I’m going to have to agree with Dr. Fielding on this one. The standard provides a uniform and well-defined way for users to indicate they do not wish to be tracked and, crucially, for web sites to acknowledge that they will honor that preference. Provided that browsers provide good feedback to users on the presence of the Tk response header, in principle the standard will allow users to punish web sites that refuse to honor their request by going elsewhere. If web sites ignore the DNT:1 set by default in IE, users can punish Microsoft by switching to other browsers, the web sites, or both. Free enterprise is at work in all cases, and the standard has done all it can to facilitate it.

What remains to be seen is, of course, whether users collectively have enough power or will to encourage web sites to honor the header at all. If not, then there is a good case for regulation to do what the market cannot, but that is entirely external to the design of the standard itself. Prof. Grimmelmann, you’re looking for an ‘opt-in’ regulation, and it sounds like you were hoping Microsoft’s decision to create a de facto one in the absence of a legal one, but if that is the case then it’s unfair to demand of the standard writers something that is outside of the standard’s scope. It’s alsol odd to invoke free enterprise in defense of your desire for the regulation.

I think it’s a simple matter of a users request is a users request. If I didn’t give someone permission to access my computer and they did so, they would be breaking the law. Websites should be held accountable in the same manner.

A simple way around this until DNT becomes something tangable in law is for IE to scan cookie headers and forcefully block them if the user has opted DNT, default or user choice.

I think it’s a simple matter of a users request is a users request. If I didn’t give someone permission to access my computer and they did so, they would be breaking the law. Websites should be held accountable in the same manner.

A simple way around this until DNT becomes something tangable in law is for IE to scan cookie headers and forcefully block them if the user has opted DNT, default or user choice.

1. Making a law for DNT is similar to gun licensing and control. Only the criminals will get guns by illegal means. Also, the rogue web sites will not honor DNT. The good guys (like Google, Yahoo, and Adobe) will honor DNT. Currently, these “good guys” are against it because it will hurt their advertiser’s business.
2. Expecting the average computer user to know about cookies and which are for what web site and which control DNT is like the average person who owns a car to know about its inner workings. If a mechanic during a tune up breaks a spring in the fuel injector and expects the customer to know about it and its effect on the operation of his vehicle, which is underhanded.

I would expect a higher standard from the engineers of these companies, but the “business professionals” they are just plain evil. They will use every immoral trick, if it is legal or they cannot be detected, to steal from the consumer.