“Do Not Track” in browser headers? Six concerns

It’s great to see smart minds turned to the question of how to empower consumers when it comes to online tracking, so you have to appreciate the announcement of donottrack.us. This effort from Stanford is giving new life to the  notion of modifying browsers to transmit a “do-not-track” preference with each header. When compliant tracking firms see the header, they would be required to recognize the opt-out preference and, presumably, ignore any other information transmitted with that request.

The chief benefit of this approach is that it is universal and potentially more scalable than collecting opt-out cookies on a user’s computer. Scalability is an important concern, particularly as the tracking company universe expands from a few hundred ad companies to thousands of brands with their own pools of user cookies.

Here are the issues:

1. Adoption by Browser Makers. Like any other browser based solution, it requires adoption by the browser companies. This seems unlikely in the absence of a new law that requires it. The FTC today doesn’t have the authority to order it, and browser functionality seems like a difficult thing for Congress to legislate directly.

2. Opt-out Framework Still Required. Even if adopted as standard equipment by one or more browser makers, consumers on unsupported browsers still need to be able to opt-out. The system would not become more simple.

3. What would be the default? Even if it were adopted as standard equipment by all browser makers, the default settings would largely determine consumer awareness and adoption. It’s hard to see the industry accept “off” as the default setting. The worst outcome would be a powerful but buried feature that no one knows about.

4. No connection or context. In the current opt-out framework, the consumer’s opt-out decision can be made directly and immediately from the notice of tracking. Because it’s a browser setting, there’s no simple way to connect header selection with the ad and online notice that provide valuable context.

5. Inferior to blocking. Compared with actually blocking interactions between the browser and the tracking company, an approach based on headers is less verifiable for the user, since it does not prevent unique identifiers from being written or read. If you’re going to modify your browser to control tracking, you should modify it not only for compliant companies, but also those who don’t comply. Given that less than a third of tracking companies are enrolled in the self-regulatory system now, incomplete coverage is likely to be an issue for a long time to come.

6. Less choice. The donottrack.us header is elegant because it is universal. But as the primary means to control tracking, that actually restricts choice in important ways. Consumers should have the ability to control which companies to block based on policies, oversight or even whether a tracking company has given them an incentive not to do so. In this way, donottrack.us is at odds with the consumer’s opportunity to influence and even have a stake in tracking.

Given these challenges, I’m not sure that the donottrack.us approach would meaningfully enhance the consumer experience compared to the current framework, flawed as it is. The current system, with some simple enhancements and much greater visibility to consumers, still seems like the right starting point. From there, browser enhancements that actually block tracking — hopefully built in and visible — provide the best upgrade for privacy-concerned consumers.