This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the proposed starting point for a renewed effort to agree on the basic principles of complying with DNT signals. To kick-off and focus our discussions, this text has proposed initial draft text as one alternative to resolve important issues. This draft does not constitute consensus and does not claim to indicate any preferred text of the group. It may not yet cover all issues that need to be addressed. It may further be augmented by adding non-normative text that provides more information. Reviewers are advised to consult the list of issues tracked in the Compliance June product and the wiki list of change proposals developed by participants in the Working Group.

To work from this draft towards a consensus Recommendation, the Chair has proposed a plan that finalises the document in two phases:

  1. Finalising Issues: We will first ensure that our list of ISSUEs is complete and that all important questions are on our radar.
  2. Closing Issues: We will consolidate a list of text alternatives for issues and identify the text alternative that draws the least substantiated objections of the group.

This draft is substantially revised from the previous Working Draft. Rather than providing sets of options, this draft provides a single text with minimal non-normative text against which the Working Group has documented change proposals. This draft has evolved from the June draft presented by chairs and staff after the last face-to-face meeting of the Working Group in Sunnyvale.

This document was published by the Tracking Protection Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-tracking-comments@w3.org (subscribe, archives). All comments are welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Scope

Do Not Track is designed to provide users with a simple preference expression mechanism to allow or limit online tracking globally or selectively.

The specification applies to compliance with requests through user agents that (1) can access the general browsable Web; (2) have a user interface that satisfies the requirements in Determining User Preference in the [TRACKING-DNT] specification; (3) and can implement all of the [TRACKING-DNT] specification, including the mechanisms for communicating a tracking status, and the user-granted exception mechanism.

Issue 209: Description of scope of specification

2. Definitions

2.1 User

A user is an individual human. When user agent software accesses online resources, whether or not the user understands or has specific knowledge of a particular request, that request is "made by the user."

2.2 User Agent

The term user agent refers to any of the various client programs capable of initiating HTTP requests, including but not limited to browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11].

2.3 Network Transaction

A network interaction is the set of HTTP requests and responses, or any other sequence of logically related network traffic caused by a user visit to a single web page or similar single action. Page re-loads, navigation, and refreshing of content cause a new network interaction to commence.

2.4 Party

A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person. For unique corporate entities to qualify as a common party with respect to this document, those entities MUST be commonly owned and commonly controlled and MUST provide easy discoverability of affiliate organizations. A list of affiliates MUST be available through a single user interaction from each page, for example, by following a single link, or through a single click.

2.5 Service Provider

An outsourced service provider is considered to be the same party as its client if the service provider:

  1. acts only as a data processor on behalf of the client;
  2. ensures that the data can only be accessed and used as directed by that client;
  3. has no independent right to use or share the data except as necessary to ensure the integrity, security, and correct operation of the service being provided; and
  4. has a contract in place that outlines and mandates these requirements.
Issue 206: Service Provider name and requirements

2.6 First Party

In the context of a specific network interaction, the first party is the party with which the user intentionally interacts. In most cases on a traditional web browser, the first party will be the party that owns and operates the domain visible in the address bar.

The party that owns and operates or has control over a branded or labeled embedded widget, search box, or similar service with which a user intentionally interacts is also considered a first party. If a user merely mouses over, closes, or mutes such content, that is not sufficient interaction to render the party a first party.

In most network interactions, there will be only one first party with which the user intends to interact. However, in some cases, a resource on the Web will be jointly operated by two or more parties, and a user would reasonably expect to communicate with all of them by accessing that resource. User understanding that multiple parties operate a particular resource can, for example, be accomplished through inclusion of multiple parties' brands in a domain name, or prominent branding on the resource indicating that multiple parties are responsible for content or functionality on the resource with which a user reasonably would expect to interact by accessing the resource. Simple branding of a party, without more, will not be sufficient to make that party a first party in any particular network interaction.

Issue 10: What is a first party?

2.7 Third Party

A third party is any party other than a first party, service provider, or the user.

Whether a party is a first or third party is determined within and limited to a specific network interaction.

2.8 Deidentified

Data is deidentified when a party:

  1. has achieved a reasonable level of justified confidence that the data cannot be used to infer information about, or otherwise be linked to, a particular consumer, computer, or other device;
  2. commits to try not to reidentify the data; and
  3. contractually prohibits downstream recipients from trying to re-identify the data.
Issue 188: Definition of de-identified (or previously, unlinkable) data

2.9 Tracking

Tracking is the retention or use, after a network interaction is complete, of data records that are, or can be, associated with a specific user, user agent, or device.

Issue 5: What is the definition of tracking?

Issue 119: Specify 'not tracking' or 'None'

2.10 Collect, Retain, Use, Share

A party collects data if it receives the data and shares the data with other parties or stores the data for more than a transient period.

A party retains data if data remains within a party's control beyond the scope of the current network interaction.

A party uses data if the party processes the data for any purpose other than storage or merely forwarding it to another party.

A party shares data if the party enables another party to receive or access that data.

Issue 16: What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.)

3. User Agent Compliance

Issue 205: user agent compliance requirements; connections to TPE

A user agent MUST offer users a minimum of two alternative choices for a Do Not Track preference: unset or DNT: 1. A user agent MAY offer a third alternative choice: DNT: 0.

If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled.

A user agent MUST have a default tracking preference of unset (not enabled).

User agents and web sites are responsible for determining the user experience by which a tracking preference is controlled. User agents and web sites MUST ensure that tracking preference choices are communicated to users clearly and accurately and shown at the time and place the tracking preference choice is made available to a user. User agents and web sites MUST ensure that the tracking preference choices describe the parties to whom DNT applies and MUST make available brief and neutral explanatory text to provide more detailed information about DNT functionality.

That text MUST indicate that:

  1. if the tracking preference is communicated, it limits collection and use of web viewing data for certain advertising and other purposes;
  2. when DNT is enabled, some data may still be collected and used for certain purposes, and a description of such purposes; and
  3. if a user affirmatively allows a particular party to collect and use information about web viewing activities, enabling DNT will not limit collection and use from that party.

User agents and web sites MUST obtain an explicit choice made by a user when setting controls that affect the tracking preference expression.

A user agent MUST transmit the tracking preference according to the [TRACKING-DNT] specification.

Implementations of HTTP that are not under control of the user MUST NOT generate or modify a tracking preference.

4. First Party Compliance

If a first party receives a DNT:1 signal the first party MAY engage in its normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.

The first party MUST NOT pass information about this network interaction to third parties who could not collect the data themselves under this standard. Information about the transaction MAY be passed on to service providers acting on behalf of the first party

First parties MAY elect to follow third party practices.

Issue 170: Definition of and what/whether limitations around data append and first parties

5. Third Party Compliance

Issue 203: Use of 'tracking' in third-party compliance

If a third party receives a DNT: 1 signal, then:

  1. the third party MUST NOT collect, retain, share, or use information related to the network interaction as part of which it received the DNT: 1 signal outside of the permitted uses as defined within this standard and any explicitly-granted exceptions provided in accordance with the requirements of this standard;
  2. the third party MUST NOT use information about previous network interactions in which it was a third party, outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard.

The third party MAY nevertheless collect, use, and retain such information for the set of permitted uses described below. Further, parties MAY collect, use, and retain such information in order to comply with applicable laws, regulations, and judicial processes.

Outside the permitted uses listed below, the third party MUST NOT collect, retain, share, or associate with the network interaction identifiers that identify the specific user, user agent, or device. For example, a third party that does not require unique user identifiers for one of the permitted uses must not place a unique identifier in cookies or other browser-based local storage mechanisms.

Third parties that disregard a DNT signal MUST signal so to the user agent, using the response mechanism defined in the [TRACKING-DNT] specification.

When a third party receives a DNT:1 signal, that third party MAY nevertheless collect, retain, share or use data related to that network interaction if the data is de-identified as defined in this specification.

It is outside the scope of this specification to control short-term, transient collection and use of data, so long as the information is not transmitted to a third party and is not used to build a profile about a user or otherwise alter an individual user’s user experience outside the current network interaction. For example, the contextual customization of ads shown as part of the same network interaction is not restricted by DNT: 1.

Issue 134: Would we additionally permit logs that are retained for a short enough period?

Issue 204: Definitions of collection / retention and transience / network interaction

It is outside the scope of this specification to control the collection and use of de-identified data.

5.1 Third Party Geolocation Compliance

If a third party is part of a network interaction with a DNT: 1 signal, then geolocation data MUST NOT be used in that interaction at any level more granular than postal code, unless specific consent has been granted for the use of more granular location data.

Issue 202: Limitations on geolocation by third parties

5.2 General Principles for Permitted Uses

Some collection, retention and use of data is permitted, notwithstanding DNT: 1, as enumerated below. Different permitted uses may differ in their permitted items of data collection, retention times, and consequences. In all cases, collection, retention, and use of data must be reasonably necessary and proportionate to achieve the purpose for which it is specifically permitted; unreasonable or disproportionate collection, retention, or use are not “permitted uses”.

5.2.1 No Secondary Uses

Third Parties MUST NOT use data retained for permitted uses for purposes other than the permitted uses for which each datum was permitted to be collected.

5.2.2 Data Minimization, Retention and Transparency

Data retained by a party for permitted uses MUST be limited to the data reasonably necessary for such permitted uses. Such data MUST NOT be retained any longer than is proporationate and reasonably necessary for such permitted uses.

Third parties MUST provide public transparency of the time periods for which data collected for permitted uses are retained. The third party MAY enumerate different retention periods for different permitted uses. Data MUST NOT be used for a permitted use once the data retention period for that permitted use has expired. After there are no remaining permitted uses for given data, the data MUST be deleted or de-identified.

Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained, and MUST NOT rely on unique identifiers for users or devices if alternative solutions are reasonably available.

Issue 199: Limitations on the use of unique identifiers

5.2.3 No Personalization

Data retained for permitted uses MUST NOT be used to alter a specific user's online experience based on multi-site activity, except as specifically permitted below.

5.2.4 Reasonable Security

Third parties MUST use reasonable technical and organizational safeguards to prevent further processing of data retained for permitted uses. While physical separation of data maintained for permitted uses is not required, best practices SHOULD be in place to ensure technical controls ensure access limitations and information security. Third parties SHOULD ensure that the access and use of data retained for permitted uses is auditable.

5.3 Permitted Uses

Issue 211: Should we specify retention periods (extended with transparency) for permitted uses?

5.3.1 Frequency Capping

Regardless of DNT signal, information MAY be collected, retained and used to limit the number of times that a user sees a particular advertisement, often called frequency capping, as long as the data retained do not reveal the user’s browsing history. Parties MUST NOT construct profiles of users or user behaviors based on their ad frequency history, or otherwise alter the user’s experience.

5.3.2 Financial Logging

Regardless of DNT signal, information MAY be collected, retained and used for billing and auditing related to the current network interaction and concurrent transactions. This may include counting ad impressions to unique visitors, verifying positioning and quality of ad impressions and auditing compliance with this and other standards.

5.3.3 Security

To the extent proportionate and reasonably necessary for detecting security risks and fraudulent or malicious activity, parties MAY collect, retain, and use data regardless of a DNT signal. This includes data reasonably necessary for enabling authentication/verification, detecting hostile and invalid transactions and attacks, providing fraud prevention, and maintaining system integrity. In the context of this specific permitted use, this information MAY be used to alter the user's experience in order to reasonably keep a service secure or prevent fraud.

Issue 24: Possible exemption for fraud detection and defense

5.3.4 Debugging

Regardless of DNT signal, information MAY be collected, retained and used for debugging purposes to identify and repair errors that impair existing intended functionality.

5.3.5 Audience Measurement


Expecting further text on audience measurement.

Issue 25: How is audience measurement adressed under DNT? (permitted use or otherwise)

6. User-Granted Exceptions

When a user sends a DNT: 0 signal, the user is expressing a preference for a personalized experience. This signal indicates explicit consent for data collection, retention, processing, disclosure, and use by the recipient of this signal to provide a personalized experience for the user. This recommendation places no restrictions on data collected from requests received with DNT: 0.

The operator of a website may engage in practices otherwise proscribed by this standard if the user has given explicit and informed consent. This consent may be obtained through the API defined in the companion [TRACKING-DNT] document, or an operator of a website may also obtain out of band consent to disregard a Do Not Track preference using a different technology. If an operator is relying on out of band consent to disregard a Do Not Track preference, the operator must indicate this consent to the user agent as described in the companion [TRACKING-DNT] document.

7. Interaction with Existing User Privacy Controls

Multiple systems may be setting, sending, and receiving DNT and/or opt-out signals at the same time. As a result, it will be important to ensure industry and web browser vendors are on the same page with respect to honoring user choices in circumstances where "mixed signals" may be received.

As a general principle, more specific settings override less specific settings.

  1. No DNT Signal / No Opt-Out: Treat as DNT unset
  2. DNT:1 Signal / No Opt-Out: Treat as DNT: 1
  3. Opt-Out / No DNT:1 Signal: Treat as DNT: 1
  4. Opt-Out / DNT User-Granted Exception: Treat as DNT: 0 for that site; DNT User-Granted Exception is honored
Issue 210: Interaction with existing privacy controls

Issue 207: Conditions for dis-regarding (or not) DNT signals

8. Unknowing Collection

If a party learns that it possesses information in violation of this standard, it MUST, where reasonably feasible, delete or de-identify that information at the earliest practical opportunity, even if it was previously unaware of such information practices despite reasonable efforts to understand its information practices.

Issue 208: Requirements on unknowing collection, retention and use

A. Acknowledgements

This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando (Microsoft Corporation), Nick Doty (W3C), Roy T. Fielding (Adobe), Yianni Lagos (Future of Privacy Forum), Tom Lowenthal (Mozilla), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), Ninja Marnau (Invited Expert), Thomas Roessler (W3C), Matthias Schunter (IBM), Wendy Seltzer (W3C), John M. Simpson (Invited Expert), Kevin G. Smith (Adobe), Peter Swire (Invited Expert), Rob van Eijk (Invited Expert), David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and Shane Wiley (Yahoo!).

The DNT header field is based on the original Do Not Track submission by Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.

B. References

B.1 Normative references

R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. RFC. URL: http://www.ietf.org/rfc/rfc2616.txt
Roy T. Fielding; David Singer. Tracking Preference Expression (DNT). 02 October 2012. W3C Working Draft. URL: http://www.w3.org/TR/tracking-dnt/