The DNT Purposes qualifier

When a particular domain originimplements tracking for multiple distinct purposes, described to the user before they are given the option to agree to one or more of them, the subset of purposes the user has selected must be communicated to the relevent domain origins. While cookies may be used for this, they may not be available to nested browsing contexts or other embedded sub-resources, and in any case the Same Origin Policy would stop them being set by an embedding domain origin, e.g. by a parent or a first-party domain.

The DNT Purposes qualifier allows an arbitrarily encoded purpose indication string to be communicated to servers solely in circumstances where the user has given their informed consent. It is denoted by "p=" followed by one or more alphanumeric characters (excluding "&", ";", CTL, SP, DQUOTE, comma or backslash). The JavaScript storeTrackingException API can be used to specify a DNT field-value containing the DNT Purposes qualifier, which can be encoded in any way that the relevent server that receives it can decode, as long as the user can always easily ascertain what purposes they have agreed to.

If an origin server implements the DNT Purposes qualifier it must only enable the tracking procedures it has described and to which the user has agreed, and MUST implement a site-wide tracking status resource with a valid Purposes property. The Purposes property is a dynamically determined HTML resource containing a human-readable explanation of all the purposes for tracking that a domain origin implements, as well as the specific purposes a particular user has agreed to as communicated in the the DNT header of the request to the site-wide tracking status resource.

For example, a request containing

DNT:0 p=an,ad

Extensions to the DNT Field Value

Future extensions to the DNT header should be encoded as a name-value pair that corresponds to the ABNF DNT-extension, where the name is a single alphanumeric character and the value any string.

API to Store a Tracking Exception

When a site has obtained consent for a user-granted exception, or a user has indicated their objection to lawfully exempted tracking when their tracking preference is not enabled, a script running within an active browsing context or nested browsing context of that site can promise-call Navigator.storeTrackingException to store one or more tracking exceptions. A script running within an active browsing context or nested browsing context can promise-call Navigator.storeTrackingException to store one or more tracking exceptions. A TrackingExData object is supplied as a parameter to define the exception's scope (the set of [site, target] duplets that encompass the granted exception) and optional information to be stored for that exception. The call returns a promise which either resolves to a TrackingExResult or is rejected with a DOMException identifying the reason for the failure.

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

Navigator.storeTrackingException passes a TrackingExData object. A user agent MUST ignore unknown properties of the TrackingExData object (for future extensibility). The following OPTIONAL properties are defined:

site

The referring domain scope for which the exception applies:

• If site is undefined, null, or the empty string, the exception's referring domain scope defaults to the script domain.
• If site is defined and equal to "*", the exception is intended to be web-wide for the set of targets. A user agent MUST reject the promise with the DOMException named "SecurityError" if both site and any of the targets are "*".
• Otherwise, the exception's referring domain scope is defined by a domain found in site that is treated in the same way as the domain parameter to cookies [[!RFC6265]], allowing subdomains to be included with the prefix "*.". The value can be set to a fully-qualified right-hand segment of the document host name, up to one level below TLD.

targets

An array of target domains for which the exception applies:

• If targets is undefined or null, the user-granted exception to be stored is [site, *], meaning that the exception applies to all domains referenced by the site.
• If targets is an empty array, the user-granted exception to be stored is [site, script domain], meaning that the exception applies only to resources that share the same domain as the effective script origin.
• Otherwise, for each domain string in the targets array, a user-granted exception to be stored is the duplet [site, domain].

name

When defined and not null or an empty string, name is a user-readable string for naming the exception, usually descriptive of the targets or their intended purpose for this site.

explanation

When defined and not null or an empty string, explanation is a user-readable short explanation of the granted exception.

details

When defined and not null or an empty string, details is a URI reference at which further information about the granted exception can be found [[!RFC3986]].

maxAge

When defined and not null, maxAge is a positive number of seconds indicating the maximum lifetime of the grant:

• If maxAge is supplied and not null, empty, or negative, the user agent MUST remove the stored exception no later than the specified number of seconds after being stored.
• If maxAge is not supplied, the user agent MAY retain the stored grant indefinitely.

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-field-value, is valid. A string whose first character is "0" can only be supplied in circumstances where the user has given their informed consent. For all other string values 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", and the rest of the string is a valid DNT-extension, 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".

The properties name, explanation, and details are provided by the caller for the sake of potential user interfaces. If a user agent presents these properties to the user, it ought to be clear that they are provided for informational value and are less important than the exception's technical effect.

In addition to the data above, a user agent might also store ambient information about the call, such as the URI associated with the top-level browsing context, the effective script origin, a current timestamp, or other information potentially obtained from applicable tracking status resources.

The calling script domain MUST have a site-wide tracking status resource with a valid tracking status representation that includes a policy property. This allows a user agent to obtain and possibly store additional information about the caller’s controller and tracking policies at the time an exception is granted.

A user agent MAY reject the promise with a DOMException named "InvalidStateError" if it cannot determine the effective script origin or if the site corresponding to that origin does not have a site-wide tracking status resource with a valid tracking status representation.

For each site-specific exception being stored, a user agent MUST NOT store the duplets and MUST reject the promise with a DOMException named "SecurityError" if the script would not be able to set a cookie on that duplet's referring domain scope following the cookie domain rules [[!RFC6265]].

For example, a script on www.foo.bar.example.com can set the site as "bar.example.com" or "example.com", but not to "something.else.example.com" or "com".

For each web-wide exception being stored, a user agent MUST NOT store the duplets and MUST reject the promise with a DOMException named "SecurityError" if the script would not be able to set a cookie on that target domain following the cookie domain rules [[!RFC6265]]. This limits storing of a web-wide exception to scripts that share the same domain scope as the exception targets, but allows such scripts to be embedded within iframes of a common consent portal.

For any other failure, such as an incorrectly formatted parameter in the TrackingExData, the user agent MUST NOT store any of the target duplets in the database and MUST reject the promise with a DOMException named "SyntaxError".

Upon fulfillment, the user agent has added to its local database one or more site-pair duplets [site, target], each indicating that a request from that site domain to the target domain will include DNT:0 regardless of the user's general tracking preference. The fulfilled promise object contains the following TrackingExResult attribute:

isSiteWide

true if the user agent stored a potentially broader exception that applies to all domains (as opposed to just the listed targets); otherwise, false.

When a list of targets is supplied for a site-specific exception, the user agent MAY ignore that list, choosing instead to store a site-specific exception for all domains ([site, *]), if it also indicates that result by setting the returned promise's isSiteWide property to true.

User agents MAY instantiate Navigator.storeTrackingException even when Navigator.doNotTrack is null. Scripts SHOULD test for the existence of Navigator.storeTrackingException before calling the method.

There are some security concerns here regarding the ability of a script with an effective script origin matching one site being able to persist the DNT value received by resources on other (target) sites. In particular, this feature could be abused to set/unset an array of exceptions, similar to an array of bit values, and be "read" as a persistent identifier by embedding requests to those domains (which might all point to the same Internet host). However, we expect that would leave an obvious trail on the user agent, unlike other sources of fingerprinting.

Likewise, allowing an exception to be stored within an iframe of another site's page could be ripe for abuse unless the calling script ensures that it is being run within a page where it expects to be collecting user consent and where the context of that consent is consistent with the exceptions being stored.

This design is consistent with the fact that there is no technical restraint from sites calling the API without having first obtained an informed consent from the user. We are assuming that the social and regulatory environment will be sufficient to punish those who might misuse the API or abuse the scope of stored exceptions. A user agent might further limit such risks by checking for a site-wide tracking status resource when its presence is required by the API.

API to Remove a Tracking Exception

When a site decides, or has been directed by the user, to revoke a user-granted exception, a script running within an active browsing context or nested browsing context of that site can promise-call Navigator.removeTrackingException to remove one or more tracking exceptions. A TrackingExData object is supplied as a parameter to identify which exceptions are to be removed. The call returns a promise which either resolves to indicate success or is rejected with a DOMException identifying the reason for the failure.

        partial interface Navigator {
          Promise<void> removeTrackingException (
            TrackingExData properties
          );
        };
        

Navigator.removeTrackingException passes a TrackingExData object. A user agent MUST ignore unknown properties of the TrackingExData object (for future extensibility). The following OPTIONAL properties are defined:

site

The referring domain scope for which the exception applies:

• If site is undefined, null, or the empty string, the exception's referring domain scope defaults to the script domain. All stored exceptions matching that domain, regardless of target, are to be removed.
• If site is defined and equal to "*", the exceptions to be removed are web-wide and identified by the set of targets.
• Otherwise, the exceptions to be removed are identified by a domain found in site that is treated in the same way as the domain parameter to cookies [[!RFC6265]], allowing subdomains to be included with the prefix "*.". All stored exceptions matching that domain scope, regardless of target, are to be removed.

targets

An array of target domains for which the exception applies:

• If site is not defined or not equal to "*", then targets is ignored (it is only used for removing web-wide exceptions).
• If targets is an empty array, the web-wide exception to be removed is the duplet [*, script domain].
• Otherwise, for each domain string in the targets array, a web-wide exception to be removed is the duplet [*, domain].

For each site-specific exception being removed, a user agent MUST NOT remove the duplets and MUST reject the promise with a DOMException named "SecurityError" if the script would not be able to set a cookie on that duplet's referring domain scope following the cookie domain rules [[!RFC6265]].

For each web-wide exception being removed, a user agent MUST NOT remove the duplets and MUST reject the promise with a DOMException named "SecurityError" if the script would not be able to set a cookie on that target domain following the cookie domain rules [[!RFC6265]].

Any processing failure, such as an incorrectly formatted parameter in the TrackingExData, will result in no duplet being removed from the database of stored grants and the returned promise being rejected with a DOMException named "SyntaxError".

If there are no matching duplets in the database of stored grants when the method is called, this operation does nothing other than resolve the promise.

Upon fulfillment, the user agent MUST have removed any stored exceptions that matched the identified duplet(s).

API to Confirm a Tracking Exception

When a site wishes to confirm that a user-granted exception exists for a set of target domains potentially referenced by that site, a script running within an active browsing context or nested browsing context of that site can promise-call Navigator.trackingExceptionExists with a TrackingExData object supplied as a parameter that identifies the set of exceptions to confirm. The call returns a promise which either resolves to true or false or is rejected with a DOMException identifying the reason for the failure.

        partial interface Navigator {
          Promise<boolean> trackingExceptionExists (
            TrackingExData properties
          );
        };
        

Navigator.trackingExceptionExists passes a TrackingExData object. A user agent MUST ignore unknown properties of the TrackingExData object (for future extensibility). The following OPTIONAL properties are defined:

site

The referring domain scope for which the exception applies:

• If site is undefined, null, or the empty string, the set of exceptions to be confirmed have a referring domain scope equal to the script domain.
• If site is defined and equal to "*", the set of exceptions to be confirmed is web-wide for the set of targets.
• Otherwise, the set of exceptions to be confirmed have a referring domain scope matching the string found in site, which is treated in the same way as the domain parameter to cookies [[!RFC6265]], allowing subdomains to be included with the prefix "*.".

targets

An array of target domains for which the exception applies:

• If targets is undefined or null, the user-granted exception to be confirmed is [site, *], meaning that the exception applies to all domains referenced by the site.
• If targets is an empty array, the user-granted exception to be confirmed is [site, script domain], meaning that the exception applies only to resources that share the same domain as the effective script origin.
• Otherwise, for each domain string in the targets array, a user-granted exception to be confirmed is the duplet [site, domain].

For each site-specific exception being confirmed, a user agent MUST reject the promise with a DOMException named "SecurityError" if the script would not be able to set a cookie on that duplet's referring domain scope following the cookie domain rules [[!RFC6265]].

For each web-wide exception being confirmed, a user agent MUST reject the promise with a DOMException named "SecurityError" if the script would not be able to set a cookie on that target domain following the cookie domain rules [[!RFC6265]].

Any processing failure, such as an incorrectly formatted parameter in the TrackingExData, will result in the returned promise being rejected with a DOMException named "SyntaxError".

A user agent MUST fulfill the promise with the value true if a current (non-expired) matching exception exists for all of the duplets identified above, or false if any of the identified duplets do not have a matching exception.

Because the database might be changed at any time (via other windows or additional user interfaces), a particular response to the API might only be accurate at the time the promise is fulfilled.

Definition

A tracking status value (TSV) is a single character response to the user's tracking preference with regard to data collected via the designated resource. For a site-wide tracking status resource, the designated resource is any resource on the same origin server. For a Tk response header field, the target resource of the corresponding request is the designated resource, and remains so for any subsequent request-specific tracking status resource referred to by the Tk field value.

The tracking status value is case sensitive, as defined formally by the following ABNF.

TSV    = %x21   ; "!" — under construction
       / %x3F   ; "?" — dynamic
       / %x47   ; "G" — gateway to multiple parties
       / %x4E   ; "N" — not tracking
       / %x54   ; "T" — tracking
       / %x43   ; "C" — tracking with consent
       / %x50   ; "P" — tracking only if consented
       / %x44   ; "D" — disregarding DNT
       / %x55   ; "U" — updated
       / TSV-extension

Under Construction (!)

A tracking status value of ! means that the origin server is currently testing its communication of tracking status. The ! value has been provided to ease testing and deployment on production systems during the initial periods of testing compliance and during adjustment periods due to future protocol changes or shifting regulatory constraints. Note that this value does not indicate that the user's preference will be ignored, nor that tracking will occur as a result of accessing the designated resource.

Dynamic (?)

A tracking status value of ? means the origin server needs more information to determine tracking status, usually because the designated resource dynamically adjusts behavior based on information in a request.

If ? is present in the site-wide tracking status, the origin server MUST send a Tk header field in all responses to requests on the designated resource. If ? is present in the Tk header field, more information will be provided in a request-specific tracking status resource referred to by the status-id. An origin server MUST NOT send ? as the tracking status value in the representation of a request-specific tracking status resource.

Gateway (G)

A tracking status value of G means the server is acting as a gateway to an exchange involving multiple parties. This might occur if a response to the designated resource involves an automated selection process, such as dynamic bidding, where the party that is selected determines how the request data will be treated with respect to an expressed tracking preference. Similar to the ? value, the G TSV indicates that the actual tracking status is dynamic and will be provided in the response message's Tk header field, presumably using information forwarded from the selected party.

This tracking status value is only valid as a site-wide status. A server MUST NOT send G as the tracking status value in a Tk header field or within the representation of a request-specific tracking status resource.

If G is present in the site-wide tracking status:

• the gateway MUST send a link within its site-wide tracking status representation to a privacy policy that explains what limitations are placed on parties that might receive data via that gateway;
• the gateway MUST forward any expressed tracking preference in the request to each party that receives data from that request;
• the gateway MUST have a contract in place with each of the parties to whom it provides request data such that only the selected party is allowed to retain tracking data from a request with an expressed tracking preference of DNT:1; and,
• the gateway MUST send a Tk header field in responses to requests on the designated resource and include within that field's value a status-id specific to the selected party, such that information about the selected party can be obtained via the request-specific tracking status resource (see ).

With respect to tracking performed by the gateway itself, the G response can be considered equivalent to the T (tracking) response defined below. The other information within the site-wide tracking status representation indicates how the gateway intends to comply with an expressed tracking preference, aside from the potential sharing of data implied by the gateway process.

Not Tracking (N)

A tracking status value of N means the origin server claims that data collected via the designated resource is not used for tracking and will not be combined with other data in a form that would enable tracking.

Tracking (T)

A tracking status value of T means the origin server might perform or enable tracking using data collected via the designated resource. Information provided in the tracking status representation might indicate whether such tracking is limited to a set of commonly accepted uses or adheres to one or more compliance regimes.

Consent (C)

A tracking status value of C means that the origin server believes it has received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, and that prior consent overrides the tracking preference expressed by this protocol. An origin server that sends the C tracking status value for a designated resource MUST provide a reference for controlling consent within the config property of its corresponding tracking status representation ().

Potential Consent (P)

A tracking status value of P means that the origin server does not know, in real-time, whether it has received prior consent for tracking this user, user agent, or device, but promises not to use or share any DNT:1 data until such consent has been determined, and further promises to delete or permanently de-identify within forty-eight hours any DNT:1 data received for which such consent has not been received.

Since this status value does not itself indicate whether a specific request is tracked, an origin server that sends a P tracking status value MUST provide a config property in the corresponding tracking status representation that links to a resource for obtaining consent status.

The P tracking status value is specifically meant to address audience survey systems for which determining consent at the time of a request is either impractical, due to legacy systems not being able to keep up with Web traffic, or potentially "gamed" by first party sites if they can determine which of their users have consented. The data cannot be used for the sake of personalization. If consent can be determined at the time of a request, the C tracking status is preferred.

Disregarding (D)

A tracking status value of D means that the origin server is unable or unwilling to respect a tracking preference received from the requesting user agent. An origin server that sends the D tracking status value MUST detail within the server's corresponding privacy policy the conditions under which a tracking preference might be disregarded.

For example, an origin server might disregard the DNT field received from specific user agents (or via specific network intermediaries) that are deemed to be non-conforming, might be collecting additional data from specific source network locations due to prior security incidents, or might be compelled to disregard certain DNT requests to comply with a local law, regulation, or order.

This specification is written with an assumption that the D tracking status value would only be used in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the server's decision to send the D signal needs re-examination, or this specification, or both.

Updated (U)

A tracking status value of U means that the request resulted in a potential change to the tracking status applicable to this user, user agent, or device. A user agent that relies on a cached tracking status SHOULD update the cache entry with the current status by making a new request on the applicable tracking status resource.

An origin server MUST NOT send U as a tracking status value anywhere other than a Tk header field that is in response to a state-changing request.

Extensions to the Tracking Status Value

Extensibility of the TSV set ensures that this protocol will continue to be usable as regional laws and regulatory environments evolve over time and compliance specifications are developed accordingly.

An origin server MAY send a TSV-extension character as a TSV if that extension has been defined by a future version of this specification or a compliance regime identified within the compliance property. Aside from storage or presentation of a server's response, a recipient MUST treat a TSV-extension value that it does not recognize as if the value was P (tracking only if consented).

TSV-extension = %x23-25  ; #$%
              / %x2A-3B  ; *+,-./0-9:;
              / %x40-42  ; @AB
              / %x45-46  ; EF
              / %x48-4D  ; HIJKLM
              / %x4F     ; O
              / %x51-53  ; QRS
              / %x56-5A  ; VWXYZ
              / %x5F     ; _
              / %x61-7A  ; a-z

Definition

The Tk response header field is a means for indicating the tracking status that applied to the corresponding request. An origin server is REQUIRED to send a Tk header field if its site-wide tracking status value is ? (dynamic) or G (gateway), or when an interactive change is made to the tracking status and indicated by U (updated).

Tk-field-name   =  "Tk"
Tk-field-value  =  TSV [ ";" status-id ]

The Tk field-value begins with a tracking status value (), optionally followed by a semicolon and a status-id that refers to a request-specific tracking status resource ().

For example, a Tk header field for a resource that claims not to be tracking would look like:

Tk: N

Referring to a Request-specific Tracking Status Resource

If an origin server has multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target resource, header fields, data, etc.), the origin server can provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The status-id portion of the Tk field-value indicates which specific tracking status resource applies to the current request. The status-id is case-sensitive.

status-id       =  1*id-char
id-char         =  ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"

For example, a response containing

Tk: T;fRx42

indicates that data collected via the target resource might be used for tracking and that an applicable tracking status representation can be obtained by performing a retrieval request on

/.well-known/dnt/fRx42

Note that the status-id is resolved relative to the origin server of the current request. A retrieval request targeting that URI can be redirected, if desired, to some other server. The status-id has been intentionally limited to a small set of characters to encourage use of short tokens instead of potentially long, human-readable strings.

If a Tk field-value has a tracking status value of ? (dynamic), the origin server MUST send a status-id in the field-value.

Indicating an Interactive Status Change

Interactive mechanisms might be used, beyond the scope of this specification, that have the effect of asking for and obtaining prior consent for tracking, or for modifying prior indications of consent. For example, the tracking status resource's status object defines a config property that can refer to such a mechanism. Although such out-of-band mechanisms are not defined by this specification, their presence might influence the tracking status object's response value.

When an origin server provides a mechanism via HTTP for establishing or modifying out-of-band tracking preferences, the origin server MUST indicate within the mechanism's response when a state-changing request has resulted in a change to the tracking status for that server. This indication of an interactive status change is accomplished by sending a Tk header field in the response with a tracking status value of U (updated).

Tk: U

Site-wide Tracking Status

A site-wide tracking status resource provides information about the potential tracking behavior of resources located at that origin server. A site-wide tracking status resource has the well-known identifier

/.well-known/dnt/

relative to the origin server's URI [[RFC5785]].

An origin server that receives a valid GET request targeting its site-wide tracking status resource MUST send either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation. Failure to provide access to such a representation implies that the origin server does not implement this protocol. The representation can be cached, as described in .

See for examples of how tracking status resources can be used to discover support for this protocol.

Request-specific Tracking Status

If an origin server has multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target resource, header fields, data, etc.), the origin server can provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The Tk response header field () can include a status-id to indicate which specific tracking status resource applies to the current request.

A tracking status resource space is defined by the following URI Template [[RFC6570]]:

/.well-known/dnt/{+status-id}

where the value of status-id is a string of URI-safe characters provided by a Tk field-value in response to a prior request. For example, a prior response containing

Tk: ?;ahoy

refers to the specific tracking status resource

/.well-known/dnt/ahoy

Resources within the request-specific tracking status resource space are represented using the same format as a site-wide tracking status resource.

Status Checks are Not Tracked

When sending a request for the tracking status, a user agent SHOULD include any cookie data [[RFC6265]] (set prior to the request) that would be sent in a normal request to that origin server, since that data might be needed by the server to determine the current tracking status. For example, the cookie data might indicate a prior out-of-band decision by the user to opt-out or consent to tracking by that origin server.

An origin server MUST NOT retain tracking data regarding requests on the site-wide tracking status resource or within the tracking status resource space, regardless of the presence, absence, or value of a DNT header field, cookies, or any other information in the request. In addition, an origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in responses to those requests, including the responses to redirected tracking status requests, and MUST NOT send a response having content that initiates tracking beyond what was already present in the request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 header field received in such a response.

Caching

If the tracking status is applicable to all users, regardless of the received DNT field-value and other data received via the request, then the origin server SHOULD mark the response as cacheable [[!RFC7234]] and assign a time-to-live (expiration or max-use) that is sufficient to enable shared caching but not greater than the earliest point at which the service's tracking behavior might increase.

For example, if the tracking status response is set to expire in seven days, then the earliest point in time that the service's tracking behavior can be increased is seven days after the tracking status representation has been updated to reflect the new behavior, since old copies might persist in caches until the expiration is triggered. A service's tracking behavior can be reduced at any time, with or without a corresponding change to the tracking status resource.

If the tracking status is only applicable to users that have the same DNT field-value, the origin server MUST send a Vary header field that includes "DNT" in its field-value or a Cache-Control header field containing one of the following directives: "private", "no-cache", "no-store", or "max-age=0".

If the tracking status is only applicable to the specific user that requested it, then the origin server MUST send a Cache-Control header field containing one of the following directives: "private", "no-cache", or "no-store".

Regardless of the cache-control settings, it is expected that user agents will check the tracking status of a service only once per session (at most). A public Internet site that intends to change its tracking status to increase tracking behavior MUST update the tracking status resource in accordance with that planned behavior at least twenty-four hours prior to activating that new behavior on the service.

A user agent that adjusts behavior based on active verification of tracking status, relying on cached tracking status responses to do so, SHOULD check responses to its state-changing requests (e.g., POST, PUT, DELETE, etc.) for a Tk header field with the U tracking status value, as described in .

Status Object

A tracking status representation consists of a single status object containing properties that describe the tracking status applicable to the designated resource. Most of the properties are optional and can be extended over time, as illustrated by the following Orderly schema [[Orderly]]:

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": ["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": "http://example.com/decoder-ring"
}

Tracking Property

A status object MUST have a property named tracking with a string value containing the tracking status value () applicable to the designated resource.

For example, the following demonstrates a minimal tracking status representation that is applicable to any resource that does not perform tracking.

{"tracking": "N"}

Compliance Property

An origin server MAY send a property named compliance with an array value containing a list of URI references that identify specific regimes to which the origin server claims to comply for the designated resource. Communicating such a claim of compliance is presumed to improve transparency, which might influence a user's decisions or configurations regarding allowed tracking.

If an origin server sends a TSV-extension or an extension property in the status object that is not defined by successors of this specification, the origin server MUST send a compliance property that contains a reference to the definitive specification of that extension. If more than one reference in the compliance array defines the same extension value, the origin server SHOULD list the array of references in order by intended precedence.

Qualifiers Property

An origin server MAY send a property named qualifiers with a string value containing a sequence of case sensitive characters corresponding to explanations or limitations on the extent of tracking. Multiple qualifiers indicate that multiple explanations or forms of tracking might apply for the designated resource. The meaning of each qualifier is presumed to be defined by one or more of the regimes listed in compliance.

Controller Property

An origin server MAY send a property named controller with an array value containing a list of URI references indirectly identifying the party or set of parties that claims to be the responsible data controller for personal data collected via the designated resource. An origin server MUST send a controller property if the responsible data controller does not own the designated resource's domain name.

An origin server that does not send controller is implying that its domain owner is the sole data controller; information about the data controller ought to be found on the designated resource's site root page, or by way of a clearly indicated link from that page (i.e., an absent controller property is equivalent to: "controller":["/"]).

If the designated resource has joint data controllers (i.e., multiple parties have independent control over the collected data), the origin server MUST send a controller property that contains a reference for each data controller.

Each URI reference provided in controller ought to refer to a resource that, if a retrieval action is performed on that URI, would provide the user with information regarding (at a minimum) the identity of the corresponding party and its data collection practices.

Same-party Property

Since a user's experience on a given site might be composed of resources that are assembled from multiple domains, it might be useful for a site to distinguish those domains that are subject to their own control (i.e., share the same data controller as the referring site). An origin server MAY send a property named same-party with an array value containing a list of domain names that the origin server claims are the same party, to the extent they are referenced by the designated resource, if all data collected via those references share the same data controller as the designated resource.

A user agent might use the same-party array, when provided, to inform or enable different behavior for references that are claimed to be same-party versus those for which no claim is made. For example, a user agent might choose to exclude, or perform additional pre-flight verification of, requests to other domains that have not been claimed as same-party by the referring site.

Audit Property

An origin server MAY send a property named audit with an array value containing a list of URI references to external audits of the designated resource's privacy policy and tracking behavior. Preferably, the audit references are to resources that describe the auditor and the results of that audit; however, if such a resource is not available, a reference to the auditor is sufficient.

Policy Property

An origin server MAY send a property named policy with a string value containing a URI reference to a human-readable document that describes the relevant privacy policy for the designated resource. This document can inform users about data that might be collected when the designated resource is accessed and how collection, use, or sharing of such data might differ based on receipt of an expressed tracking preference (DNT:1 or DNT:0).

An origin server MUST send a policy property if that server is the effective script origin of a script that calls the JavaScript API for storing a user-granted exception, as described in .

The content of such a policy document is beyond the scope of this protocol and only supplemental to what is described in the machine-readable tracking status representation. If no policy property is provided, this information might be obtained via the links provided in controller.

If the policy associated with a designated resource happens to be defined as a common standard that is applicable to multiple sites, or includes such a standard by reference, that standard ought to be referenced by a URI within the machine-readable compliance property.

Config Property

An origin server MAY send a property named config with a string value containing a URI reference to a resource for giving the user control over personal data collected via the designated resource (and possibly other resources). If the tracking status value indicates prior consent (C), the origin server MUST send a config property referencing a resource that describes how such consent is established and how to revoke that consent.

A config resource might include the ability to review past data collected, delete some or all of the data, provide additional data (if desired), or opt-in, opt-out, or otherwise modify an out-of-band consent status regarding data collection. The design of such a resource, the extent to which it can provide access to that data, and how one might implement an out-of-band consent mechanism are beyond the scope of this protocol.

If no config property is provided, this information might be obtained via the links provided in controller or policy.

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 the different purposes for tracking implemented by this origin server.

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

Extensions to the Status Object

Extensibility of the status object ensures that this protocol will continue to be usable as regional laws and regulatory environments evolve over time and compliance specifications are developed accordingly.

An origin server MAY send additional properties in the status object if those extensions have been defined by a future version of this specification or a compliance regime identified within the compliance property. Aside from storage or presentation of a server's response, a recipient MUST ignore extension properties that it does not recognize.