tpe_CR_20150321.txt   tpe_ED_20170830.txt 
W3C W3C
Tracking Preference Expression (DNT) Tracking Preference Expression (DNT)
W3C Candidate Recommendation 20 August 2015 W3C Editor's Draft 30 August 2017
This version: This version:
http://www.w3.org/TR/2015/CR-tracking-dnt-20150820/ https://w3c.github.io/dnt/drafts/tracking-dnt.html
Latest published version: Latest published version:
http://www.w3.org/TR/tracking-dnt/ https://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 https://w3c.github.io/dnt/drafts/tracking-dnt.html
Implementation report:
http://www.w3.org/2011/tracking-protection/track/products/7
Previous version: Previous editor's draft:
http://www.w3.org/TR/2014/WD-tracking-dnt-20140424/ https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
Editors: Editors:
Roy T. Fielding, Adobe Roy T. Fielding, Adobe
David Singer, Apple David Singer, Apple
Copyright © 2015 W3C^® (MIT, ERCIM, Keio, Beihang). W3C liability, Repository and Participation:
trademark and document use rules apply. Mailing list archive
Commit history
File a bug/issue
Copyright © 2017 W3C^® (MIT, ERCIM, Keio, Beihang). W3C liability,
trademark and permissive document license rules apply.
---------------------------------------------------------------------- ----------------------------------------------------------------------
Abstract Abstract
This specification defines the DNT request header field as an HTTP This specification defines the DNT request header field as an HTTP
mechanism for expressing the user's preference regarding tracking, an HTML mechanism for expressing a user's preference regarding tracking, an HTML
DOM property to make that expression readable by scripts, and APIs that DOM property to make that expression readable by scripts, and APIs that
allow scripts to register site-specific exceptions granted by the user. It allow scripts to register exceptions granted by the user. It also defines
also defines mechanisms for sites to communicate whether and how they mechanisms for sites to communicate whether and how they honor a received
honor a received preference through use of the Tk response header field preference, including well-known resources for retrieving preflight
and well-known resources that provide a machine-readable tracking status. tracking status, a media type for representing tracking status
information, and the Tk response header field for confirming tracking
status.
Status of This Document Status of This Document
This section describes the status of this document at the time of its This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports index at http://www.w3.org/TR/. can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the Tracking Protection Working Group as a
Candidate Recommendation on 20 August 2015. This document is intended to
become a W3C Recommendation. If you wish to make comments regarding this
document, please send them to public-tracking-comments@w3.org (subscribe,
archives). W3C publishes a Candidate Recommendation to indicate that the
document is believed to be stable and to encourage implementation by the
developer community. This Candidate Recommendation is expected to advance
to Proposed Recommendation no earlier than 20 November 2015. The Working
Group expects to have sufficient implementation experience by 20 February
2016. All comments are welcome.
Readers may review changes from the Last Call Working Draft; changes
include: moving JavaScript property to navigator; addition of a tracking
status value for gateways; clarifications of terminology; and updated
references. An issue tracking system is available for recording raised,
open, pending review, closed, and postponed issues regarding this
document. There is also a list of issues reported and addressed during the
Last Call period.
The following feature is at risk and might be cut from the specification
during the CR period if there are no (correct) implementations:
* DNT-extension This document is an editors' straw man reflecting a snapshot of live
discussions within the Tracking Protection Working Group. It does not
necessarily constitute working group consensus. This draft has been
prepared using the DNT github repository and its associated issues list.
However, see the previous issue tracking system for working group
decisions prior to 2017.
Please see the Working Group's implementation report. This document was published by the Tracking Protection Working Group as an
Editor's Draft. Comments regarding this document are welcome. Please send
them to public-tracking@w3.org (subscribe, archives).
Publication as a Candidate Recommendation does not imply endorsement by Publication as an Editor's Draft does not imply endorsement by the W3C
the W3C Membership. This is a draft document and may be updated, replaced Membership. This is a draft document and may be updated, replaced or
or obsoleted by other documents at any time. It is inappropriate to cite obsoleted by other documents at any time. It is inappropriate to cite this
this document as other than work in progress. document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 This document was produced by a group operating under the 5 February 2004
W3C Patent Policy. W3C maintains a public list of any patent disclosures W3C Patent Policy. W3C maintains a public list of any patent disclosures
made in connection with the deliverables of the group; that page also made in connection with the deliverables of the group; that page also
includes instructions for disclosing a patent. An individual who has includes instructions for disclosing a patent. An individual who has
actual knowledge of a patent which the individual believes contains actual knowledge of a patent which the individual believes contains
Essential Claim(s) must disclose the information in accordance with Essential Claim(s) must disclose the information in accordance with
section 6 of the W3C Patent Policy. section 6 of the W3C Patent Policy.
This document is governed by the 14 October 2005 W3C Process Document. This document is governed by the 1 March 2017 W3C Process Document.
Table of Contents Table of Contents
* 1. Introduction 1. Introduction
* 2. Terminology 2. Terminology
* 2.1 HTTP 2.1 HTTP
* 2.2 Activity 2.2 HTML
* 2.3 Participants 2.3 Activity
* 2.4 Data 2.4 Participants
* 2.5 Preferences 2.5 Data
* 3. Notational Conventions 3. Notational Conventions
* 3.1 Requirements 3.1 Requirements
* 3.2 Formal Syntax 3.2 Formal Syntax
* 4. Determining User Preference 4. Determining User Preference
* 5. Expressing a Tracking Preference 5. Expressing a Tracking Preference
* 5.1 Expression Format 5.1 Expression Format
* 5.2 DNT Header Field for HTTP Requests 5.2 DNT Header Field for HTTP Requests
* 5.2.1 DNT Extensions 5.2.1 Extensions to the DNT Field Value
* 5.3 JavaScript Property to Detect Preference 5.3 JavaScript Property to Detect Preference
* 5.4 Tracking Preference Expressed in Other Protocols 5.4 Tracking Preference Expressed in Other Protocols
* 6. Communicating a Tracking Status 6. User-Granted Exceptions
* 6.1 Overview 6.1 Overview
* 6.2 Tracking Status Value 6.2 Site-specific or Web-wide
* 6.2.1 Definition 6.3 Granting an Exception
* 6.2.2 Under Construction (!) 6.4 Checking for an Exception
* 6.2.3 Dynamic (?) 6.5 Revoking an Exception
* 6.2.4 Gateway (G) 6.6 Client-side Scripting API
* 6.2.5 Not Tracking (N) 6.6.1 API to Store a Tracking Exception
* 6.2.6 Tracking (T) 6.6.2 API to Remove a Tracking Exception
* 6.2.7 Consent (C) 6.6.3 API to Confirm a Tracking Exception
* 6.2.8 Potential Consent (P) 6.7 User Agent Management of Exceptions
* 6.2.9 Disregarding (D) 7. Communicating a Tracking Status
* 6.2.10 Updated (U) 7.1 Overview
* 6.3 Tk Header Field for HTTP Responses 7.2 Tracking Status Value
* 6.3.1 Definition 7.2.1 Definition
* 6.3.2 Referring to a Request-specific Tracking Status 7.2.2 Under Construction (!)
7.2.3 Dynamic (?)
7.2.4 Gateway (G)
7.2.5 Not Tracking (N)
7.2.6 Tracking (T)
7.2.7 Consent (C)
7.2.8 Potential Consent (P)
7.2.9 Disregarding (D)
7.2.10 Updated (U)
7.2.11 Extensions to the Tracking Status Value
7.3 Tk Header Field for HTTP Responses
7.3.1 Definition
7.3.2 Referring to a Request-specific Tracking Status
Resource Resource
* 6.3.3 Indicating an Interactive Status Change 7.3.3 Indicating an Interactive Status Change
* 6.4 Tracking Status Resource 7.4 Tracking Status Resource
* 6.4.1 Site-wide Tracking Status 7.4.1 Site-wide Tracking Status
* 6.4.2 Request-specific Tracking Status 7.4.2 Request-specific Tracking Status
* 6.4.3 Status Checks are Not Tracked 7.4.3 Status Checks are Not Tracked
* 6.4.4 Caching 7.4.4 Caching
* 6.5 Tracking Status Representation 7.5 Tracking Status Representation
* 6.5.1 Status Object 7.5.1 Status Object
* 6.5.2 Tracking Property 7.5.2 Tracking Property
* 6.5.3 Compliance Property 7.5.3 Compliance Property
* 6.5.4 Qualifiers Property 7.5.4 Qualifiers Property
* 6.5.5 Controller Property 7.5.5 Controller Property
* 6.5.6 Same-party Property 7.5.6 Same-party Property
* 6.5.7 Audit Property 7.5.7 Audit Property
* 6.5.8 Policy Property 7.5.8 Policy Property
* 6.5.9 Config Property 7.5.9 Config Property
* 6.5.10 Extensions 7.5.10 Extensions to the Status Object
* 6.6 Status Code for Tracking Required 7.6 Status Code for Tracking Required
* 6.7 Using the Tracking Status 8. Use Cases
* 6.7.1 Discovering Deployment 8.1 Discovering Deployment
* 6.7.2 Preflight Checks 8.2 Preflight Checks
* 7. User-Granted Exceptions 9. Security Considerations
* 7.1 Overview 10. Privacy Considerations
* 7.2 Motivating Principles and Use Cases 10.1 Why DNT:1 is Not Preconfigured by Default
* 7.3 Exception Model 10.2 Fingerprinting
* 7.3.1 User Interaction 10.3 Stored Exceptions are Stored History
* 7.3.2 Processing Model A. Acknowledgements
* 7.4 Site-specific Exceptions B. Registrations
* 7.4.1 API to Request a Site-specific Exception C. References
* 7.4.2 API to Cancel a Site-specific Exception C.1 Normative references
* 7.4.3 API to Confirm a Site-specific Exception C.2 Informative references
* 7.5 Web-wide Exceptions
* 7.5.1 API to Request a Web-wide Exception
* 7.5.2 API to Cancel a Web-wide Exception
* 7.5.3 API to Confirm a Web-wide Exception
* 7.6 User Interface Guidelines
* 7.7 Exceptions without Interactive JavaScript
* 7.8 Exceptions without an Expressed Preference
* 7.9 Exception Use by Sites
* 7.10 Fingerprinting
* A. Acknowledgements
* B. Registrations
* C. References
* C.1 Normative references
* C.2 Informative references
1. Introduction 1. Introduction
The World Wide Web consists of billions of resources interconnected The World Wide Web consists of billions of resources interconnected
through the use of hypertext. Hypertext provides a simple, page-oriented through the use of hypertext. Hypertext provides a simple, page-oriented
view of the information provided by those resources, which can be view of the information provided by those resources, which can be
traversed by selecting links, manipulating controls, and supplying data traversed by selecting links, manipulating controls, and supplying data
via forms and search dialogs. via forms and search dialogs.
A Web page is often composed of many information sources beyond the A Web page is often composed of many information sources beyond the
skipping to change at line 208 skipping to change at line 195
connects a user's activity across multiple pages. A survey of these connects a user's activity across multiple pages. A survey of these
techniques and their privacy implications can be found in [KnowPrivacy]. techniques and their privacy implications can be found in [KnowPrivacy].
Users need a mechanism to express their own preferences regarding tracking Users need a mechanism to express their own preferences regarding tracking
that is both simple to configure and efficient when implemented. However, that is both simple to configure and efficient when implemented. However,
merely expressing a preference does not imply that all recipients will merely expressing a preference does not imply that all recipients will
comply. In some cases, a server might be dependent on some forms of comply. In some cases, a server might be dependent on some forms of
tracking and unwilling or unable to turn that off. In other cases, a tracking and unwilling or unable to turn that off. In other cases, a
server might perform only limited forms of tracking that would be server might perform only limited forms of tracking that would be
acceptable to most users. Therefore, servers need mechanisms for acceptable to most users. Therefore, servers need mechanisms for
communicating their own tracking behavior, requesting an exception to a communicating their own tracking behavior, requesting consent, and storing
user's general preference, and storing such a user-granted exception after a user-granted exception once the user has made an informed choice.
the user has made an informed choice.
This specification extends Hypertext Transfer Protocol (HTTP) semantics This specification extends Hypertext Transfer Protocol (HTTP) semantics
[RFC7231] to communicate a user's tracking preference, if any, and an [RFC7231] to communicate a user's tracking preference, if any, and an
origin server's tracking behavior. The DNT request header field is defined origin server's tracking behavior. The DNT request header field is defined
for communicating the user's tracking preference for the target resource. for communicating the user's tracking preference for the target resource.
A well-known URI for a tracking status resource and the Tk response header A well-known URI for a tracking status resource and the Tk response header
field are defined for communicating the server's tracking behavior. In field are defined for communicating the server's tracking behavior. In
addition, JavaScript APIs are defined for enabling scripts to determine addition, JavaScript APIs are defined for enabling scripts to determine
DNT status and register a user-granted exception. DNT status and register a user-granted exception.
skipping to change at line 236 skipping to change at line 222
regime defines its own requirements on compliant behavior. For example, regime defines its own requirements on compliant behavior. For example,
[TCS] is a work-in-progress that intends to define such a compliance [TCS] is a work-in-progress that intends to define such a compliance
regime. regime.
2. Terminology 2. Terminology
2.1 HTTP 2.1 HTTP
The following terms are used as defined by HTTP/1.1 syntax [RFC7230] and The following terms are used as defined by HTTP/1.1 syntax [RFC7230] and
semantics [RFC7231]: client, server, origin server, user agent, sender, semantics [RFC7231]: client, server, origin server, user agent, sender,
recipient, request, response, message, intermediary, proxy, cache, header recipient, request, response, message, intermediary, proxy, cache,
field, target resource, resource, and representation. uri-host, authority, header field, target resource, resource, and
representation.
2.2 Activity 2.2 HTML
The following terms are used as defined by HTML [HTML5]: active document,
document.domain, effective script origin, responsible document, browsing
context, nested browsing context, and top-level browsing context.
2.3 Activity
Tracking is the collection of data regarding a particular user's activity Tracking is the collection of data regarding a particular user's activity
across multiple distinct contexts and the retention, use, or sharing of across multiple distinct contexts and the retention, use, or sharing of
data derived from that activity outside the context in which it occurred. data derived from that activity outside the context in which it occurred.
A context is a set of resources that are controlled by the same party or A context is a set of resources that are controlled by the same party or
jointly controlled by a set of parties. jointly controlled by a set of parties.
A network interaction is a single HTTP request and its corresponding A network interaction is a single HTTP request and its corresponding
response(s): zero or more interim (1xx) responses and a single final response(s): zero or more interim (1xx) responses and a single final
(2xx-5xx) response. (2xx-5xx) response.
A user action is a deliberate action by the user, via configuration, A user action is a deliberate action by the user, via configuration,
invocation, or selection, to initiate a network interaction. Selection of invocation, or selection, to initiate a network interaction. Selection of
a link, submission of a form, and reloading a page are examples of user a link, submission of a form, and reloading a page are examples of user
actions. User activity is any set of such user actions. actions. User activity is any set of such user actions.
2.3 Participants 2.4 Participants
A user is a natural person who is making, or has made, use of the Web. A user is a natural person who is making, or has made, use of the Web.
A party is a natural person, a legal entity, or a set of legal entities A party is a natural person, a legal entity, or a set of legal entities
that share common owner(s), common controller(s), and a group identity that share common owner(s), common controller(s), and a group identity
that is easily discoverable by a user. Common branding or providing a list that is easily discoverable by a user. Common branding or providing a list
of affiliates that is available via a link from a resource where a party of affiliates that is available via a link from a resource where a party
describes DNT practices are examples of ways to provide this describes DNT practices are examples of ways to provide this
discoverability. discoverability.
skipping to change at line 309 skipping to change at line 302
1. processes the data on behalf of the contractee; 1. processes the data on behalf of the contractee;
2. ensures that the data is only retained, accessed, and used as directed 2. ensures that the data is only retained, accessed, and used as directed
by the contractee; by the contractee;
3. has no independent right to use the data other than in a permanently 3. has no independent right to use the data other than in a permanently
de-identified form (e.g., for monitoring service integrity, load de-identified form (e.g., for monitoring service integrity, load
balancing, capacity planning, or billing); and, balancing, capacity planning, or billing); and,
4. has a contract in place with the contractee which is consistent with 4. has a contract in place with the contractee which is consistent with
the above limitations. the above limitations.
2.4 Data 2.5 Data
A party collects data received in a network interaction if that data A party collects data received in a network interaction if that data
remains within the party’s control after the network interaction is remains within the party’s control after the network interaction is
complete. complete.
A party uses data if the party processes the data for any purpose other A party uses data if the party processes the data for any purpose other
than storage or merely forwarding it to another party. than storage or merely forwarding it to another party.
A party shares data if it transfers or provides a copy of that data to any A party shares data if it transfers or provides a copy of that data to any
other party. other party.
Data is permanently de-identified when there exists a high level of Data is permanently de-identified when there exists a high level of
confidence that no human subject of the data can be identified, directly confidence that no human subject of the data can be identified, directly
or indirectly (e.g., via association with an identifier, user agent, or or indirectly (e.g., via association with an identifier, user agent, or
device), by that data alone or in combination with other retained or device), by that data alone or in combination with other retained or
available information. available information.
2.5 Preferences
A user-granted exception is a specific tracking preference, overriding a
user's general tracking preference, that has been obtained and recorded
using the mechanisms defined in section 7. User-Granted Exceptions.
3. Notational Conventions 3. Notational Conventions
3.1 Requirements 3.1 Requirements
The key words must, must not, required, should, should not, recommended, The key words must, must not, required, should, should not, recommended,
may, and optional in this specification are to be interpreted as described may, and optional in this specification are to be interpreted as described
in [RFC2119]. in [RFC2119].
3.2 Formal Syntax 3.2 Formal Syntax
This specification uses the Augmented Backus-Naur Form (ABNF) notation of This specification uses the Augmented Backus-Naur Form (ABNF) notation of
[RFC5234] to define network protocol syntax and WebIDL [WEBIDL] to define [RFC5234] to define network protocol syntax and WebIDL [WEBIDL] to define
scripting APIs. Conformance criteria and considerations regarding error scripting APIs. Conformance criteria and considerations regarding error
handling are defined in Section 2.5 of [RFC7230]. handling are defined in Section 2.5 of [RFC7230].
How to throw a DOMexception and the exceptions named "InvalidStateError",
"SecurityError", and "SyntaxError" are defined in [WEBIDL].
Promise objects are defined in [ECMASCRIPT]; the phrases promise-call,
resolve promise, reject promise, upon fulfillment, and upon rejection are
used in accordance with [PromiseGuide].
4. Determining User Preference 4. 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 recipients of that preference communicate with via HTTP, thereby allowing recipients of that preference
to adjust tracking behavior accordingly or to reach a separate agreement to adjust tracking behavior accordingly or to reach a separate agreement
with the user that satisfies all parties. with the user that satisfies all parties.
Key to that notion of expression is that the signal sent MUST reflect the Key to that notion of expression is that the signal sent MUST reflect the
user's preference, not the choice of some vendor, institution, site, or user's preference, not the choice of some vendor, institution, site, or
network-imposed mechanism outside the user's control; this applies equally network-imposed mechanism outside the user's control; this applies equally
to both the general preference and exceptions. The basic principle is that to both the general preference and exceptions. The basic principle is that
a tracking preference expression is only transmitted when it reflects a 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 (see section 10.1 Why DNT:1 is Not
Preconfigured by Default).
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 DNT:1. A user agent MAY offer a third Do Not Track preference: unset or DNT:1. A user agent MAY offer a third
alternative choice: DNT:0. alternative choice: DNT:0.
If the user's choice is DNT:1 or DNT:0, the tracking preference is If the user's choice is DNT:1 or DNT:0, the tracking preference is
enabled; otherwise, the tracking preference is not enabled. 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 user's enabled) unless a specific tracking preference is implied by the user's
skipping to change at line 444 skipping to change at line 439
5. Expressing a Tracking Preference 5. Expressing a Tracking Preference
5.1 Expression Format 5.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. expressed to all mechanisms that might perform or initiate tracking.
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 site. 1 This user prefers not to be tracked on this request.
0 This user prefers to allow tracking on the target site. 0 This user prefers to allow tracking on this request.
A user agent MUST NOT send a tracking preference expression if a tracking A user agent MUST NOT send a tracking preference expression if a tracking
preference is not enabled. This means that no expression is sent for each preference is not enabled. This means that no expression is sent for each
of the 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 transmit 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
skipping to change at line 480 skipping to change at line 475
DNT-field-name = "DNT" DNT-field-name = "DNT"
DNT-field-value = ( "0" / "1" ) *DNT-extension DNT-field-value = ( "0" / "1" ) *DNT-extension
A user agent MUST NOT generate a DNT header field if the user's tracking A user agent MUST NOT generate a DNT header field if the user's tracking
preference is not enabled. preference is not enabled.
A user agent MUST generate a DNT header field with a field-value that A user agent MUST generate a DNT header field with a field-value that
begins with the numeric character "1" if the user's tracking preference is begins with the numeric character "1" if the user's tracking preference is
enabled, their preference is for DNT:1, and no exception has been granted enabled, their preference is for DNT:1, and no exception has been granted
for the request target (see section 7. User-Granted Exceptions). for the target resource (see section 6. User-Granted Exceptions).
A user agent MUST generate a DNT header field with a field-value that A user agent MUST generate a DNT header field with a field-value that
begins with the numeric character "0" if the user's tracking preference is begins with the numeric character "0" if the user's tracking preference is
enabled and their preference is for DNT:0, or if an exception has been enabled and their preference is for DNT:0, or if an exception has been
granted for the request target. granted for the target resource.
A proxy MUST NOT generate a DNT header field unless it has been A proxy MUST NOT generate a DNT header field unless it has been
specifically installed or configured to do so by the user making the specifically installed or configured to do so by the user making the
request and adheres to the above requirements as if it were a user agent. request and adheres to the above requirements as if it were a user agent.
Example 1 Example 1
GET /something/here HTTP/1.1 GET /something/here HTTP/1.1
Host: example.com Host: example.com
DNT: 1 DNT: 1
5.2.1 DNT Extensions 5.2.1 Extensions to the DNT Field Value
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. DNT extensions can only be transmitted reserved for future extensions. DNT extensions can only be transmitted
when a tracking preference is enabled. The extension syntax is restricted when a tracking preference is enabled. The extension syntax is restricted
to visible ASCII characters that can be parsed as a single word in HTTP to visible ASCII characters that can be parsed as a single word in HTTP
and safely embedded in a JSON string without further encoding (section 6.5 and safely embedded in a JSON string without further encoding (section 7.5
Tracking Status Representation). Tracking Status Representation).
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
For example, additional characters might indicate modifiers to the main For example, additional characters might indicate modifiers to the main
preference expressed by the first digit, such that the main preference preference expressed by the first digit, such that the main preference
will be understood if the recipient does not understand the extension. will be understood if the recipient does not understand the extension.
Hence, a field-value of "1xyz" can be thought of as do not track, but if Hence, a field-value of "1xyz" can be thought of as do not track, but if
you understand the refinements defined by x, y, or z, then adjust my you understand the refinements defined by x, y, or z, then adjust my
preferences according to those refinements. preferences according to those refinements.
User agents that do not implement DNT extensions MUST NOT send User agents that do not implement DNT extensions MUST NOT send
DNT-extension characters in the DNT field-value. Servers that do not DNT-extension characters in the DNT field-value. Servers that do not
implement DNT extensions SHOULD ignore anything beyond the first implement DNT extensions SHOULD ignore anything beyond the first
character. character.
Note Note
The DNT-extension feature is considered at-risk. Since no extensions have This DNT-extension feature is speculative because no known extensions have
been defined, implementors that don't read specifications are likely to been defined; implementers that do not read this specification are likely
assume that DNT only has the fixed values of "0" or "1". Furthermore, the to assume that DNT only has the fixed values of "0" or "1". Furthermore,
potential benefits of this mechanism are unclear given that extension the potential benefits of this mechanism are unclear given that extension
information could be supplied using separate request header fields. information could be supplied using separate request header fields.
Inappropriate extensions to the "1" value might cause the user's requests
to be more easily fingerprinted.
5.3 JavaScript Property to Detect Preference 5.3 JavaScript Property to Detect Preference
The doNotTrack property enables a client-side script with read access to The Navigator.doNotTrack property enables a client-side script with read
the Navigator object to determine what DNT header field value would be access to the Navigator object [HTML5] to determine what DNT header field
sent in requests to the document-origin, taking into account the user's value would be sent to the effective script origin, taking into account
general preference (if any) and any user-granted exceptions applicable to the user's general preference (if any) and user-granted exceptions
that origin server. applicable to the target domain when referenced by the active document's
top-level browsing context.
partial interface Navigator { partial interface Navigator {
readonly attribute DOMString? doNotTrack; readonly attribute DOMString? doNotTrack;
}; };
doNotTrack of type DOMString, readonly , nullable The value is null if no DNT header field would be sent (e.g., because a
Returns the same string value that would be sent in a tracking preference is not enabled and no user-granted exception is
DNT-field-value (section 5.2 DNT Header Field for HTTP Requests) applicable); otherwise, the value is a string beginning with "0" or "1",
to a target that is the document-origin of the window, in the possibly followed by DNT-extension characters.
browser context of the current top-level origin. The value is null
if no DNT header field would be sent (e.g., because a tracking Specifically, the value of Navigator.doNotTrack for a given script is
preference is not enabled); otherwise, the value is a string either null or the string value that would be sent in a DNT field-value
beginning with "0" or "1", possibly followed by DNT-extension (section 5.2 DNT Header Field for HTTP Requests) in a request to a target
characters. resource at the effective script origin (the current document.domain of
the script's responsible document) when that request is due to an embedded
reference from this site (the document.domain of the top-level browsing
context's active document).
Ideally, the value of Navigator.doNotTrack ought to reflect the current
set of user-granted exceptions in effect when the attribute is read. In
practice, however, the value might only reflect the value that was in
effect when the script was initiated.
5.4 Tracking Preference Expressed in Other Protocols 5.4 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. However, it is of the protocols being used for Internet communication. However, it is
beyond the scope of this specification to define how a user's tracking beyond the scope of this specification to define how a user's tracking
preference might be communicated via protocols other than HTTP. preference might be communicated via protocols other than HTTP.
6. Communicating a Tracking Status 6. User-Granted Exceptions
6.1 Overview 6.1 Overview
Content providers might wish to prompt visitors to opt in to tracking for
behavioral advertising or similar purposes when they arrive with the Do
Not Track setting enabled. However, granting an exception in one context
(e.g., while browsing a news site) does not imply that exception is
applicable to other contexts (e.g., browsing an unrelated medical site).
Furthermore, users might wish to view or edit all the exceptions they've
granted in a single, consistent user interface, rather than managing
preferences in a different way on every content provider or tracker's
privacy page.
A user-granted exception is the record of a decision by the user to grant
consent for tracking (DNT:0) on future requests from a given site to a set
of target domains. Both site and target are scoped by domain, similar to
the existing domain scope of cookies (Section 5.3.1 of [HTML5]), to avoid
prompting the user for every subdomain of a site and every target resource
that might be referenced.
A client-side database can be used for persistent storage of user-granted
exceptions, such that permission to send DNT:0 is obtained by a site and
stored via a JavaScript API. However, we only define the API (below); the
choice of storage mechanism is left to each implementation. In comparison
to the use of cookies to manage consent, an exception database and APIs
provide more transparency and better user control, while also providing
better persistence of those exceptions for sites.
6.2 Site-specific or Web-wide
There are three domain concepts involved in the processing of user-granted
exceptions:
site domain
the domain associated with a site on which a given reference might
be found and for which the user-granted exceptions API might be
queried: specifically, the current document.domain of the
top-level browsing context's active document [HTML5].
target domain
the uri-host subcomponent of the authority component of a
referenced "http" or "https" URI [RFC7230].
script domain
the effective domain of a script when it uses the exception API:
specifically, the current document.domain of the script's
responsible document [HTML5].
A user-granted exception is site-specific if the exception is limited to
requests embedded in, or referred by, a given site domain; otherwise, the
exception is web-wide because it applies to the target domain regardless
of the referring site. For example, a user might wish to grant a certain
target domain a web-wide exception for the purpose of audience measurement
across multiple sites, perhaps in exchange for some incentive.
When asking for consent to record a site-specific exception, a site might
make some claims regarding limitations on the actions and behavior of the
known third parties that it references. Such a site might wish to restrict
its site-specific exceptions to only target domains for which those claims
have been verified. (For example, consider the dilemma of a site that has
trusted advertisers and analytics providers, along with some less trusted
mashed-up content that might reference other sites). For this reason,
site-specific exceptions can be limited to the script domain, limited to a
named set of target domains, or be applicable to any target domain ("*").
6.3 Granting an Exception
It is expected that a site will explain to the user, in its online
content, the need for an exception and the consequences of granting or
denying that exception. Upon receipt of an informed consent from the user,
a script operating on the site's page is expected to promise-call the
Navigator.storeTrackingException API using parameters consistent with the
consent granted by the user.
A site MUST ensure that a call to store an exception reflects the user's
intention to grant an exception at the time of that call. It is the sole
responsibility of the site to determine that a call to record an exception
reflects the user's informed consent at the time of that call.
Third party target domains that might wish to receive a user-granted
exception often do not have the ability to invoke an interactive
JavaScript presence on a page (for example, those that provide only images
or "tracking pixels"). They cannot request an exception under these
circumstances, either because a script is needed to make the API call or
it requires interaction to ensure the user is informed and to receive an
indication of their consent. In general, this process of informing,
getting consent, and calling the API is not expected within page elements
where such trackers are invoked.
A first party site's page (the top-level browsing context) might be used
to obtain site-specific consent for multiple parties; e.g., using multiple
iframe elements containing scripts that can convey information about each
party's policies and obtain specific consent for each party. In this case,
the effective script origin might be different from the site for which
consent is being granted.
Alternatively, a third party might encourage the user to visit their own
site directly in order to engage in a consent dialog and make use of the
API to store a web-wide exception.
A site can request an exception be stored even when the user's general
preference is not enabled. This permits the sending of DNT only for target
resources for which an expressed preference is desired. Stored exceptions
could affect which preference is transmitted if a user later chooses to
configure a general tracking preference.
A user agent might not store the exception immediately, possibly because
it is allowing the user to confirm. Even though the site has acquired the
user's informed consent before calling the store API, it is possible that
the user will change their mind, allow the storing of an exception to
proceed but later remove it, or perhaps deny the storage by prior
configuration. Nonetheless, at the time of a call, the site has acquired
the user's consent and can proceed on that basis whether or not the user
agent has stored an exception.
6.4 Checking for an Exception
A site can promise-call the Navigator.trackingExceptionExists API to
enquire whether a set of exceptions has been granted and stands in the
user agent. If the promise resolves to false (indicating the exception set
has expired, been deleted, or has not yet been stored), the user can be
asked again for consent.
A user agent is expected to query the exceptions database at the time of a
request in order to determine what value (if any) to send as the user's
tracking preference.
* While the user is browsing a given site, if the duplet [site domain,
target domain] matches any duplet in the database, then a DNT:0
preference is sent, otherwise the user’s general preference is sent
(if any).
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A
pair of values A and X match if and only if one of the following is true:
* either A or X is "*";
* A and X are the same string;
* A has the form '*.domain' and X is 'domain' or is of the form
'string.domain', where 'string' is any sequence of characters.
For example, a user might grant an exception for metrics.example.net to
track their activity on news.example.com and weather.example.com, but not
on medical.example.org. If the document at
http://news.example.com/news/story/2098373.html has embedded references to
http://metrics.example.net/1x1.gif and
http://weather.example.com/widget.js, the site domain for those references
is news.example.com and the target domains are metrics.example.net and
weather.example.com, respectively.
A user agent MAY choose to disregard a user-granted exception when the
target resource does not have a corresponding tracking status resource
with a valid tracking status representation, since that would imply the
target resource does not conform to this specification.
6.5 Revoking an Exception
A site that stores exceptions is also expected to enable revocation of
those exceptions. The Navigator.removeTrackingException API can be
promise-called by a script to remove all exceptions applicable to that
site.
A site MAY monitor for changes to its user-granted exceptions. If a user
revokes consent by deleting an exception, the site MUST respect that
revocation, though it MAY ask again for a new exception. In other words, a
site MUST NOT resurrect a deleted exception without first interacting with
and receiving new consent from the user.
6.6 Client-side Scripting API
6.6.1 API to Store a Tracking Exception
When a site has obtained consent for a user-granted exception, a script
running within an active browsing context or nested browsing context of
that site can promise-call Navigator.storeTrackingException to store one
or more tracking exceptions. A TrackingExData object is supplied as a
parameter to define the exception's scope (the set of [site, target]
duplets that encompass the granted exception) and optional information to
be stored for that exception. The call returns a promise which either
resolves to a TrackingExResult or is rejected with a DOMException
identifying the reason for the failure.
partial interface Navigator {
Promise<TrackingExResult> storeTrackingException(TrackingExData
properties);
};
dictionary TrackingExData {
DOMString? site;
sequence<DOMString>? targets;
DOMString? name;
DOMString? explanation;
DOMString? details;
long? maxAge;
};
dictionary TrackingExResult {
boolean isSiteWide;
};
Navigator.storeTrackingException passes a TrackingExData object. A user
agent MUST ignore unknown properties of the TrackingExData object (for
future extensibility). The following OPTIONAL properties are defined:
site
The referring domain scope for which the exception applies:
* If site is undefined, null, or the empty string, the
exception's referring domain scope defaults to the script
domain.
* If site is defined and equal to "*", the exception is
intended to be web-wide for the set of targets. A user agent
MUST reject the promise with the DOMException named
"SecurityError" if both site and any of the targets are "*".
* Otherwise, the exception's referring domain scope is defined
by a domain found in site that is treated in the same way as
the domain parameter to cookies [RFC6265], allowing
subdomains to be included with the prefix "*.". The value can
be set to a fully-qualified right-hand segment of the
document host name, up to one level below TLD.
targets
An array of target domains for which the exception applies:
* If targets is undefined or null, the user-granted exception
to be stored is [site, *], meaning that the exception applies
to all domains referenced by the site.
* If targets is an empty array, the user-granted exception to
be stored is [site, script domain], meaning that the
exception applies only to resources that share the same
domain as the effective script origin.
* Otherwise, for each domain string in the targets array, a
user-granted exception to be stored is the duplet
[site, domain].
name
When defined and not null or an empty string, name is a
user-readable string for naming the exception, usually descriptive
of the targets or their intended purpose for this site.
explanation
When defined and not null or an empty string, explanation is a
user-readable short explanation of the granted exception.
details
When defined and not null or an empty string, details is a URI
reference at which further information about the granted exception
can be found [RFC3986].
maxAge
When defined and not null, maxAge is a positive number of seconds
indicating the maximum lifetime of the grant:
* If maxAge is supplied and not null, empty, or negative, the
user agent MUST remove the stored exception no later than the
specified number of seconds after being stored.
* If maxAge is not supplied, the user agent MAY retain the
stored grant indefinitely.
The properties name, explanation, and details are provided by the caller
for the sake of potential user interfaces. If a user agent presents these
properties to the user, it ought to be clear that they are provided for
informational value and are less important than the exception's technical
effect.
In addition to the data above, a user agent might also store ambient
information about the call, such as the URI associated with the top-level
browsing context, the effective script origin, a current timestamp, or
other information potentially obtained from applicable tracking status
resources.
The calling script domain MUST have a site-wide tracking status resource
with a valid tracking status representation that includes a policy
property. This allows a user agent to obtain and possibly store additional
information about the caller’s controller and tracking policies at the
time an exception is granted.
A user agent MAY reject the promise with a DOMException named
"InvalidStateError" if it cannot determine the effective script origin or
if the site corresponding to that origin does not have a site-wide
tracking status resource with a valid tracking status representation.
For each site-specific exception being stored, a user agent MUST NOT store
the duplets and MUST reject the promise with a DOMException named
"SecurityError" if the script would not be able to set a cookie on that
duplet's referring domain scope following the cookie domain rules
[RFC6265].
For example, a script on www.foo.bar.example.com can set the site as
"bar.example.com" or "example.com", but not to
"something.else.example.com" or "com".
For each web-wide exception being stored, a user agent MUST NOT store the
duplets and MUST reject the promise with a DOMException named
"SecurityError" if the script would not be able to set a cookie on that
target domain following the cookie domain rules [RFC6265]. This limits
storing of a web-wide exception to scripts that share the same domain
scope as the exception targets, but allows such scripts to be embedded
within iframes of a common consent portal.
For any other failure, such as an incorrectly formatted parameter in the
TrackingExData, the user agent MUST NOT store any of the target duplets in
the database and MUST reject the promise with a DOMException named
"SyntaxError".
Upon fulfillment, the user agent has added to its local database one or
more site-pair duplets [site, target], each indicating that a request from
that site domain to the target domain will include DNT:0 regardless of the
user's general tracking preference. The fulfilled promise object contains
the following TrackingExResult attribute:
isSiteWide
true if the user agent stored a potentially broader exception that
applies to all domains (as opposed to just the listed targets);
otherwise, false.
When a list of targets is supplied for a site-specific exception, the user
agent MAY ignore that list, choosing instead to store a site-specific
exception for all domains ([site, *]), if it also indicates that result by
setting the returned promise's isSiteWide property to true.
User agents MAY instantiate Navigator.storeTrackingException even when
Navigator.doNotTrack is null. Scripts SHOULD test for the existence of
Navigator.storeTrackingException before calling the method.
Note
There are some security concerns here regarding the ability of a script
with an effective script origin matching one site being able to persist
the DNT value received by resources on other (target) sites. In
particular, this feature could be abused to set/unset an array of
exceptions, similar to an array of bit values, and be "read" as a
persistent identifier by embedding requests to those domains (which might
all point to the same Internet host). However, we expect that would leave
an obvious trail on the user agent, unlike other sources of
fingerprinting.
Likewise, allowing an exception to be stored within an iframe of another
site's page could be ripe for abuse unless the calling script ensures that
it is being run within a page where it expects to be collecting user
consent and where the context of that consent is consistent with the
exceptions being stored.
This design is consistent with the fact that there is no technical
restraint from sites calling the API without having first obtained an
informed consent from the user. We are assuming that the social and
regulatory environment will be sufficient to punish those who might misuse
the API or abuse the scope of stored exceptions. A user agent might
further limit such risks by checking for a site-wide tracking status
resource when its presence is required by the API.
6.6.2 API to Remove a Tracking Exception
When a site decides, or has been directed by the user, to revoke a
user-granted exception, a script running within an active browsing context
or nested browsing context of that site can promise-call
Navigator.removeTrackingException to remove one or more tracking
exceptions. A TrackingExData object is supplied as a parameter to identify
which exceptions are to be removed. The call returns a promise which
either resolves to indicate success or is rejected with a DOMException
identifying the reason for the failure.
partial interface Navigator {
Promise<void> removeTrackingException(TrackingExData properties);
};
Navigator.removeTrackingException passes a TrackingExData object. A user
agent MUST ignore unknown properties of the TrackingExData object (for
future extensibility). The following OPTIONAL properties are defined:
site
The referring domain scope for which the exception applies:
* If site is undefined, null, or the empty string, the
exception's referring domain scope defaults to the script
domain. All stored exceptions matching that domain,
regardless of target, are to be removed.
* If site is defined and equal to "*", the exceptions to be
removed are web-wide and identified by the set of targets.
* Otherwise, the exceptions to be removed are identified by a
domain found in site that is treated in the same way as the
domain parameter to cookies [RFC6265], allowing subdomains to
be included with the prefix "*.". All stored exceptions
matching that domain scope, regardless of target, are to be
removed.
targets
An array of target domains for which the exception applies:
* If site is not defined or not equal to "*", then targets is
ignored (it is only used for removing web-wide exceptions).
* If targets is an empty array, the web-wide exception to be
removed is the duplet [*, script domain].
* Otherwise, for each domain string in the targets array, a
web-wide exception to be removed is the duplet [*, domain].
For each site-specific exception being removed, a user agent MUST NOT
remove the duplets and MUST reject the promise with a DOMException named
"SecurityError" if the script would not be able to set a cookie on that
duplet's referring domain scope following the cookie domain rules
[RFC6265].
For each web-wide exception being removed, a user agent MUST NOT remove
the duplets and MUST reject the promise with a DOMException named
"SecurityError" if the script would not be able to set a cookie on that
target domain following the cookie domain rules [RFC6265].
Any processing failure, such as an incorrectly formatted parameter in the
TrackingExData, will result in no duplet being removed from the database
of stored grants and the returned promise being rejected with a
DOMException named "SyntaxError".
If there are no matching duplets in the database of stored grants when the
method is called, this operation does nothing other than resolve the
promise.
Upon fulfillment, the user agent MUST have removed any stored exceptions
that matched the identified duplet(s).
6.6.3 API to Confirm a Tracking Exception
When a site wishes to confirm that a user-granted exception exists for a
set of target domains potentially referenced by that site, a script
running within an active browsing context or nested browsing context of
that site can promise-call Navigator.trackingExceptionExists with a
TrackingExData object supplied as a parameter that identifies the set of
exceptions to confirm. The call returns a promise which either resolves to
true or false or is rejected with a DOMException identifying the reason
for the failure.
partial interface Navigator {
Promise<boolean> trackingExceptionExists(TrackingExData properties);
};
Navigator.trackingExceptionExists passes a TrackingExData object. A user
agent MUST ignore unknown properties of the TrackingExData object (for
future extensibility). The following OPTIONAL properties are defined:
site
The referring domain scope for which the exception applies:
* If site is undefined, null, or the empty string, the set of
exceptions to be confirmed have a referring domain scope
equal to the script domain.
* If site is defined and equal to "*", the set of exceptions to
be confirmed is web-wide for the set of targets.
* Otherwise, the set of exceptions to be confirmed have a
referring domain scope matching the string found in site,
which is treated in the same way as the domain parameter to
cookies [RFC6265], allowing subdomains to be included with
the prefix "*.".
targets
An array of target domains for which the exception applies:
* If targets is undefined or null, the user-granted exception
to be confirmed is [site, *], meaning that the exception
applies to all domains referenced by the site.
* If targets is an empty array, the user-granted exception to
be confirmed is [site, script domain], meaning that the
exception applies only to resources that share the same
domain as the effective script origin.
* Otherwise, for each domain string in the targets array, a
user-granted exception to be confirmed is the duplet
[site, domain].
For each site-specific exception being confirmed, a user agent MUST reject
the promise with a DOMException named "SecurityError" if the script would
not be able to set a cookie on that duplet's referring domain scope
following the cookie domain rules [RFC6265].
For each web-wide exception being confirmed, a user agent MUST reject the
promise with a DOMException named "SecurityError" if the script would not
be able to set a cookie on that target domain following the cookie domain
rules [RFC6265].
Any processing failure, such as an incorrectly formatted parameter in the
TrackingExData, will result in the returned promise being rejected with a
DOMException named "SyntaxError".
A user agent MUST fulfill the promise with the value true if a current
(non-expired) matching exception exists for all of the duplets identified
above, or false if any of the identified duplets do not have a matching
exception.
Because the database might be changed at any time (via other windows or
additional user interfaces), a particular response to the API might only
be accurate at the time the promise is fulfilled.
6.7 User Agent Management of Exceptions
There is no required user interface for a user agent regarding the
granting of exceptions; a user agent MAY choose to provide none.
Alternatively, a user agent MAY:
* indicate that a call to store an exception has just been made;
* allow the user to confirm a user-granted exception prior to storage;
* indicate that one or more exceptions exist for the current site;
* indicate that one or more exceptions exist for target domains
incorporated into the current page; or,
* provide a user interface to see and edit the database of recorded
exception grants.
When an explicit list of target domains is provided through the API, their
names might mean little to the user. The user might, for example, be told
that there is a stored exception for a specific set of targets on
such-and-such site, rather than listing them by name; or the user agent
might decide to store an all-target exception, effectively ignoring any
list of targets.
Conversely, if a wild-card is used for the target, the user might be told
that there is a stored exception for all third parties that are embedded
by the indicated site.
A user agent that chooses to highlight when tracking exceptions are
applicable might provide an interface, such as a selectable icon in the
status bar, that can direct the user to more information about the
exception and how to revoke it.
In some user agent implementations, decisions to grant exceptions might
have been made in the past (and since forgotten) or might have been made
by other users of the device. Thus, exceptions might not always represent
the current preferences of the user. Some user agents might choose to
provide ambient notice that user-opted tracking is ongoing, or easy access
to view and control these preferences. Users might also desire to edit
exceptions within a separate user interface, which would allow a user to
modify their stored exceptions without visiting the target sites.
A user-agent MUST handle each set of exception duplets stored by a single
storeTrackingException call as a 'unit', granting and maintaining the
duplets in their entirety, or not at all. A user agent MUST NOT indicate
to a site that it has stored an exception for targets {a, b, c} in the
database, and later remove only one or two of {a, b, c} from its logical
database of stored grants. This assures sites that the set of target
domains they need for operational integrity is treated as a unit.
7. Communicating a Tracking Status
7.1 Overview
In addition to expressing the user's preference regarding tracking, this In addition to expressing the user's preference regarding tracking, this
protocol enables servers to communicate machine-readable claims regarding protocol enables servers to communicate machine-readable claims regarding
their own tracking behavior. Since a personalized tracking status on every their own tracking behavior. Since a personalized tracking status on every
response would disable caching, a combination of response mechanisms are response would disable caching, a combination of response mechanisms are
defined to allow the tracking status to be communicated prior to making a defined to allow the tracking status to be communicated prior to making a
trackable request and without making every response dynamic. trackable request and without making every response dynamic.
6.2 Tracking Status Value 7.2 Tracking Status Value
6.2.1 Definition 7.2.1 Definition
A tracking status value (TSV) is a single character response to the user's A tracking status value (TSV) is a single character response to the user's
tracking preference with regard to data collected via the designated tracking preference with regard to data collected via the designated
resource. For a site-wide tracking status resource, the designated resource. For a site-wide tracking status resource, the designated
resource is any resource on the same origin server. For a Tk response resource is any resource on the same origin server. For a Tk response
header field, the target resource of the corresponding request is the header field, the target resource of the corresponding request is the
designated resource, and remains so for any subsequent request-specific designated resource, and remains so for any subsequent request-specific
tracking status resource referred to by the Tk field value. tracking status resource referred to by the Tk field value.
The tracking status value is case sensitive, as defined formally by the The tracking status value is case sensitive, as defined formally by the
skipping to change at line 593 skipping to change at line 1128
TSV = %x21 ; "!" — under construction TSV = %x21 ; "!" — under construction
/ %x3F ; "?" — dynamic / %x3F ; "?" — dynamic
/ %x47 ; "G" — gateway to multiple parties / %x47 ; "G" — gateway to multiple parties
/ %x4E ; "N" — not tracking / %x4E ; "N" — not tracking
/ %x54 ; "T" — tracking / %x54 ; "T" — tracking
/ %x43 ; "C" — tracking with consent / %x43 ; "C" — tracking with consent
/ %x50 ; "P" — tracking only if consented / %x50 ; "P" — tracking only if consented
/ %x44 ; "D" — disregarding DNT / %x44 ; "D" — disregarding DNT
/ %x55 ; "U" — updated / %x55 ; "U" — updated
/ TSV-extension
6.2.2 Under Construction (!) 7.2.2 Under Construction (!)
A tracking status value of ! means that the origin server is currently A tracking status value of ! means that the origin server is currently
testing its communication of tracking status. The ! value has been testing its communication of tracking status. The ! value has been
provided to ease testing and deployment on production systems during the provided to ease testing and deployment on production systems during the
initial periods of testing compliance and during adjustment periods due to initial periods of testing compliance and during adjustment periods due to
future protocol changes or shifting regulatory constraints. Note that this future protocol changes or shifting regulatory constraints. Note that this
value does not indicate that the user's preference will be ignored, nor value does not indicate that the user's preference will be ignored, nor
that tracking will occur as a result of accessing the designated resource. that tracking will occur as a result of accessing the designated resource.
6.2.3 Dynamic (?) 7.2.3 Dynamic (?)
A tracking status value of ? means the origin server needs more A tracking status value of ? means the origin server needs more
information to determine tracking status, usually because the designated information to determine tracking status, usually because the designated
resource dynamically adjusts behavior based on information in a request. resource dynamically adjusts behavior based on information in a request.
If ? is present in the site-wide tracking status, the origin server MUST If ? is present in the site-wide tracking status, the origin server MUST
send a Tk header field in all responses to requests on the designated send a Tk header field in all responses to requests on the designated
resource. If ? is present in the Tk header field, more information will be resource. If ? is present in the Tk header field, more information will be
provided in a request-specific tracking status resource referred to by the provided in a request-specific tracking status resource referred to by the
status-id. An origin server MUST NOT send ? as the tracking status value status-id. An origin server MUST NOT send ? as the tracking status value
in the representation of a request-specific tracking status resource. in the representation of a request-specific tracking status resource.
6.2.4 Gateway (G) 7.2.4 Gateway (G)
A tracking status value of G means the server is acting as a gateway to an A tracking status value of G means the server is acting as a gateway to an
exchange involving multiple parties. This might occur if a response to the exchange involving multiple parties. This might occur if a response to the
designated resource involves an automated selection process, such as designated resource involves an automated selection process, such as
dynamic bidding, where the party that is selected determines how the dynamic bidding, where the party that is selected determines how the
request data will be treated with respect to an expressed tracking request data will be treated with respect to an expressed tracking
preference. Similar to the ? value, the G TSV indicates that the actual preference. Similar to the ? value, the G TSV indicates that the actual
tracking status is dynamic and will be provided in the response message's tracking status is dynamic and will be provided in the response message's
Tk header field, presumably using information forwarded from the selected Tk header field, presumably using information forwarded from the selected
party. party.
skipping to change at line 648 skipping to change at line 1184
* the gateway MUST forward any expressed tracking preference in the * the gateway MUST forward any expressed tracking preference in the
request to each party that receives data from that request; request to each party that receives data from that request;
* the gateway MUST have a contract in place with each of the parties to * the gateway MUST have a contract in place with each of the parties to
whom it provides request data such that only the selected party is whom it provides request data such that only the selected party is
allowed to retain tracking data from a request with an expressed allowed to retain tracking data from a request with an expressed
tracking preference of DNT:1; and, tracking preference of DNT:1; and,
* the gateway MUST send a Tk header field in responses to requests on * the gateway MUST send a Tk header field in responses to requests on
the designated resource and include within that field's value a the designated resource and include within that field's value a
status-id specific to the selected party, such that information about status-id specific to the selected party, such that information about
the selected party can be obtained via the request-specific tracking the selected party can be obtained via the request-specific tracking
status resource (see section 6.4.2 Request-specific Tracking Status). status resource (see section 7.4.2 Request-specific Tracking Status).
With respect to tracking performed by the gateway itself, the G response With respect to tracking performed by the gateway itself, the G response
can be considered equivalent to the T (tracking) response defined below. can be considered equivalent to the T (tracking) response defined below.
The other information within the site-wide tracking status representation The other information within the site-wide tracking status representation
indicates how the gateway intends to comply with an expressed tracking indicates how the gateway intends to comply with an expressed tracking
preference, aside from the potential sharing of data implied by the preference, aside from the potential sharing of data implied by the
gateway process. gateway process.
6.2.5 Not Tracking (N) 7.2.5 Not Tracking (N)
A tracking status value of N means the origin server claims that data A tracking status value of N means the origin server claims that data
collected via the designated resource is not used for tracking and will collected via the designated resource is not used for tracking and will
not be combined with other data in a form that would enable tracking. not be combined with other data in a form that would enable tracking.
6.2.6 Tracking (T) 7.2.6 Tracking (T)
A tracking status value of T means the origin server might perform or A tracking status value of T means the origin server might perform or
enable tracking using data collected via the designated resource. enable tracking using data collected via the designated resource.
Information provided in the tracking status representation might indicate Information provided in the tracking status representation might indicate
whether such tracking is limited to a set of commonly accepted uses or whether such tracking is limited to a set of commonly accepted uses or
adheres to one or more compliance regimes. adheres to one or more compliance regimes.
6.2.7 Consent (C) 7.2.7 Consent (C)
A tracking status value of C means that the origin server believes it has A tracking status value of C means that the origin server believes it has
received prior consent for tracking this user, user agent, or device, received prior consent for tracking this user, user agent, or device,
perhaps via some mechanism not defined by this specification, and that perhaps via some mechanism not defined by this specification, and that
prior consent overrides the tracking preference expressed by this prior consent overrides the tracking preference expressed by this
protocol. An origin server that sends the C tracking status value for a protocol. An origin server that sends the C tracking status value for a
designated resource MUST provide a reference for controlling consent designated resource MUST provide a reference for controlling consent
within the config property of its corresponding tracking status within the config property of its corresponding tracking status
representation (section 6.5 Tracking Status Representation). representation (section 7.5 Tracking Status Representation).
6.2.8 Potential Consent (P) 7.2.8 Potential Consent (P)
A tracking status value of P means that the origin server does not know, A tracking status value of P means that the origin server does not know,
in real-time, whether it has received prior consent for tracking this in real-time, whether it has received prior consent for tracking this
user, user agent, or device, but promises not to use or share any DNT:1 user, user agent, or device, but promises not to use or share any DNT:1
data until such consent has been determined, and further promises to data until such consent has been determined, and further promises to
delete or permanently de-identify within forty-eight hours any DNT:1 data delete or permanently de-identify within forty-eight hours any DNT:1 data
received for which such consent has not been received. received for which such consent has not been received.
Since this status value does not itself indicate whether a specific Since this status value does not itself indicate whether a specific
request is tracked, an origin server that sends a P tracking status value request is tracked, an origin server that sends a P tracking status value
skipping to change at line 704 skipping to change at line 1240
representation that links to a resource for obtaining consent status. representation that links to a resource for obtaining consent status.
The P tracking status value is specifically meant to address audience The P tracking status value is specifically meant to address audience
survey systems for which determining consent at the time of a request is survey systems for which determining consent at the time of a request is
either impractical, due to legacy systems not being able to keep up with either impractical, due to legacy systems not being able to keep up with
Web traffic, or potentially "gamed" by first party sites if they can Web traffic, or potentially "gamed" by first party sites if they can
determine which of their users have consented. The data cannot be used for determine which of their users have consented. The data cannot be used for
the sake of personalization. If consent can be determined at the time of a the sake of personalization. If consent can be determined at the time of a
request, the C tracking status is preferred. request, the C tracking status is preferred.
6.2.9 Disregarding (D) 7.2.9 Disregarding (D)
A tracking status value of D means that the origin server is unable or A tracking status value of D means that the origin server is unable or
unwilling to respect a tracking preference received from the requesting unwilling to respect a tracking preference received from the requesting
user agent. An origin server that sends the D tracking status value MUST user agent. An origin server that sends the D tracking status value MUST
detail within the server's corresponding privacy policy the conditions detail within the server's corresponding privacy policy the conditions
under which a tracking preference might be disregarded. under which a tracking preference might be disregarded.
For example, an origin server might disregard the DNT field received from For example, an origin server might disregard the DNT field received from
specific user agents (or via specific network intermediaries) that are specific user agents (or via specific network intermediaries) that are
deemed to be non-conforming, might be collecting additional data from deemed to be non-conforming, might be collecting additional data from
skipping to change at line 727 skipping to change at line 1263
local law, regulation, or order. local law, regulation, or order.
Note Note
This specification is written with an assumption that the D tracking This specification is written with an assumption that the D tracking
status value would only be used in situations that can be adequately status value would only be used in situations that can be adequately
described to users as an exception to normal behavior. If this turns out described to users as an exception to normal behavior. If this turns out
not to be the case, either the server's decision to send the D signal not to be the case, either the server's decision to send the D signal
needs re-examination, or this specification, or both. needs re-examination, or this specification, or both.
6.2.10 Updated (U) 7.2.10 Updated (U)
A tracking status value of U means that the request resulted in a A tracking status value of U means that the request resulted in a
potential change to the tracking status applicable to this user, user potential change to the tracking status applicable to this user, user
agent, or device. A user agent that relies on a cached tracking status 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 SHOULD update the cache entry with the current status by making a new
request on the applicable tracking status resource. request on the applicable tracking status resource.
An origin server MUST NOT send U as a tracking status value anywhere other 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. than a Tk header field that is in response to a state-changing request.
6.3 Tk Header Field for HTTP Responses 7.2.11 Extensions to the Tracking Status Value
6.3.1 Definition Extensibility of the TSV set ensures that this protocol will continue to
be usable as regional laws and regulatory environments evolve over time
and compliance specifications are developed accordingly.
An origin server MAY send a TSV-extension character as a TSV if that
extension has been defined by a future version of this specification or a
compliance regime identified within the compliance property. Aside from
storage or presentation of a server's response, a recipient MUST treat a
TSV-extension value that it does not recognize as if the value was P
(tracking only if consented).
TSV-extension = %x23-25 ; #$%
/ %x2A-3B ; *+,-./0-9:;
/ %x40-42 ; @AB
/ %x45-46 ; EF
/ %x48-4D ; HIJKLM
/ %x4F ; O
/ %x51-53 ; QRS
/ %x56-5A ; VWXYZ
/ %x5F ; _
/ %x61-7A ; a-z
7.3 Tk Header Field for HTTP Responses
7.3.1 Definition
The Tk response header field is a means for indicating the tracking status The Tk response header field is a means for indicating the tracking status
that applied to the corresponding request. An origin server is REQUIRED to that applied to the corresponding request. An origin server is REQUIRED to
send a Tk header field if its site-wide tracking status value is ? send a Tk header field if its site-wide tracking status value is ?
(dynamic) or G (gateway), or when an interactive change is made to the (dynamic) or G (gateway), or when an interactive change is made to the
tracking status and indicated by U (updated). tracking status and indicated by U (updated).
Tk-field-name = "Tk" Tk-field-name = "Tk"
Tk-field-value = TSV [ ";" status-id ] Tk-field-value = TSV [ ";" status-id ]
The Tk field-value begins with a tracking status value (section 6.2 The Tk field-value begins with a tracking status value (section 7.2
Tracking Status Value), optionally followed by a semicolon and a status-id Tracking Status Value), optionally followed by a semicolon and a status-id
that refers to a request-specific tracking status resource (section 6.3.2 that refers to a request-specific tracking status resource (section 7.3.2
Referring to a Request-specific Tracking Status Resource). Referring to a Request-specific Tracking Status Resource).
For example, a Tk header field for a resource that claims not to be For example, a Tk header field for a resource that claims not to be
tracking would look like: tracking would look like:
Example 2 Example 2
Tk: N Tk: N
6.3.2 Referring to a Request-specific Tracking Status Resource 7.3.2 Referring to a Request-specific Tracking Status Resource
If an origin server has multiple, request-specific tracking policies, such If an origin server has multiple, request-specific tracking policies, such
that the tracking status might differ depending on some aspect of the 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 resource, header fields, data, etc.), the
server can provide an additional subtree of well-known resources origin server can provide an additional subtree of well-known resources
corresponding to each of those distinct tracking statuses. The status-id corresponding to each of those distinct tracking statuses. The status-id
portion of the Tk field-value indicates which specific tracking status portion of the Tk field-value indicates which specific tracking status
resource applies to the current request. The status-id is case-sensitive. resource applies to the current request. The status-id is case-sensitive.
status-id = 1*id-char status-id = 1*id-char
id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
For example, a response containing For example, a response containing
Example 3 Example 3
skipping to change at line 797 skipping to change at line 1357
Note that the status-id is resolved relative to the origin server of the Note that the status-id is resolved relative to the origin server of the
current request. A retrieval request targeting that URI can be redirected, current request. A retrieval request targeting that URI can be redirected,
if desired, to some other server. The status-id has been intentionally if desired, to some other server. The status-id has been intentionally
limited to a small set of characters to encourage use of short tokens limited to a small set of characters to encourage use of short tokens
instead of potentially long, human-readable strings. instead of potentially long, human-readable strings.
If a Tk field-value has a tracking status value of ? (dynamic), the origin If a Tk field-value has a tracking status value of ? (dynamic), the origin
server MUST send a status-id in the field-value. server MUST send a status-id in the field-value.
6.3.3 Indicating an Interactive Status Change 7.3.3 Indicating an Interactive Status Change
Interactive mechanisms might be used, beyond the scope of this Interactive mechanisms might be used, beyond the scope of this
specification, that have the effect of asking for and obtaining prior specification, that have the effect of asking for and obtaining prior
consent for tracking, or for modifying prior indications of consent. For consent for tracking, or for modifying prior indications of consent. For
example, the tracking status resource's status object defines a config example, the tracking status resource's status object defines a config
property that can refer to such a mechanism. Although such out-of-band property that can refer to such a mechanism. Although such out-of-band
mechanisms are not defined by this specification, their presence might mechanisms are not defined by this specification, their presence might
influence the tracking status object's response value. influence the tracking status object's response value.
When an origin server provides a mechanism via HTTP for establishing or When an origin server provides a mechanism via HTTP for establishing or
modifying out-of-band tracking preferences, the origin server MUST modifying out-of-band tracking preferences, the origin server MUST
indicate within the mechanism's response when a state-changing request has indicate within the mechanism's response when a state-changing request has
resulted in a change to the tracking status for that server. This resulted in a change to the tracking status for that server. This
indication of an interactive status change is accomplished by sending a Tk 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). header field in the response with a tracking status value of U (updated).
Example 4 Example 4
Tk: U Tk: U
6.4 Tracking Status Resource 7.4 Tracking Status Resource
6.4.1 Site-wide Tracking Status 7.4.1 Site-wide Tracking Status
A site-wide tracking status resource provides information about the A site-wide tracking status resource provides information about the
potential tracking behavior of resources located at that origin server. A potential tracking behavior of resources located at that origin server. A
site-wide tracking status resource has the well-known identifier site-wide tracking status resource has the well-known identifier
/.well-known/dnt/ /.well-known/dnt/
relative to the origin server's URI [RFC5785]. relative to the origin server's URI [RFC5785].
An origin server that receives a valid GET request targeting its site-wide An origin server that receives a valid GET request targeting its site-wide
tracking status resource MUST send either a successful response containing tracking status resource MUST send either a successful response containing
a machine-readable representation of the site-wide tracking status, as a machine-readable representation of the site-wide tracking status, as
defined below, or a sequence of redirects that leads to such a defined below, or a sequence of redirects that leads to such a
representation. Failure to provide access to such a representation implies representation. Failure to provide access to such a representation implies
that the target origin server does not implement this protocol. The that the origin server does not implement this protocol. The
representation can be cached, as described in section 6.4.4 Caching. representation can be cached, as described in section 7.4.4 Caching.
See section 6.7 Using the Tracking Status for examples of how tracking See section 8. Use Cases for examples of how tracking status resources can
status resources can be used to discover support for this protocol. be used to discover support for this protocol.
6.4.2 Request-specific Tracking Status 7.4.2 Request-specific Tracking Status
If an origin server has multiple, request-specific tracking policies, such If an origin server has multiple, request-specific tracking policies, such
that the tracking status might differ depending on some aspect of the 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 resource, header fields, data, etc.), the
server can provide an additional subtree of well-known resources origin server can 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 6.3 Tk Header Field for HTTP Responses) can include header field (section 7.3 Tk Header Field for HTTP Responses) can include
a status-id to indicate which specific tracking status resource applies to a status-id to indicate which specific tracking status resource applies to
the current request. the current request.
A tracking status resource space is defined by the following URI Template A tracking status resource space is defined by the following URI Template
[RFC6570]: [RFC6570]:
/.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
skipping to change at line 872 skipping to change at line 1432
Tk: ?;ahoy Tk: ?;ahoy
refers to the specific tracking status resource refers to the specific tracking status resource
/.well-known/dnt/ahoy /.well-known/dnt/ahoy
Resources within the request-specific tracking status resource space are Resources within the request-specific tracking status resource space are
represented using the same format as a site-wide tracking status resource. represented using the same format as a site-wide tracking status resource.
6.4.3 Status Checks are Not Tracked 7.4.3 Status Checks are Not Tracked
When sending a request for the tracking status, a user agent SHOULD When sending a request for the tracking status, a user agent SHOULD
include any cookie data [RFC6265] (set prior to the request) that would be include any cookie data [RFC6265] (set prior to the request) that would be
sent in a normal request to that origin server, since that data might be 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 needed by the server to determine the current tracking status. For
example, the cookie data might indicate a prior out-of-band decision by 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 user to opt-out or consent to tracking by that origin server.
An origin server MUST NOT retain tracking data regarding requests on the An origin server MUST NOT retain tracking data regarding requests on the
site-wide tracking status resource or within the tracking status resource site-wide tracking status resource or within the tracking status resource
space, regardless of the presence, absence, or value of a DNT header space, regardless of the presence, absence, or value of a DNT header
field, cookies, or any other information in the request. In addition, an field, cookies, or any other information in the request. In addition, an
origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in
responses to those requests, including the responses to redirected responses to those requests, including the responses to redirected
tracking status requests, and MUST NOT send a response having content that tracking status requests, and MUST NOT send a response having content that
initiates tracking beyond what was already present in the request. A user 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 agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2
header field received in such a response. header field received in such a response.
6.4.4 Caching 7.4.4 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 and other data received via the request, then the
origin server SHOULD mark the response as cacheable [RFC7234] and assign a origin server SHOULD mark the response as cacheable [RFC7234] and assign a
time-to-live (expiration or max-use) that is sufficient to enable shared time-to-live (expiration or max-use) that is sufficient to enable shared
caching but not greater than the earliest point at which the service's caching but not greater than the earliest point at which the service's
tracking behavior might increase. tracking behavior might increase.
For example, if the tracking status response is set to expire in seven For example, if the tracking status response is set to expire in seven
days, then the earliest point in time that the service's tracking behavior days, then the earliest point in time that the service's tracking behavior
can be increased is seven days after the tracking status representation can be increased is seven days after the tracking status representation
has been updated to reflect the new behavior, since old copies might has been updated to reflect the new behavior, since old copies might
persist in caches until the expiration is triggered. A service's tracking persist in caches until the expiration is triggered. A service's tracking
behavior can be reduced at any time, with or without a corresponding behavior can be reduced at any time, with or without a corresponding
change to the tracking status resource. change to the tracking status resource.
If the tracking status is only applicable to users that have the same If the tracking status is only applicable to users that have the same DNT
DNT-field-value, the origin server MUST send a Vary header field that field-value, the origin server MUST send a Vary header field that includes
includes "DNT" in its field-value or a Cache-Control header field "DNT" in its field-value or a Cache-Control header field containing one of
containing one of the following directives: "private", "no-cache", the following directives: "private", "no-cache", "no-store", or
"no-store", or "max-age=0". "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 origin server MUST send a Cache-Control header requested it, then the origin server MUST send a Cache-Control header
field containing one of the following directives: "private", "no-cache", field containing one of the following directives: "private", "no-cache",
or "no-store". or "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 U tracking status value, as DELETE, etc.) for a Tk header field with the U tracking status value, as
described in section 6.3.3 Indicating an Interactive Status Change. described in section 7.3.3 Indicating an Interactive Status Change.
6.5 Tracking Status Representation 7.5 Tracking Status Representation
For each tracking status resource, an origin server MUST provide a valid For each tracking status resource, an origin server MUST provide a valid
representation using the application/tracking-status+json media type. This representation using the application/tracking-status+json media type. This
media type consists of a status object serialized as JSON [RFC7159]. More media type consists of a status object serialized as JSON [RFC7159]. More
information about the application/tracking-status+json media type can be information about the application/tracking-status+json media type can be
found in section B. Registrations. found in section B. Registrations.
6.5.1 Status Object 7.5.1 Status Object
A tracking status representation consists of a single status object A tracking status representation consists of a single status object
containing properties that describe the tracking status applicable to the containing properties that describe the tracking status applicable to the
designated resource. Most of the properties are optional and can be designated resource. Most of the properties are optional and can be
extended over time, as illustrated by the following Orderly schema extended over time, as illustrated by the following Orderly schema
[Orderly]: [Orderly]:
object { object {
string tracking; // TSV string tracking; // TSV
array { string; } compliance?; // hrefs array { string; } compliance?; // hrefs
skipping to change at line 982 skipping to change at line 1542
"example_vids.net", "example_vids.net",
"example_stats.com" "example_stats.com"
], ],
"audit": [ "audit": [
"http://auditor.example.org/727073" "http://auditor.example.org/727073"
], ],
"policy": "/privacy.html#tracking", "policy": "/privacy.html#tracking",
"config": "http://example.com/your/data" "config": "http://example.com/your/data"
} }
6.5.2 Tracking Property 7.5.2 Tracking Property
A status object MUST have a property named tracking with a string value A status object MUST have a property named tracking with a string value
containing the tracking status value (section 6.2 Tracking Status Value) containing the tracking status value (section 7.2 Tracking Status Value)
applicable to the designated resource. applicable to the designated resource.
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.
Example 7 Example 7
{"tracking": "N"} {"tracking": "N"}
6.5.3 Compliance Property 7.5.3 Compliance Property
An origin server MAY send a property named compliance with an array value An origin server MAY send a property named compliance with an array value
containing a list of URI references that identify specific regimes to containing a list of URI references that identify specific regimes to
which the origin server claims to comply for the designated resource. which the origin server claims to comply for the designated resource.
Communicating such a claim of compliance is presumed to improve Communicating such a claim of compliance is presumed to improve
transparency, which might influence a user's decisions or configurations transparency, which might influence a user's decisions or configurations
regarding allowed tracking, but does not have any direct impact on this regarding allowed tracking.
protocol.
6.5.4 Qualifiers Property If an origin server sends a TSV-extension or an extension property in the
status object that is not defined by successors of this specification, the
origin server MUST send a compliance property that contains a reference to
the definitive specification of that extension. If more than one reference
in the compliance array defines the same extension value, the origin
server SHOULD list the array of references in order by intended
precedence.
7.5.4 Qualifiers Property
An origin server MAY send a property named qualifiers with a string value An origin server MAY send a property named qualifiers with a string value
containing a sequence of case sensitive characters corresponding to containing a sequence of case sensitive characters corresponding to
explanations or limitations on the extent of tracking. Multiple qualifiers explanations or limitations on the extent of tracking. Multiple qualifiers
indicate that multiple explanations or forms of tracking might apply for indicate that multiple explanations or forms of tracking might apply for
the designated resource. The meaning of each qualifier is presumed to be the designated resource. The meaning of each qualifier is presumed to be
defined by one or more of the regimes listed in compliance. defined by one or more of the regimes listed in compliance.
6.5.5 Controller Property 7.5.5 Controller Property
An origin server MAY send a property named controller with an array value An origin server MAY send a property named controller with an array value
containing a list of URI references indirectly identifying the party or containing a list of URI references indirectly identifying the party or
set of parties that claims to be the responsible data controller for set of parties that claims to be the responsible data controller for
personal data collected via the designated resource. An origin server MUST personal data collected via the designated resource. An origin server MUST
send a controller property if the responsible data controller does not own send a controller property if the responsible data controller does not own
the designated resource's domain name. the designated resource's domain name.
An origin server that does not send controller is implying that its domain An origin server that does not send controller is implying that its domain
owner is the sole data controller; information about the data controller owner is the sole data controller; information about the data controller
skipping to change at line 1040 skipping to change at line 1607
If the designated resource has joint data controllers (i.e., multiple If the designated resource has joint data controllers (i.e., multiple
parties have independent control over the collected data), the origin parties have independent control over the collected data), the origin
server MUST send a controller property that contains a reference for each server MUST send a controller property that contains a reference for each
data controller. data controller.
Each URI reference provided in controller ought to refer to a resource Each URI reference provided in controller ought to refer to a resource
that, if a retrieval action is performed on that URI, would provide the that, if a retrieval action is performed on that URI, would provide the
user with information regarding (at a minimum) the identity of the user with information regarding (at a minimum) the identity of the
corresponding party and its data collection practices. corresponding party and its data collection practices.
6.5.6 Same-party Property 7.5.6 Same-party Property
Since a user's experience on a given site might be composed of resources Since a user's experience on a given site might be composed of resources
that are assembled from multiple domains, it might be useful for a site to that are assembled from multiple domains, it might be useful for a site to
distinguish those domains that are subject to their own control (i.e., distinguish those domains that are subject to their own control (i.e.,
share the same data controller as the referring site). An origin server share the same data controller as the referring site). An origin server
MAY send a property named same-party with an array value containing a list MAY send a property named same-party with an array value containing a list
of domain names that the origin server claims are the same party, to the of domain names that the origin server claims are the same party, to the
extent they are referenced by the designated resource, if all data extent they are referenced by the designated resource, if all data
collected via those references share the same data controller as the collected via those references share the same data controller as the
designated resource. designated resource.
A user agent might use the same-party array, when provided, to inform or A user agent might use the same-party array, when provided, to inform or
enable different behavior for references that are claimed to be same-party enable different behavior for references that are claimed to be same-party
versus those for which no claim is made. For example, a user agent might versus those for which no claim is made. For example, a user agent might
choose to exclude, or perform additional pre-flight verification of, choose to exclude, or perform additional pre-flight verification of,
requests to other domains that have not been claimed as same-party by the requests to other domains that have not been claimed as same-party by the
referring site. referring site.
6.5.7 Audit Property 7.5.7 Audit Property
An origin server MAY send a property named audit with an array value An origin server MAY send a property named audit with an array value
containing a list of URI references to external audits of the designated containing a list of URI references to external audits of the designated
resource's privacy policy and tracking behavior. Preferably, the audit resource's privacy policy and tracking behavior. Preferably, the audit
references are to resources that describe the auditor and the results of 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 that audit; however, if such a resource is not available, a reference to
the auditor is sufficient. the auditor is sufficient.
6.5.8 Policy Property 7.5.8 Policy Property
An origin server MAY send a property named policy with a string value An origin server MAY send a property named policy with a string value
containing a URI reference to a human-readable document that describes the containing a URI reference to a human-readable document that describes the
relevant privacy policy for the designated resource. The content of such a relevant privacy policy for the designated resource. This document can
policy document is beyond the scope of this protocol and only supplemental inform users about data that might be collected when the designated
to what is described in the machine-readable tracking status resource is accessed and how collection, use, or sharing of such data
representation. If no policy property is provided, this information might might differ based on receipt of an expressed tracking preference (DNT:1
be obtained via the links provided in controller. or DNT:0).
6.5.9 Config Property An origin server MUST send a policy property if that server is the
effective script origin of a script that calls the JavaScript API for
storing a user-granted exception, as described in section 6.3 Granting an
Exception.
The content of such a policy document is beyond the scope of this protocol
and only supplemental to what is described in the machine-readable
tracking status representation. If no policy property is provided, this
information might be obtained via the links provided in controller.
If the policy associated with a designated resource happens to be defined
as a common standard that is applicable to multiple sites, or includes
such a standard by reference, that standard ought to be referenced by a
URI within the machine-readable compliance property.
7.5.9 Config Property
An origin server MAY send a property named config with a string value An origin server MAY send a property named config with a string value
containing a URI reference to a resource for giving the user control over containing a URI reference to a resource for giving the user control over
personal data collected via the designated resource (and possibly other personal data collected via the designated resource (and possibly other
resources). If the tracking status value indicates prior consent (C), the resources). If the tracking status value indicates prior consent (C), the
origin server MUST send a config property referencing a resource that origin server MUST send a config property referencing a resource that
describes how such consent is established and how to revoke that consent. describes how such consent is established and how to revoke that consent.
A config resource might include the ability to review past data collected, A config resource might include the ability to review past data collected,
delete some or all of the data, provide additional data (if desired), or delete some or all of the data, provide additional data (if desired), or
opt-in, opt-out, or otherwise modify an out-of-band consent status opt-in, opt-out, or otherwise modify an out-of-band consent status
regarding data collection. The design of such a resource, the extent to regarding data collection. The design of such a resource, the extent to
which it can provide access to that data, and how one might implement an which it can provide access to that data, and how one might implement an
out-of-band consent mechanism are beyond the scope of this protocol. out-of-band consent mechanism are beyond the scope of this protocol.
If no config property is provided, this information might be obtained via If no config property is provided, this information might be obtained via
the links provided in controller or policy. the links provided in controller or policy.
6.5.10 Extensions 7.5.10 Extensions to the Status Object
An origin server MAY send additional properties in the status object to Extensibility of the status object ensures that this protocol will
support future enhancements to this protocol. A recipient MUST ignore continue to be usable as regional laws and regulatory environments evolve
extension properties that it does not recognize. over time and compliance specifications are developed accordingly.
6.6 Status Code for Tracking Required An origin server MAY send additional properties in the status object if
those extensions have been defined by a future version of this
specification or a compliance regime identified within the compliance
property. Aside from storage or presentation of a server's response, a
recipient MUST ignore extension properties that it does not recognize.
7.6 Status Code for Tracking Required
If an origin server receives a request with DNT:1, does not have If an origin server receives a request with DNT:1, does not have
out-of-band consent for tracking this user, and wishes to deny access to out-of-band consent for tracking this user, and wishes to deny access to
the requested resource until the user provides some form of user-granted the requested resource until the user provides some form of user-granted
exception or consent for tracking, then the origin server SHOULD send a exception or consent for tracking, then the origin server SHOULD send a
409 (Conflict) response with a message payload that describes why the 409 (Conflict) response with a message payload that describes why the
request has been refused and how one might supply the required consent or request has been refused and how one might supply the required consent or
exception to avoid this conflict [RFC7231]. exception to avoid this conflict [RFC7231].
The 409 response ought to include a user authentication mechanism in the The 409 response ought to include a user authentication mechanism in the
header fields and/or message body if user login is one of the ways through header fields and/or message body if user login is one of the ways through
which access is granted. which access is granted.
6.7 Using the Tracking Status 8. Use Cases
Note This section is non-normative.
Editor's note
This section is for collecting use cases that describe questions a user 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 agent might have about tracking status and how the protocol can be used to
answer such questions. More cases are needed. answer such questions. More cases are needed.
6.7.1 Discovering Deployment 8.1 Discovering Deployment
Deployment of this protocol for a given service can be discovered by Deployment of this protocol for a given service can be discovered by
making a retrieval request on the site-wide tracking resource making a retrieval request on the site-wide tracking resource
/.well-known/dnt/ relative to the service URI. /.well-known/dnt/ relative to the service URI.
If the response is an error, then the service does not implement this 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 standard. If the response is a redirect, then follow the redirect to
obtain the tracking status (up to some reasonable maximum of redirects to obtain the tracking status (up to some reasonable maximum of redirects to
avoid misconfigured infinite request loops). If the response is avoid misconfigured infinite request loops). If the response is
successful, obtain the tracking status representation from the message successful, obtain the tracking status representation from the message
payload, if possible, or consider it an error. payload, if possible, or consider it an error.
6.7.2 Preflight Checks 8.2 Preflight Checks
A key advantage of providing the tracking status at a resource separate 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 from the site's normal services is that the status can be accessed and
reviewed prior to making use of those services. reviewed prior to making use of those services.
A user agent MAY check the tracking status for a designated resource by A user agent can check the tracking status for a designated resource by
first making a retrieval request for the site-wide tracking status first making a retrieval request for the site-wide tracking status
representation, as described above, and then parsing the representation as representation, as described above, and then parsing the representation as
JSON to extract the status object. If the retrieval is unsuccessful or JSON to extract the status object. If the retrieval is unsuccessful or
parsing results in a syntax error, the user agent ought to consider the parsing results in a syntax error, the user agent ought to consider the
site to be non-conformant with this protocol. site to be non-conformant with this protocol.
The status object is supposed to have a property named tracking containing The status object is supposed to have a property named tracking containing
the tracking status value. The meaning of each tracking status value is the tracking status value. The meaning of each tracking status value is
defined in section 6.2 Tracking Status Value. defined in section 7.2 Tracking Status Value.
If the tracking status value is N, then the origin server claims that no If the tracking status value is N, then the origin server claims that no
tracking is performed for the designated resource for at least the next 24 tracking is performed for the designated resource for at least the next 24
hours or until the Cache-Control information indicates that this response hours or until the Cache-Control information indicates that this response
expires. expires.
If the tracking status value is not N, then the origin server claims that 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 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 least the next 24 hours or until the Cache-Control information indicates
that this response expires. that this response expires.
7. User-Granted Exceptions 9. Security Considerations
7.1 Overview
This section is non-normative.
User-granted exceptions to Do Not Track, including site-specific
exceptions, are agreed between the site and the user, and stored by the
user agent. A resource ought to rely on the DNT header field it receives
to determine the user's preference for tracking with respect to that
particular request. An API is provided so that sites can request and check
the status of exceptions for tracking.
Note
We envisage that the exceptions might also be usable as a consent
mechanism.
7.2 Motivating Principles and Use Cases
This section is non-normative.
The following principles guide the design of user-agent-managed
exceptions.
* Content providers might wish to prompt visitors to their properties to
opt back in to tracking for behavioral advertising or similar purposes
when they arrive with the Do Not Track setting enabled.
* Privacy-conscious users might wish to view or edit all the exceptions
they've granted in a single, consistent user interface, rather than
managing preferences in a different way on every content provider or
tracker's privacy page.
* Granting an exception in one context (e.g., while browsing a news
site) does not imply that exception is applicable to other contexts
(e.g., browsing an unrelated medical site).
* Tracking providers ought to be able to avoid second-guessing a user's
expressed tracking preference.
* The solution need not require cross-domain communication between a
first-party publisher and its third parties.
When asking for a site-specific exception, the top-level origin making the
request might make some implicit or explicit claims as to the actions and
behavior of its third parties; for this reason, it might want to establish
exceptions for only those for which it is sure that those claims are true.
(Consider a site that has some trusted advertisers and analytics
providers, along with some mashed-up content from less-trusted sites). For
this reason, there is support both for explicitly named sites, as well as
support for granting an exception to all third-parties on a given site
(site-wide exception, using the conceptual wild-card "*").
There are some cases in which a user might desire a site to be allowed to
track them on any top-level origin. An API is provided so that a site
might obtain such a web-wide exception from the user.
7.3 Exception Model
7.3.1 User Interaction
The call to store an exception MUST reflect the user's intention to grant
an exception at the time of that call. This intention MUST be determined
by the site prior to each call to store an exception, at the time of the
call. (This allows a user to change their mind and delete a stored
exception, which might result in the site explaining and asking for the
exception again.) It is the sole responsibility of the site making the
call to determine that a call to record an exception reflects the user's
informed consent at the time of that call.
A site MAY ask for an exception, and have it stored, even when the user's
general preference is not enabled. (This permits recording a permission to
allow tracking in jurisdictions where such permission cannot be assumed –
see section 7.7 Exceptions without Interactive JavaScript.)
The user agent MAY provide interfaces to the user:
* To indicate that a call to store an exception has just been made;
* To allow the user to confirm a user-granted exception prior to
storage;
* To indicate that one or more exceptions exist for the current
top-level origin;
* To indicate that one or more exceptions exist for sites incorporated
into the current page;
* To allow the user to see and possibly revoke stored exceptions;
* Other aspects of the exception mechanism, as desired.
There is no required user interface for the user agent; a user agent MAY
choose to provide no user interface regarding user-granted exceptions.
If the user revokes the consent by deleting the exception, the site MUST
respect that revocation (though it MAY ask again for the exception). The
site MUST NOT use this exception mechanism if it will deem consent to
exist even after the exception has been revoked.
7.3.2 Processing Model
This section describes the effect of the APIs in terms of a logical
processing model; this model describes the behavior, but is not to be read
as mandating any specific implementation.
This API considers exceptions which are double-keyed to two domains: the
site, and the target. A user might — for instance — want AnalytiCo to be
allowed to track them on Example News, but not on Example Medical. To
simplify language used in this API specification, we define three terms:
* A top-level origin is the top-level browsing context, as defined by
[HTML5];
* A target site is the host subcomponent of the authority part in an
"http" or "https" URI, as defined by [RFC7230] and [RFC3986]; and,
* The document origin of a script is the effective script origin, as
defined by [HTML5].
For instance, if the document at
http://web.exnews.com/news/story/2098373.html references the resources
http://exnews.analytico.net/1x1.gif and
http://widgets.exsocial.org/good-job-button.js, the top-level origin is
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both
targets.
The domains that enter into the behavior of the APIs include:
* As described above, the document origin active at the time of the
call, and;
* Domain names passed to the API.
Domains that enter into the decision over what DNT header field to be sent
in a given request include:
* The top-level origin of the current browser context;
* The target of the request.
Note
Note that these strict, machine-discoverable concepts might not match the
definitions of first and third party; in particular, sites themselves need
to determine when they are a first party in relation to a given user
action; the user agent does not change the DNT header field based on the
type of network interaction.
The calls cause the following steps to occur (subject to user confirmation
of the exception, if the user agent asks for it):
* The user agent adds to its local database one or more site-pair
duplets [document-origin, target]; one or the other of these MAY be a
wild-card ("*");
* While the user is browsing a given site (top-level origin), and a DNT
header field is to be sent to a target domain, if the duplet
[top-level origin, target domain] matches any duplet in the database,
then a DNT:0 preference is sent, otherwise the user’s general
preference is sent (if any).
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A
pair of values A and X match if and only if one of the following is true:
* either A or X is "*";
* A and X are the same string;
* A has the form '*.domain' and X is 'domain' or is of the form
'string.domain', where 'string' is any sequence of characters.
In addition, responses to the JavaScript API indicated should be
consistent with this user preference (see below).
User-agents MUST handle each API request as a 'unit', granting and
maintaining it in its entirety, or not at all. That means that a user
agent MUST NOT indicate to a site that a request for targets {a, b, c}
exists in the database, and later remove only one or two of {a, b, c} from
its logical database of remembered grants. This assures sites that the set
of sites they need for operational integrity is treated as a unit. Each
separate call to an API is a separate unit.
It is left up to individual user agent implementations how to determine
and how and whether to store users' tracking preferences.
When an explicit list of domains is provided through the API, their names
might mean little to the user. The user might, for example, be told that
there is a stored exception for a specific set of sites on such-and-such
top-level origin, rather than listing them by name; or the user agent
might decide to store a site-wide exception, effectively ignoring any list
of domain names.
Conversely, if a wild-card is used, the user might be told that there is a
stored exception for all third-parties that are embedded by the indicated
top-level origin.
7.4 Site-specific Exceptions
7.4.1 API to Request a Site-specific Exception
partial interface Navigator {
void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty
Bag properties);
};
storeSiteSpecificTrackingException
Called by a page to store a site-specific tracking exception.
Parameter Type Nullable Optional Description
properties StoreSiteSpecificExceptionPropertyBag ✘ ✘
Return type: void
dictionary StoreExceptionPropertyBag {
DOMString? domain;
DOMString? siteName;
DOMString? explanationString;
DOMString? detailURI;
DOMString? expires;
long? maxAge;
};
detailURI of type DOMString, nullable
A location at which further information about this request can be
found.
domain of type DOMString, nullable
a cookie-domain as defined in [RFC6265], to which the exception
applies.
expires of type DOMString, nullable
A date and time, encoded as described for the cookie Expires
attribute described in [RFC6265], indicating the maximum lifetime
of the remembered grant.
explanationString of type DOMString, nullable
A short explanation of the request.
maxAge of type long, nullable
A positive number of seconds indicating the maximum lifetime of
the remembered grant.
siteName of type DOMString, nullable
A user-readable string for the name of the top-level origin.
dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag {
sequence<DOMString> arrayOfDomainStrings;
};
arrayOfDomainStrings of type sequence<DOMString>,
A JavaScript array of strings.
The storeSiteSpecificTrackingException method takes a dictionary argument
of type StoreSiteSpecificExceptionPropertyBag that allows optional
information to be provided.
If the request does not include the arrayOfDomainStrings, then this
request is for a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target. When called,
storeSiteSpecificTrackingException MUST return immediately.
If the list arrayOfDomainStrings is supplied, the user agent MAY choose to
store a site-wide exception. If it does so it MUST indicate this in the
return value.
If domain is not specified or is null or empty then the execution of this
API and the use of the resulting permission (if granted) use the
'implicit' parameter, when the API is called, the document origin. This
forms the first part of the duplet in the logical model, and hence in
operation will be compared with the top-level origin.
If permission is stored for an explicit list, then the set of duplets (one
per target):
[document-origin, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[document-origin, * ]
is added to the database of remembered grants.
If domain is supplied and not empty then it is treated in the same way as
the domain parameter to cookies and allows setting for subdomains. The
domain argument can be set to fully-qualified right-hand segment of the
document host name, up to one level below TLD.
For example, www.foo.bar.example.com can set the domain parameter as as
"bar.example.com" or "example.com", but not to
"something.else.example.com" or "com".
If the document-origin would not be able to set a cookie on the domain
following the cookie domain rules [RFC6265] (e.g. domain is not a
right-hand match or is a TLD) then the duplet MUST NOT be entered into the
database and a SYNTAX_ERR exception SHOULD be thrown.
If permission is stored for an explicit list, then the set of duplets (one
per target):
[*.domain, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[*.domain, * ]
is added to the database of remembered grants.
A particular response to the API — like a DNT response header field — is
only valid immediately; a user might later choose to edit stored
exceptions and revoke some or all of them.
If expires is supplied and not null or empty the remembered grant will be
cancelled (i.e. processed as if the relevant Cancel API had been called)
no later than the specified date and time. After this the database of
remembered grants will no longer contain any duplets for which the first
part is the current document origin; i.e., no duplets [document-origin,
target] for any target.
If maxAge is supplied and not null, empty or negative the remembered grant
will be cancelled (i.e. processed as if the relevant Cancel API had been
called) no later than the specified number of seconds following the grant.
If both maxAge and expires are supplied, maxAge has precedence. If neither
maxAge or expires are supplied, the user agent MAY retain the remembered
grant until it is cancelled.
7.4.2 API to Cancel a Site-specific Exception
partial interface Navigator {
void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag proper
ties);
};
removeSiteSpecificTrackingException
If domain is not supplied or is null or empty then this ensures
that the database of remembered grants no longer contains any
duplets for which the first part is the current document origin;
i.e., no duplets [document-origin, target] for any target.
If domain is supplied and is not empty then this ensures that the
database of remembered grants no longer contains any duplets for
which the first part is the domain wildcard; i.e., no duplets
[*.domain, target] for any target.
There is no callback. After the call has been made, it is assured
that there are no site-specific or site-wide exceptions for the
given top-level origin.
Parameter Type Nullable Optional Description
properties RemoveExceptionPropertyBag ✘ ✘
Return type: void
dictionary RemoveExceptionPropertyBag {
DOMString? domain;
};
domain of type DOMString, nullable
a cookie-domain as defined in [RFC6265], to which the exception
applies.
When this method returns, the database of grants no longer contains the
indicated grant(s); if some kind of processing error occurred then an
appropriate exception will be thrown.
If there are no matching duplets in the database of remembered grants when
the method is called then this operation does nothing (and does not throw
an exception).
7.4.3 API to Confirm a Site-specific Exception
partial interface Navigator {
boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptionP
ropertyBag properties);
};
confirmSiteSpecificTrackingException
Called by a page to confirm a site-specific tracking exception.
Parameter Type Nullable Optional Description
properties ConfirmSiteSpecificExceptionPropertyBag ✘ ✘
Return type: boolean
dictionary ConfirmExceptionPropertyBag {
DOMString? domain;
};
domain of type DOMString, nullable
a cookie-domain as defined in [RFC6265], to which the exception
applies.
dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBa
g {
sequence<DOMString> arrayOfDomainStrings;
};
arrayOfDomainStrings of type sequence<DOMString>,
A JavaScript array of strings.
If the call does not include the arrayOfDomainStrings, then this call is
to confirm a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target.
If the list arrayOfDomainStrings is supplied, and the user agent stores
only site-wide exceptions, then the user agent MUST match by confirming a
site-wide exception.
If the domain argument is not supplied or is null or empty then the
execution of this API uses the 'implicit' parameter, when the API is
called, the document origin. This forms the first part of the duplet in
the logical model.
If the user agent stores explicit lists, and the call includes one, the
database is checked for the existence of all the duplets (one per target):
[document-origin, target]
If the user agent stores only site-wide exceptions or the call did not
include an explicit list, the database is checked for the single duplet:
[document-origin, * ]
If the user agent stores explicit lists, the call includes one, and the
domain argument is provided and is not empty, then the database is checked
for the existence of all the duplets (one per target):
[*.domain, target]
If the user agent stores only site-wide exceptions or the call did not
include an explicit list, and the domain argument is provided and is not
empty then the database is checked for the single duplet:
[*.domain, * ]
The returned boolean has the following possible values:
* true all the duplets exist in the database;
* false one or more of the duplets does not exist in the database.
7.5 Web-wide Exceptions
7.5.1 API to Request a Web-wide Exception
partial interface Navigator {
void storeWebWideTrackingException (StoreExceptionPropertyBag properties);
};
storeWebWideTrackingException
The single duplet [ * , document-origin] or [ * , *.domain] (based
on if domain is provided and is not null and not empty) is added
to the database of remembered grants. The properties of the
StoreExceptionPropertyBag dictionary are as described above in the
request for site-specific exceptions.
Parameter Type Nullable Optional Description
properties StoreExceptionPropertyBag ✘ ✘
Return type: void
This API requests the addition of a web-wide grant for a specific site to
the database.
7.5.2 API to Cancel a Web-wide Exception
partial interface Navigator {
void removeWebWideTrackingException (RemoveExceptionPropertyBag properties)
;
};
removeWebWideTrackingException
Ensures that the database of remembered grants no longer contains
the duplet [ * , document-origin] or [ * , *.domain] (based on if
domain is provided and is not null and not empty). There is no
callback. After the call has been made, the indicated pair is
assured not to be in the database. The same matching process
defined for determining which header field to send is also used to
detect which entry (if any) to remove from the database.
Parameter Type Nullable Optional Description
properties RemoveExceptionPropertyBag ✘ ✘
Return type: void
7.5.3 API to Confirm a Web-wide Exception
partial interface Navigator {
boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag proper
ties);
};
confirmWebWideTrackingException
Confirms that there exists in the database a web-wide exception
for a specific site.
Parameter Type Nullable Optional Description
properties ConfirmExceptionPropertyBag ✘ ✘
Return type: boolean
The returned boolean indicates whether the duplet [ * , document-origin]
or [ * , *.domain] (based on if domain is provided and is not null and not
empty) exists in the database.
* true indicates that the web-wide exception exists;
* false indicates that the web-wide exception does not exist.
7.6 User Interface Guidelines
This section is non-normative.
As described above, it is the sole responsibility of the site making an
API call to determine that an exception grant reflects the user's informed
consent at the time of the call.
It is expected that a site will explain to the user, in its online
content, the need for an exception and the consequences of granting or
denying that exception.
User agents are free to implement exception management user interfaces as
they see fit. Some agents might provide a notification to the user at the
time of the request, or even not complete the storing of the exception
until the user approves. Some agents might provide a user-interface to see
and edit the database of recorded exception grants. The API parameters
siteName, explanationString, and detailURI are provided so that the user
agent can use them in their user interface. If a user agent presents these
parameters to the user, it ought to be clear that they are provided for
informational value and are less important than the exception's technical
effect.
A user agent that chooses to highlight when tracking exceptions have been
stored might provide an interface like the following:
* an icon in the status bar indicating that an exception has been
stored, which, when clicked on, gives the user more information about
the exception and an option to revoke such an exception.
* an infobar stating "Example News (news.example.com) has indicated to
Browser that you have consented to granting it exceptions to your
general Do Not Track preference. If you believe this is incorrect,
click Revoke."
* no UI at all.
In some user agent implementations, decisions to grant exceptions might
have been made in the past (and since forgotten) or might have been made
by other users of the device. Thus, exceptions might not always represent
the current preferences of the user. Some user agents might choose to
provide ambient notice that user-opted tracking is ongoing, or easy access
to view and control these preferences. Users might also desire to edit
exceptions within a separate user interface, which would allow a user to
modify their stored exceptions without visiting the target sites.
7.7 Exceptions without Interactive JavaScript
This section is non-normative.
Some third party servers that might wish to receive a user-granted
exception do not have the ability to invoke an interactive JavaScript
presence on a page (for example, those that provide only images or
"tracking pixels"). They cannot request an exception under these
circumstances, both because a script is needed, and because they would be
required to explain to the user the need for and consequences of granting
an exception, and get the user's consent. In general, this process of
informing, getting consent, and calling the API is not expected within
page elements where such trackers are invoked.
To obtain an exception, a document (page, frame, etc.) that loads the
Javascript is needed. The user might visit the site that desires an
exception directly, the first party site could load a frame of the site
desiring the exception, or that frame might be part of some other page
containing a number of frames, which allows aggregation of requests for
exceptions.
In all these ways, the site is contributing to informing the user and
obtaining their consent, while enabling a call to the Javascript API when
such consent is granted.
7.8 Exceptions without an Expressed Preference
Sites might wish to request exceptions even when a user arrives without a
DNT header field. Users might wish to grant affirmative permission to
tracking on or by certain sites even without expressing a general tracking
preference.
User agents MAY instantiate navigator.storeSiteSpecificTrackingException
even when window.doNotTrack is null. Scripts SHOULD test for the existence
of storeSiteSpecificTrackingException before calling the method. If an
exception is granted and the user agent stores that preference, a user
agent might send the DNT:0 tracking preference even if it has not enabled
preferences to be sent for other requests. Persisted preferences MAY
affect which preference is transmitted if a user later chooses to express
a tracking preference.
Note
Users might not configure their agents to have simple values for DNT, but
use different browsing modes or other contextual information to decide on
a DNT value. What algorithm a user agent employs to determine DNT values
(or the lack thereof) is out of the scope of this specification.
7.9 Exception Use by Sites
This section is non-normative.
This section is to inform the authors of sites on some considerations in
using the exceptions APIs to best effect; sites of particular interest
here are those that need an exception in order to allow the user to
perform some operation or to have some access.
The 'Store' calls return immediately, without a return value. If there is Information communicated via the DNT header field is minimized to avoid
a problem with the calling parameters, then a Javascript exception will be abuse of the field for fingerprinting or as a side-channel. However,
raised. future DNT-extensions might allow for the sending of additional
information when signaling consent for tracking via DNT:0, since this
consent mechanism is intended to be more persistent than cookies and could
be used to convey a pseudonymous identifier as a user-preferred
alternative to allowing a cookie to be set.
A user agent might not store the exception immediately, possibly because Use of client-side storage is always a security concern. Although the
it is allowing the user to confirm. Even though the site has acquired the information being stored for each user-granted exception is limited and
user's informed consent before calling the 'Store' API, it is possible cannot be directly accessed by scripts, storing too many exceptions might
that the user will change their mind, allow the storing of an exception to exceed available storage or indicate an attempt to exploit other
proceed but later remove it, or perhaps deny the storage by prior vulnerabilities.
configuration.
Nonetheless, at the time of the call, the site has acquired the user's There are also security concerns regarding the ability of scripts to store
consent and can proceed on that basis, whether or not the user-agent has exceptions beyond the scope of their effective script origin. See the note
stored the exception immediately. It is not necessary to call the confirm about API security in section 6.6.1 API to Store a Tracking Exception.
API at the time of consent.
On other visits, a site can call the 'Confirm' APIs to enquire whether a 10. Privacy Considerations
specific exception has been granted and stands in the user agent. This is
the call to make to determine whether the exception exists, and hence to
control access to the function or operation; if it fails (the exception
has been deleted or not yet granted), then the user is ideally again
offered the information needed to give their informed consent, and again
offered the opportunity to indicate that they grant it. As stated in the
normative text, the site needs to explain and acquire consent immediately
prior to calling the Store API, and not remember some past consent; this
allows a user to change their mind.
If they do grant it (using some positive interaction such as a button), 10.1 Why DNT:1 is Not Preconfigured by Default
the site can return to checking the 'Confirm' API.
In this way the site: This specification defines a protocol for communicating the user's
tracking preference, not a protocol that prevents tracking on its own. It
might be tempting to assume that design for privacy would justify calling
for DNT:1 to be preconfigured as the default for all user agents. However,
that would violate the field's semantics, make its presence in a request
meaningless, and add eight extra bytes to every HTTP request (with no
effect).
* does not assume that the storage is instantaneous and mistakenly grant The DNT signal alone does nothing to enhance a user's privacy. It is only
access when the exception does not (yet) stand; when recipients believe that the signal has been deliberately and
* does not call the Confirm API repeatedly, in a loop, without a knowingly configured, and not defined as a default, that they will
user-interaction between each call; and, consider it to be the user's preference. Furthermore, when no signal is
* permits the user the opportunity to delete a previously granted sent, recipients remain subject to whatever regulatory, legal, or other
exception. regional requirements regarding tracking exist in the absence of consent.
7.10 Fingerprinting 10.2 Fingerprinting
By storing a client-side configurable state and providing functionality to User-granted exceptions introduce a privacy risk. By storing client-side
learn about it later, this API might facilitate user fingerprinting and configurable state and providing functionality to learn about it later,
the user-granted exceptions 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. requests or using other heuristics to mitigate fingerprinting risk.
10.3 Stored Exceptions are Stored History
A database of stored exceptions is effectively storing a local history of
the sites browsed by the user over time. Separate databases are needed per
user profile (and per incognito session) and ought to be protected from
observation. A user might wish to clear stored exceptions, or clear the
database as a whole, but as a separate action from clearing the visible
browser history.
A. Acknowledgements A. Acknowledgements
This specification consists of input from many discussions within and This specification consists of input from many discussions within and
around the W3C Tracking Protection Working Group, along with written around the W3C Tracking Protection Working Group, along with written
contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT),
Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited
Expert), Roy T. Fielding (Adobe), Vinay Goel (Adobe), Tom Lowenthal Expert), Roy T. Fielding (Adobe), Vinay Goel (Adobe), Tom Lowenthal
(Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Stanford), (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Stanford),
Mike O'Neill (Baycloud Systems), Matthias Schunter (Intel), John Simpson Mike O'Neill (Baycloud Systems), Matthias Schunter (Intel), John Simpson
(Consumer Watchdog), David Singer (Apple), Rigo Wenning (W3C/ERCIM), (Consumer Watchdog), David Singer (Apple), Rigo Wenning (W3C/ERCIM),
skipping to change at line 1825 skipping to change at line 1833
The DNT header field is based on the original Do Not Track submission by The DNT header field is based on the original Do Not Track submission by
Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm
(Mozilla). The JavaScript DOM property for doNotTrack is based on the Web (Mozilla). The JavaScript DOM property for doNotTrack is based on the Web
Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Tracking Protection submission by Andy Zeigler, Adrian Bateman, and
Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.
B. Registrations B. Registrations
The Internet media type application/tracking-status+json is used for The Internet media type application/tracking-status+json is used for
tracking status representations (section 6.5 Tracking Status tracking status representations (section 7.5 Tracking Status
Representation). Representation).
Type name: Type name:
application application
Subtype name: Subtype name:
tracking-status+json tracking-status+json
Required parameters: Required parameters:
N/A N/A
skipping to change at line 1850 skipping to change at line 1858
Encoding considerations: Encoding considerations:
binary binary
Security considerations: Security considerations:
See JSON [RFC7159], Section 12. See JSON [RFC7159], Section 12.
Interoperability considerations: Interoperability considerations:
N/A N/A
Published specification: Published specification:
Tracking Preference Expression (DNT), section 6.5 Tracking Status Tracking Preference Expression (DNT), section 7.5 Tracking Status
Representation. Representation.
http://www.w3.org/TR/tracking-dnt/ https://www.w3.org/TR/tracking-dnt/
Applications that use this media type: Applications that use this media type:
N/A N/A
Fragment identifier considerations: Fragment identifier considerations:
N/A N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
skipping to change at line 1886 skipping to change at line 1894
Roy T. Fielding and David Singer Roy T. Fielding and David Singer
Change controller: Change controller:
W3C W3C
C. References C. References
C.1 Normative references C.1 Normative references
[HTML5] [HTML5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead;
Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 28
2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/ October 2014. W3C Recommendation. URL:
https://www.w3.org/TR/html5/
[RFC2119] [RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Key words for use in RFCs to Indicate Requirement Levels. S.
Levels. March 1997. Best Current Practice. URL: Bradner. IETF. March 1997. Best Current Practice. URL:
https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/rfc2119
[RFC3986] [RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee;
Identifier (URI): Generic Syntax. January 2005. Internet Standard. R. Fielding; L. Masinter. IETF. January 2005. Internet Standard.
URL: https://tools.ietf.org/html/rfc3986 URL: https://tools.ietf.org/html/rfc3986
[RFC5234] [RFC5234]
D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P.
Specifications: ABNF. January 2008. Internet Standard. URL: Overell. IETF. January 2008. Internet Standard. URL:
https://tools.ietf.org/html/rfc5234 https://tools.ietf.org/html/rfc5234
[RFC6265] [RFC6265]
A. Barth. HTTP State Management Mechanism. April 2011. Proposed HTTP State Management Mechanism. A. Barth. IETF. April 2011.
Standard. URL: https://tools.ietf.org/html/rfc6265 Proposed Standard. URL: https://tools.ietf.org/html/rfc6265
[RFC7159] [RFC7159]
T. Bray, Ed.. The JavaScript Object Notation (JSON) Data The JavaScript Object Notation (JSON) Data Interchange Format. T.
Interchange Format. March 2014. Proposed Standard. URL: Bray, Ed.. IETF. March 2014. Proposed Standard. URL:
https://tools.ietf.org/html/rfc7159 https://tools.ietf.org/html/rfc7159
[RFC7230] [RFC7230]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and
(HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014.
Standard. URL: https://tools.ietf.org/html/rfc7230 Proposed Standard. URL: https://tools.ietf.org/html/rfc7230
[RFC7231] [RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R.
(HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed
URL: https://tools.ietf.org/html/rfc7231 Standard. URL: https://tools.ietf.org/html/rfc7231
[RFC7234] [RFC7234]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. Hypertext Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.;
Transfer Protocol (HTTP/1.1): Caching. June 2014. Proposed M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed
Standard. URL: https://tools.ietf.org/html/rfc7234 Standard. URL: https://tools.ietf.org/html/rfc7234
[WEBIDL] [WEBIDL]
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 4 August 2015. Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15
W3C Working Draft. URL: http://www.w3.org/TR/WebIDL-1/ December 2016. W3C Editor's Draft. URL:
https://heycam.github.io/webidl/
C.2 Informative references C.2 Informative references
[ECMASCRIPT]
ECMAScript Language Specification. Ecma International. URL:
https://tc39.github.io/ecma262/
[KnowPrivacy] [KnowPrivacy]
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June KnowPrivacy. Joshua Gomez; Travis Pinnick; Ashkan Soltani. UC
2009. URL: Berkeley, School of Information. 01 June 2009. URL:
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf
[Orderly] [Orderly]
Lloyd Hilaiel. Orderly JSON. 10 Feb 2015. URL: Orderly JSON. Lloyd Hilaiel.22 February 2010. URL:
http://orderly-json.org/ https://github.com/lloyd/orderly
[PromiseGuide]
Writing Promise-Using Specifications. Domenic Denicola. W3C. 03
January 2017. Finding of the W3C TAG. URL:
http://www.w3.org/2001/tag/doc/promises-guide
[RFC5785] [RFC5785]
M. Nottingham; E. Hammer-Lahav. Defining Well-Known Uniform Defining Well-Known Uniform Resource Identifiers (URIs). M.
Resource Identifiers (URIs). April 2010. Proposed Standard. URL: Nottingham; E. Hammer-Lahav. IETF. April 2010. Proposed Standard.
https://tools.ietf.org/html/rfc5785 URL: https://tools.ietf.org/html/rfc5785
[RFC6570] [RFC6570]
J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard. URI Template. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham;
URI Template. March 2012. Proposed Standard. URL: D. Orchard. IETF. March 2012. Proposed Standard. URL:
https://tools.ietf.org/html/rfc6570 https://tools.ietf.org/html/rfc6570
[TCS] [TCS]
Nick Doty; Heather West; Justin Brookman; Sean Harvey; Erica Tracking Compliance and Scope. Nick Doty; Heather West; Justin
Newland. Tracking Compliance and Scope. 14 July 2015. W3C Last Brookman; Sean Harvey; Erica Newland. W3C. 31 March 2015. W3C
Call Working Draft. URL: http://www.w3.org/TR/tracking-compliance/ Working Draft. URL: https://www.w3.org/TR/tracking-compliance/
 End of changes. 121 change blocks. 
905 lines changed or deleted 916 lines changed or added

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