| Jul | AUG | Sep |
| 15 | ||
| 2020 | 2021 | 2022 |
COLLECTED BY
Collection: github.com
DNT request header field as an
HTTP mechanism for expressing a user's preference regarding tracking,
an HTML DOM property to make that expression readable by scripts, and
APIs that allow scripts to register exceptions granted by
the user. It also defines mechanisms for sites to communicate whether
and how they honor a received preference, including
well-known resources for retrieving preflight tracking status,
a media type for representing tracking status information, and the
Tkresponse header field for confirming tracking status.
DNT request header field
is defined for communicating the user's tracking preference for the
target resource. A well-known URI for a
tracking status resource and the
Tkresponse header field are defined for communicating the
server's tracking behavior. In addition, JavaScript APIs are defined for
enabling scripts to determine DNT status and register a user-granted
exception.
This specification does not define requirements on what a recipient
needs to do to comply with a user's expressed tracking preference,
except for the means by which such compliance is communicated. Instead,
the tracking status provides the ability to identify a set of compliance
regimes to which the server claims to comply, with the assumption being
that each regime defines its own requirements on compliant behavior.
For example, [TCS] is a work-in-progress that intends to define such a
compliance regime.
Do Not Trackpreference:
unsetorDNT:1.
A user agent MAY offer a third alternative choice: DNT:0.
If the user's choice is DNT:1orDNT:0, the
tracking preference is enabled; otherwise, the
tracking preference is not enabled.
A user agent MUST have a default tracking preference of
unset (not enabled) unless a specific tracking preference
is implied by the user's decision to use that agent. For example, use
of a general-purpose browser would not imply a tracking preference
when invoked normally as SuperFred, but might imply a preference if invoked as
SuperDoNotTrackor
UltraP
rivacyFred. Implementations of HTTP that are not under control of the user MUST NOT add, delete, or modify a tracking preference. Some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled. However, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment (aside from blanket limitations on what resources can or cannot be accessed through that network). An HTTP intermediary MUST NOT add, delete, or modify a tracking preference expression in a request forwarded through that intermediary unless the intermediary has been specifically installed or configured to do so by the user making the request. For example, an Internet Service Provider MUST NOT inject
DNT:1 on behalf
of all users who have not expressed a preference.
User agents often include user-installable extensions, also
known as add-onsorplug-ins, that are
capable of modifying configurations and making network requests. From
the user's perspective, these extensions are considered part of the
user agent and ought to respect the user's configuration of a tracking
preference. The user agent as a whole is responsible for ensuring
conformance with this protocol, to the extent possible, which means
the user agent core and each extension are jointly responsible for
conformance. However, there is no single standard for extension
interfaces. A user agent that permits such extensions SHOULD provide
an appropriate mechanism for extensions to determine the user's
tracking preference.
A user agent extension MUST NOT alter the tracking preference
expression or its associated configuration unless the act of
installing and enabling that extension is an explicit choice by the
user for that tracking preference, or the extension itself complies
with all of the requirements this protocol places on a user agent.
Likewise, software outside of the user agent might filter network
traffic or cause a user agent's configuration to be changed.
Software that alters a user agent configuration MUST adhere to the
above requirements on a user agent extension. Software that filters
network traffic MUST adhere to the above requirements on an HTTP
intermediary.
Aside from the above requirements, we do not specify how the tracking
preference choices are offered to the user or how the preference is
enabled: each implementation is responsible for determining the user
experience by which a tracking preference is enabled.
For example, a user might select a check-box in their user agent's
configuration, install an extension that is specifically
designed to add a tracking preference expression,
or make a choice for privacy that then implicitly includes a
tracking preference (e.g., Privacy settings: high). A user agent might ask the user for their preference during startup, perhaps on first use or after an update adds the tracking protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.
| DNT | meaning |
|---|---|
| 1 | This user prefers not to be tracked on this request. |
| 0 | This user prefers to allow tracking on this request. |
DNT header field is a mechanism for expressing the
user's tracking preference in an HTTP request ([RFC7230]).
At most one DNT header field can be present in a valid request.
DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extensionA user agent MUST NOT generate a
DNT header field if the
user's tracking preference is not enabled.
A user agent MUST generate a DNT header field with a
field-value that begins with the numeric character "1" if the user's
tracking preference is enabled, their preference is for
DNT:1, and no exception has been granted for the
target resource (see section 6. User-Granted Exceptions).
A user agent MUST generate a DNT header field with a
field-value that begins with the numeric character "0" if the user's
tracking preference is enabled and their preference is for
DNT:0, or if an exception has been granted for
the target resource.
A proxy MUST NOT generate a DNT header field unless it has
been specifically installed or configured to do so by the user
making the request and adheres to the above requirements as if it
were a user agent.
Example 1
GET /something/here HTTP/1.1
Host: example.com
DNT: 1
DNT field-value, after the initial character,
is reserved for future extensions. DNT extensions can only be
transmitted when a tracking preference is enabled.
The extension syntax is restricted to visible ASCII characters that
can be parsed as a single word in HTTP and safely embedded in a
JSON string without further encoding
(section 7.5 Tracking Status Representation).
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash
For example, additional characters might indicate modifiers to the
main preference expressed by the first digit, such that the main
preference will be understood if the recipient does not understand
the extension. Hence, a field-value of "1xyz" can be thought of
as do not track, but if y
ou understand the refinements de
fined by x, y, or z, then adjust
my preferences according to tho
se refinements.User agents that do not implement DNT extensions MUST NOT send DNT-extension characters in the
DNT field-value.
Servers that do not implement DNT extensions SHOULD ignore
anything beyond the first character.
Note
This DNT-extension feature is speculative because no known
extensions have been defined; implementers that do not read this
specification are likely to assume that DNT only has the
fixed values of "0" or "1". Furthermore, the potential benefits
of this mechanism are unclear given that extension information
could be supplied using separate request header fields.
Inappropriate extensions to the "1" value might cause the user's
requests to be more easily
fingerprinted.
Navigator.doNotTrack property enables
a client-side script with read access to the
Navigator object
[HTML51] to determine what DNT header field value would be
sent to the effective script origin, taking into account the
user's general preference (if any) and user-granted exceptions
applicable to the target domain when referenced by the
active document's top-level browsing context.
null if no DNT header field would be
sent (e.g., because a tracking preference is not enabled
and no user-granted exception is applicable);
otherwise, the value is a string beginning with "0" or "1",
possibly followed by DNT-extension characters.
Specifically, the value of Navigator.doNotTrack for a given
script is either null or the string value that would be
sent in a DNT field-value
(section 5.2 DNT Header Field for HTTP Requests)
in a request to a target resource at the
effective script origin (the current document.domain of
the script's responsible document) when that request is due to
an embedded reference from this site (the document.domain of
the top-level browsing context's active document).
Ideally, the value of Navigator.doNotTrack ought to reflect
the current set of user-granted exceptions in effect when the
attribute is read. In practice, however, the value might only reflect
the value that was in effect when the script was initiated.
opt into tracking for behavioral advertising or similar purposes when they arrive with the Do Not Track setting enabled. However, granting an exception in one context (e.g., while browsing a news site) does not imply that exception is applicable to other contexts (e.g., browsing an unrelated medical site). Furthermore, users might wish to view or edit all the exceptions they've granted in a single, consistent user interface, rather than managing preferences in a different way on every content provider or tracker's privacy page. Auser-granted exception is the record of a decision by the user to grant consent for tracking (
DNT:0) on future
requests from a given site to a set of target domains.
Both site and target are scoped by domain, similar to the existing
domain scope of cookies
(Section 5.3.1
of [HTML51]), to avoid prompting the user for every subdomain of a
site and every target resource that might be referenced.
A client-side database can be used for persistent storage of
user-granted exceptions, such that permission to send DNT:0
is obtained by a site and stored via a JavaScript API. However, we
only define the API (below); the choice of storage mechanism is left
to each implementation. In comparison to the use of cookies to manage
consent, an exception database and APIs provide more transparency and
better user control, while also providing better persistence of those
exceptions for sites.
Navigator.storeTrackingException API using
parameters consistent with the consent granted by the user.
A site MUST ensure that a call to store an exception reflects the
user's intention to grant an exception at the time of that call. It
is the sole responsibility of the site to determine that a call to
record an exception reflects the user's informed consent at the
time of that call.
Third party target domains that might wish to receive a user-granted
exception often do not have the ability to invoke an interactive
JavaScript presence on a page (for example, those that provide only
images or "tracking pixels"). They cannot request an exception under
these circumstances, either because a script is needed to make the
API call or it requires interaction to ensure the user is informed
and to receive an indication of their consent. In general, this
process of informing, getting consent, and calling the API is not
expected within page elements where such trackers are invoked.
A first party site's page (the top-level browsing context)
might be used to obtain consent for multiple
parties;
e.g., using multiple iframe elements containing scripts that can
convey information about each party's policies and obtain specific
consent for each party. In this case, the effective script origin
might be different from the site for which consent is being granted.
Alternatively, a third party might encourage the user to visit their
own site directly in order to engage in a consent dialog and make use
of the API to store a web-wide exception.
A site can request an exception be stored even when the user's
general preference is not enabled. This permits the sending of
DNT only for target resources for which an expressed
preference is desired. Stored exceptions could affect which
preference is transmitted if a user later chooses to configure a
general tracking preference.
A user agent might not store the exception immediately, possibly
because it is allowing the user to confirm. Even though the site has
acquired the user's informed consent before calling the store API,
it is possible that the user will change their mind, allow the
storing of an exception to proceed but later remove it, or perhaps
deny the storage by prior configuration.
Nonetheless, at the time of a call, the site has acquired the
user's consent and can proceed on that basis whether or not the
user agent has stored an exception.
Navigator.trackingExceptionExists
API to enquire whether a set of exceptions has been granted and stands
in the user agent. If the promise resolves to false (indicating the
exception set has expired, been deleted, or has not yet been stored),
the user can be asked again for consent.
A user agent is expected to query the exceptions database at the
time of a request in order to determine what value (if any) to send
as the user's tracking preference.
●While the user is browsing a given site,
if the duplet [site domain, target domain] matches
any duplet in the database, then a DNT:0 preference is sent,
otherwise the user’s general preference is sent (if any).
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y.
A pair of values A and X match if and only if one of the following
is true:
●either A or X is "*";
●A and X are the same string;
●A has the form '*.domain' and X is 'domain' or is of the form
'string.domain', where 'string' is any sequence of characters.
For example, a user might grant an exception for metrics.example.net
to track their activity on news.example.com and weather.example.com,
but not on medical.example.org. If the document at
http://news.example.com/news/story/2098373.html
has embedded references to
http://metrics.example.net/1x1.gif and
http://weather.example.com/widget.js, the
site domain for those references is
news.example.com and the target domains are
metrics.example.net and
weather.example.com, respectively.
A user agent MAY choose to disregard a user-granted exception when
the target resource does not have a corresponding tracking
status resource with a valid tracking status representation, since
that would imply the target resource does not conform to this
specification.
Navigator.removeTrackingException API
can be promise-called by a script to remove all exceptions applicable
to that site.
A site MAY monitor for changes to its user-granted exceptions.
If a user revokes consent by deleting an exception, the site MUST
respect that revocation, though it MAY ask again for a new
exception. In other words, a site MUST NOT resurrect a deleted
exception without first interacting with and receiving new
consent from the user.
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.
dictionaryTrackingExData{ DOMString?site; sequence<DOMString>?targets; DOMString?name; DOMString?explanation; DOMString?details; long?maxAge; }; dictionaryTrackingExResult{ booleanisSiteWide; };
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:
●Ifsite is
undefined, null, or the empty string, the exception's referring
domain scope defaults to the script domain.
●Ifsite 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:
●Iftargets
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.
●Iftargets
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, encoded as UTF-8 and appropriate for the natural language(s)
used to inform consent for the exception.
explanation
When defined and not null or an empty string,
explanation is a
user-readable short explanation of the granted exception,
encoded as UTF-8 and in the same natural language(s)
used to inform consent for the 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:
●IfmaxAge 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.
●IfmaxAge is not supplied, the user agent
MAY retain the stored grant indefinitely.
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 siteas"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.
Note
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.
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.
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:
●Ifsite 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.
●Ifsite 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:
●Ifsite is not
defined or not equal to "*", then
targets is ignored
(it is only used for removing web-wide exceptions).
●Iftargets 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).
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.
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:
●Ifsite is
undefined, null, or the empty string, the set of exceptions
to be confirmed have a referring domain scope equal to the
script domain.
●Ifsite 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:
●Iftargets
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.
●Iftargets
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.
Tkresponse 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
!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.
?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 Tkheader field in all
responses to requests on the designated resource.
If ?is present in the Tkheader 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.
Gmeans 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 GTSV
indicates that the actual tracking status is dynamic and will be
provided in the response message's Tkheader 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 Gas the
tracking status value in a Tkheader field or within the
representation of a request-specific tracking status resource.
IfGis 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 Tkheader 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
section 7.4.2 Request-specific Tracking Status).
With respect to tracking performed by the gateway itself, the
Gresponse 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.
Nmeans 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.
Tmeans 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.
Cmeans 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 Ctracking status
value for a designated resource MUST provide a reference
for controlling consent within the config
property of its corresponding tracking status representation
(section 7.5 Tracking Status Representation).
Pmeans 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
Ptracking status value MUST provide a
config property in the corresponding tracking
status representation that links to a resource for obtaining
consent status.
The Ptracking 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 Ctracking status is preferred.
Dmeans 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 Dtracking 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.
Note
This specification is written with an assumption that the
Dtracking 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.
Umeans 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 Uas a tracking status
value anywhere other than a Tkheader field that is in
response to a state-changing request.
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
Tkresponse header field is a means for indicating
the tracking status that applied to the corresponding request.
An origin server is REQUIRED to send a Tkheader
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 (section 7.2 Tracking Status Value), optionally followed by a semicolon and a
status-id
that refers to a request-specific tracking status resource
(section 7.3.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:
Example 2
Tk: N
status-id
portion of the Tkfield-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 Example 3
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/fRx42Note 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.
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
Tkheader field in the response with a tracking status
value of U(updated).
Example 4
Tk: U
/.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 section 7.4.4 Caching.
See section 8. Use Cases for
examples of how tracking status resources can be used to discover
support for this protocol.
Tkresponse header field
(section 7.3 Tk Header Field for HTTP Responses) can
include a status-id to indicate which specific
tracking status resource applies to the current request.
Atracking 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 Tkfield-value in response to a
prior request. For example, a prior response containing
Example 5
Tk: ?;ahoy
refers to the specific tracking status resource
/.well-known/dnt/ahoyResources within the request-specific tracking status resource space are represented using the same format as a site-wide tracking status resource.
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 Tkheader field
with the Utracking status value, as described in
section 7.3.3 Indicating an Interactive Status Change.
application/tracking-status+json media type.
This media type consists of a status object
serialized as JSON [RFC8259]. More information about the
application/tracking-status+json media type can be
found in section B. Registrations.
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
}*;
The following example representation demonstrates a status object
with all of the properties defined by this specification.
Example 6
{
"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"
}
tracking with a string value containing
the tracking status value
(section 7.2 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.
Example 7
{"tracking": "N"}
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 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 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 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 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 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:1orDNT: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
section 6.3 Granting an Exception.
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 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
controllerorpolicy.
compliance property.
Aside from storage or presentation of a server's response,
a recipient MUST ignore extension properties that it does
not recognize.
DNT:1,
does not have out-of-band consent for tracking this user, and
wishes to deny access to the requested resource until the user
provides some form of user-granted exception or consent for tracking,
then the origin server SHOULD send a 409 (Conflict) response with a
message payload that describes why the request has been refused and
how one might supply the required consent or exception to avoid this
conflict [RFC7231].
The 409 response ought to include a user authentication mechanism in
the header fields and/or message body if user login is one of the
ways through which access is granted.
/.well-known/dnt/tracking containing the tracking
status value. The meaning of each tracking status value is defined
in section 7.2 Tracking Status Value.
If the tracking status value is N, then the origin server
claims that no tracking is performed for the designated resource
for at least the next 24 hours or until the Cache-Control
information indicates that this response expires.
If the tracking status value is not N, then the origin
server claims that it might track the user agent for requests on
the URI being checked for at least the next 24 hours or until the
Cache-Control information indicates that this response expires.
DNT:0,
since this consent mechanism is intended to be more persistent than
cookies and could be used to convey a pseudonymous identifier as a
user-preferred alternative to allowing a cookie to be set.
Use of client-side storage is always a security concern. Although the
information being stored for each user-granted exception is
limited and cannot be directly accessed by scripts, storing too many
exceptions might exceed available storage or indicate an attempt to
exploit other vulnerabilities.
There are also security concerns regarding the ability of scripts to
store exceptions beyond the scope of their effective script origin.
See the note about API securityinsection 6.6.1 API to Store a Tracking Exception.
design for privacywould justify calling for
DNT:1 to be preconfigured as the default
for all user agents. However, that would violate the field's semantics,
make its presence in a request meaningless, and add eight extra bytes
to every HTTP request (with no effect).
The DNT signal alone does nothing to enhance a user's privacy.
It is only when recipients believe that the signal has been
deliberately and knowingly configured, and not defined as a default,
that they will consider it to be the user's preference.
Furthermore, when no signal is sent, recipients remain subject to
whatever regulatory, legal, or other regional requirements regarding
tracking exist in the absence of consent.
doNotTrack 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.
application/tracking-status+json is
used for tracking status representations
(section 7.5 Tracking Status Representation).
Type name:
application
Subtype name:
tracking-status+json
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
binary
Security considerations:
See JSON [RFC8259], Section 12.
Interoperability considerations:
N/A
Published specification:
Tracking Preference Expression (DNT),
section 7.5 Tracking Status Representation.
https://www.w3.org/TR/tracking-dnt/
Applications that use this media type:
N/A
Fragment identifier considerations:
N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
W3C Tracking Protection Working Group <public-tracking@w3.org>
Intended usage:
COMMON
Restrictions on usage:
N/A
Author(s):
Roy T. Fielding and David Singer
Change controller:
W3C