dnt-sea.txt   dnt-aug14.txt 
W3C W3C
Tracking Preference Expression (DNT) Tracking Preference Expression (DNT)
W3C Editor's Draft 20 June 2012 W3C Editor's Draft 14 August 2012
This version: This version:
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
Latest published version: Latest published version:
http://www.w3.org/TR/tracking-dnt/ http://www.w3.org/TR/tracking-dnt/
Latest editor's draft: Latest editor's draft:
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
Previous version:
http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/
Editors: Editors:
Roy T. Fielding, Adobe Roy T. Fielding, Adobe
David Singer, Apple David Singer, Apple
Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved.
W3C liability, trademark and document use rules apply. W3C liability, trademark and document use rules apply.
---------------------------------------------------------------------- ----------------------------------------------------------------------
Abstract Abstract
skipping to change at line 87 skipping to change at line 84
* 1. Introduction * 1. Introduction
* 2. Notational Conventions * 2. Notational Conventions
* 2.1 Requirements * 2.1 Requirements
* 2.2 Formal Syntax * 2.2 Formal Syntax
* 2.3 Terminology * 2.3 Terminology
* 3. Determining User Preference * 3. Determining User Preference
* 4. Expressing a Tracking Preference * 4. Expressing a Tracking Preference
* 4.1 Expression Format * 4.1 Expression Format
* 4.2 DNT Header Field for HTTP Requests * 4.2 DNT Header Field for HTTP Requests
* 4.3 JavaScript API to Detect Preference * 4.3 JavaScript API to Detect Preference
* 4.3.1 Interface
* 4.3.2 Attributes
* 4.3.3 Implements
* 4.4 Plug-In APIs * 4.4 Plug-In APIs
* 4.5 Tracking Preference Expressed in Other Protocols * 4.5 Tracking Preference Expressed in Other Protocols
* 5. Communicating a Tracking Status * 5. Communicating a Tracking Status
* 5.1 Overview * 5.1 Overview
* 5.2 Tracking Status Resource * 5.2 Tracking Status Value
* 5.2.1 Definition
* 5.2.2 Representation
* 5.2.3 Response Value
* 5.2.4 Using the Tracking Status
* 5.2.5 Caching
* 5.2.6 Status-object ABNF
* 5.3 Tk Header Field for HTTP Responses * 5.3 Tk Header Field for HTTP Responses
* 5.3.1 Definition * 5.3.1 Definition
* 5.3.2 Indicating Tracking Design * 5.3.2 Referring to a Request-specific Tracking Status
Resource
* 5.3.3 Indicating an Interactive Status Change * 5.3.3 Indicating an Interactive Status Change
* 5.3.4 Indicating a Specific Tracking Status Resource * 5.4 Tracking Status Resource
* 5.4 Status Code for Tracking Required * 5.4.1 Site-wide Tracking Status
* 5.4.2 Request-specific Tracking Status
* 5.4.3 Representation
* 5.4.4 Status Checks are Not Tracked
* 5.4.5 Caching
* 5.5 Status Code for Tracking Required
* 5.6 Using the Tracking Status
* 5.6.1 Discovering Deployment
* 5.6.2 Preflight Checks
* 6. User-Granted Exceptions * 6. User-Granted Exceptions
* 6.1 Overview * 6.1 Overview
* 6.2 Motivating principles and use cases * 6.2 Motivating Principles and Use Cases
* 6.3 Exception model * 6.3 Exception model
* 6.3.1 Introduction * 6.3.1 Introduction
* 6.3.2 Exception use by browsers * 6.3.2 Exception use by browsers
* 6.4 JavaScript API for site-specific exceptions * 6.4 JavaScript API for Site-specific Exceptions
* 6.4.1 API to request site-specific exceptions * 6.4.1 API to request site-specific exceptions
* 6.4.1.1 Methods * 6.4.2 API to Cancel a Site-specific Exception
* 6.4.1.2 Methods * 6.5 JavaScript API for Web-wide Exceptions
* 6.4.2 API to cancel a site-specific exception * 6.5.1 API to Request a Web-wide Exception
* 6.4.2.1 Methods
* 6.5 JavaScript API for web-wide exceptions
* 6.5.1 API to request a web-wide exception
* 6.5.1.1 Methods
* 6.5.2 API to cancel a web-wide exception * 6.5.2 API to cancel a web-wide exception
* 6.5.2.1 Methods * 6.6 Querying a host's exception status
* 6.6 User interface guidelines * 6.7 User interface guidelines
* 6.7 Exceptions without a DNT header * 6.8 Exceptions without a DNT header
* 6.8 Fingerprinting * 6.9 Fingerprinting
* A. Acknowledgements * A. Acknowledgements
* B. References * B. References
* B.1 Normative references * B.1 Normative references
* B.2 Informative references * B.2 Informative references
1. Introduction 1. Introduction
The World Wide Web (WWW, or Web) consists of millions of sites The World Wide Web (WWW, or Web) consists of millions of sites
interconnected through the use of hypertext. Hypertext provides a simple, interconnected through the use of hypertext. Hypertext provides a simple,
page-oriented view of a wide variety of information that can be traversed page-oriented view of a wide variety of information that can be traversed
skipping to change at line 196 skipping to change at line 189
service's DNT compliance, the HTTP response header field Tk for resources service's DNT compliance, the HTTP response header field Tk for resources
to communicate their compliance or non-compliance with the user's to communicate their compliance or non-compliance with the user's
expressed preference, and JavaScript APIs for determining DNT status and expressed preference, and JavaScript APIs for determining DNT status and
requesting a user-granted exception. requesting a user-granted exception.
A companion document, [TRACKING-COMPLIANCE], more precisely defines the A companion document, [TRACKING-COMPLIANCE], more precisely defines the
terminology of tracking preferences, the scope of its applicability, and terminology of tracking preferences, the scope of its applicability, and
the requirements on compliant first-party and third-party participants the requirements on compliant first-party and third-party participants
when an indication of tracking preference is received. when an indication of tracking preference is received.
ISSUE-136: Resolve dependencies of the TPE on the compliance Issue 136: Resolve dependencies of the TPE on the compliance specification
specification.
The WG has not come to consensus regarding the definition of tracking and The WG has not come to consensus regarding the definition of tracking and
the scope of DNT. As such, a site cannot actually say with any confidence the scope of DNT. As such, a site cannot actually say with any confidence
whether or not it is tracking, let alone describe the finer details in a whether or not it is tracking, let alone describe the finer details in a
tracking status resource. This issue will be resolved by progress on the tracking status resource. This issue will be resolved by progress on the
TCS document, though its resolution is a necessary prerequisite to TCS document, though its resolution is a necessary prerequisite to
understanding and correctly implementing the protocol defined by this understanding and correctly implementing the protocol defined by this
document. document.
2. Notational Conventions 2. Notational Conventions
skipping to change at line 227 skipping to change at line 220
network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs.
2.3 Terminology 2.3 Terminology
This specification uses the term user agent to refer to any of the various This specification uses the term user agent to refer to any of the various
client programs capable of initiating HTTP requests, including, but not client programs capable of initiating HTTP requests, including, but not
limited to, browsers, spiders (web-based robots), command-line tools, limited to, browsers, spiders (web-based robots), command-line tools,
native applications, and mobile apps [HTTP11]. native applications, and mobile apps [HTTP11].
The term permitted use is used to indicate a restricted set of conditions The term permitted use is used to indicate a restricted set of conditions
under which tracking is allowed in spite of the user's DNT preference. The under which tracking is allowed in spite of the user's DNT preference.
term user-granted exception is used when the user has permitted tracking,
usually in the form of a site-specific exception, for a given third-party. The term user-granted exception is used when the user has permitted
In general: permitted uses are additional permissions granted by the tracking by a given third party, usually in the form of a site-specific
standard; user-granted exceptions are additional permissions granted by exception.
the user. These words are often confused when drafting new text.
3. Determining User Preference 3. Determining User Preference
The goal of this protocol is to allow a user to express their personal 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 preference regarding tracking to each server and web application that they
communicate with via HTTP, thereby allowing each service to either adjust communicate with via HTTP, thereby allowing each service to either adjust
their behavior to meet the user's expectations or reach a separate their behavior to meet the user's expectations or reach a separate
agreement with the user to satisfy all parties. agreement with the user to satisfy all parties.
Key to that notion of expression is that it must reflect the user's Key to that notion of expression is that it must reflect the user's
choice, not the choice of some vendor, institution, or network-imposed preference, not the choice of some vendor, institution, or network-imposed
mechanism outside the user's control. The basic principle is that a mechanism outside the user's control. The basic principle is that a
tracking preference expression is only transmitted when it reflects 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 deliberate choice by the user. In the absence of user choice, there is no
tracking preference expressed. tracking preference expressed.
A user agent must offer users a minimum of two alternative choices for a A user agent must offer users a minimum of two alternative choices for a
Do Not Track preference: unset or on. A user agent may offer a third Do Not Track preference: unset or DNT:1. A user agent may offer a third
alternative choice: off. If the user's choice is on or off, the tracking alternative choice: DNT:0.
preference is enabled; otherwise, the tracking preference is not enabled.
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 A user agent must have a default tracking preference of unset (not
enabled) unless a specific tracking preference is implied by the decision enabled) unless a specific tracking preference is implied by the decision
to use that agent. For example, use of a general-purpose browser would not 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 tracking preference when invoked normally as SuperFred, but might
imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred. imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred.
Likewise, a user agent extension or add-on must not alter the tracking Likewise, a user agent extension or add-on must not alter the tracking
preference unless the act of installing and enabling that extension or preference unless the act of installing and enabling that extension or
add-on is an explicit choice by the user for that tracking preference. add-on is an explicit choice by the user for that tracking preference.
We do not specify how tracking preference choices are offered to the user We do not specify how tracking preference choices are offered to the user
or how the preference is enabled: each implementation is responsible for or how the preference is enabled: each implementation is responsible for
determining the user experience by which a tracking preference is enabled. 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 For example, a user might select a check-box in their user agent's
configuration, install an extension or add-on that is specifically configuration, install an extension or add-on that is specifically
designed to add a tracking preference expression, or make a choice for designed to add a tracking preference expression, or make a choice for
privacy that then implicitly includes a tracking preference (e.g., Privacy privacy that then implicitly includes a tracking preference (e.g., Privacy
settings: high). Likewise, a user might install or configure a proxy to settings: high). The 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. add the expression to their own outgoing requests.
Although some controlled network environments, such as public access Although some controlled network environments, such as public access
terminals or managed corporate intranets, might impose restrictions on the terminals or managed corporate intranets, might impose restrictions on the
use or configuration of installed user agents, such that a user might only use or configuration of installed user agents, such that a user might only
have access to user agents with a predetermined preference enabled, the have access to user agents with a predetermined preference enabled, the
user is at least able to choose whether to make use of those user agents. user is at least able to choose whether to make use of those user agents.
In contrast, if a user brings their own Web-enabled device to a library or In contrast, if a user brings their own Web-enabled device to a library or
cafe with wireless Internet access, the expectation will be that their cafe with wireless Internet access, the expectation will be that their
chosen user agent and personal preferences regarding Web site behavior chosen user agent and personal preferences regarding Web site behavior
will not be altered by the network environment, aside from blanket will not be altered by the network environment, aside from blanket
limitations on what resources can or cannot be accessed through that limitations on what resources can or cannot be accessed through that
network. Implementations of HTTP that are not under control of the user network. Implementations of HTTP that are not under control of the user
must not express a tracking preference on their behalf. must not generate or modify a tracking preference.
4. Expressing a Tracking Preference 4. Expressing a Tracking Preference
4.1 Expression Format 4.1 Expression Format
When a user has enabled a tracking preference, that preference needs to be When a user has enabled a tracking preference, that preference needs to be
expressed to all mechanisms that might perform or initiate tracking by expressed to all mechanisms that might perform or initiate tracking by
third parties, including sites that the user agent communicates with via third parties, including sites that the user agent communicates with via
HTTP, scripts that can extend behavior on pages, and plug-ins or HTTP, scripts that can extend behavior on pages, and plug-ins or
extensions that might be installed and activated for various media types. extensions that might be installed and activated for various media types.
When enabled, a tracking preference is expressed as either: When enabled, a tracking preference is expressed as either:
DNT meaning DNT meaning
1 This user prefers not to be tracked on the target 1 This user prefers not to be tracked on the target
site. site.
0 This user prefers to allow tracking on the target 0 This user prefers to allow tracking on the target
site. site.
If a tracking preference is not enabled, then no preference is expressed A user agent must not send a tracking preference expression if a tracking
by this protocol. This means that no expression is sent for each of the preference is not enabled. This means that no expression is sent for each
following cases: of the following cases:
* the user agent does not implement this protocol; * the user agent does not implement this protocol;
* the user has not yet made a choice for a specific preference; or, * the user has not yet made a choice for a specific preference; or,
* the user has chosen not to indicate a preference. * the user has chosen not to transmit a preference.
In the absence of regulatory, legal, or other requirements, servers may In the absence of regulatory, legal, or other requirements, servers may
interpret the lack of an expressed tracking preference as they find most interpret the lack of an expressed tracking preference as they find most
appropriate for the given user, particularly when considered in light of appropriate for the given user, particularly when considered in light of
the user's privacy expectations and cultural circumstances. Likewise, the user's privacy expectations and cultural circumstances. Likewise,
servers might make use of other preference information outside the scope servers might make use of other preference information outside the scope
of this protocol, such as site-specific user preferences or third-party of this protocol, such as site-specific user preferences or third-party
registration services, to inform or adjust their behavior when no explicit registration services, to inform or adjust their behavior when no explicit
preference is expressed via this protocol. preference is expressed via this protocol.
ISSUE-59: Should the first party be informed about whether the user has
sent a DNT header to third parties on their site?
ISSUE-111: Different DNT value to signify existence of site-specific
exception (also linked to 4.1 and 6 below)
4.2 DNT Header Field for HTTP Requests 4.2 DNT Header Field for HTTP Requests
The DNT header field is hereby defined as the means for expressing a The DNT header field is hereby defined as the means for expressing a
user's tracking preference via HTTP [HTTP11]. user's tracking preference via HTTP [HTTP11].
DNT-field-name = "DNT" ; case-insensitive DNT-field-name = "DNT" ; case-insensitive
DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash ; excludes CTL, SP, DQUOTE, comma, backslash
A user agent must send the DNT header field on all HTTP requests if (and A user agent must send the DNT header field on all HTTP requests if (and
only if) a tracking preference is enabled. A user agent must not send the only if) a tracking preference is enabled. A user agent must not send the
DNT header field if a tracking preference is not enabled. DNT header field if a tracking preference is not enabled.
The DNT field-value sent by a user agent must begin with the numeric The DNT field-value sent by a user agent must begin with the numeric
character "1" (%x31) if a tracking preference is enabled, the preference character "1" (%x31) if a tracking preference is enabled, and the
is for no tracking, and there is not a site-specific exception for the preference is for no tracking, and there is not a site-specific exception
origin server targeted by this request. for the origin server targeted by this request.
The DNT field-value sent by a user agent must begin with the numeric The DNT field-value sent by a user agent must begin with the numeric
character "0" (%x30) if a tracking preference is enabled and the character "0" (%x30) if a tracking preference is enabled, and the
preference is to allow tracking in general or by specific exception for preference is to allow tracking in general or by specific exception for
the origin server targeted by this request. the origin server targeted by this request.
Example 1
GET /something/here HTTP/1.1 GET /something/here HTTP/1.1
Host: example.com Host: example.com
DNT: 1 DNT: 1
An HTTP intermediary must not add, delete, or modify the DNT header field An HTTP intermediary must not add, delete, or modify the DNT header field
in requests forwarded through that intermediary unless that intermediary in requests forwarded through that intermediary unless that intermediary
has been specifically installed or configured to do so by the user making has been specifically installed or configured to do so by the user making
the requests. For example, an Internet Service Provider must not inject the requests. For example, an Internet Service Provider must not inject
DNT: 1 on behalf of all of their users who have not selected a choice. DNT: 1 on behalf of all of their users who have not expressed a
preference.
The remainder of the DNT field-value after the initial character is The remainder of the DNT field-value after the initial character is
reserved for future extensions. User agents that do not implement such reserved for future extensions. User agents that do not implement such
extensions must not send DNT-extension characters in the DNT field-value. extensions must not send DNT-extension characters in the DNT field-value.
Servers that do not implement such extensions should ignore anything Servers that do not implement such extensions should ignore anything
beyond the first character. beyond the first character.
DNT extensions are to be interpreted as modifiers to the main preference DNT extensions are to be interpreted as modifiers to the main preference
expressed by the first digit, such that the main preference will be obeyed expressed by the first digit, such that the main preference will be obeyed
if the recipient does not understand the extension. Hence, a if the recipient does not understand the extension. Hence, a
DNT-field-value of "1xyz" can be thought of as do not track, but if you DNT-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 understand the refinements defined by x, y, or z, then adjust my
preferences according to those refinements. DNT extensions can only be preferences according to those refinements. DNT extensions can only be
transmitted when a tracking preference is enabled. transmitted when a tracking preference is enabled.
The extension syntax is restricted to visible ASCII characters that can be 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 parsed as a single word in HTTP and safely embedded in a JSON string
without further encoding (section 5.2.2 Representation). Since the DNT without further encoding (section 5.4.3 Representation). Since the DNT
header field is intended to be sent on every request, when enabled, header field is intended to be sent on every request, when enabled,
designers of future extensions ought to use as few extension characters as designers of future extensions ought to use as few extension characters as
possible. possible.
Note
This document does not have any implied or specified behavior for the This document does not have any implied or specified behavior for the
user-agent treatment of cookies when DNT is enabled. user-agent treatment of cookies when DNT is enabled.
ISSUE-111: Different DNT value to signify existence of site-specific
exceptions
Should the user agent send a different DNT value to a first party site if
there exist site-specific exceptions for that first party? (e.g. DNT:2
implies I have Do Not Track enabled but grant permissions to some third
parties while browsing this domain) [OPEN]
4.3 JavaScript API to Detect Preference 4.3 JavaScript API to Detect Preference
4.3.1 Interface A doNotTrack attribute on the Navigator interface [NAVIGATOR] (e.g., the
window.navigator object) is hereby defined as the means for expressing the
The NavigatorDoNotTrack interface provides a means for the user's tracking user's general tracking preference to scripts running within a top-level
preference to be expressed to web applications running within a page page. A user agent must provide a doNotTrack attribute on the Navigator
rendered by the user agent. interface for each top-level page.
[NoInterfaceObject] partial interface Navigator {
interface NavigatorDoNotTrack {
readonly attribute DOMString doNotTrack; readonly attribute DOMString doNotTrack;
}; };
4.3.2 Attributes
doNotTrack of type DOMString, readonly doNotTrack of type DOMString, readonly
When a tracking preference is enabled, the doNotTrack attribute When a tracking preference is enabled, the doNotTrack attribute
must have a string value that is the same as the DNT-field-value for each top-level page must have the same string value that would
defined in section 4.2 DNT Header Field for HTTP Requests. If a be sent in a DNT-field-value (section 4.2 DNT Header Field for
tracking preference is not enabled, the value is null. HTTP Requests) to an origin server that does not have any
corresponding user-granted exceptions. When a tracking preference
is not enabled, the doNotTrack attribute for each top-level page
must have a value of null.
4.3.3 Implements The doNotTrack attribute only provides the user's general tracking
preference, independent of any user-granted exceptions or out-of-band
consent. A script wishing to determine the specific tracking preference
for a given document origin is expected to use the API in section 6.6
Querying a host's exception status.
Navigator implements NavigatorDoNotTrack; A user agent must provide a doNotTrack attribute value that is consistent
with the user's current tracking preference that would be expressed via
the DNT header field. However, changes to the user's preference might
occur between the time when the APIs are checked and an actual request is
made. A server must treat the user's most recently received preference as
authoritative.
Objects implementing the Navigator interface [NAVIGATOR] (e.g., the Issue 84: Make DNT status available to JavaScript
window.navigator object) must also implement the NavigatorDoNotTrack
interface. An instance of NavigatorDoNotTrack is obtained by using
binding-specific casting methods on an instance of Navigator.
ISSUE-84: Make DNT status available to JavaScript [PENDING REVIEW] Updated text in this section.
[OPEN] The API above has been deemed inadequate due to origin restrictions
on embedded javascript by reference. We are awaiting new text to resolve
this issue.
ISSUE-116: How can we build a JS DOM property which doesn't allow inline Issue 116: How can we build a JS DOM property which doesn't allow inline
JS to receive mixed signals? JS to receive mixed signals?
[PENDING REVIEW] Updated text in this section.
4.4 Plug-In APIs 4.4 Plug-In APIs
User agents often include user-installable component parts, commonly known User agents often include user-installable component parts, commonly known
as plug-ins or browser extensions, that are capable of making their own as plug-ins or browser extensions, that are capable of making their own
network requests. From the user's perspective, these components are network requests. From the user's perspective, these components are
considered part of the user agent and thus ought to respect the user's considered part of the user agent and thus ought to respect the user's
configuration of a tracking preference. However, plug-ins do not normally configuration of a tracking preference. However, plug-ins do not normally
have read access to the browser configuration. have read access to the browser configuration.
Note
It is unclear whether we need to standardize the plug-in APIs or if we It is unclear whether we need to standardize the plug-in APIs or if we
should rely on it being defined per user agent based on general advice should rely on it being defined per user agent based on general advice
here. No plug-in APIs have been proposed yet. here. No plug-in APIs have been proposed yet.
4.5 Tracking Preference Expressed in Other Protocols 4.5 Tracking Preference Expressed in Other Protocols
A user's tracking preference is intended to apply in general, regardless A user's tracking preference is intended to apply in general, regardless
of the protocols being used for Internet communication. The protocol of the protocols being used for Internet communication. The protocol
expressed here is specific to HTTP communication; however, the semantics expressed here is specific to HTTP communication; however, the semantics
are not restricted to use in HTTP; the same semantics may be carried by are not restricted to use in HTTP; the same semantics may be carried by
other protocols, either in future revisions of this specification, or in other protocols, either in future revisions of this specification, or in
other specifications. other specifications.
When it is known that the user's preference is for no tracking, compliant When it is known that the user's preference is for no tracking, compliant
services are still required to honor that preference, even if other services are still required to honor that preference, even if other
protocols are used. For example, re-directing to another protocol in order protocols are used. For example, redirecting to another protocol in order
to avoid receipt of the header is not compliant. to avoid receipt of the header is not compliant.
Note
The last paragraph may be more appropriate in the compliance document, as The last paragraph may be more appropriate in the compliance document, as
it discusses compliance. it discusses compliance.
5. Communicating a Tracking Status 5. Communicating a Tracking Status
5.1 Overview 5.1 Overview
The Tracking Protection protocol is designed to be applicable regardless The primary goals of this protocol-expressing the user's preference and
of the response from servers that receive the tracking preference adhering to that preference-can be accomplished without any response from
expression, allowing conformance to be achieved without impacting the the server. However, the protocol also seeks to improve the transparency
operational performance of site resources. However, there is also a desire of tracking behavior by providing a machine-readable means for discovering
to support verification or pre-flight testing of a site's conformance with claims of compliance and determining the current tracking status.
this protocol for evaluating conformance before sending data, enabling
specialized user interfaces, discovering the scope of protocol deployment, Unfortunately, providing a dynamic indication of tracking compliance on
and testing adherence to potential regulations. every HTTP response is not feasible, since it would have the effect of
disabling caching for the entire Web. Instead, this protocol defines a
combination of response mechanisms that allow the information to be
communicated without making every response dynamic.
This section explains how a user agent may discover an origin server's This section explains how a user agent may discover an origin server's
tracking status for a given resource. It defines a required well-known tracking status for a given resource. It defines a required site-wide
tracking status resource for describing a machine-readable tracking status tracking status resource at a specific well-known location and an optional
and a Tk response header field that may be sent in any HTTP response and space of request-specific tracking status resources for sites where the
must be sent in responses to requests that modify the tracking status for tracking status might vary based on data within the request. It also
that user agent. defines a Tk response header field that may be sent in any HTTP response,
must be sent in responses to requests that modify the tracking status, and
may direct the user to a request-specific tracking status resource
applicable to the current request.
5.2 Tracking Status Resource Issue 120: Should the response header be mandatory (MUST) or recommended
(SHOULD)
5.2.1 Definition [PENDING REVIEW] The site-wide resource is mandatory; the header field is
optional, except for the single must case above.
An origin server must provide a tracking status resource at the well-known Issue 124: Alternative DNT implementations that replace HTTP headers with
identifier [RFC5785] something else
[PENDING REVIEW] The tracking status resource minimizes bandwidth usage
because only a small proportion of user agents are expected to perform
active verification, status would only be requested once per site per day,
and the response can be extensively cached.
5.2 Tracking Status Value
A tracking status value is a short notation for communicating how a
designated resource conforms to the tracking protection protocol, as
defined by this document and [TRACKING-COMPLIANCE]. There is no form of
negative response; i.e., an origin server that does not wish to claim
conformance to this protocol would not supply a tracking status resource
and would not send a Tk header field in responses.
For a site-wide tracking status resource, the designated resource to which
the tracking status applies is any resource on the same origin server. For
a Tk response header field, the corresponding request target is the
designated resource and remains so for any subsequent request-specific
tracking status resource referred to by that field.
All of the tracking status mechanisms use a common format for the tracking
status value: a single character from a limited set. The meaning of each
allowed character is defined in the following table.
status meaning
N None: The designated resource does not perform
tracking of any kind, not even for a permitted use,
and does not make use of any data collected from
tracking.
1 First party: The designated resource is designed for
use within a first-party context and conforms to the
requirements on a first party. If the designated
resource is operated by an outsourced service
provider, the service provider claims that it
conforms to the requirements on a third party acting
as a first party.
3 Third party: The designated resource is designed for
use within a third-party context and conforms to the
requirements on a third party.
X Dynamic: The designated resource is designed for use
in both first and third-party contexts and
dynamically adjusts tracking status accordingly. If
X is present in the site-wide tracking status, more
information must be provided via the Tk response
header field when accessing a designated resource.
If X 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 X as the
tracking status value in the representation of a
request-specific tracking status resource.
C Consent: The designated resource 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.
U Updated: 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.
For the site-wide tracking status and Tk header field, the tracking status
values 1 and 3 indicate how the designated resource is designed to
conform, not the nature of the request. Hence, if a user agent is making a
request in what appears to be a third-party context and the tracking
status value indicates that the designated resource is designed only for
first-party conformance, then either the context has been misunderstood
(both are actually the same party) or the resource has been referenced
incorrectly. For the request-specific tracking status resource, an
indication of first or third party as the status value describes how the
resource conformed to that specific request, and thus indicates both the
nature of the request (as viewed by the origin server) and the applicable
set of requirements to which the origin server claims to conform.
The tracking status value is case sensitive, as defined formally by the
following ABNF.
tracking-v = "1" ; "1" - first-party
/ "3" ; "3" - third-party
/ %x43 ; "C" - consent
/ %x4E ; "N" - none
/ %x55 ; "U" - updated
/ %x58 ; "X" - dynamic
Issue 137: Does hybrid tracking status need to distinguish between first
party (1) and outsourcing service provider acting as a first party (s)
[PENDING REVIEW] No, in practice there may be dozens of service providers
on any given request. If the designated resource is operated by a service
provider acting as a first party, then the responsible first party is
identified by the policy link or the owner of the origin server domain.
This satisfies the use case of distinguishing between a service provider
acting for some other site and the same service provider acting on one of
its own sites.
5.3 Tk Header Field for HTTP Responses
5.3.1 Definition
The Tk response header field is hereby defined as an optional means for
indicating the tracking status that applied to the corresponding request
and as a required means for indicating that a state-changing request has
resulted in an interactive change to the tracking status.
Tk-field-name = "Tk" ; case-insensitive
Tk-field-value = tracking-v [ ";" status-id ]
The Tk field-value begins with a tracking status value (section 5.2
Tracking Status Value), optionally followed by a semicolon and a status-id
that refers to a request-specific tracking status resource (section 5.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
whereas a Tk header field for a resource that might perform tracking
(though not necessarily for every request) and conforms to the third-party
requirements of [TRACKING-COMPLIANCE] would look like:
Example 3
Tk: 3
Issue 107: Exact format of the response header?
[PENDING REVIEW] See the proposal in this section.
5.3.2 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 may provide an additional subtree of well-known resources
corresponding to each of those distinct tracking statuses. The optional
status-id portion of the Tk field-value indicates which specific tracking
status resource applies to the current request.
status-id = 1*id-char ; case-sensitive
id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
For example, a response containing
Example 4
Tk: 1;fRx42
indicates that the target resource claims to conform to the first-party
requirements of [TRACKING-COMPLIANCE] and that an applicable tracking
status representation can be obtained by performing a retrieval request on
/.well-known/dnt/fRx42
If a Tk field-value has a tracking status value of X (dynamic), then a
status-id must be included in the field-value.
5.3.3 Indicating an Interactive Status Change
We anticipate that interactive mechanisms might be used, beyond the scope
of this specification, that have the effect of asking for and obtaining
prior consent for tracking, or for modifying prior indications of consent.
For example, the tracking status resource's status-object defines a
control member that can refer to such a mechanism. Although such
out-of-band mechanisms are not defined by this specification, their
presence might influence the tracking status object's response value.
When an origin server provides a mechanism via HTTP for establishing or
modifying out-of-band tracking preferences, the origin server must
indicate within the mechanism's response when a state-changing request has
resulted in a change to the tracking status for that server. This
indication of an interactive status change is accomplished by sending a Tk
header field in the response with a tracking status value of U (updated).
Example 5
Tk: U
5.4 Tracking Status Resource
5.4.1 Site-wide Tracking Status
An origin server must provide a site-wide tracking status resource at the
well-known identifier [RFC5785]
/.well-known/dnt /.well-known/dnt
(relative to the URI of that origin server) for obtaining information (relative to the URI of that origin server) for obtaining information
about the potential tracking behavior of resources provided by that origin about the potential tracking behavior of resources provided by that origin
server. A tracking status resource may be used for verification of DNT server. A tracking status resource may be used for verification of DNT
support, as described in section 5.2.4 Using the Tracking Status. support, as described in section 5.6 Using the Tracking Status.
A valid retrieval request (e.g., a GET in HTTP) on the well-known URI must A valid retrieval request (e.g., a GET in HTTP) on the well-known URI must
result in either a successful response containing a machine-readable result in either a successful response containing a machine-readable
representation of the site-wide tracking status, as defined below, or a representation of the site-wide tracking status, as defined below, or a
sequence of redirects that leads to such a representation. A user agent sequence of redirects that leads to such a representation. A user agent
may consider failure to provide access to such a representation equivalent may consider failure to provide access to such a representation equivalent
to the origin server not implementing this protocol. The representation to the origin server not implementing this protocol. The representation
may be cached, as described in section 5.2.5 Caching. may be cached, as described in section 5.4.5 Caching.
If an origin server has multiple, resource-specific tracking policies, 5.4.2 Request-specific Tracking Status
such that the tracking status might differ depending on some aspect of the
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 request (e.g., method, target URI, header fields, data, etc.), the origin
server may provide an additional subtree of well-known resources server may provide an additional subtree of well-known resources
corresponding to each of those distinct tracking statuses. The Tk response corresponding to each of those distinct tracking statuses. The Tk response
header field (section 5.3 Tk Header Field for HTTP Responses) can include header field (section 5.3 Tk Header Field for HTTP Responses) can include
a status-id to indicate which specific tracking status resource applies to a status-id to indicate which specific tracking status resource applies to
the current request. This subtree of resources is called the tracking the current request.
status resource space.
The tracking status resource space is defined by the following URI The tracking status resource space is defined by the following URI
Template [URI-TEMPLATE]: Template [URI-TEMPLATE]:
/.well-known/dnt{/status-id} /.well-known/dnt{/status-id}
where the value of status-id is a string of URI-safe characters provided 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 by a Tk field-value in response to a prior request. For example, a prior
response containing response containing
Tk: 1;fRx42 Example 6
Tk: 1;ahoy
refers to the specific tracking status resource refers to the specific tracking status resource
/.well-known/dnt/fRx42 /.well-known/dnt/ahoy
Resources within the tracking status resource space are represented using Resources within the request-specific tracking status resource space are
the same format as a site-wide tracking status resource. represented using the same format as a site-wide tracking status resource.
When sending a request for the tracking status, a user agent should 5.4.3 Representation
include any cookie data [COOKIES] (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.
All requests on the tracking status resource space, including the The representation of a tracking status resource shall be provided in the
site-wide tracking status resource, must not be tracked, irrespective of "application/json" format [RFC4627] and must conform to the ABNF for
the presence, value, or absence of a DNT header field, cookies, or any status-object (except that the members within each member-list may be
other information in the request. In addition, all responses to those provided in any order).
requests, including the responses to redirected tracking status requests,
must not have Set-Cookie or Set-Cookie2 header fields and must not have
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.
5.2.2 Representation The following example tracking status representation illustrates all of
the fields defined by this specification, most of which are optional.
The representation of a tracking status resource shall be provided in the Example 7
"application/json" format [RFC4627] and must conform to the ABNF in
section 5.2.6 Status-object ABNF. The following is an example tracking
status representation that illustrates all of the fields defined by this
specification, most of which are optional.
{ {
"tracking": true, "tracking": "1",
"received": "1",
"response": "t1",
"same-party": [ "same-party": [
"example.com", "example.com",
"example_vids.net", "example_vids.net",
"example_stats.com" "example_stats.com"
], ],
"partners": [ "third-party": [
"api.example-third-party.com" "api.example.net"
],
"audit": [
"http://auditor.example.org/727073"
], ],
"policy": "/tracking.html", "policy": "/tracking.html",
"control": "http://example-third-party.com/your/data" "control": "http://example.com/your/data"
} }
A tracking status representation consists of a single status-object A tracking status representation consists of a single status-object
containing members that describe the tracking status applicable to this containing members that describe the tracking status applicable to the
user agent's request. designated resource.
A status-object must have a member named tracking with a boolean value. A status-object = begin-object member-list end-object
value of false indicates that the corresponding resources do not perform
tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true member-list = tracking ns tracking-v
indicates that the corresponding resource performs tracking and claims to [ vs same-party ns same-party-v ]
conform to all tracking compliance requirements applicable to this site. [ vs third-party ns third-party-v ]
[ vs audit ns audit-v ]
[ vs policy ns policy-v ]
[ vs control ns control-v ]
*( vs extension )
A status-object must have a member named tracking that contains a single
character tracking status value (section 5.2 Tracking Status Value).
tracking = %x22 "tracking" %x22
For example, the following demonstrates a minimal tracking status For example, the following demonstrates a minimal tracking status
representation that is applicable to any resource that does not perform representation that is applicable to any resource that does not perform
tracking. tracking.
{"tracking": false} Example 8
If tracking is true, the status-object must include two additional
members, named received and response, and may include other members as
described below.
The received member must have either a string value equal to the
DNT-field-value received in that request or the value null if no
DNT-field-value was received. Any invalid characters received in the
DNT-field-value must be elided from the string value to ensure that
invalid data is not injected into the JSON result.
The response member must have a string value that indicates the status of {"tracking": "N"}
tracking applicable specifically to this user in light of the received
DNT-field-value. The string value begins with t (tracking), n (not
tracking), or s (see the more specific tracking status resource), and may
be followed by alphanumeric characters that indicate qualifiers for that
status. The defined qualifier characters and their meanings are described
in section Not foundstatus-reponse-value.
An optional member named same-party may be provided with an array value An optional member named same-party may be provided with an array value
containing a list of domain names that the origin server claims are the containing a list of domain names that the origin server claims are the
same party, to the extent they are referenced on this site, since all data same party, to the extent they are referenced by the designated resource,
collected via those references share the same data controller. since all data collected via those references share the same data
controller.
An optional member named partners may be provided with an array value same-party = %x22 "same-party" %x22
same-party-v = array-of-strings
An optional member named third-party may be provided with an array value
containing a list of domain names for third-party services that might be containing a list of domain names for third-party services that might be
invoked while using this site but do not share the same data controller as invoked while using the designated resource but do not share the same data
this site. controller as the designated resource.
third-party = %x22 "third-party" %x22
third-party-v = array-of-strings
An optional member named audit may be provided with an array value
containing a list of URI references to external audits of the designated
resource's tracking policy and tracking behavior in compliance with this
protocol. Preferably, the audit references are to resources that describe
the auditor and the results of that audit; however, if such a resource is
not available, a reference to the auditor is sufficient.
audit = %x22 "audit" %x22
audit-v = array-of-strings
An optional member named policy may be provided with a string value An optional member named policy may be provided with a string value
containing a URI-reference to a human-readable document that describes the containing a URI-reference to a human-readable document that describes the
tracking policy for this site. The content of such a policy document is tracking policy for the designated resource. The content of such a policy
beyond the scope of this protocol and only supplemental to what is document is beyond the scope of this protocol and only supplemental to
described by this machine-readable tracking status representation. what is described by this machine-readable tracking status representation.
policy = %x22 "policy" %x22
policy-v = string ; URI-reference
If the tracking status value is 1 and the designated resource is being
operated by an outsourced service provider on behalf of a first party, the
origin server must identify the responsible first party via the domain of
the policy URI, if present, or by the domain owner of the origin server.
If no policy URI is provided and the origin server domain is owned by the
service provider, then the service provider is the first party.
An optional member named control may be provided with a string value An optional member named control may be provided with a string value
containing a URI-reference to a resource for giving the user control over containing a URI-reference to a resource for giving the user control over
personal data collected by this site. Such control might include the personal data collected by the designated resource (and possibly other
ability to review past data collected, delete some or all of the data, resources); a control member should be provided if the tracking status
value indicates prior consent (C). Such a control 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 provide additional data (if desired), or opt-in, opt-out, or otherwise
modify an out-of-band consent status regarding data collection by this modify an out-of-band consent status regarding data collection. The design
site. The design of such a resource, the extent to which it can provide of such a resource, the extent to which it can provide access to that
access to that data, and how one might implement an out-of-band consent data, and how one might implement an out-of-band consent mechanism is
mechanism is beyond the scope of this protocol. beyond the scope of this protocol.
control = %x22 "control" %x22
control-v = string ; URI-reference
Additional extension members may be provided in the status-object to Additional extension members may be provided in the status-object to
support future enhancements to this protocol. A user agent should ignore support future enhancements to this protocol. A user agent should ignore
extension members that it does not recognize. extension members that it does not recognize.
extension = object
array-of-strings = begin-array
[ string *( vs string ) ]
end-array
ns = <name-separator (:), as defined in [[!RFC4627]]>
vs = <value-separator (,), as defined in [[!RFC4627]]>
begin-array = <begin-array ([), as defined in [[!RFC4627]]>
end-array = <end-array (]), as defined in [[!RFC4627]]>
begin-object = <begin-object ({), as defined in [[!RFC4627]]>
end-object = <end-object (}), as defined in [[!RFC4627]]>
object = <object, as defined in [[!RFC4627]]>
string = <string, as defined in [[!RFC4627]]>
true = <true, as defined in [[!RFC4627]]>
false = <false, as defined in [[!RFC4627]]>
null = <null, as defined in [[!RFC4627]]>
Note that the tracking status resource space applies equally to both Note that the tracking status resource space applies equally to both
first-party and third-party services. An example of a third-party tracking first-party and third-party services. An example of a third-party tracking
status is status is
Example 9
{ {
"tracking": true, "tracking": "3",
"received": "1",
"response": "n",
"policy": "/privacy.html", "policy": "/privacy.html",
"control": "/your/data", "control": "/your/data",
} }
ISSUE-47: Should the response from the server indicate a policy that Issue 47: Should the response from the server indicate a policy that
describes the DNT practices of the server? describes the DNT practices of the server?
[PENDING REVIEW] The tracking status resource is a machine-readable policy [PENDING REVIEW] The tracking status resource is a machine-readable policy
and provides a mechanism for supplying a link to a human-readable policy. and provides a mechanism for supplying a link to a human-readable policy.
ISSUE-61: A site could publish a list of the other domains that are Issue 61: A site could publish a list of the other domains that are
associated with them associated with them
[PENDING REVIEW] The same-party and partners members provide a means to
list first-party and third-party domains, respectively.
ISSUE-124: Alternative DNT implementations that replace HTTP headers with
something else
[PENDING REVIEW] The tracking status resource minimizes bandwidth usage
because only a small proportion of user agents are expected to perform
active verification, status would only be requested once per site per day,
and the response can be extensively cached.
5.2.3 Response Value
When present, the tracking status response member's value consists of a
string of characters that starts with the tracking status, signified by t
(tracking), n (not tracking), or s (see the more specific tracking status
resource), and may be followed by a set of qualifier characters indicating
reasons or limitations applicable to that status. Multiple qualifiers can
be provided.
qualifier meaning
First-party: The origin server acts as a
first-party for requests on this resource,
1 either in all contexts when no "3" qualifier is
present or only for the domains listed in
same-party.
Third-party: The origin server acts as a
third-party for requests on this resource,
3 either in all contexts when no "1" qualifier is
present or only for the domains not listed in
same-party.
Audit: Tracking is limited to that necessary for
a an external audit of the service context and the
data collected is minimized accordingly.
Ad frequency capping: Tracking is limited to
c frequency capping and the data collected is
minimized accordingly.
Prior consent: The origin server believes it has
p received prior explicit and informed consent for
tracking this user, user agent, or device.
Fraud prevention: Tracking is limited to that
f necessary for preventing or investigating
fraudulent behavior and security violations; the
data collected is minimized accordingly.
Local constraints: Tracking is limited to what
l is required by local law, rule, or regulation
and the data collected is minimized accordingly.
Referrals: Tracking is limited to collecting
r referral information and the data collected is
minimized accordingly.
Qualifiers that indicate limitations on tracking correspond to the
specific permitted uses in [TRACKING-COMPLIANCE]. An origin server
indicating one or more of those permitted uses also indicates that it
conforms to the requirements associated with those permitted uses.
Multiple limitation qualifiers mean that multiple permitted uses of
tracking might be present and that each such use conforms to the
associated requirements. All limitation qualifiers imply some form of
tracking might be used and thus must not be provided with a tracking
status that begins with n (not tracking).
A 1 qualifier indicates that the resource has been designed for use within
a first-party context and will conform to the requirements on tracking by
a first-party. A 3 qualifier indicates that the resource has been designed
for use within a third-party context and will conform to the requirements
on tracking by a third-party. If both qualifiers are present, the resource
is designed to dynamically adjust its tracking behavior according to the
context in which it is used, and thus conforms to first-party requirements
when used in a first-party context and third-party requirements when used
in a third-party context.
A p qualifier indicates that the origin server believes it has obtained
prior explicit and informed consent for tracking the requesting user
agent, perhaps via some mechanism not defined by this specification, and
that prior consent overrides the tracking preference expressed by this
protocol. When prior consent is indicated, the tracking status object
should include a control member that references a resource for modifying
this consent.
Future extensions to this protocol might define additional characters as
qualifiers from the ext-qualifier set (consisting of the remaining unused
lowercase letters, dot, dash, and underscore). Recipients should ignore
extension qualifiers that they do not understand.
ISSUE-136: Resolve dependencies of the TPE on the compliance
specification.
The list of qualifiers is intended to correspond to constraints and
permitted uses identified by [TRACKING-COMPLIANCE], and at some point
might perhaps even move to that document in the sections defining the
permitted uses. The above list will be updated accordingly.
ISSUE-137: Does hybrid tracking status need to distinguish between first
party (1) and outsourcing service provider acting as a first party (s)
[PENDING REVIEW] No, a third party that satisfies the requirements for
acting as a first party will communicate to users as the first party.
5.2.4 Using the Tracking Status
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 and prior to making
requests on third-party resources referenced by those services. In
addition, the presence (or absence) of a site-wide tracking status
representation is a means for testing deployment of this standard and
verifying that a site's claims regarding tracking are consistent with the
site's observed behavior over time.
A user agent may check the tracking status for a given resource URI by [PENDING REVIEW] The same-party and third-party members provide a means to
making a retrieval request for the well-known address /.well-known/dnt list first-party and third-party domains, respectively.
relative to that URI.
If the response is an error, then the service does not implement this
standard. If the response is a redirect, then follow the redirect to
obtain 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.
Once the tracking status representation is obtained, parse the
representation as JSON to extract the Javascript status-object. If parsing
results in a syntax error, the user agent should consider the site to be
non-conformant with this protocol.
The status-object is supposed to have a member named tracking with a
boolean value. If the value is false, then no tracking is performed for
the URI being checked. If the value is true, then examine the member named
received to verify that the DNT header field sent by the user agent has
been correctly received by the server. If the received value is incorrect,
there may be an intermediary interfering with transmission of the DNT
request header field.
If the received value is correct, then examine the member named response
to see what the origin server has claimed regarding the tracking status
for this user agent in light of the received DNT-field-value.
If the first character of the response value is "n", then the origin
server claims that it will not 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, as
described below.
If the first character of the response value is "t", then the origin
server claims that it might track the user agent for requests on the URI
being checked for at least the next 24 hours or until the Cache-Control
information indicates that this response expires.
If the first character of the response value is "s", then the origin 5.4.4 Status Checks are Not Tracked
server has multiple tracking status representations and the specific one
applicable to each request is indicated by a status-id within the Tk
field-value of the corresponding response.
The remaining characters of the response value might indicate qualifiers When sending a request for the tracking status, a user agent should
for the above choices or limitations that the origin server will place on include any cookie data [COOKIES] (set prior to the request) that would be
its tracking. 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.
The others members of the status-object may be used to help the user agent All requests on the tracking status resource space, including the
differentiate between a site's first-party and third-party services, to site-wide tracking status resource, must not be tracked, irrespective of
provide links to additional human-readable information related to the the presence, value, or absence of a DNT header field, cookies, or any
tracking policy, and to provide links for control over past data collected other information in the request. In addition, all responses to those
or over some consent mechanism outside the scope of this protocol. requests, including the responses to redirected tracking status requests,
must not have Set-Cookie or Set-Cookie2 header fields and must not have
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.
5.2.5 Caching 5.4.5 Caching
If the tracking status is applicable to all users, regardless of the 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 received DNT-field-value or other data received via the request, then the
response should be marked as cacheable and assigned a time-to-live response should be marked as cacheable and assigned a time-to-live
(expiration or max-use) that is sufficient to enable shared caching but (expiration or max-use) that is sufficient to enable shared caching but
not greater than the earliest point at which the service's tracking not greater than the earliest point at which the service's tracking
behavior might increase. For example, if the tracking status response is 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 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 service's tracking behavior can be increased is seven days after the
policy has been updated to reflect the new behavior, since old copies policy has been updated to reflect the new behavior, since old copies
might persist in caches until the expiration is triggered. A service's might persist in caches until the expiration is triggered. A service's
tracking behavior can be reduced at any time, with or without a tracking behavior can be reduced at any time, with or without a
corresponding change to the tracking status resource. corresponding change to the tracking status resource.
If the tracking status is only applicable to all users that have the same If the tracking status is only applicable to all users that have the same
DNT-field-value, then either the response must include a Cache-Control DNT-field-value, then the response must either be marked with a Vary
header field with one of the directives "no-cache", "no-store", header field that includes "DNT" in its field-value or marked as not
"must-revalidate", or "max-age=0", or the response must include a Vary reusable by a shared cache without revalidation with a Cache-Control
header field that includes "DNT" in its field-value. 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 If the tracking status is only applicable to the specific user that
requested it, then the response must include a Cache-Control header field requested it, then the response must include a Cache-Control header field
with one of the directives "no-cache", "no-store", "must-revalidate", or containing one of the following directives: "private", "no-cache", or
"max-age=0". "no-store".
Regardless of the cache-control settings, it is expected that user agents 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 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 most). A public Internet site that intends to change its tracking status
to increase tracking behavior must update the tracking status resource in to increase tracking behavior must update the tracking status resource in
accordance with that planned behavior at least twenty-four hours prior to accordance with that planned behavior at least twenty-four hours prior to
activating that new behavior on the service. activating that new behavior on the service.
A user agent that adjusts behavior based on active verification of A user agent that adjusts behavior based on active verification of
tracking status, relying on cached tracking status responses to do so, tracking status, relying on cached tracking status responses to do so,
should check responses to its state-changing requests (e.g., POST, PUT, should check responses to its state-changing requests (e.g., POST, PUT,
DELETE, etc.) for a Tk header field with the update-needed field-value, as DELETE, etc.) for a Tk header field with the U tracking status value, as
described in section 5.3.3 Indicating an Interactive Status Change. described in section 5.3.3 Indicating an Interactive Status Change.
5.2.6 Status-object ABNF 5.5 Status Code for Tracking Required
The representation of a site's machine-readable tracking status must
conform to the following ABNF for status-object, except that the members
within each member-list may be provided in any order.
status-object = begin-object member-list end-object
member-list = tracking ns tracking-v
[ vs received ns received-v ]
[ vs response ns response-v ]
[ vs same-party ns same-party-v ]
[ vs partners ns partners-v ]
[ vs policy ns policy-v ]
[ vs control ns control-v ]
*( vs extension )
tracking = %x22 "tracking" %x22
tracking-v = true / false
received = %x22 "received" %x22
received-v = null / string
response = %x22 "response" %x22
response-v = %x22 r-codes %x22
r-codes = (%x74 / %x6E / %x73) *qualifier
qualifier = "1" ; "1" - first-party
/ "3" ; "3" - third-party
/ %x61 ; "a" - audit
/ %x63 ; "c" - ad frequency capping
/ %x66 ; "f" - fraud prevention
/ %x6C ; "l" - local law, rule, or regulation
/ %x70 ; "p" - prior consent
/ %x72 ; "r" - referrals
/ ext-qualifier
ext-qualifier = %x2D-2E / "0" / "2" / %x34-39 / %x5F
/ %x62 / %x64-65 / %x67-6B / %x6D / %x6F
/ %x71 / %x75-7A
same-party = %x22 "same-party" %x22
same-party-v = array-of-strings
partners = %x22 "partners" %x22
partners-v = array-of-strings
policy = %x22 "policy" %x22
policy-v = string ; URI-reference
control = %x22 "control" %x22
control-v = string ; URI-reference
extension = object
array-of-strings = begin-array
[ string *( vs string ) ]
end-array
ns = <name-separator (:), as defined in [RFC4627]>
vs = <value-separator (,), as defined in [RFC4627]>
begin-array = <begin-array ([), as defined in [RFC4627]>
end-array = <end-array (]), as defined in [RFC4627]>
begin-object = <begin-object ({), as defined in [RFC4627]>
end-object = <end-object (}), as defined in [RFC4627]>
object = <object, as defined in [RFC4627]>
string = <string, as defined in [RFC4627]>
true = <true, as defined in [RFC4627]>
false = <false, as defined in [RFC4627]>
null = <null, as defined in [RFC4627]>
5.3 Tk Header Field for HTTP Responses
5.3.1 Definition
As a supplement to the tracking status resource, the Tk response header
field is defined as an optional means for indicating DNT conformance and
as a required means for indicating that a state-changing request has
resulted in an interactive change to the tracking status for this user
agent.
Tk-field-name = "Tk" ; case-insensitive
Tk-field-value = tracking-design [ ";" status-id ]
tracking-design = tracking-never
/ tracking-first
/ tracking-third
/ update-needed
tracking-never = "0"
tracking-first = "1"
tracking-third = "3"
update-needed = %x75 ; lowercase "u"
ISSUE-107: Exact format of the response header?
[PENDING REVIEW] See the proposal in this section.
5.3.2 Indicating Tracking Design
The Tk field-value begins with a single character tracking-design that
indicates how the target resource conforms to [TRACKING-COMPLIANCE]. We
refer to this as the tracking design because it reflects only how the
resource is designed to work, rather than the current status of tracking
for this requesting user agent or received DNT field-value. Separating the
design and status allows conformance to this protocol to be indicated
without having a negative impact on caching of responses.
An origin server may send a Tk header field in a response with a
tracking-design of "0" to indicate that the resource never performs
tracking as it is defined by [TRACKING-COMPLIANCE]. This has the same
meaning as {"tracking": "false"} in the tracking status resource.
Tk: 0
An origin server may send a Tk header field in a response with a
tracking-design of "1" to indicate that the resource does perform tracking
(though not necessarily for every request), conforms to
[TRACKING-COMPLIANCE], and considers itself to be the first-party for this
request.
Tk: 1
An origin server may send a Tk header field in a response with a If an origin server receives a request with DNT:1, does not have
tracking-design of "3" to indicate that the resource does perform tracking out-of-band consent for tracking this user, and wishes to deny access to
(though not necessarily for every request), conforms to the requested resource until the user provides some form of user-granted
[TRACKING-COMPLIANCE], and considers itself to be a third-party for this exception or consent for tracking, then the origin server should send an
request. HTTP error response with a status code of 409 (Conflict) and a message
body that describes why the request has been refused and how one might
supply the required consent or exception to avoid this conflict [HTTP11].
Tk: 3 The 409 response should 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.
ISSUE-120: Should the response header be mandatory (must) or recommended Issue 128: HTTP error status code to signal that tracking is required?
(should)
[PENDING REVIEW] The site-wide resource is mandatory; the header field is
optional, except for the single must case below.
5.3.3 Indicating an Interactive Status Change [PENDING REVIEW] As defined by this section.
We anticipate that interactive mechanisms might be used, beyond the scope 5.6 Using the Tracking Status
of this specification, that have the effect of asking for and obtaining
prior consent for tracking, or for modifying prior indications of consent.
For example, the tracking status resource's status-object defines a
control member that can refer to such a mechanism. Although such
out-of-band mechanisms are not defined by this specification, their
presence might influence the tracking status object's response value.
When an origin server provides a mechanism via HTTP for establishing or Note
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-design of lowercase "u"
(update-needed).
Tk: u 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.
5.3.4 Indicating a Specific Tracking Status Resource 5.6.1 Discovering Deployment
If an origin server has multiple, resource-specific tracking policies, The presence of a site-wide tracking status representation is a claim that
such that the tracking status might differ depending on some aspect of the the service conforms to this protocol for a given user agent. Hence,
request (e.g., method, target URI, header fields, data, etc.), the origin deployment of this protocol for a given service can be discovered by
server may provide an additional subtree of well-known resources making a retrieval request on the site-wide tracking resource
corresponding to each of those distinct tracking statuses. The optional /.well-known/dnt relative to the service URI.
status-id portion of the Tk field-value indicates which specific tracking
status resource applies to the current request.
For example, a response containing 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.
Tk: 1;fRx42 5.6.2 Preflight Checks
indicates that the target resource conforms to this protocol as a A key advantage of providing the tracking status at a resource separate
first-party and the current tracking status can be obtained by performing from the site's normal services is that the status can be accessed and
a retrieval request on reviewed prior to making use of those services and prior to making
requests on third-party resources referenced by those services.
/.well-known/dnt/fRx42 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 Javascript status-object. If retrieval is unsuccessful
or parsing results in a syntax error, the user agent should consider the
site to be non-conformant with this protocol.
5.4 Status Code for Tracking Required The status-object is supposed to have a member named tracking containing
the tracking status value. The meaning of each tracking status value is
defined in section 5.2 Tracking Status Value.
An HTTP error response status code might be useful for indicating that the If the tracking status value is N, then the origin server claims that no
site refuses service unless the user either logs into a subscription tracking is performed for the designated resource for at least the next 24
account or agrees to an exception to DNT for this site and its contracted hours or until the Cache-Control information indicates that this response
third-party sites. expires.
ISSUE-128: HTTP error status code to signal that tracking is required? 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.
6. User-Granted Exceptions 6. User-Granted Exceptions
ISSUE-111: Different DNT values to signify existence of site-specific
exceptions
6.1 Overview 6.1 Overview
This section is non-normative. This section is non-normative.
User-granted exceptions to Do Not Track, including site-specific User-granted exceptions to Do Not Track, including site-specific
exceptions, are managed by the user agent. A resource should rely on the exceptions, are managed by the user agent. A resource should rely on the
DNT header it receives to determine the user's preference for tracking DNT header it receives to determine the user's preference for tracking
with respect to that particular request. An API is provided so that sites with respect to that particular request. An API is provided so that sites
may request and check the status of exceptions for tracking. may request and check the status of exceptions for tracking.
We anticipate that many user-agents might provide a prompt to users when We anticipate that many user-agents might provide a prompt to users when
this API is used, or to store exceptions. Questions of user interface this API is used, or to store exceptions. Questions of user interface
specifics - for granting, configuring, storing, syncing and revoking specifics - for granting, configuring, storing, syncing and revoking
exceptions - are explicitly left open to implementers. exceptions - are explicitly left open to implementers.
6.2 Motivating principles and use cases Issue 144: What constraints on user agents should be imposed for
user/granted exceptions
[OPEN] but mostly addressed in the proposal here.
6.2 Motivating Principles and Use Cases
This section is non-normative. This section is non-normative.
The following principles guide the design of user-agent-managed The following principles guide the design of user-agent-managed
exceptions. exceptions.
* Content providers may wish to prompt visitors to their properties to * Content providers may wish to prompt visitors to their properties to
"opt back in" to tracking for behavioral advertising or similar opt back in to tracking for behavioral advertising or similar purposes
purposes when they arrive with the Do Not Track setting enabled. when they arrive with the Do Not Track setting enabled.
* Privacy-conscious users may wish to view or edit all the exceptions * Privacy-conscious users may wish to view or edit all the exceptions
they've granted in a single, consistent user interface, rather than they've granted in a single, consistent user interface, rather than
managing preferences in a different way on every content provider or managing preferences in a different way on every content provider or
tracker's privacy page. tracker's privacy page.
* Granting an exception in one context (while browsing a news site) * Granting an exception in one context (while browsing a news site)
should not apply that exception to other contexts (browsing a medical should not apply that exception to other contexts (browsing a medical
site) that may not be expected. site) that may not be expected.
* Tracking providers should not ever have to second-guess a user's * Tracking providers should not ever have to second-guess a user's
expressed Do Not Track preference. expressed Do Not Track preference.
* The solution should not require cross-domain communication between a * The solution should not require cross-domain communication between a
first party publisher and its third parties. first-party publisher and its third parties.
When asking for a site-specific exception, the top-level domain making the When asking for a site-specific exception, the top-level domain making the
request may be making some implicit or explicit claims as to the actions request may be making some implicit or explicit claims as to the actions
and behavior of its third parties; for this reason, it might want to 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 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 are true. (Consider a site that has some trusted advertisers and analytics
providers, and some mashed-up content from less-trusted sites). For this providers, and some mashed-up content from less-trusted sites). For this
reason, there is support both for explicitly named sites, as well as 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 support for granting an exception to all third-parties on a given site
(site-wide exception, using the wild-card "*"). (site-wide exception, using the conceptual wild-card "*").
There are some cases in which a user may desire a site to be allowed to There are some cases in which a user may desire a site to be allowed to
track them on any top-level domain. An API is provided so that the site track them on any top-level domain. An API is provided so that the site
and the user may establish such a web-wide exception. and the user may establish such a web-wide exception.
6.3 Exception model 6.3 Exception model
6.3.1 Introduction 6.3.1 Introduction
This section describes the effect of the APIs in terms of a logical
processing model; this model describes the behavior, but should not be
read as mandating any specific implementation.
This API considers exceptions which are double-keyed to two domains: the This API considers exceptions which are double-keyed to two domains: the
site, and the target. A user might - for instance - want AnalytiCo to site, and the target. A user might - for instance - want AnalytiCo to be
track them on Example News, but not on Example Medical. To simplify allowed to track them on Example News, but not on Example Medical. To
language used in this API specification, we define two terms: simplify language used in this API specification, we define three terms:
* Top-Level Domain (TLD) is the domain name of the top-level document * Top-Level Domain (TLD) is the domain name of the top-level document
origin of this DOM: essentially the fully qualified domain name in the origin of this DOM: essentially the fully qualified domain name in the
address bar. For all these APIs, this must match the script origin. address bar.
* A target site is a domain name which is the target of an HTTP request, * A target site is a domain name which is the target of an HTTP request,
and which may be an origin for embedded resources on the indicated and which may be an origin for embedded resources on the indicated
top-level domain. top-level domain.
* The document origin of a script is the domain of origin of the
document that caused that script to be loaded (not necessarily the
same as the origin of the script itself).
For instance, if the document at For instance, if the document at
http://web.exnews.com/news/story/2098373.html references the resources http://web.exnews.com/news/story/2098373.html references the resources
http://exnews.analytico.net/1x1.gif and http://exnews.analytico.net/1x1.gif and
http://widgets.exsocial.org/good-job-button.js, the top-level domain is http://widgets.exsocial.org/good-job-button.js, the top-level domain is
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both
targets. targets.
ISSUE-112: How are sub-domains handled for site-specific exceptions? Issue 112: How are sub-domains handled for site-specific exceptions?
Should a request for a tracking exception apply to all subdomains of the
first party making the request? Or should a first party explicitly list [PENDING REVIEW] Should a request for a tracking exception apply to all
the subdomains that it's asking for? Similarly, should third party subdomains of the first party making the request? Or should a first party
subdomains be allowed (e.g. *.tracker.com)? explicitly list the subdomains that it's asking for? Similarly, should
third-party subdomains be allowed (e.g. *.tracker.com)?
Proposal: Exceptions are requested for fully-qualified domain names. Proposal: Exceptions are requested for fully-qualified domain names.
The domains that enter into the behavior of the APIs include: The domains that enter into the behavior of the APIs include:
* As described above, the Top-Level Domain (TLD); * As described above, the document origin active at the time of the
* The domain of the origin of the script; call, and;
* Domain names passed to the API; * Domain names passed to the API.
* Domains declared in the well-known resource as 'partners'.
Domains that enter into the decision over what DNT header to be sent in a
given HTTP request include:
* The top-level domain of the current context;
* The target of the HTTP request.
Note
Note that these strict, machine-discoverable, concepts may not match the Note that these strict, machine-discoverable, concepts may not match the
definitions of first and third party; in particular, sites themselves need definitions of first and third party; in particular, sites themselves need
to determine (and signal) when they get 'promoted' to first party by to determine (and signal) when they get 'promoted' to first party by
virtue of user interaction; the UA will not change the DNT header it sends virtue of user interaction; the UA will not change the DNT header it sends
them. them.
During the execution of these APIs, the top-level browsing domain and the The calls cause the following steps to occur:
domain origin of the script must match, otherwise no action is taken, and
an error value returned.
The calls causes the following steps to occur:
* First, the UA somehow confirms with the user that they agree to the * First, the UA somehow confirms with the user that they agree to the
grant of exception; grant of exception, if not already granted;
* If they agree, then the UA adds to its local database one or more * If they agree, then the UA adds to its local database one or more
site-pair duplets (top-level-domain, other-domain); one or other of site-pair duplets [document-origin, target]; one or other of these may
these may be a wild-card ("*"); be a wild-card ("*");
* While the user is browsing a given site [top-level domain], and a DNT * While the user is browsing a given site (top-level domain), and a DNT
header is to be sent to a target domain, if the duplet [top-level header is to be sent to a target domain, if the duplet [top-level
domain, target domain] matches any duplet in the database, then a domain, target domain] matches any duplet in the database, then a
DNT:0 header is sent, otherwise DNT:1 is sent. DNT:0 header is sent, otherwise DNT:1 is sent.
6.3.2 Exception use by browsers 6.3.2 Exception use by browsers
If a user wishes to be tracked by a target on the top-level domain, this If a user agrees to allow tracking by a target on the top-level domain,
should result in two user-agent behaviors: this should result in two user-agent behaviors:
1. If requests to the target for resources that are part of the DOM for 1. If requests to the target for resources that are part of the DOM for
pages on top-level domain include a DNT header, that header must be pages on top-level domain include a DNT header, that header must be
DNT:0. DNT:0.
2. Responses to the JavaScript API indicated should be consistent with 2. Responses to the JavaScript API indicated should be consistent with
this user preference (see below). this user preference (see below).
Issue 158: What is the effect of re-directs for content on the operation
of exceptions?
What is the effect of re-directs, when the source of the re-direct would What is the effect of re-directs, when the source of the re-direct would
get a different DNT header than the target, using these matching rules? get a different DNT header than the target, using these matching rules?
Proposal: The re-direct is not relevant; each site gets the DNT header
controlled by the list of grants.
Issue 159: How do we allow sites that mash-in add-supported content to
maintain their own trusted third parties?
This model does not support mashed-up content which is in turn supported
by ads; it's not clear how to distinguish between embedded content which
is embedding ads (and hence the top-level domain stays the same) and
embedded content that should start a new context.
Proposal: For this version of the specification, we don't address this
corner case.
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} has been granted, 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.
When a user-agent receives an API request for an exception that already
exists (i.e. the grant is recorded in its database), it should bypass
asking the user to confirm, and simply re-confirm the grant to the caller.
Note
It is left up to individual user-agent implementations how to determine It is left up to individual user-agent implementations how to determine
and how and whether to store users' tracking preferences. and how and whether to store users' tracking preferences.
When such an explicit list of domains is provided through the API, their When an explicit list of domains is provided through the API, their names
names might mean little to the user. The user might, for example, be told might mean little to the user. The user might, for example, be told that
that such-and-such top-level domain is asking for an exception for a such-and-such top-level domain is asking for an exception for a specific
specific set of sites, rather than listing them by name. set of sites, rather than listing them by name; or the user-agent may
decide to ask the user for a site-wide exception, effectively ignoring the
list of domain names, if supplied.
Conversely, if a wild-card is used, the user may be told that the Conversely, if a wild-card is used, the user may be told that the
top-level domain is asking for an exception for all third-parties that top-level domain is asking for an exception for all third-parties that
are, or will be, embedded in it. The API might fetch the list of sites are, or will be, embedded in it.
currently declared in the well-known URI as 'partners' as an example of
the third-parties involved, but it should be noted that the partners list,
and the set of embedded domains, might change after the API process is
complete, and that the wild-card in the database applies dynamically to
all sites that might be embedded, not just to the current 'partners' list.
ISSUE-111: Different DNT values to signify existence of user-granted Issue 111: Different DNT values to signify existence of user-granted
exception exception
Should the user agent send a different DNT value to a first party site if
there exist user-granted exceptions for that first party? (e.g. DNT:2
implies "I have Do Not Track enabled but grant permissions to some third
parties while browsing this domain")
Proposal: No, this API provides client-side means for sites to request
that information. Sites may also employ cookies to recall a user's past
response. Finally, a site may add [self, self] to the database as part of
its request, and it will then get DNT:0.
6.4 JavaScript API for site-specific exceptions [POSTPONED] Should the user agent send a different DNT value to a first
party site if there exist user-granted exceptions for that first party?
(e.g. DNT:2 implies "I have Do Not Track enabled but grant permissions to
some third parties while browsing this domain")
Proposal: A previous proposal was that it can add itself to the list (i.e.
an exception for [site, site]) and then it will get DNT:0, but DNT:0 to a
first party means something different (that it can pass data to third
parties, and tracking is permitted). It would be better to have an
indication in the DNT header that one or more site-specific exceptions
exist for the given target (i.e. that there is at least one duplet in the
database with target as its first host name), for example "DNT:1E" where E
means you are a first party with one or more active exceptions.
6.4 JavaScript API for Site-specific Exceptions
6.4.1 API to request site-specific exceptions 6.4.1 API to request site-specific exceptions
[NoInterfaceObject] [NoInterfaceObject]
interface NavigatorDoNotTrack { interface NavigatorDoNotTrack {
void requestSiteSpecificTrackingException (sequence<DOMString> arrayOfDomai nStrings, TrackingResponseCallback callback, optional siteName, optional expla nationString, optional detailURI); void requestSiteSpecificTrackingException (TrackingResponseCallback callbac k, optional sequence<DOMString> arrayOfDomainStrings, optional optional siteName , optional optional explanationString, optional optional detailURI);
}; };
6.4.1.1 Methods
requestSiteSpecificTrackingException requestSiteSpecificTrackingException
Called by a page to request or confirm a user-granted tracking Called by a page to request or confirm a user-granted tracking
exception. exception.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
arrayOfDomainStrings sequence<DOMString> * *
callback TrackingResponseCallback * * callback TrackingResponseCallback * *
siteName * * arrayOfDomainStrings sequence<DOMString> * *
explanationString * * siteName optional * *
detailURI * * explanationString optional * *
detailURI optional * *
Return type: void Return type: void
[Callback, NoInterfaceObject] [Callback, NoInterfaceObject]
interface TrackingResponseCallback { interface TrackingResponseCallback {
void handleEvent (boolean granted); void handleEvent (integer granted);
}; };
6.4.1.2 Methods
handleEvent handleEvent
The callback is called by the user agent to indicate the user's The callback is called by the user agent to indicate the user's
response. response.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
granted boolean * * granted integer * *
Return type: void Return type: void
The requestSiteSpecificTrackingException method takes two mandatory The requestSiteSpecificTrackingException method takes one mandatory
arguments: argument:
* arrayOfDomainStrings, a JavaScript array of strings, and
* callback, a method that will be called when the request is complete. * callback, a method that will be called when the request is complete.
It also takes three optional arguments: It also takes four optional arguments:
* siteName, a string for the name of the top-level domain (script * arrayOfDomainStrings, a JavaScript array of strings,
origin), * siteName, a user-readable string for the name of the top-level domain,
* explanationString, a short explanation of the request, and * explanationString, a short explanation of the request, and
* detailURI, a location at which further information about this request * detailURI, a location at which further information about this request
can be found. can be found.
Each string in arrayOfDomainStrings specifies a target. The special string If the request does not include the arrayOfDomainStrings, then this
"*" signifies all targets. When called, request is for a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target. When called,
requestSiteSpecificTrackingException must return immediately, then requestSiteSpecificTrackingException must return immediately, then
asynchronously determine whether the user grants the requested exceptions. asynchronously determine whether the user grants the requested
exception(s).
The granted parameter passed to the callback is the user's response; true If the list arrayOfDomainStrings is supplied, the user-agent may choose to
indicates the user grants an exception on top-level domain for all of the ask the user to grant a site-wide exception. If it does so, and the user
targets specified in arrayOfDomainStrings. The response false indicates agrees, it must indicate this in the response callback.
that the user does not want an exception on top-level domain for at least
one of the targets specified in arrayOfDomainStrings.
The execution of this API and the use of the resulting permission (if The execution of this API and the use of the resulting permission (if
granted) use the 'implicit' parameter, when the API is called, of the granted) use the 'implicit' parameter, when the API is called, the
domain of the origin of the script (script-origin). If permission is document origin. This forms the first part of the duplet in the logical
granted, then the set of duplets (one per DOMstring): model, and hence in operation will be compared with the top-level domain.
[top-level-domain, DOMstring] The granted parameter passed to the callback is the user's response; The
response
* 0 indicates that user does not grant the exception on top-level domain
for the indicated targets.
* 1 indicates the user grants an exception on top-level domain for the
specific targets.
* 2 indicates the user grants a site-wide exception on top-level domain
for all targets.
If permission is granted 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 granted for a site-wide exception, then the duplets:
[document-origin, * ]
is added to the database of remembered grants. is added to the database of remembered grants.
A particular response to the API - like a DNT response header - is only A particular response to the API - like a DNT response header - is only
valid immediately, and users' preferences may change. valid immediately, and users' preferences may change.
A user agent may use an interactive method to ask the user about their A user agent may use an interactive method to ask the user about their
preferences, so sites should not assume that the callback function will be preferences, so sites should not assume that the callback function will be
called immediately. called immediately.
6.4.2 API to cancel a site-specific exception 6.4.2 API to Cancel a Site-specific Exception
[NoInterfaceObject] [NoInterfaceObject]
interface NavigatorDoNotTrack { interface NavigatorDoNotTrack {
void removeSiteSpecificTrackingException (sequence<DOMString> arrayOfDomain Strings); boolean removeSiteSpecificTrackingException ();
}; };
6.4.2.1 Methods
removeSiteSpecificTrackingException removeSiteSpecificTrackingException
Ensures that the database of remembered grants no longer contains 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.
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-domain.
No parameters.
Return type: boolean
[top-level-domain, DOMstring] This returns a boolean indicating, when true, that the call has succeeded,
and that the database of grants no longer contains, or very soon will no
for all DOMstrings. This method never fails and there is no longer contain, the indicated grant(s); when false, some kind of
callback. After the call has been made, the indicated pairs are processing error occurred.
assured not to be in the database. The same matching as is used
for determining which header to send is used to detect which
entries (if any) to remove from the database.
Note that establishing [site, *] and then requesting removal of
[site, otherSite] simply leaves [site, *] in the database; the
removal request has no effect and does not establish "grant an
exception to everyone except otherSite".
Parameter Type Nullable Optional Description
arrayOfDomainStrings sequence<DOMString> * *
Return type: void
6.5 JavaScript API for web-wide exceptions
ISSUE-113: Should there be a JavaScript API to prompt for a Web-wide 6.5 JavaScript API for Web-wide Exceptions
exception?
PROPOSAL: In this section
6.5.1 API to request a web-wide exception 6.5.1 API to Request a Web-wide Exception
[NoInterfaceObject] [NoInterfaceObject]
interface NavigatorDoNotTrack { interface NavigatorDoNotTrack {
void requestWebWideTrackingException (TrackingResponseCallback callback, op tional siteName, optional explanationString, optional detailURI); void requestWebWideTrackingException (TrackingResponseCallback callback, op tional siteName, optional optional explanationString, optional optional detailU RI);
}; };
6.5.1.1 Methods
requestWebWideTrackingException requestWebWideTrackingException
If permission is granted, then the single duplet [ * ,
If permission is granted, then the single duplet document-origin] is added to the database of remembered grants.
[ * , top-level-domain]
is added to the database of remembered grants.
The parameters are as described above in the request for The parameters are as described above in the request for
site-specific exceptions. site-specific exceptions.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
callback TrackingResponseCallback * * callback TrackingResponseCallback * *
siteName * * siteName * *
explanationString * * explanationString optional * *
detailURI * * detailURI optional * *
Return type: void Return type: void
Users may wish to configure exceptions for a certain trusted tracker Users may wish to configure exceptions for a certain trusted tracker
across all sites. This API requests the addition of a web-wide grant for a across all sites. This API requests the addition of a web-wide grant for a
specific site, to the database. specific site, to the database.
6.5.2 API to cancel a web-wide exception 6.5.2 API to cancel a web-wide exception
[NoInterfaceObject] [NoInterfaceObject]
interface NavigatorDoNotTrack { interface NavigatorDoNotTrack {
void removeWebWideTrackingException (); boolean removeWebWideTrackingException ();
}; };
6.5.2.1 Methods
removeWebWideTrackingException removeWebWideTrackingException
Ensures that the database of remembered grants no longer contains Ensures that the database of remembered grants no longer contains
the duplet [ * , document-origin]. There is no callback. After the
[ * , top-level-domain] call has been made, the indicated pair is assured not to be in the
This method never fails and there is no callback. After the call
has been made, the indicated pair is assured not to be in the
database. The same matching as is used for determining which database. The same matching as is used for determining which
header to send is used to detect which entry (if any) to remove header to send is used to detect which entry (if any) to remove
from the database. from the database.
No parameters. No parameters.
Return type: void Return type: boolean
6.6 User interface guidelines This returns a boolean indicating, when true, that the call has succeeded,
and that the database of grants no longer contains, or very soon will no
longer contain, the indicated grant; when false, some kind of processing
error occurred.
6.6 Querying a host's exception status
Issue 160: Do we need an exception-query API?
It might be useful, and 'complete the model', if we had a JS API that told
a host what its current exception status is in a given context.
Proposal: Specifically, an API QueryExceptionStatus() which examines the
document origin of the script, the current top-level domain and returns an
empty string if no DNT header would be sent to that document origin, or
the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
6.7 User interface guidelines
This section is non-normative. This section is non-normative.
User agents are free to implement exception management user interfaces as User agents are free to implement exception management user interfaces as
they see fit. Some agents might provide a prompt to the user at the time they see fit. Some agents might provide a prompt to the user at the time
of the request. Some agents might allow users to configure this preference of the request. Some agents might allow users to configure this preference
in advance. In either case, the user agent responds with the user's in advance. In either case, the user agent responds with the user's
preference. preference.
A user agent that chooses to implement a prompt to present tracking A user agent that chooses to implement a prompt to present tracking
exception requests to the user might provide an interface like the exception requests to the user might provide an interface like the
following: following:
Example 10
Example News (web.exnews.com) would like to know Example News (web.exnews.com) would like to know
whether you permit tracking by a specific set of sites (click whether you permit tracking by a specific set of sites (click
here for their names). here for their names).
Example News says: Example News says:
"These sites allow Example News to see how we're These sites allow Example News to see how we're
doing, and provide useful features of the Example News doing, and provide useful features of the Example News
experience." [More info] experience. [More info]
[Allow Tracking] [Deny Tracking Request] [Allow Tracking] [Deny Tracking Request]
In this example, the domains listed are those specified in In this example, the domains listed are those specified in
arrayOfDomainStrings, the phrase "Example News" is from siteName, and the arrayOfDomainStrings, the phrase Example News is from siteName, and the
explanationString is displayed for the user with a "More info" link explanationString is displayed for the user with a More info link pointing
pointing to detailURI. to detailURI.
The user agent might then store that decision, and answer future requests The user agent might then store that decision, and answer future requests
based on this stored preference. A user agent might provide the user with based on this stored preference. A user agent might provide the user with
an interface to explicitly remove (or add) user-granted exceptions. an interface to explicitly remove (or add) user-granted exceptions.
Users might not configure their agents to have simple values for DNT, but Users might not configure their agents to have simple values for DNT, but
use different browsing modes or other contextual information to decide on use different browsing modes or other contextual information to decide on
a DNT value. What algorithm a user agent employs to determine DNT values 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. (or the lack thereof) is out of the scope of this specification.
In some user-agent implementations, decisions to grant exceptions may have In some user-agent implementations, decisions to grant exceptions may have
been made in the past (and since forgotten) or may have been made by other been made in the past (and since forgotten) or may have been made by other
users of the device. Thus, exceptions may not always represent the current users of the device. Thus, exceptions may not always represent the current
preferences of the user. Some user agents might choose to provide ambient 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 notice that user-opted tracking is ongoing, or easy access to view and
control these preferences. Users may desire options to edit exceptions control these preferences. Users may desire options to edit exceptions
either at the time of tracking or in a separate user interface. This might either at the time of tracking or in a separate user interface. This might
allow the user to edit their preferences for a site they do not trust allow the user to edit their preferences for a site they do not trust
without visiting that site. without visiting that site.
ISSUE-83: How do you opt out if already opted in? Issue 140: Do we need site-specific exceptions, i.e., concrete list of
PROPOSAL: In this section
ISSUE-129: Should a blanket exception of the type ["firstparty", "*"] be
possible?
PROPOSAL: In this section
ISSUE-130: Should a global exception for a given third party on all sites
be supported?
PROPOSAL: In this section
ISSUE-140: Do we need site-specific exceptions, i.e., concrete list of
permitted third parties for a site? permitted third parties for a site?
PROPOSAL: In this section; yes, as some sites may have a mix of
[PENDING REVIEW]: In this section; yes, as some sites may have a mix of
trusted/needed third parties, and others that either don't need to track, trusted/needed third parties, and others that either don't need to track,
or aren't as trusted, or both. or aren't as trusted, or both. But all sites are (a) told what they got
granted (list, or *) and (b) are assured that requests will be treated
'atomically'.
6.7 Exceptions without a DNT header 6.8 Exceptions without a DNT header
Sites might wish to request exceptions even when a user arrives without a Sites might wish to request exceptions even when a user arrives without a
DNT header. Users might wish to grant affirmative permission to tracking DNT header. Users might wish to grant affirmative permission to tracking
on or by certain sites even without expressing general tracking on or by certain sites even without expressing general tracking
preferences. preferences.
User agents may instantiate User agents may instantiate
NavigatorDoNotTrack.requestSiteSpecificTrackingException even when NavigatorDoNotTrack.requestSiteSpecificTrackingException even when
navigator.doNotTrack is null. Sites should test for the existence of navigator.doNotTrack is null. Sites should test for the existence of
requestSiteSpecificTrackingException before calling the method. If an requestSiteSpecificTrackingException before calling the method. If an
exception is granted in this context and the user-agent stores that exception is granted in this context and the user-agent stores that
preference, a user agent may send a DNT:0 header even if a tracking preference, a user agent may send a DNT:0 header even if a tracking
preference isn't expressed for other requests. Persisted preferences may preference isn't expressed for other requests. Persisted preferences may
also affect which header is transmitted if a user later chooses to express also affect which header is transmitted if a user later chooses to express
a tracking preference. a tracking preference.
Note
Users might not configure their agents to have simple values for DNT, but Users might not configure their agents to have simple values for DNT, but
use different browsing modes or other contextual information to decide on use different browsing modes or other contextual information to decide on
a DNT value. What algorithm a user agent employs to determine DNT values 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. (or the lack thereof) is out of the scope of this specification.
6.8 Fingerprinting 6.9 Fingerprinting
By storing a client-side configurable state and providing functionality to By storing a client-side configurable state and providing functionality to
learn about it later, this API might facilitate user fingerprinting and learn about it later, this API might facilitate user fingerprinting and
tracking. User agent developers ought to consider the possibility of tracking. User agent developers ought to consider the possibility of
fingerprinting during implementation and might consider rate-limiting fingerprinting during implementation and might consider rate-limiting
requests or using other heuristics to mitigate fingerprinting risk. User requests or using other heuristics to mitigate fingerprinting risk. User
agents should clear stored user-granted exceptions when the user chooses agents should clear stored user-granted exceptions when the user chooses
to clear cookies or other client-side state. to clear cookies or other client-side state.
A. Acknowledgements A. Acknowledgements
 End of changes. 167 change blocks. 
675 lines changed or deleted 708 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/