Tracking Compliance and Scope defines a set of requirements and best practices regarding tracking to which an origin server can claim adherence by reference within the tracking status representation of the Tracking Preference Expression (TPE) protocol. These requirements and best practices are intended to meet a user's expectations regarding a Do Not Track (DNT) preference by limiting tracking to specific permitted uses and retention policies when DNT:1 is received.

This temporary editor's draft is provided as a proposal to address ISSUE-203. It does not constitute consensus and will change frequently, with the goal of eventually replacing or merging with TCS.

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. The Working Group has published a Last Call Working Draft of the companion Tracking Preference Expression document.


This specification defines a set of compliance requirements and best practices for tracking protection. It applies to any tracking data that has been collected via a resource for which the origin server provided a corresponding tracking status representation, as defined in [[!TRACKING-DNT]], with a compliance property that contained at least one reference to this specification (see ).

In other words, this specification applies whenever a party that controls a given resource claims to be adhering to this specification. Such a claim implies that the origin server, resource owner, and all recipients of the data collected as a result of accessing that resource (during the period in which the tracking status representation is fresh) intend to conform to this specification with regard to that data for as long as that data has not been de-identified.

The remainder of this specification assumes that the origin server has indicated compliance on behalf of the party (or joint parties) that control any data collected via the designated resource. Requirements that are placed on either a party or an origin server are meant to constrain both the behavior of the origin server software and the behavior of any party that receives data collected via the designated resource.

Data collection, retention, use, or sharing that does not amount to tracking is outside the scope of this specification. For example, collecting data about a particular user's activity within a single context is not considered tracking, but retaining, using, or sharing data derived from that activity (such as a user profile) outside the context in which that activity occurred is considered tracking. Likewise, data that has been de-identified is outside the scope of this specification.

Short-term, transient collection and use of data is also outside the scope of this specification so long as the data is not used to build a profile about the user. For example, customization of ads based only on the current context in which the ad is placed, such as the content of the surrounding page or nature of the site being visited, is not restricted by a tracking preference.


This specification uses the following terms as they have been defined by [[!TRACKING-DNT]]: tracking, context, designated resource, user, user agent, network interaction, user activity, party, collects, uses, and shares.

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


Data is de-identified 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.

OPEN This definition is being actively discussed and may soon be replaced by a term with less baggage.

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


Indicating Compliance

To indicate compliance with this specification for a given designated resource, an origin server MUST do all of the following:

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

The editor's draft URI points to content that will change and is only suitable for testing purposes. 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.

Communicating Tracking Status

When a tracking status representation is used to communicate the tracking status for a designated resource, the origin server MUST send within the representation's tracking property a TSV that is consistent with the current or anticipated tracking that might occur if a similar request is sent to that designated resource.

When a Tk response header field [[!TRACKING-DNT]] is used to communicate a tracking status for the current request, the origin server MUST send a TSV that either refers to a request-specific tracking status resource or reflects the target resource's current tracking behavior for this request.

Adhering to Tracking Status

An origin server that sends a TSV of N (not tracking) MUST NOT engage tracking if a similar request is made to the designated resource while that tracking status remains fresh. A tracking status remains fresh until 24 hours after retrieval or, if later, until the HTTP response metadata indicates that it is stale (see Section 6.4.4 Caching of [[!TRACKING-DNT]]). In other words, the party MUST NOT knowingly collect, retain, use, or share data from a network interaction with the designated resource that would allow that party to associate the same user with tracking data it has previously obtained from user activity in other contexts, MUST NOT retain, use, or share data derived from this user activity outside the context in which this activity occurred, and MUST NOT tailor or personalize the response from the designated resource based on data derived from this user's activity in other contexts (aside from contextual data provided by the user in the current request).

An origin server that sends a TSV of T (tracking) MAY engage tracking if a similar request is made to the designated resource. Further limitations on that tracking depend on the received tracking preference expression, if any:

The user is expressing a preference for a personalized experience and this signal indicates explicit consent for data collection, retention, use, and sharing by the recipient of this signal to provide a personalized experience for the user. This specification does not limit tracking in the presence of DNT:0. Note, however, a party might be limited by its own statements to the user, if any, regarding the DNT:0 setting.
The party MUST limit its tracking to the permitted uses defined in . The party MAY provide additional information in the qualifiers property of a tracking status representation to indicate what permitted uses of tracking are engaged while under DNT:1, as described in . The party MUST NOT share data about this network interaction with any party other than the controller(s) of the context in which this activity occurred, service providers to said controller(s), or service providers to the party.
not enabled
In the absence of regulatory, legal, or other requirements, a party MAY interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, origin servers might make use of other preference information outside the scope of this specification, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed in a request.

An origin server that sends a TSV of C (consent) MUST have received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, that overrides a tracking preference expressed by this protocol.

An origin server that sends a TSV of P (potential consent) MAY engage tracking for requests made to the designated resource, but MUST NOT use or share any data to which DNT:1 applies until it can be determined that it has received prior consent to do so. If not, the origin server MUST delete or de-identify the collected data within forty-eight hours.

An origin server MAY send a tracking status value of ? (dynamic), D (disregarding), or U (updated) when such a response is consistent with its associated requirements in [[!TRACKING-DNT]].

Limited Tracking Permitted under DNT:1

When an origin server sends a TSV of T (tracking) for a designated resource and a request is received targeting that resource with a tracking preference expression of DNT:1, some limited tracking is still permitted if it conforms to the requirements of this section.

General Requirements for Permitted Uses

Data Minimization, Retention, and Transparency

When DNT:1 is received, a party MUST minimize the tracking data it collects under one or more permitted uses to what is reasonably necessary for each such permitted use. A party MUST NOT retain such data any longer than is proportionate to, and reasonably necessary for, those permitted uses.

A party MUST provide public transparency of the time periods for which tracking data collected for permitted uses are retained. A party MAY enumerate different retention periods for different permitted uses. A party MUST NOT use data collected for a permitted use once the data retention period for that permitted use has expired. When all such data retention periods have expired for the permitted uses for which a given data set has been retained, the party MUST delete or de-identify that data.

No Secondary Uses

When DNT:1 is received, a party MUST NOT use tracking data collected in that request for purposes other than the permitted use(s) for which that data was collected.

A party that collects tracking data under a permitted use MUST implement reasonable technical and organizational safeguards to prevent further processing of that data for non-permitted uses. While physical separation of data retained for permitted uses is not required, a party SHOULD implement best practices and technical controls that ensure access limitations and information security. A party SHOULD ensure that access and use of data retained under one or more permitted uses is auditable.

Permitted Uses

Frequency Capping

When DNT:1 is received, a party MAY collect, retain, and use tracking data to limit the number of times that a user sees a particular advertisement — a practice commonly referred to as frequency capping — provided that the retained data does not reveal the user’s browsing history. A party MUST NOT construct profiles of users or user behaviors, or otherwise alter a user’s experience beyond the effect of frequency capping, based on the ad frequency history retained under this permitted use.

Financial Logging

When DNT:1 is received, a party MAY collect, retain, and use tracking data to support 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, tracking referrals and conversion to the extent necessary to account for an agreed bounty program, and auditing compliance with this and other standards.


When DNT:1 is received, a party MAY collect, retain, and use tracking data 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.

When feasible, a graduated response to a detected security incident is preferred over widespread data collection. A graduated response is 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.


When DNT:1 is received, a party MAY collect, retain, and use tracking data for debugging purposes to identify and repair errors that impair existing intended functionality.

Audience Measurement

An open question for the group is whether or how audience measurement would be addressed.

Sending Qualifiers to Indicate Permitted Uses

A party MAY send the qualifiers property in a tracking status representation [[TRACKING-DNT]] to communicate what permitted uses of tracking might be in use for the designated resource. Multiple qualifier characters indicate that each of those permitted uses might be used.

While sending qualifiers is OPTIONAL, a party that does send qualifiers MUST send exactly those characters corresponding to the applicable permitted uses for that designated resource, as defined by the following table.

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

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

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.

Legal Compliance

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


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.