This specification defines the DNT request header field as an
HTTP mechanism for expressing the user's preference regarding tracking,
an HTML DOM property to make that expression readable by scripts, and
APIs that allow scripts to register site-specific exceptions granted by
the user. It also defines mechanisms for sites to communicate whether
and how they honor a received preference through use of the Tk
response header field and well-known resources that provide a
machine-readable tracking status.

This document is an editors' straw man reflecting a snapshot of live
discussions within the
Tracking
Protection Working Group. It does not yet capture all of our work
and does not constitute working group consensus.
Text in option boxes (highlighted with light blue background color)
present options that the group is currently considering, particularly
where consensus is known to be lacking, and should be read as a set of
proposals rather than as limitations on the potential outcome.
An
issue tracking system
is available for recording
raised,
open,
pending review,
closed, and
postponed
issues regarding this document.

The following feature is at risk and might be cut from the specification
during the CR period if there are no (correct) implementations:

Introduction

The World Wide Web consists of billions of resources interconnected
through the use of hypertext. Hypertext provides a simple, page-oriented
view of the information provided by those resources, which can be
traversed by selecting links, manipulating controls, and supplying data
via forms and search dialogs.

A Web page is often composed of many information sources beyond the
initial resource request, including embedded references to stylesheets,
inline images, javascript, and other elements that might be
automatically requested as part of the rendering or behavioral
processing defined for that page. The user's experience is seamless,
even if the page has been composed from the results of many network
interactions with multiple servers. From the user's perspective, they
are simply visiting and interacting with a single Web site: all of the
technical details and protocol mechanisms used to compose a page to
represent that site are hidden behind the scenes.

Web site owners often collect data regarding usage of their sites, for a
variety of purposes, including what led a user to visit the site
(referrals), how effective the user experience is within the
site (web analytics), and the nature of who is using the
site (audience segmentation).
In some cases, the data collected is used to dynamically adapt content
(personalization) or advertising presented to the user
(targeted advertising). Data collection often occurs through
insertion of embedded elements on each page, resulting in a stream of
data that connects a user's activity across multiple pages. A survey of
these techniques and their privacy implications can be found in
[[KnowPrivacy]].

Users need a mechanism to express their own preferences regarding
tracking that is both simple to configure and efficient when
implemented. However, merely expressing a preference does not imply that
all recipients will comply. In some cases, a server might be dependent
on some forms of tracking and unwilling or unable to turn that off.
In other cases, a server might perform only limited forms of tracking
that would be acceptable to most users. Therefore, servers need
mechanisms for communicating their own tracking behavior, requesting an
exception to a user's general preference, and storing such a
user-granted exception after the user has made an informed choice.

This specification extends Hypertext Transfer Protocol (HTTP) semantics
[[!RFC7231]] to communicate a user's tracking preference, if any, and an
origin server's tracking behavior. The 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
Tk response 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.

Activity

Tracking is the collection of data regarding a particular
user's activity across multiple distinct contexts and the retention,
use, or sharing of data derived from that activity outside the
context in which it occurred.
A context is a set of resources that are controlled by
the same party or jointly controlled by a set of parties.

A network interaction is a single HTTP request and its
corresponding response(s): zero or more interim (1xx) responses and
a single final (2xx-5xx) response.

A user action is a deliberate action by the user, via
configuration, invocation, or selection, to initiate a network
interaction. Selection of a link, submission of a form, and
reloading a page are examples of user actions.
User activity is any set of such user actions.

Participants

A user is a natural person who is making, or has made,
use of the Web.

A party is a natural person, a legal entity, or a set of
legal entities that share common owner(s), common controller(s), and
a group identity that is easily discoverable by a user. Common
branding or providing a list of affiliates that is available via a
link from a resource where a party describes DNT practices are
examples of ways to provide this discoverability.

With respect to a given user action, a first party
is a party with which the user intends to interact, via one or more
network interactions, as a result of making that action. Merely
hovering over, muting, pausing, or closing a given piece of content
does not constitute a user's intent to interact with another party.

In some cases, a resource on the Web will be jointly controlled by
two or more distinct parties. Each of those parties is considered a
first party if a user would reasonably expect to communicate with
all of them when accessing that resource. For example, prominent
co-branding on the resource might lead a user to expect that
multiple parties are responsible for the content or functionality.

For any data collected as a result of one or more network
interactions resulting from a user's action,
a third party is any party other than that user, a first
party for that user action, or a service provider acting on behalf
of either that user or that first party.

Access to Web resources often involves multiple parties that might
process the data received in a network interaction. For example,
domain name services, network access points, content distribution
networks, load balancing services, security filters, cloud
platforms, and software-as-a-service providers might be a party to a
given network interaction because they are contracted by either the
user or the resource owner to provide the mechanisms for
communication. Likewise, additional parties might be engaged after a
network interaction, such as when services or contractors are used
to perform specialized data analysis or records retention.

For the data received in a given network interaction, a
service provider is considered to be the same party as
its contractee if the service provider:

processes the data on behalf of the contractee;

ensures that the data is only retained, accessed, and used as
directed by the contractee;

has no independent right to use the data other than in a
permanently de-identified form (e.g., for monitoring
service integrity, load balancing, capacity planning, or
billing); and,

has a contract in place with the contractee which is consistent
with the above limitations.

Data

A party collects data received in a network interaction
if that data remains within the party’s control after the network
interaction is complete.

A party uses data if the party processes the data for any
purpose other than storage or merely forwarding it to another party.

A party shares data if it transfers or provides a copy of
that data to any other party.

Data is permanently de-identified when there exists a
high level of confidence that no human subject of the data can be
identified, directly or indirectly (e.g., via association with an
identifier, user agent, or device), by that data alone or in
combination with other retained or available information.

Preferences

A user-granted exception is a specific tracking
preference, overriding a user's general tracking preference, that
has been obtained and recorded using the mechanisms defined in
.

Notational Conventions

Requirements

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

Determining User Preference

The goal of this protocol is to allow a user to express their
personal preference regarding tracking to each server and
web application that they communicate with via HTTP, thereby allowing
recipients of that preference to adjust tracking behavior accordingly
or to reach a separate agreement with the user that satisfies all
parties.

Key to that notion of expression is that the signal sent MUST reflect
the user's preference, not the choice of some vendor, institution,
site, or network-imposed mechanism outside the user's control;
this applies equally to both the general preference and exceptions.
The basic principle is that a tracking preference expression is only
transmitted when it reflects a deliberate choice by the user. In the
absence of user choice, there is no tracking preference expressed.

A user agent MUST offer users a minimum of two alternative choices
for a Do Not Track preference: unset or
DNT:1.
A user agent MAY offer a third alternative choice: DNT:0.

If the user's choice is DNT:1 or DNT: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 SuperDoNotTrack or
UltraPrivacyFred.

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-ons or plug-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.

Expressing a Tracking Preference

Expression Format

When a user has enabled a tracking preference, that
preference needs to be expressed to all mechanisms that might
perform or initiate tracking.

A user agent MUST NOT send a tracking preference expression if
a tracking preference is not enabled. This means that no
expression is sent for each of the following cases:

the user agent does not implement this protocol;

the user has not yet made a choice for a specific preference;
or,

the user has chosen not to transmit a preference.

In the absence of regulatory, legal, or other requirements, servers
MAY interpret the lack of an expressed tracking preference as they
find most appropriate for the given user, particularly when
considered in light of the user's privacy expectations and cultural
circumstances. Likewise, servers might make use of other preference
information outside the scope of this protocol, such as
site-specific user preferences or third-party registration services,
to inform or adjust their behavior when no explicit preference is
expressed via this protocol.

DNT Header Field for HTTP Requests

The 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-extension

A 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
request target (see ).

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 request target.

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.

GET /something/here HTTP/1.1
Host: example.com
DNT: 1

DNT Extensions

The remainder of the 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
().

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 you understand the refinements defined
by x, y, or z, then adjust my preferences according to those
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.

The DNT-extension feature is considered at-risk.
Since no extensions have been defined, implementors that don't
read specifications 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.

JavaScript Property to Detect Preference

The doNotTrack property enables a client-side script
with read access to the Navigator object to determine what
DNT header field value would be sent in requests to the
document-origin, taking into account the user's general preference
(if any) and any user-granted exceptions applicable to that
origin server.

readonly attribute DOMString? doNotTrack

Returns the same string value that would be sent in a
DNT-field-value
() to a
target that is the document-origin of the
window, in the browser context of the current
top-level origin.
The value is null if no DNT header field would be
sent (e.g., because a tracking preference is not enabled);
otherwise, the value is a string beginning with "0" or "1",
possibly followed by DNT-extension characters.

Tracking Preference Expressed in Other Protocols

A user's tracking preference is intended to apply in general,
regardless of the protocols being used for Internet communication.
However, it is beyond the scope of this specification to define how
a user's tracking preference might be communicated via protocols
other than HTTP.

Communicating a Tracking Status

Overview

In addition to expressing the user's preference regarding tracking,
this protocol enables servers to communicate machine-readable claims
regarding their own tracking behavior. Since a personalized tracking
status on every response would disable caching, a combination of
response mechanisms are defined to allow the tracking status to be
communicated prior to making a trackable request and without making
every response dynamic.

Tracking Status Value

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.

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.

Tk Header Field for HTTP Responses

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 URI, 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.

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

Tracking Status Resource

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 target
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 URI, 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 or 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
.

Tracking Status Representation

For each tracking status resource, an origin server MUST provide a
valid representation using the
application/tracking-status+json media type.
This media type consists of a status object
serialized as JSON [[!RFC7159]]. More information about the
application/tracking-status+json media type can be
found 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]]:

Tracking Property

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, but does not have any
direct impact on this protocol.

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

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.

Extensions

An origin server MAY send additional properties in the
status object to support future enhancements
to this protocol. A recipient MUST ignore extension properties
that it does not recognize.

Status Code for Tracking Required

If an origin server receives a request with 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.

Using the Tracking Status

This section is for collecting use cases that describe questions a
user agent might have about tracking status and how the protocol
can be used to answer such questions. More cases are needed.

Discovering Deployment

Deployment of this protocol for a given service can
be discovered by making a retrieval request on the site-wide
tracking resource /.well-known/dnt/ relative
to the service 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 the tracking status (up to some reasonable
maximum of redirects 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.

Preflight Checks

A key advantage of providing the tracking status at 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.

A user agent MAY check the tracking status for a
designated resource by first making a retrieval request for
the site-wide tracking status representation, as described above,
and then parsing the representation as JSON to extract the
status object.
If the retrieval is unsuccessful or parsing results in a syntax
error, the user agent ought to consider the site to be
non-conformant with this protocol.

The status object is supposed to have a
property named tracking containing the tracking
status value. The meaning of each tracking status value is defined
in .

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.

User-Granted Exceptions

Overview

User-granted exceptions to Do Not Track, including site-specific
exceptions, are agreed between the site and the user, and stored by
the user agent. A resource ought to rely on the DNT header field it
receives to determine the user's preference for tracking with
respect to that particular request. An API is provided so that sites
can request and check the status of exceptions for tracking.

We envisage that the exceptions might also be usable as
a consent mechanism.

Motivating Principles and Use Cases

The following principles guide the design of user-agent-managed
exceptions.

Content providers might wish to prompt visitors to their
properties to opt back in to tracking for behavioral
advertising or similar purposes when they arrive with the Do Not
Track setting enabled.

Privacy-conscious 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.

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

Tracking providers ought to be able to avoid second-guessing a
user's expressed tracking preference.

The solution need not require cross-domain communication
between a first-party publisher and its third parties.

When asking for a site-specific exception, the top-level origin
making the request might make some implicit or explicit claims as
to the actions and behavior of its third parties; for this reason,
it might want to establish exceptions for only those for which it is
sure that those claims are true. (Consider a site that has some
trusted advertisers and analytics providers, along with some mashed-up
content from less-trusted sites). For this reason, there is support
both for explicitly named sites, as well as support for granting an
exception to all third-parties on a given site (site-wide exception,
using the conceptual wild-card "*").

There are some cases in which a user might desire a site to be allowed
to track them on any top-level origin. An API is provided so that
a site might obtain such a web-wide exception from the user.

Exception Model

User Interaction

The call to store an exception MUST reflect the user's intention
to grant an exception at the time of that call. This intention
MUST be determined by the site prior to each call to store an
exception, at the time of the call. (This allows a user to
change their mind and delete a stored exception, which might result
in the site explaining and asking for the exception again.)
It is the sole responsibility of the site making the call to
determine that a call to record an exception reflects the user's
informed consent at the time of that call.

A site MAY ask for an exception, and have it stored, even when the
user's general preference is not enabled. (This permits
recording a permission to allow tracking in jurisdictions where
such permission cannot be assumed – see
.)

The user agent MAY provide interfaces to the user:

To indicate that a call to store an exception has just been
made;

To allow the user to confirm a user-granted exception prior
to storage;

To indicate that one or more exceptions exist for the
current top-level origin;

To indicate that one or more exceptions exist for sites
incorporated into the current page;

To allow the user to see and possibly revoke stored
exceptions;

Other aspects of the exception mechanism, as desired.

There is no required user interface for the user agent;
a user agent MAY choose to provide no user interface regarding
user-granted exceptions.

If the user revokes the consent by deleting the exception, the
site MUST respect that revocation (though it MAY ask again for
the exception). The site MUST NOT use this exception mechanism if it
will deem consent to exist even after the exception has been
revoked.

Processing Model

This section describes the effect of the APIs in terms of a
logical processing model; this model describes the behavior, but
is not to be read as mandating any specific implementation.

This API considers exceptions which are double-keyed to two
domains: the site, and the
target. A user might — for instance —
want AnalytiCo to be allowed to track them on Example News, but
not on Example Medical. To simplify language used in this API
specification, we define three terms:

A top-level origin is the top-level
browsing context, as defined by [[!HTML5]];

A target site is the host subcomponent of the
authority part in an "http" or "https" URI, as defined by
[[!RFC7230]] and [[!RFC3986]]; and,

The document origin of a script is the
effective script origin, as defined by
[[!HTML5]].

For instance, if the document at
http://web.exnews.com/news/story/2098373.html
references the resources
http://exnews.analytico.net/1x1.gif and
http://widgets.exsocial.org/good-job-button.js,
the top-level origin is web.exnews.com;
exnews.analytico.net and
widgets.exsocial.org are both
targets.

The domains that enter into the behavior of the APIs include:

As described above, the document origin
active at the time of the call, and;

Domain names passed to the API.

Domains that enter into the decision over what DNT header field to
be sent in a given request include:

The top-level origin of the current browser
context;

The target of the request.

Note that these strict, machine-discoverable concepts might not
match the definitions of first and third party; in particular,
sites themselves need to determine when they are a first party in
relation to a given user action; the user agent does not change the
DNT header field based on the type of network interaction.

The calls cause the following steps to occur (subject to user
confirmation of the exception, if the user agent asks for it):

The user agent adds to its local database one or more site-pair
duplets [document-origin, target]; one or the other of these MAY
be a wild-card ("*");

While the user is browsing a given site (top-level origin),
and a DNT header field is to be sent to a target domain, if the
duplet [top-level origin, 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.

In addition, responses to the JavaScript API indicated should be
consistent with this user preference (see below).

User-agents MUST handle each API request as a 'unit', granting and
maintaining it in its entirety, or not at all. That means that a
user agent MUST NOT indicate to a site that a request for targets
{a, b, c} exists in the database, and later remove only one or two
of {a, b, c} from its logical database of remembered grants. This
assures sites that the set of sites they need for operational
integrity is treated as a unit. Each separate call to an API is a
separate unit.

It is left up to individual user agent implementations how to
determine and how and whether to store users' tracking
preferences.

When an explicit list of domains is provided through the API,
their names might mean little to the user. The user might, for
example, be told that there is a stored exception for a specific
set of sites on such-and-such top-level origin, rather than
listing them by name; or the user agent might decide to store a
site-wide exception, effectively ignoring any list of domain names.

Conversely, if a wild-card is used, the user might be told that
there is a stored exception for all third-parties that are embedded
by the indicated top-level origin.

If the request does not include the
arrayOfDomainStrings, then this request is for a
site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a
target. When called,
storeSiteSpecificTrackingException MUST return
immediately.

If the list arrayOfDomainStrings is supplied, the
user agent MAY choose to store a site-wide exception. If it does
so it MUST indicate this in the return value.

If domain is not specified or is null or empty then
the execution of this API and the use of the resulting permission
(if granted) use the 'implicit' parameter, when the API is called,
the document origin. This forms the first part of
the duplet in the logical model, and hence in operation will be
compared with the top-level origin.

If permission is stored for an explicit list, then the set of
duplets (one per target):

[document-origin, target]

is added to the database of remembered grants.

If permission is stored for a site-wide exception, then the
duplet:

[document-origin, * ]

is added to the database of remembered grants.

If domain is supplied and not empty then it is
treated in the same way as the domain parameter to cookies and
allows setting for subdomains. The domain argument
can be set to fully-qualified right-hand segment of the document
host name, up to one level below TLD.

For example, www.foo.bar.example.com can set the domain
parameter as as "bar.example.com" or
"example.com", but not to
"something.else.example.com" or "com".

If the document-origin would not be able to set a cookie on the
domain following the cookie domain rules [[!RFC6265]]
(e.g. domain is not a right-hand match or is a TLD)
then the duplet MUST NOT be entered into the database and a
SYNTAX_ERR exception SHOULD be thrown.

If permission is stored for an explicit list, then the set of
duplets (one per target):

[*.domain, target]

is added to the database of remembered grants.

If permission is stored for a site-wide exception, then the
duplet:

[*.domain, * ]

is added to the database of remembered grants.

A particular response to the API — like a DNT response header
field — is only valid immediately; a user might later choose
to edit stored exceptions and revoke some or all of them.

If expires is supplied and not null or empty the
remembered grant will be cancelled (i.e. processed as if the
relevant Cancel API had been called) no later than the specified
date and time. After this the database of remembered grants will
no longer contain any duplets for which the first part is the
current document origin; i.e., no duplets
[document-origin, target] for any target.

If maxAge is supplied and not null, empty or negative
the remembered grant will be cancelled (i.e. processed as if the
relevant Cancel API had been called) no later than the specified
number of seconds following the grant.

If both maxAge and expires are supplied,
maxAge has precedence. If neither maxAge
or expires are supplied, the user agent MAY retain
the remembered grant until it is cancelled.

API to Cancel a Site-specific Exception

If domain is not supplied or is null or empty then this
ensures that the database of remembered grants no longer
contains any duplets for which the first part is the current
document origin; i.e., no duplets
[document-origin, target] for any target.

If domain is supplied and is not empty then this ensures that
the database of remembered grants no longer contains any
duplets for which the first part is the domain wildcard; i.e.,
no duplets [*.domain, target] for any target.

There is no callback. After the call has been made, it is
assured that there are no site-specific or site-wide
exceptions for the given top-level origin.

DOMString? domain

a cookie-domain as defined in [[!RFC6265]],
to which the exception applies.

When this method returns, the database of grants no longer
contains the indicated grant(s); if some kind of processing error
occurred then an appropriate exception will be thrown.

If there are no matching duplets in the database of remembered
grants when the method is called then this operation does nothing
(and does not throw an exception).

API to Confirm a Site-specific Exception

a cookie-domain as defined in [[!RFC6265]],
to which the exception applies.

sequence<DOMString> arrayOfDomainStrings

A JavaScript array of strings.

If the call does not include the
arrayOfDomainStrings, then this call is to confirm a
site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a
target.

If the list arrayOfDomainStrings is supplied, and the
user agent stores only site-wide exceptions, then the user agent
MUST match by confirming a site-wide exception.

If the domain argument is not supplied or is null or
empty then the execution of this API uses the 'implicit'
parameter, when the API is called, the
document origin. This forms the first part of the
duplet in the logical model.

If the user agent stores explicit lists, and the call includes
one, the database is checked for the existence of all the duplets
(one per target):

[document-origin, target]

If the user agent stores only site-wide exceptions or the call did
not include an explicit list, the database is checked for the
single duplet:

[document-origin, * ]

If the user agent stores explicit lists, the call includes
one, and the domain argument is provided and is not
empty, then the database is checked for the existence of all the
duplets (one per target):

[*.domain, target]

If the user agent stores only site-wide exceptions or the call did
not include an explicit list, and the domain argument
is provided and is not empty then the database is checked for the
single duplet:

[*.domain, * ]

The returned boolean has the following possible values:

true all the duplets exist in the database;

false one or more of the duplets does not exist
in the database.

Web-wide Exceptions

API to Request a Web-wide Exception

The single duplet
[ * , document-origin] or
[ * , *.domain] (based on if domain
is provided and is not null and not empty)
is added to the database of remembered grants.
The properties of the StoreExceptionPropertyBag
dictionary are as described
above in the
request for site-specific exceptions.

This API requests the addition of a web-wide grant for a specific
site to the database.

API to Cancel a Web-wide Exception

Ensures that the database of remembered grants no longer
contains the duplet [ * , document-origin]
or [ * , *.domain] (based on if domain
is provided and is not null and not empty).
There is no callback. After the call has been made, the
indicated pair is assured not to be in the database. The same
matching process defined for determining which header field to
send is also used to detect which entry (if any) to remove from
the database.

API to Confirm a Web-wide Exception

Confirms that there exists in the database a web-wide exception
for a specific site.

The returned boolean indicates whether the duplet
[ * , document-origin] or [ * , *.domain]
(based on if domain is provided and is not null and
not empty) exists in the database.

true indicates that the web-wide exception
exists;

false indicates that the web-wide exception
does not exist.

User Interface Guidelines

As described above, it is the sole responsibility of the site
making an API call to determine that an exception grant reflects the
user's informed consent at the time of the call.

It is expected that a site will explain to the user, in its online
content, the need for an exception and the consequences of granting or
denying that exception.

User agents are free to implement exception management user
interfaces as they see fit. Some agents might provide a notification
to the user at the time of the request, or even not complete the
storing of the exception until the user approves. Some agents might
provide a user-interface to see and edit the database of recorded
exception grants. The API parameters siteName, explanationString,
and detailURI are provided so that the user agent can use them in
their user interface. If a user agent presents these parameters 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.

A user agent that chooses to highlight when tracking exceptions have
been stored might provide an interface like the following:

an icon in the status bar indicating that an exception has been
stored, which, when clicked on, gives the user more information
about the exception and an option to revoke such an exception.

an infobar stating "Example News (news.example.com) has
indicated to Browser that you have consented to granting it
exceptions to your general Do Not Track preference. If you believe
this is incorrect, click Revoke."

no UI at all.

In some user agent implementations, decisions to grant exceptions
might have been made in the past (and since forgotten) or might have
been made by other users of the device. Thus, exceptions might not
always represent the current preferences of the user. Some user
agents might choose to provide ambient notice that user-opted
tracking is ongoing, or easy access to view and control these
preferences. Users might also desire to edit exceptions within a
separate user interface, which would allow a user to modify their
stored exceptions without visiting the target sites.

Exceptions without Interactive JavaScript

Some third party servers that might wish to receive a user-granted
exception 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, both because a script is needed, and because they would
be required to explain to the user the need for and consequences of
granting an exception, and get the user's consent. In general, this
process of informing, getting consent, and calling the API is not
expected within page elements where such trackers are invoked.

To obtain an exception, a document (page, frame, etc.) that loads
the Javascript is needed. The user might visit the site that desires
an exception directly, the first party site could load a frame of
the site desiring the exception, or that frame might be part of some
other page containing a number of frames, which allows aggregation
of requests for exceptions.

In all these ways, the site is contributing to informing the user and
obtaining their consent, while enabling a call to the Javascript API
when such consent is granted.

Exceptions without an Expressed Preference

Sites might wish to request exceptions even when a user arrives
without a DNT header field. Users might wish to grant affirmative
permission to tracking on or by certain sites even without
expressing a general tracking preference.

User agents MAY instantiate
navigator.storeSiteSpecificTrackingException even when
window.doNotTrack is null. Scripts SHOULD test for the
existence of storeSiteSpecificTrackingException before
calling the method. If an exception is granted and the user agent
stores that preference, a user agent might send the
DNT:0 tracking preference even if it has not
enabled preferences to be sent for other requests. Persisted
preferences MAY affect which preference is transmitted if a user
later chooses to express a tracking preference.

Users might not configure their agents to have simple values for
DNT, but use different browsing modes or other contextual
information to decide on a DNT value. What algorithm a user agent
employs to determine DNT values (or the lack thereof) is out of the
scope of this specification.

Exception Use by Sites

This section is to inform the authors of sites on some
considerations in using the exceptions APIs to best effect; sites of
particular interest here are those that need an exception in order
to allow the user to perform some operation or to have some access.

The 'Store' calls return immediately, without a return value.
If there is a problem with the calling parameters, then
a Javascript exception will be raised.

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 the call, the site has acquired the
user's consent and can proceed on that basis, whether or not the
user-agent has stored the exception immediately. It is not necessary
to call the confirm API at the time of consent.

On other visits, a site can call the 'Confirm' APIs to enquire
whether a specific exception has been granted and stands in the user
agent. This is the call to make to determine whether the exception
exists, and hence to control access to the function or operation; if
it fails (the exception has been deleted or not yet granted), then
the user is ideally again offered the information needed to give
their informed consent, and again offered the opportunity to
indicate that they grant it. As stated in the normative text, the
site needs to explain and acquire consent immediately prior to
calling the Store API, and not remember some past consent; this
allows a user to change their mind.

If they do grant it (using some positive interaction such as a
button), the site can return to checking the 'Confirm' API.

In this way the site:

does not assume that the storage is instantaneous and
mistakenly grant access when the exception does not (yet) stand;

does not call the Confirm API repeatedly, in a loop, without a
user-interaction between each call; and,

permits the user the opportunity to delete a previously
granted exception.

Fingerprinting

By storing a client-side configurable state and providing
functionality to learn about it later, this API might facilitate
user fingerprinting and tracking. User agent developers ought to
consider the possibility of fingerprinting during implementation and
might consider rate-limiting requests or using other heuristics to
mitigate fingerprinting risk.

The DNT header field is based on the original Do Not Track
submission by Jonathan Mayer (Stanford), Arvind Narayanan
(Stanford), and Sid Stamm (Mozilla).
The JavaScript DOM property for 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.

Registrations

The Internet media type application/tracking-status+json is
used for tracking status representations
().