This specification extends the [[TPE]] to achieve the following:

This document is an editors' straw man reflecting a snapshot of live discussions within the Tracking Protection Working Group . It does not necessarily constitute working group consensus. This draft has been prepared using the DNT Github repository and its associated issues list. However, see the previous issue tracking system for working group decisions prior to 2017. See for a summary of changes since the first Candidate Recommendation.


The GDPR requires that the identity of origin server is discoverable by web users, and the [[TPE]] supports this by enabling every origin server to identify itself by hosting a Tracking Status Resource (TSR) at the /.well-known/dnt/ location. This specification further requires that the information presented to a user before they agreed to a Tracking Exception, i.e. gave their informed consent for the collection and further processing of personal data derived from on-line activity, is permanently determinable from the TSR. As cookie headers SHOULD be present in the TSR request, servers can use them, or an identifier encoded in the DNT header as described in this specification, to determine what purposes the user has agreed to, and present them in a human-readable document pointed to by a new "purposes" TSR property. As cookies may not always be available to third-party requests the DNT encoded identifier could be a more reliable way to do it.

As well as introducing universal mechanisms for delivering machine-readable transparency information, and conveying a signal indicating individuals consent or otherwise for tracking in the DNT request header, the [[TPE]], via the Site-Specific Tracking Exception, introduced the ability to communicate this consent signal efficiently to embedded third-parties. Publishers can use this to signal immediately to third-parties when users have given consent, and the reverse when consent expires or is withdrawn. Under the GDPR consent must be "specific", meaning this signal must be capable of being selectively delivered to those parties to which the user has given their agreement, and this is supported by the API by allowing DNT:0 only to be sent to named embedded third-parties. Furthermore, when the user withdraws their consent, or has never given it, the opted-in/opted-out indication is restricted to a particular site - opting-out does not have to apply to the whole web, as it does when only standard third-party HTTP cookies are available.

Although a single boolean, indicating consent/no-consent, can be delivered this way, i.e. site-specifically via the DNT header, there is currently no way to do this similarly for data. HTTP cookies are intrinsically web-wide, once stored they will always be included in resource requests, whether to embedded third-parties or to first-party websites. The privacy concerns arising from this has led to cookies being increasingly blocked in third-party requests, either by the browser or by user action. Even when they are available users are much less likely to give their consent to tracking when there is no guarantee it will be constrained to one site, or a defined subset of sites. This means that if the user has agreed to site-specific tracking, say within a publishers first-party site, the persisted information has to recorded in a first-party cookie and communicated to embedded third-parties somehow. Even if this can be done in a scalable way, for example by editing the target URL with a mutually agreed encoding, the third-party could not persist it in one of its own cookies, because even if cookies were not blocked the tracking data would then be available web-wide, i.e on any site which embedded the same third-party.

This specification describes the ability for first-parties to efficiently communicate site-specific values to embedded third-party servers, but only after the user has agreed to a site-specific Tracking Exception indicating consent. This value is communicated to server in the DNT request header, and to their associated browsing contexts in the navigator.doNotTrack property.The data would be immediately available to the third-party server within the request, so there would be no need for additional round-trip delays. Like cookies, it would be available in all requests to the domain, i.e. not just to particular resources, and it would not need to be separately persisted. The value could be encoded by first-party script at any time, for any purpose for which then user had agreed, and there would be no need for the logistically complex and inefficient mechanisms needed for user-specific URL editing. The value is only transmitted to, or available to, first-party or embedded third-party servers in the context of a single site, or defined subset of the web, and this could be readily and externally verified.

As further security measures this value would only be settable when the registering API call is made within a user gesture, similar to the way the WebKit [[StorageAPI]] requestStorageAccess() is constrained, and only when the request is secure, i.e. delivered over https.

Browsers SHOULD support an ability to indicate to the user when a DNT header is carrying a site-specific value, say in the browser chrome. How this information interacts with browser specific anti-tracking features is left to browser vendors.

The Tracking Exception API has been extended to support the ability of servers to register a site-specific Tracking Exception value of "1", useful in situations where a user has not configured their browser with a general Tracking Preference, and servers are legally required to support a signal to indicate the right-to-object, for example under the GDPR's Article 21.5.'

Notational Conventions


The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [[!RFC2119]].

Formal Syntax

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [[!RFC5234]] to define network protocol syntax and WebIDL [[!WebIDL-20161215]] to define scripting APIs. Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

How to throw a DOMexception and the exceptions named "InvalidStateError", "SecurityError", and "SyntaxError" are defined in [[!WebIDL-20161215]].

Promise objects are defined in [[ECMASCRIPT]]; the phrases promise-call, resolve promise, reject promise, upon fulfillment, and upon rejection are used in accordance with [[PromiseGuide]].

Expressing a Tracking Preference

DNT Header Field for HTTP Requests

The following replaces the ABNF text and example

            DNT-field-name  = "DNT"
            DNT-field-value = ( "0" DNT-Consent / "1" )
            DNT-Consent = %x21-2B / %x2D-7E ; excludes CTL, SP, comma
GET /something/DoNotTrack HTTP/1.1
DNT: 1

GET /something/consentGiven HTTP/1.1
DNT: 02B3AC6

6.6.1 API to Store a Tracking Exception (amended)

The following definition has had a new "fieldValue" property added

        partial interface Navigator {
            Promise<TrackingExResult> storeTrackingException (
              TrackingExData properties
        dictionary TrackingExData {
           DOMString? site;
           sequence<DOMString>? targets;
           DOMString? name;
           DOMString? explanation;
           DOMString? details;
           long?      maxAge;
           DOMString  fieldValue;
        dictionary TrackingExResult {
          boolean isSiteWide;

The following text describes the new dictionary property "fieldValue"

When defined and not null or an empty string, fieldValue indicates the field-value of the DNT header to be sent to all domains for which this exception applies. Only a field-value consisting of either the single character "1", or a string whose first character is "0" and which complies with the definition of a DNT-Consent value, is valid. A string whose first character is "0" can only be registered via this call when the browser is processing a user gesture in which user has given their informed consent, AND the Tracking Exception requested is site-specific (i.e. the site property is not "*"), AND the call is being executed within a secure top-level browsing context. For all other string values, or the executing browsing context is not secure, or the site property is "*", or the browser is not executing a user gesture, the user agent MUST NOT store the exception, and MUST reject the promise with a DOMException named "SyntaxError".
  • If fieldValue is equal to "1" the user agent must send a DNT header with the field-value set to "1" for all requests to domains for which this exception applies; or
  • If the first character of fieldValue is "0", the executing context is top-level, secure and processing a user gesture, and the rest of the string is a valid DNT-Consent value, the user agent MUST send a DNT header with the field-value set to fieldValue for all requests to domains for which this exception applies; or
  • If fieldValue is not defined, null or the empty string the user agent MUST send a DNT header with the field-value set to "0" for all requests to domains for which this exception applies; or
  • If fieldValue is any other value then the user agent MUST NOT store an exception and MUST reject the promise with a DOMException named "SyntaxError".

Communicating a Tracking Status

7.5 Tracking Status Representation (amended)

Status Object

The following has been changed to add the new "purposes" property.

object {
    string tracking;                 // TSV
    array { string; } compliance?;   // hrefs
    string qualifiers?;              // compliance flags
    array { string; } controller?;   // hrefs
    array { string; } same-party?;   // domains
    array { string; } audit?;        // hrefs
    string policy?;                  // href
    string config?;                  // href
    string purposes?;                // href

The following example representation demonstrates a status object with all of the properties defined by this specification.

  "tracking": "T",
  "compliance": [""],
  "qualifiers": "afc",
  "controller": [""],
  "same-party": [
  "audit": [
  "policy": "/privacy.html#tracking",
  "config": "",
  "purposes":" "

Purposes Property

An origin server MAY send a property named purposes with a string value containing a URI reference to a human-readable document that describes each of the purposes for tracking implemented by this origin server.

If the origin server supports the DNT-Consent qualifier then this property MUST be supported and be dynamically generated by decoding the field-value of the request's DNT header, to highlight or otherwise indicate the specific subset of purpose the user has agreed to.

10. Privacy Considerations (Amended)


Information communicated via the DNT header field is minimized to avoid abuse of the field for fingerprinting or as a side-channel. However, the DNT-Consent extension allows for the sending of additional information when signaling consent for tracking via DNT:0, and could be used to send persistent state information without the user's knowledge. For this reason browsers MUST NOT register a DNT-Consent value when the browsing context is insecure, the Navigator.storeTrackingException call is for a web-wide Tracking Exception, or was not processed in the context of a user gesture. Servers MUST ensure that a DNT-Consent value is only used when the user has given their consent.

Browsers SHOULD support an ability to indicate to the user in the browser chrome when a DNT header is carrying a DNT-Consent extension.