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

• to support the ability of user agents to determine and possibly record the information presented to individuals when they are asked to give their consent for tracking, such as the reasons for why data is collected, and what it will be used for. User agents can then make this information available to users, for example whenever they request it, helping to meet the transparency requirements of European data protection/privacy law.
• to define a mechanism whereby persisted state information may be specified and delivered in site-specific way, i.e. restricted to a top-level context and the embedded third-parties that have obtained site-specific consent.
• to allow a top-level context to specify domain specific DNT:1, which can be used to express a user's right-to-object to data collection or processing in certain circumstances, as called for by Article 21 of the GDPR.

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.

Introduction

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

Expressing a Tracking Preference

            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
Host: example.com
DNT: 1

GET /something/consentGiven HTTP/1.1
Host: example.com
DNT: 02B3AC6

DNT:0 purpose=an,ad

DNT:0 audience=male>65

Communicating a Tracking Status

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
}*;

{
  "tracking": "T",
  "compliance": ["https://acme.example.org/tracking101"],
  "qualifiers": "afc",
  "controller": ["https://www.example.com/privacy"],
  "same-party": [
    "example.com",
    "example_vids.net",
    "example_stats.com"
  ],
  "audit": [
    "http://auditor.example.org/727073"
  ],
  "policy": "/privacy.html#tracking",
  "config": "http://example.com/your/data",
  "purposes":"https://example.com/purposesAgreed/ "
}

10. Privacy Considerations (Amended)