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 draft does not constitute consensus and does not claim to indicate any preferred text of the group. Reviewers are advised to consult the list of issues tracked in the Compliance Current product and the wiki list of change proposals developed by participants in the Working Group. It may further be augmented by adding non-normative text that provides more information. The Working Group has published a Last Call Working Draft of the companion Tracking Preference Expression document.

Revisions from the previous Working Draft primarily consist of harmonizing compliance requirements and terminology with the mechanisms defined in the Tracking Preference Expression document. Readers may review changes from the previous Working Draft.

This document was published by the Tracking Protection Working Group as a Working Draft on 07 August 2014. 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 [RFC7230].

Issue 227: User Agent requirements in UA Compliance vs. Scope section

There is a proposal to move a sentence about user agents from the Introduction/Scope section to this section. We might also include a reference here to the conformance requirements on user agents in the companion TPE recommendation.

2.3 Network Interaction

A network interaction is a single HTTP request and its corresponding response(s): zero or more interim (1xx) responses and a single final (2xx-5xx) response.

2.4 User Action

A user action is a deliberate action by the user, via configuration, invocation, or selection, to initiate a network interaction. Selection of a link, submission of a form, and reloading a page are examples of user actions.

2.5 Subrequest

A subrequest is any network interaction that is not directly initiated by user action. For example, an initial response in a hypermedia format that contains embedded references to stylesheets, images, frame sources, and onload actions will cause a browser, depending on its capabilities and configuration, to perform a corresponding set of automated subrequests to fetch those references using additional network interactions.

2.6 Party

A party is a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user. Common branding or providing a list of affiliates that is available via a link from a resource where a party describes DNT practices are examples of ways to provide this discoverability.

2.7 Service Provider

Access to Web resources often involves multiple parties that might process the data received in a network interaction. For example, domain name services, network access points, content distribution networks, load balancing services, security filters, cloud platforms, and software-as-a-service providers might be a party to a given network interaction because they are contracted by either the user or the resource owner to provide the mechanisms for communication. Likewise, additional parties might be engaged after a network interaction, such as when services or contractors are used to perform specialized data analysis or records retention.

For the data received in a given network interaction, a service provider is considered to be the same party as its contractee if the service provider:

  1. processes the data on behalf of the contractee;
  2. ensures that the data is only retained, accessed, and used as directed by the contractee;
  3. has no independent right to use the data other than in a deidentified form (e.g., for monitoring service integrity, load balancing, capacity planning, or billing); and,
  4. has a contract in place with the contractee which is consistent with the above limitations.

2.8 First Party

With respect to a given user action, a first party is a party with which the user intends to interact, via one or more network interactions, as a result of making that action. Merely hovering over, muting, pausing, or closing a given piece of content does not constitute a user's intent to interact with another party.

In some cases, a resource on the Web will be jointly controlled by two or more distinct parties. Each of those parties is considered a first party if a user would reasonably expect to communicate with all of them when accessing that resource. For example, prominent co-branding on the resource might lead a user to expect that multiple parties are responsible for the content or functionality.

2.9 Third Party

For any data collected as a result of one or more network interactions resulting from a user's action, a third party is any party other than that user, a first party for that user action, or a service provider acting on behalf of either that user or that first party.

2.10 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 make no attempt to re-identify the data; and
  3. contractually prohibits downstream recipients from attempting to re-identify the data.

Note that geolocation data (of a certain precision or over a period of time) may itself identify otherwise deidentified data.

Issue 188: Definition of de-identified (or previously, unlinkable) data

Issue 202: Limitations on geolocation by third parties

2.11 Tracking

Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties.

2.12 Collect, Use, Share, Facilitate

A party collects data received in a network interaction if that data remains within the party’s control after the network interaction is complete.

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 it transfers or provides a copy of data to any other party.

A party facilitates any other party’s collection of data if it enables such party to collect data and engage in tracking.

2.13 Graduated Response

A graduated response a methodology where the action taken is proportional to the size of the problem or risk that is trying to be mitigated. In the context of this document, the term is used to describe an increase in the collection of data about a user or interaction in response to a specific problem that a party has become aware of, such as an increase in fraudulent activity originating from a particular network or IP address range resulting in increased logging of data relating to interactions from that specific range of IP addresses as opposed to increased logging for all users in general.


Only used in security, below, and may overlap with the explanation there. Delete the definition and let it be defined the only place it's used?

3. Server Compliance

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


As part of ISSUE-203, the Working Group is actively discussing the use of "tracking" and "context" in the framing of these requirements. These sections may change.

It is outside the scope of this specification to control short-term, transient collection and use of data, so long as the data is not shared with 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 a DNT:1 signal.

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

3.1 Indicating Compliance and Non-Compliance

In order to communicate compliance with a user's expressed tracking preference as described in this recommendation, a party MUST indicate compliance using the tracking status resource defined in the [TRACKING-DNT] recommendation. A party MUST use the following URI (in the compliance property array) to indicate compliance with this version of the recommendation:


A party to a given user action that is tracking that action MUST indicate so to the user agent. A party that is tracking a user with that user's consent MUST use the corresponding C or P tracking status values. A party that is tracking a user for reasons allowable under this recommendation (for example, for one of the permitted uses described below) MUST use the T value. A party to a given user action that is not engaged in tracking SHOULD use the N value (a T value is also conformant but not as informative).

A party to a given user action that disregards a DNT signal MUST indicate so to the user agent, using the response mechanism defined in the [TRACKING-DNT] recommendation. The party MUST provide information in its privacy policy listing the specific reasons for not honoring the user's expressed preference. The party's representation MUST be clear and easily discoverable.

In the interest of transparency, especially where multiple reasons are listed, a server might use the [TRACKING-DNT] qualifiers or config properties to indicate a particular reason for disregarding or steps to address the issue. A user agent can parse this response to communicate the reason to the user or direct the user to the relevant section of a privacy policy. This document does not define specific qualifiers for different reasons servers might have for disregarding signals.

3.2 First Party Compliance

With respect to a given user action, a first party to that action which receives a DNT:1 signal MAY collect and use data received from those network interactions. This includes customizing content, services and advertising with respect to those user actions.

A first party to a given user action MUST NOT share data about those network interactions with third parties to that action who are prohibited from collecting data from those network interactions under this recommendation. Data about the interaction MAY be shared withh service providers acting on behalf of the first party.

A first party to a given user action MAY elect to follow the rules defined under this recommendation for third parties.


Given WG decision on ISSUE-241, how should a first party to an action indicate to the user that it is electing to follow third-party rules? Should we suggest using "N" or some other tracking status code?

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

3.3 Third Party Compliance

When a third party to a given user action receives a DNT:1 signal in a related network interaction:

  1. that party MUST NOT collect, share, or use data related to that interaction;
  2. that party MUST NOT use data about previous network interactions in which it was a third party.

A third party to a given user action MAY nevertheless collect and use such data when:

  1. a user has explicitly-granted an exception, as described below;
  2. data is collected for the set of permitted uses described below;
  3. or, the data is de-identified as defined in this recommendation.

Outside the permitted uses and explicitly-granted exceptions listed below, a third party to a given user action MUST NOT collect, share, or associate with related network interactions any identifiers that identify a 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.

3.3.1 General Requirements for Permitted Uses

Some collection and use of data by third parties to a given user action is permitted, notwithstanding receipt of DNT:1 in a network interaction, as enumerated below. Different permitted uses may differ in their permitted items of data collection, retention times, and consequences. In all cases, collection 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”.


The requirements in the following sub-sections apply to a party that collects data for a permitted use and that would otherwise be prohibited from collecting, retaining or using that data under the third-party compliance requirements above. Where a first party to a given user action, for example, collects some data for a purpose listed among the permitted uses (e.g. security of network services), these requirements do not apply. No Secondary Uses

A party MUST NOT use data collected for permitted uses for purposes other than the permitted uses for which each datum was permitted to be collected. Data Minimization, Retention and Transparency

Data collected by a party for permitted uses MUST be minimized to the data reasonably necessary for such permitted uses. Such data MUST NOT be retained any longer than is proportionate to, and reasonably necessary for, such permitted uses. A party MUST NOT rely on unique identifiers if alternative solutions are reasonably available.

A party MUST provide public transparency of the time periods for which data collected for permitted uses are retained. The 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 deidentified.

Issue 199: Limitations on the use of unique identifiers No Personalization

A party that collects data for a permitted use MUST NOT use that data to alter a specific user's online experience based on multi-site activity, except as specifically permitted below. Reasonable Security

A party that collects data for a permitted use 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. That party SHOULD ensure that the access and use of data retained for permitted uses is auditable.

3.3.2 Permitted Uses

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

Regardless of the tracking preference expressed, data 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. A party MUST NOT construct profiles of users or user behaviors based on their ad frequency history, or otherwise alter the user’s experience. Financial Logging

Regardless of the tracking preference expressed, data MAY be collected 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. Security

Regardless of the tracking preference expressed, data MAY be collected and used to the extent reasonably necessary to detect security incidents, protect the service against malicious, deceptive, fraudulent, or illegal activity, and prosecute those responsible for such activity, provided that such data is not used for operational behavior (profiling or personalization) beyond what is reasonably necessary to protect the service or institute a graduated response.

When feasible, a graduated response to a detected security incident is preferred over widespread data collection. An example would be recording all use from a given IP address range, regardless of DNT signal, if the party believes it is seeing a coordinated attack on its service (such as click fraud) from that IP address range. Similarly, if an attack shared some other identifiable fingerprint, such as a combination of User Agent and other protocol information, the party could retain logs on all interactions matching that fingerprint until it can be determined that they are not associated with such an attack or such retention is no longer necessary to support prosecution. Debugging

Regardless of the tracking preference expressed, data MAY be collected, retained and used for debugging purposes to identify and repair errors that impair existing intended functionality. Audience Measurement

Note: An open question for the group is whether or how audience measurement would be addressed; see issue 25.

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

3.3.3 Qualifiers for Permitted Uses

A party MAY indicate which of the listed permitted uses apply to tracking of a user with the qualifiers mechanism defined in the [TRACKING-DNT] document. While providing qualifiers is OPTIONAL, a party that wishes to indicate particular permitted uses MUST use the corresponding characters as indicated in the table below.

qualifier permitted use
c frequency capping
f financial logging
s security
d debugging
m audience measurement

A party MAY use multiple qualifiers to indicate that multiple permitted uses of tracking might be ongoing and that each such use conforms to any corresponding requirements. Where qualifiers are present, a party MUST indicate all claimed permitted uses.


The qualifiers in this table correspond directly to the permitted uses described in the previous section. This list, the characters and the names may change depending on the resolution of open issues regarding the permitted uses.

4. 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.

A party MAY engage in practices otherwise proscribed by this recommendation 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 a party MAY obtain out of band consent to disregard a Do Not Track preference using a different technology. If a party is relying on out of band consent to disregard a Do Not Track preference, the party MUST indicate this consent to the user agent as described in the companion [TRACKING-DNT] document.

5. 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

6. Unknowing Collection

If a party learns that it possesses data in violation of this recommendation, it MUST, where reasonably feasible, delete or de-identify that data 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, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: http://www.ietf.org/rfc/rfc7230.txt
Roy T. Fielding; David Singer. Tracking Preference Expression (DNT). 24 April 2014. W3C Last Call Working Draft. URL: http://www.w3.org/TR/2014/WD-tracking-dnt-20140424/