Tracking Preference Expression (DNT)

doNotTrack of type DOMString , readonly

When a tracking preference is enabled , the doNotTrack attribute must for each top-level page MUST have a the same string value that is the same as the would be sent in a DNT-field-value defined in ( section 4.2 DNT Header Field for HTTP Requests . If ) to an origin server that does not have any corresponding user-granted exceptions. When a tracking preference is not enabled , the doNotTrack attribute for each top-level page MUST have a value is of null .

5.4.1 Definition

The Tk response header field is hereby defined as an OPTIONAL means for indicating the tracking status that applied to notify the user when something corresponding request and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the TSR tracking status.

Tk-field-name   =  "Tk"       ; case-insensitiveTk-field-value  =  tracking-v [tracking-q] [ ";" status-id ]

The Tk field-value begins with a tracking status value ( section 5.2 Tracking Status Value ), optionally followed by one or more tracking qualifiers ( section 5.3 Tracking Status Qualifier Values ), and then optionally a semicolon and a status-id that refers to a request-specific tracking status resource ( section 5.4.2 Referring 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

whereas a Tk header field for a resource that might perform tracking (though not necessarily for every request) and conforms to the third-party requirements of [ TRACKING-COMPLIANCE ], while claiming the audit exception, would look like:

Tk:
3a

5.4.2 Referring to a Request-specific Tracking Status Resource

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

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

For example, a response containing

Tk:
1;fRx42

indicates that the target resource claims to conform to the first-party requirements of [ TRACKING-COMPLIANCE ] and that an applicable tracking status representation can be obtained by performing a retrieval request on

/.well-known/dnt/fRx42

If a Tk field-value has a tracking status value of X (dynamic), then a status-id MUST be included in real time. the field-value.

5.4.3 Indicating an Interactive Status Change

We anticipate that 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 control member 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

5.1.1 5.5.1 Resource Definition Site-wide Tracking Status

An origin server must MUST provide a site-wide tracking status resource at the well-known identifier [ RFC5785 ]

/.well-known/dnt

(relative to the URI of that origin server) for obtaining information about the potential tracking behavior of services resources provided by that origin server. A tracking status resource may MAY be used for verification of DNT support, as described in section 5.1.3 5.7 Using the Tracking Status .

A valid retrieval request (e.g., a GET in [ HTTP11 ]) HTTP) on the well-known URI must MUST result in 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. A user agent may MAY consider failure to provide access to such a representation equivalent to the origin server not implementing this protocol. The representation might MAY be cached, as described in section 5.1.4 Tracking Status 5.5.5 Caching .

5.5.2 Request-specific Tracking Status

If an origin server contains multiple services that are controlled by distinct parties or has multiple, request-specific tracking policies, such that the tracking status might have differing behavior or policies regarding tracking, then it may differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY also provide a space an additional subtree of well-known resources for obtaining information about the potential tracking behavior of corresponding to each specific service. This parallel tree of resources is called the those distinct tracking statuses. The Tk response header field ( section 5.4 Tk Header Field for HTTP Responses ) can include a status-id to indicate which specific tracking status resource space . applies to the current request.

The tracking status resource space is defined by the following URI Template [ URI-TEMPLATE ]:

/.well-known/dnt{+pathinfo}

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

where the value of pathinfo status-id is equal to the path component [ RFC3986 ] a string of URI-safe characters provided by a given reference Tk field-value in response to that origin server, excluding those references already within the above resource space. a prior request. For example, a reference to prior response containing

Tk:
1;ahoy

may have a corresponding refers to the specific tracking status resource identified by

http://example.com/.well-known/dnt/over/here

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

5.1.2 5.5.3 Tracking Status Representation

The representation of a tracking status resource shall be provided in the "application/json" format [ RFC4627 ] and must MUST conform to the ABNF for status-object (except that the members within each member-list MAY be provided in section 5.1.5 Tracking Status ABNF . any order).

The following is an example tracking status representation that illustrates all of the fields defined by this specification, most of which are optional.

{
  "tracking": "1",
  "same-party": [

    "example.com",
    "example_vids.net",
    "example_stats.com"
  ],
  "partners": [
    "api.example-third-party.com"

  "third-party": [
    "api.example.net"
  ],
  "audit": [
    "http://auditor.example.org/727073"

  ],
  "policy": "/tracking.html",
  "edit": "http://example-third-party.com/your/data",
  "options": "http://example-third-party.com/your/consent"

  "control": "http://example.com/your/data"

}

A tracking status representation consists of a single status-object containing members that describe the tracking status applicable to this user agent's request. If the status-object has an optional path member, then this object describes the tracking status for the entire space of resources that share the same path prefix as the value of path . The user agent must interpret the path value relative to the originally referenced resource, not the resource where it obtained the tracking status representation. For the site-wide tracking status resource, the presence of a path member with a value of "/" indicates that this status-object applies for the entire origin server of the originally referenced designated resource. If the originally referenced resource's path component does not share the same prefix as the value of path , or if the path member is absent, then the tracking status for the referenced resource may be obtained via a request on the corresponding tracking status resource space.

status-object = begin-object member-list end-object
member-list   = tracking         ns tracking-v [tracking-q]
                [ vs same-party  ns same-party-v  ]
                [ vs third-party ns third-party-v ]
                [ vs audit       ns audit-v       ]
                [ vs policy      ns policy-v      ]
                [ vs control     ns control-v     ]
                *( vs extension )

A status-object must MUST have a member named tracking with a boolean value. A value of false indicates that the corresponding resources do not perform contains a single character tracking as it is defined by [ TRACKING-COMPLIANCE ]. A status value of true ( section 5.2 Tracking Status Value indicates that the corresponding resource performs tracking and claims to conform to all ), optionally followed by one or more tracking compliance requirements applicable to this site. qualifiers ( section 5.3 Tracking Status Qualifier Values ) .

tracking      = %x22 "tracking" %x22

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

{"tracking":
"N"}

An optional OPTIONAL member named same-site same-party may MAY be provided with an array value containing a list of domain names that the origin server claims are the same site, party, to the extent they are referenced on this site, by the designated resource, since all data collected via those references share the same data controller.

same-party    = %x22 "same-party" %x22
same-party-v  = array-of-strings

An optional OPTIONAL member named partners third-party may MAY be provided with an array value containing a list of domain names for third-party services that might track the user as a result of be invoked while using this site and which the designated resource but do not have share the same data controller as the designated resource.

third-party   = %x22 "third-party" %x22third-party-v = array-of-strings

An OPTIONAL member named audit MAY be provided with an array value containing a list of URI references to external audits of the designated resource's tracking policy and tracking behavior in compliance with this site. protocol. 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.

audit         = %x22 "audit" %x22
audit-v       = array-of-strings

An optional OPTIONAL member named policy may MAY be provided with a string value containing a URI-reference to a human-readable document that describes the tracking policy for this site. the designated resource. The content of such a policy document is beyond the scope of this protocol and only supplemental to what is described by this machine-readable tracking status representation.

policy        = %x22 "policy" %x22
policy-v      = string       ; URI-reference

If the tracking status value is 1 and the designated resource is being operated by an outsourced service provider on behalf of a first party, the origin server MUST identify the responsible first party via the domain of the policy URI, if present, or by the domain owner of the origin server. If no policy URI is provided and the origin server domain is owned by the service provider, then the service provider is the first party.

An optional OPTIONAL member named edit control may MAY be provided with a string value containing a URI-reference to a resource intended to allow a tracked for giving the user agent to review or delete control over personal data collected by this site, if any such data remains associated with this user agent. The design of such a resource and the extent to which it can provide access to that data is beyond the scope of this protocol. An optional member named designated resource (and possibly other resources); a options control may member SHOULD be provided with a string if the tracking status value containing a URI-reference to indicates prior consent ( C ). Such a control resource intended to allow a user agent 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 their an out-of-band consent status regarding data collection by this site. collection. The design of such a resource resource, the extent to which it can provide access to that data, and how it one might implement an out-of-band consent mechanism is beyond the scope of this protocol.

control       = %x22 "control" %x22
control-v     = string       ; URI-reference

Additional extension members may MAY be provided in the status-object to support future enhancements to this protocol. A user agent should SHOULD ignore extension members that it does not recognize.

extension     = object
array-of-strings = begin-array
                   [ string *( vs string ) ]
                   end-array
ns            = <name-separator  (:), as defined in [[!RFC4627]]>vs            = <value-separator (,), as defined in [[!RFC4627]]>begin-array   = <begin-array     ([), as defined in [[!RFC4627]]>end-array     = <end-array       (]), as defined in [[!RFC4627]]>begin-object  = <begin-object    ({), as defined in [[!RFC4627]]>end-object    = <end-object      (}), as defined in [[!RFC4627]]>object        = <object, as defined in [[!RFC4627]]>string        = <string, as defined in [[!RFC4627]]>true          = <true,   as defined in [[!RFC4627]]>false         = <false,  as defined in [[!RFC4627]]>null          = <null,   as defined in [[!RFC4627]]>

Note that the tracking status resource space applies equally to both first-party and third-party services. An example of a third-party tracking status is { "tracking": true, "received": "1", "response": "n",

{
  "tracking": "3",

  "policy": "/privacy.html",
  "edit": "/your/data",
  "options": "/your/consent"

  "control": "/your/data",

}

5.1.3 5.5.4 Using the Tracking Status Checks are Not Tracked

A key advantage of providing the tracking status at When sending a resource separate from the site's normal services is that the status can be accessed and reviewed prior to making use of those services and prior to making requests on third-party resources referenced by those services. In addition, request for the presence (or absence) of a site-wide tracking status representation is a means for testing deployment of this standard and verifying that status, a site's claims regarding tracking are consistent with the site's observed behavior over time. A user agent may SHOULD check include any cookie data [ COOKIES ] (set prior to the tracking status for a given resource URI by making request) that would be sent in a retrieval normal request for the well-known address /.well-known/dnt relative to that URI. If the response is an error, then the service does not implement this standard. If the response is a redirect, then follow the redirect to obtain origin server, since that data might be needed by the tracking status (up to some reasonable maximum of redirects server to avoid misconfigured infinite request loops). If the response is successful, obtain the tracking status representation from the message payload, if possible, or consider it an error. Once determine the current tracking status representation is obtained, parse the representation as JSON to extract status. For example, the Javascript status-object . If parsing results in cookie data might indicate a syntax error, prior out-of-band decision by the user agent should consider the site to be non-conformant with this protocol. If the status-object does not have a member named path opt-out or if the value of path is not "/" and not a prefix of the path component for the URI being checked, then find the service-specific consent to tracking status resource by taking the template /.well-known/dnt{+pathinfo} and replacing {+pathinfo} with the path component of the URI being checked. Perform a retrieval request that origin server.

All requests on the service-specific tracking status resource and process the result as described above to obtain the specific tracking status. The status-object is supposed to have a member named tracking with a boolean value. If space, including the value is false , then no site-wide tracking is performed for the URI being checked. If the value is true , then examine the member named received to verify that the DNT header field sent by the user agent has been correctly received by the server. If the received value is incorrect, there may status resource, MUST NOT be an intermediary interfering with transmission tracked, irrespective of the presence, value, or absence of a DNT request header field. If the received value is correct, then examine field, cookies, or any other information in the member named response request. In addition, all responses to see what the origin server has claimed regarding those requests, including the responses to redirected tracking status for this user agent in light of the received DNT-field-value . If the first character of the response value is "n", then the origin server claims requests, MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have content that it will not track initiates tracking beyond what was already present in the request. A user agent for requests on the URI being checked, and for any URIs with a path prefix matching the path member's value, for at least the next 24 hours SHOULD ignore, or until the Cache-Control information indicates that this response expires, treat as described below. If the first character of the response value is "t", then the origin server claims that it might track the user agent for requests on the URI being checked, and for an error, any URIs with a path prefix matching the path member's value, for at least the next 24 hours or until the Cache-Control information indicates that this response expires. The remaining characters of the response value might indicate reasons for the above choices Set-Cookie or limitations that the origin server will place on its tracking. The others members of the status-object may be used to help the user agent differentiate between Set-Cookie2 header field received in such a site's first-party and third-party services, to provide links to additional human-readable information related to the tracking policy, and to provide links for control over past data collected or over some consent mechanism outside the scope of this protocol. response.

5.1.4 5.5.5 Tracking Status Caching

If the tracking status is applicable to all users, regardless of the received DNT-field-value or other data received via the request, then the response should SHOULD be marked as cacheable and assigned 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 policy 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 all users that have the same DNT-field-value , then either the response must MUST include a Cache-Control header field either be marked with one of the directives "no-cache", "no-store", "must-revalidate", or "max-age=0", or the response must include a Vary header field that includes "DNT" in its field-value. field-value or marked as not reusable by a shared cache without revalidation with 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 response must MUST include a Cache-Control header field with containing one of the directives following directives: "private", "no-cache", "no-store", "must-revalidate", or "max-age=0". "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 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.

The representation A user agent that adjusts behavior based on active verification of a site's machine-readable tracking status, relying on cached tracking status must responses to do so, SHOULD conform check responses to the following ABNF its state-changing requests (e.g., POST, PUT, DELETE, etc.) for status-object , except that a Tk header field with the members within each member-list may be provided U tracking status value, as described in any order. section 5.4.3 Indicating an Interactive Status Change .

]. 5.7.1 Discovering Deployment

Tk: s ( service-provider ) indicates that: this party complies with [ TRACKING-COMPLIANCE ], this resource The presence of a site-wide tracking status representation is intended to be used in a claim that the context of third party acting as an outsourced service provider conforms to this protocol for a first party, and this party will process given user agent. Hence, deployment of this request according to the exemption protocol for a third party acting as an outsourced given service provider for can be discovered by making a first party, as described in [ retrieval request on the site-wide tracking resource TRACKING-COMPLIANCE /.well-known/dnt ]. relative to the service URI.

The opt-in-flag indicates that If the server believes that response is an error, then the user has affirmatively consented to allow service does not implement this party additional permission to track them. Unless standard. If the opt-in-flag response is included, a redirect, then follow the server asserts that will act in responding redirect to this request as if obtain the user has not affirmatively consented tracking status (up to allow this party additional permission some reasonable maximum of redirects to track them. The reason-code can be used when requesting more information (see below). 5.2.4 More Information avoid misconfigured infinite request loops). If a reason code is specified in the response, the well-known resource defined here must exist; if an opt-in-flag response is included, the wel--known resource defined here should exist; otherwise it may exist. The user can understand and manage their opt-in by visiting the well-known URI /.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code} relative to the request-target. The information at this URI provides additional information about this party's privacy practices and practices, particularly concerning the opt-in-flag . The above well-known URI has not yet been reconciled with the similar but distinct definition for successful, obtain the tracking status resource. We anticipate that one or representation from the other will be adopted, message payload, if possible, or the two proposals will be merged. consider it an error.

5.2.5 5.7.2 Implementation and Usage Considerations Preflight Checks

Implementers should use caution when allowing caching of resources on which an opt-in flag is included. If caching is not carefully managed, there is a risk of sending a response intended for opted-in users to users who haven't opted in. Implementers should carefully choose the cache properties A key advantage of providing the items tracking status at a resource separate from the well-known URI. The content at these locations must be correct for site's normal services is that the entire cache duration, otherwise users who load stale cached copies status can be accessed and reviewed prior to making use of these those services and prior to making requests on third-party resources may be misled. referenced by those services.

Any party can use A user agent MAY check the not-tracking response: this response just indicates a behavior. If tracking status for a designated resource by first party complies with the third-party definition, they are free to send this response. However, the first-party and service provider responses indicate both making a behavior retrieval request for the site-wide tracking status representation, as described above, and an intention about that party's status. It would be deceptive to send then parsing the first-party header on a resource which is only ever embedded representation as a third party. The no-dnt response should not be used on requests which are processed in accordance with [ TRACKING-COMPLIANCE ]. An entity which implements DNT should not use this response. When embedding content from other sites, consider how that site expects their content to be used. If you embed/link JSON to an object on another site, it's possible that extract the resource will send a first-party response even though it Javascript status-object . If retrieval is now unsuccessful or parsing results in a third-party context because syntax error, the user agent SHOULD consider the designer of that site never intended that object to be embedded. If a resource always sends a third-party response, there is no risk of non-conformant with this inconsistent response. Only the first-party outsourcer of service-provider objects should ever embed them. protocol.

The site status-object is supposed to have a third or first party, in compliance with member named tracking containing the definitions tracking status value. The meaning of a 3rd party that each tracking status value is not tracking. defined in section 5.2 Tracking Status Value .

The site If the tracking status value is a third party, N , then the origin server claims that believes it has an explicit opt-in from no tracking is performed for the user; more information can be found at: /.well-known/dnt?status=1&opt-in=1&r=agreed 5.3 Status Code designated resource for Tracking Required An HTTP error at least the next 24 hours or until the Cache-Control information indicates that this response expires.

If the tracking status code value is not N , then the origin server claims that it might be useful track the user agent for indicating that requests on the site refuses service unless URI being checked for at least the user either logs into a subscription account next 24 hours or agrees to an exception to DNT for until the Cache-Control information indicates that this site and its contracted third-party sites. response expires.