User consent can get complicated fast. The history lessons of "Do Not Track" can help guide us in our quest to solve the identity and data protection issues of today.
Why it matters — "Do Not Track" (DNT) seemed like an easy solution that the industry and regulators could agree on and implement. However, the details and competing commercial interests were complicated, and eventually, after much hand-wringing, the solution was abandoned in 2015 by browsers, the ad industry and trade organizations alike. Yet, similar conversations are happening now around data use, user consent and where control for both should sit. If we look back at the lessons of DNT, it helps to inform the issues facing industry and solutions being proposed today.
What is “DNT”?
Let’s start with the definition of “Do Not Track” (or DNT). Unlike other industry or proprietary opt-outs from online “tracking” stored in cookies that can be cleared or are imperfect because they’re stored server-side, in local storage or elsewhere, the idea behind DNT was to create a simple, universal, and persistent opt-out.
It was supposed to work like this:
Every time your computer sends or receives information over the internet, the request begins with short pieces of information called headers that include information like what browser you’re using and other technical details.
The DNT signal would be included as a machine-readable header indicating a user didn’t want to be tracked.
Because this signal is a header, and not a cookie, users could clear their cookies without disrupting the functionality of the Do Not Track flag.
Where did it come from?
The idea of sending “DNT” requests in HTTP headers was first suggested around 2009 because of concerns over existing cookie-based and server-side user choice options that were confusing, difficult to use and “fragile” (e.g. easily cleared or deleted).
The proposal was an alternative to regulation and endorsed by the U.S. Federal Trade Commission. In 2011, Safari and Firefox made it possible for users to select this option in their browsers, but websites and their adtech vendors disagreed on what the signal meant and therefore did not alter their behavior in response to it. Around the same time, Internet Explorer turned it on by default for its users.
The inconsistency led to the creation of a working group at the World Wide Web Consortium (W3C) tasked with standardizing the technical interaction, and setting an agreement on what websites should do on receipt of the signal (the “policy”).
The working group included publishers, adtech companies, browser and software companies and user advocates. There was hope of a compromise, but given competing commercial interests the working group stalled in 2012.
How did it end?
The umbrella online advertising trade organization, the Digital Advertising Alliance (DAA) pulled support.
In 2014, Yahoo! dropped support from all of its websites, saying the standards were too murky to be useful with their privacy team stating, “Right now, when a consumer puts Do Not Track in the header, we don’t know what they mean… Privacy is not a one size fits all thing.”
In 2015, Microsoft reversed its position clarifying that Internet Explorer would no longer send DNT signals to websites by default. By then, however, it was too late.
Why did it fail?
Because the parties at the table couldn’t agree on the policy underlying the signal. By all accounts for 4 main reasons:
- Opt-in or opt-out: Microsoft argued it should be set by the browser by default and users could turn it off (opt-in). Others argued it should be actively set by the users (opt-out)
- Messaging: Who controls explaining this choice (and the value exchange) to consumers? Browsers? Publishers?
- Applicability: Should the signal apply uniformly to all parties or should its application be different for different parties (e.g. could 1Ps like Google, Microsoft and Yahoo ignore it for both their direct content and third party ad businesses) while third party adtech had to honor the choice
- Proper response: What should parties stop doing on receipt of the signal? No data collection or use? No building or enhancing third party profiles? Could they still run a contextual auction? Ad delivery using publisher audience data? Ad delivery using advertiser data? Frequency and recency capping? Fraud? Security detection? Something else?
If this all sounds familiar it’s because it’s the same issues we hear day-in and day out in the news, from regulators, from our clients and partners, in contract negotiations and in industry working groups interpreting and solving for GDPR, CCPA/CPRA, Privacy Sandbox, etc. including the ads working group at W3C, the Global Privacy Control, IAB Transparency and Consent Framework, IAB CCPA Framework, NAI Code, DAA Principles, AdChoices, etc.
Should users have to opt-in to ad tracking or opt-out? What does “ad tracking” even mean? Should parties with direct consumer relationships be treated differently? Should communications with consumers be controlled at the device level by gatekeepers (e.g. Apple, Android, ePrivacy)? Should gatekeepers control access to that data and not share it (Privacy Sandbox, Ads Data Hub)? Is there an overall better way to serve and measure ads?
This isn’t going away any time soon but for folks who think these conversations are new and can be easily solved with another opt-out or opt-in, look at history. Learn from the mistakes that have been made. Listen to folks who have been down this path before. Acknowledge not all interests are aligned. Ideally simplify as much as possible. Maybe even fundamentally change how things work.
