Tracking Compliance and Scope W3C Last Call Working Draft 14 July 2015 This version: Latest published version: Latest editor's draft: Previous version: Editors: Nick Doty , W3C Heather West , Google (until 2014) Justin Brookman , CDT (until September 2013) Sean Harvey , Google (until June 2012) Erica Newland , CDT (until May 2012) Copyright © 2015 W3C ® ( MIT , ERCIM , Keio , Beihang ). W3C liability , trademark and document use rules apply. Abstract

This specification defines a set of practices for compliance with a user's Do Not Track (DNT) tracking preference to which a server may claim adherence.

Status of This Document

This section describes the status of this document at the time of Since 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 This document was published by the Tracking Protection Working Group last publication as a Last Call Working Draft on 14 July 2015. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to ( subscribe , archives ). All comments are publicly archived; if you have not used W3C mailing lists Candidate Recommendation in the past, you will need to approve archiving (instructions are sent via email auto-reply) before your comments will be distributed. The Last Call period ends 07 October 2015. All comments are welcome. The Tracking Protection Working Group invites broad community review, especially of technical requirements and dependencies. Reviewers are encouraged to comment on the extent to which technical requirements of the group's charter have been met and how significant dependencies with groups inside and outside W3C have April 2016, there has not been satisfied. The Working Group will evaluate all comments received and determine whether or how the specification needs to be modified in light sufficient adoption of the comments. Comments will be most useful in identifying particular problems with the specification that might inhibit adoption, or where this specification fails defined compliance practices to justify further goals advancement, nor have there been indications of planned support among user privacy and user control, and whether this specification creates or does not otherwise resolve dependencies with other technical standards, practices, or processes. The Chairs of the Working Group will issue written responses to all comments received. The Working Group previously published a Last Call Working Draft of the companion Tracking Preference Expression [ TPE ] specification, which defines mechanisms for expressing a user's preference regarding tracking and for communicating whether and how received preferences are honored. That specification is expected to transition to Candidate Recommendation shortly. Revisions from the previous Working Draft include editorial changes, removal of separate "tracking data" terminology, and updates to compliance with expressed tracking preferences agents, third parties, and indications of such compliance. Readers may review changes from the previous Working Draft . Publication as a Last Call 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 ecosystem at any time. It is inappropriate large. The working group has therefore decided to cite this document as other than conclude its work in progress. This is a Last Call Working Draft and thus republish the Working Group has determined that final product as this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process. 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 Note, with section 6 of the W3C Patent Policy . This document is governed by the 14 October 2005 W3C Process Document . Table of Contents 1. Scope 2. Definitions 2.1 User 2.2 User Agent 2.3 Network Interaction 2.4 User Action 2.5 Party 2.6 Service Provider 2.7 First Party 2.8 Third Party 2.9 De-identification 2.9.1 De-identification Considerations 2.10 Tracking 2.11 Collect, Use, Share 3. Server Compliance 3.1 Indicating Compliance and Non-Compliance 3.2 First Party Compliance 3.3 Third Party Compliance 3.3.1 General Requirements for Permitted Uses No Secondary Uses Data Minimization, Retention and Transparency No Personalization Reasonable Security 3.3.2 Permitted Uses Frequency Capping Financial Logging Security Debugging 3.3.3 Qualifiers for Permitted Uses 4. Consent 4.1 Transfer of consent any future addendums to another party 5. Interaction with Existing User Privacy Controls 6. Unknowing Collection 7. Legal Compliance A. Acknowledgements B. References B.1 Normative references be published separately.



Do Not Track is designed to provide users with a simple mechanism to express a preference to allow or limit online tracking . Complying with the user's preference as described in this document includes limits on the collection, retention and use of data collected as a third party to user actions and the sharing of data not permanently de-identified .

This specification is intended for compliance with expressed user preferences via 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 [ TPE ] [[!TPE]] specification; and, (3) can implement all of the [ TPE ] [[!TPE]] specification, including the mechanisms for communicating a tracking status, and the user-granted exception mechanism.

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





A user is a natural person who is making, or has made, use of the Web.


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 ]. [[!RFC7230]].


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.


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.



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.

When data pertaining to a user action is collected as a result of one or more network interactions, a party acts in one of roles defined below, i.e. as a first party or as a third party to a given user action. These terms are not meant to denote the business practices of a party as a whole, but rather to describe a party's role in a particular network interaction.


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 permanently de-identified 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.

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 to a given user action 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.

Network interactions related to a given user action may not constitute intentional interaction when, for example, the user is unaware or only transiently informed of redirection or framed content.


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.



Data is permanently de-identified when there exists a high level of confidence that no human subject of the data can be identified, directly or indirectly (e.g., via association with an identifier, user agent, or device), by that data alone or in combination with other retained or available information.


De-identification Considerations

This section is non-normative.

In this specification the term permanently de-identified is used for data that has passed out of the scope of this specification and can not, and will never, come back into scope. The organization that performs the de-identification needs to be confident that the data can never again identify the human subjects whose activity contributed to the data. That confidence may result from ensuring or demonstrating that it is no longer possible to:

  • isolate some or all records which correspond to a device or user;
  • link two or more records (either from the same database or different databases), concerning the same device or user; or
  • deduce, with significant probability, information about a device or user.

Regardless of the de-identification approach, unique keys can be used to correlate records within the de-identified dataset, provided the keys do not exist and cannot be derived outside the de-identified dataset and have no meaning outside the de-identified dataset (i.e. no mapping table can exist that links the original identifiers to the keys in the de-identified dataset).

In the case of records in such data that relate to a single user or a small number of users, usage and/or distribution restrictions are advisable; experience has shown that such records can, in fact, sometimes be used to identify the user or users despite technical measures taken to prevent re-identification. It is also a good practice to disclose (e.g. in the privacy policy) the process by which de-identification of these records is done, as this can both raise the level of confidence in the process, and allow for for feedback on the process. The restrictions might include, for example:

  • technical safeguards that prohibit re-identification of de-identified data;
  • business processes that specifically prohibit re-identification of de-identified data;
  • business processes that prevent inadvertent release of de-identified data;
  • administrative controls that limit access to de-identified data.

Geolocation data (of a certain precision or over a period of time) may itself identify otherwise de-identified data.



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.


Collect, Use, Share

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.


Server Compliance 3.1

Indicating Compliance and Non-Compliance

In order to indicate a party's compliance with a user's expressed tracking preference as described in this specification for a given resource, an origin server:

  1. MUST conform to the origin server requirements of [ TPE ]; [[!TPE]];
  2. MUST send a tracking status value other than ! (under construction) or D (disregarding) for that resource; and
  3. MUST send, in a tracking status representation applicable to that resource, a compliance property that contains a reference to the following URI:

The editor's draft URI points to content that will change. Versions of this document that are published as Working Drafts or later maturity levels will use permanent URIs in this section, pointing to content that does not change.

When a user sends a DNT:0 signal, the user is expressing a preference to allow tracking. This specification places no restrictions on collection or use of data from network interactions with DNT:0 signals. Note, however, that a party might be limited by its own statements to the user regarding the DNT:0 setting. For more information, see Section 4. Consent .

A party to a given user action which receives a DNT:1 signal and is tracking that action MUST indicate so to the user agent. A party that is tracking a user with that user's consent to override an expressed DNT:1 preference MUST indicate so with the corresponding C or P tracking status values . A party that is tracking a user for reasons allowable under this specification (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:1 signal MUST indicate that non-compliance to the user agent, using the response mechanism defined in the [ TPE ] [[!TPE]] specification. 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 [ TPE ] [[!TPE]] 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.


First Party Compliance

With respect to a given user action, a first party to that action which receives a DNT:1 signal MAY collect, retain 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 specification. Data about the interaction MAY be shared with service providers acting on behalf of that first party.

Compliance rules in this section apply where a party determines that it is a first party to a given user action — either because network resources are intended only for use as a first party to a user action or because the status is dynamically discerned. For cases where a party later determines that data was unknowingly collected as a third party to a user action, see Section 6. Unknowing Collection .

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


Third Party Compliance

When a third party to a given user action receives a DNT:1 signal in a related network interaction, that party MAY collect and use data about those network interactions when:

  1. a user has explicitly granted consent, as described below (Section 4. Consent );
  2. the data is collected for the set of permitted uses described below (Section 3.3.2 Permitted Uses ); or
  3. or, the data is permanently de-identified as defined in this specification.

Other than under those enumerated conditions, that party:

  1. MUST NOT collect data from this network interaction that would result in data regarding this particular user being associated across multiple contexts;
  2. MUST NOT retain, use, or share data from this particular user's activity outside the context in which that activity occurred; and
  3. MUST NOT use data from network interactions with this particular user in a different context .

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.


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”. "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 publicly describe definite 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 permanently de-identified .
No Personalization

A party that collects data for a permitted use MUST NOT use that data to alter a specific user's online experience, 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.


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.

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 specification and other standards.


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 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. In this specification, a graduated response is a data minimization methodology where actions taken are proportional to the problem or risk being mitigated.


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.


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 [ TPE ] [[!TPE]] document. While providing qualifiers is OPTIONAL , 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

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.



A party MAY engage in practices otherwise proscribed by this specification when the user has given explicit and informed consent. After consent is received, it might be subsequently registered through the User-Granted Exceptions API defined in the companion [ TPE ] [[!TPE]] document or recorded out of band using a different technology. A party MUST indicate when it is relying on out of band consent to override a Do Not Track preference, as described in the companion [ TPE ] [[!TPE]] document.


Transfer of consent to another party

When a party requests consent from the user as described above, it might include consent for sharing data with its service providers . This transitive permission might apply even to those parties to which the user has not separately granted consent to be tracked.

A party that transfers consent in this way MUST ensure that its service providers acknowledge this consent by use of the corresponding tracking status value of C and a qualifier of t ("transferred").


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, as where the specific consent in user-granted exceptions overrides a general preference. If a party perceives a conflict between settings, a party MAY seek clarification from the user or MAY honor the more restrictive setting.


Unknowing Collection

If a party learns that it possesses data in violation of this specification, it MUST , 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.


Legal Compliance

Notwithstanding anything in this specification, a party MAY collect, use, and share data required to comply with applicable laws, regulations, and judicial processes.

Implementers might find the following resources useful in determining how use of Tracking Compliance interacts with requirements in various jurisdictions:



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), Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Vinay Goel (Adobe), Yianni Lagos (Future of Privacy Forum), Tom Lowenthal (Mozilla), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford), Ninja Marnau (Invited Expert), Mike O'Neill (Baycloud Systems), Thomas Roessler ( W3C ), (W3C), Wendy Seltzer ( W3C ), (W3C), Rob Sherman (Facebook), John M. Simpson (Invited Expert), David Singer (Apple), Kevin G. Smith (Adobe), Vincent Toubiana (Invited Expert), Rigo Wenning ( W3C ), (W3C), and Shane Wiley (Yahoo!). The co-chairs of the group have helped guide those discussions: Justin Brookman ( CDT ), Carl Cargill (Adobe), Aleecia M. McDonald (Stanford), Matthias Schunter (Intel), and Peter Swire (Invited Expert).

Many thanks to Robin Berjon for ReSpec .

B. References B.1 Normative references [RFC7230] R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing . June 2014. Proposed Standard. URL: [TPE] Roy T. Fielding; David Singer. Tracking Preference Expression (DNT) . 24 April 2014. W3C Last Call Working Draft. URL: