tpe_CR_20150321.txt   tpe_ED_20170702.txt 
W3C W3C
Tracking Preference Expression (DNT) Tracking Preference Expression (DNT)
W3C Candidate Recommendation 20 August 2015 W3C Editor's Draft 02 July 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. 1. Introduction
* 2. Terminology 2. 2. Terminology
* 2.1 HTTP 1. 2.1 HTTP
* 2.2 Activity 2. 2.2 HTML
* 2.3 Participants 3. 2.3 Activity
* 2.4 Data 4. 2.4 Participants
* 2.5 Preferences 5. 2.5 Data
* 3. Notational Conventions 3. 3. Notational Conventions
* 3.1 Requirements 1. 3.1 Requirements
* 3.2 Formal Syntax 2. 3.2 Formal Syntax
* 4. Determining User Preference 4. 4. Determining User Preference
* 5. Expressing a Tracking Preference 5. 5. Expressing a Tracking Preference
* 5.1 Expression Format 1. 5.1 Expression Format
* 5.2 DNT Header Field for HTTP Requests 2. 5.2 DNT Header Field for HTTP Requests
* 5.2.1 DNT Extensions 1. 5.2.1 Extensions to the DNT Field Value
* 5.3 JavaScript Property to Detect Preference 3. 5.3 JavaScript Property to Detect Preference
* 5.4 Tracking Preference Expressed in Other Protocols 4. 5.4 Tracking Preference Expressed in Other Protocols
* 6. Communicating a Tracking Status 6. 6. Communicating a Tracking Status
* 6.1 Overview 1. 6.1 Overview
* 6.2 Tracking Status Value 2. 6.2 Tracking Status Value
* 6.2.1 Definition 1. 6.2.1 Definition
* 6.2.2 Under Construction (!) 2. 6.2.2 Under Construction (!)
* 6.2.3 Dynamic (?) 3. 6.2.3 Dynamic (?)
* 6.2.4 Gateway (G) 4. 6.2.4 Gateway (G)
* 6.2.5 Not Tracking (N) 5. 6.2.5 Not Tracking (N)
* 6.2.6 Tracking (T) 6. 6.2.6 Tracking (T)
* 6.2.7 Consent (C) 7. 6.2.7 Consent (C)
* 6.2.8 Potential Consent (P) 8. 6.2.8 Potential Consent (P)
* 6.2.9 Disregarding (D) 9. 6.2.9 Disregarding (D)
* 6.2.10 Updated (U) 10. 6.2.10 Updated (U)
* 6.3 Tk Header Field for HTTP Responses 11. 6.2.11 Extensions to the Tracking Status Value
* 6.3.1 Definition 3. 6.3 Tk Header Field for HTTP Responses
* 6.3.2 Referring to a Request-specific Tracking Status 1. 6.3.1 Definition
2. 6.3.2 Referring to a Request-specific Tracking Status
Resource Resource
* 6.3.3 Indicating an Interactive Status Change 3. 6.3.3 Indicating an Interactive Status Change
* 6.4 Tracking Status Resource 4. 6.4 Tracking Status Resource
* 6.4.1 Site-wide Tracking Status 1. 6.4.1 Site-wide Tracking Status
* 6.4.2 Request-specific Tracking Status 2. 6.4.2 Request-specific Tracking Status
* 6.4.3 Status Checks are Not Tracked 3. 6.4.3 Status Checks are Not Tracked
* 6.4.4 Caching 4. 6.4.4 Caching
* 6.5 Tracking Status Representation 5. 6.5 Tracking Status Representation
* 6.5.1 Status Object 1. 6.5.1 Status Object
* 6.5.2 Tracking Property 2. 6.5.2 Tracking Property
* 6.5.3 Compliance Property 3. 6.5.3 Compliance Property
* 6.5.4 Qualifiers Property 4. 6.5.4 Qualifiers Property
* 6.5.5 Controller Property 5. 6.5.5 Controller Property
* 6.5.6 Same-party Property 6. 6.5.6 Same-party Property
* 6.5.7 Audit Property 7. 6.5.7 Audit Property
* 6.5.8 Policy Property 8. 6.5.8 Policy Property
* 6.5.9 Config Property 9. 6.5.9 Config Property
* 6.5.10 Extensions 10. 6.5.10 Extensions to the Status Object
* 6.6 Status Code for Tracking Required 6. 6.6 Status Code for Tracking Required
* 6.7 Using the Tracking Status 7. 6.7 Using the Tracking Status
* 6.7.1 Discovering Deployment 1. 6.7.1 Discovering Deployment
* 6.7.2 Preflight Checks 2. 6.7.2 Preflight Checks
* 7. User-Granted Exceptions 7. 7. User-Granted Exceptions
* 7.1 Overview 1. 7.1 Motivating Principles
* 7.2 Motivating Principles and Use Cases 2. 7.2 Exception Model
* 7.3 Exception Model 3. 7.3 Granting Exception
* 7.3.1 User Interaction 4. 7.4 Exception Management
* 7.3.2 Processing Model 5. 7.5 Checking for Exception
* 7.4 Site-specific Exceptions 6. 7.6 Site-specific Exception
* 7.4.1 API to Request a Site-specific Exception 1. 7.6.1 API to Request a Site-specific Exception
* 7.4.2 API to Cancel a Site-specific Exception 2. 7.6.2 API to Cancel a Site-specific Exception
* 7.4.3 API to Confirm a Site-specific Exception 3. 7.6.3 API to Confirm a Site-specific Exception
* 7.5 Web-wide Exceptions 7. 7.7 Web-wide Exceptions
* 7.5.1 API to Request a Web-wide Exception 1. 7.7.1 API to Request a Web-wide Exception
* 7.5.2 API to Cancel a Web-wide Exception 2. 7.7.2 API to Cancel a Web-wide Exception
* 7.5.3 API to Confirm a Web-wide Exception 3. 7.7.3 API to Confirm a Web-wide Exception
* 7.6 User Interface Guidelines 8. 7.8 Exceptions without Interactive JavaScript
* 7.7 Exceptions without Interactive JavaScript 9. 7.9 Exceptions without an Expressed Preference
* 7.8 Exceptions without an Expressed Preference 10. 7.10 Exception Use by Sites
* 7.9 Exception Use by Sites 8. 8. Security Considerations
* 7.10 Fingerprinting 9. 9. Privacy Considerations
* A. Acknowledgements 1. 9.1 Fingerprinting
* B. Registrations 10. A. Acknowledgements
* C. References 11. B. Registrations
* C.1 Normative references 12. C. References
* C.2 Informative references 1. C.1 Normative references
2. 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 199
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 226
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, 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 306
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
skipping to change at line 444 skipping to change at line 435
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
interpret the lack of an expressed tracking preference as they find most interpret the lack of an expressed tracking preference as they find most
appropriate for the given user, particularly when considered in light of appropriate for the given user, particularly when considered in light of
the user's privacy expectations and cultural circumstances. Likewise, the user's privacy expectations and cultural circumstances. Likewise,
servers might make use of other preference information outside the scope servers might make use of other preference information outside the scope
of this protocol, such as site-specific user preferences or third-party of this protocol, such as site-specific user preferences or third-party
registration services, to inform or adjust their behavior when no explicit registration services, to inform or adjust their behavior when no explicit
preference is expressed via this protocol. preference is expressed via this protocol.
Note
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).
The DNT signal alone does nothing to enhance a user's privacy. It is only
when recipients believe that the signal has been deliberately and
knowingly configured, and not defined as a default, that they will
consider it to be the user's preference. Furthermore, when no signal is
sent, recipients remain subject to whatever regulatory, legal, or other
regional requirements regarding tracking exist in the absence of consent.
5.2 DNT Header Field for HTTP Requests 5.2 DNT Header Field for HTTP Requests
The DNT header field is a mechanism for expressing the user's tracking The DNT header field is a mechanism for expressing the user's tracking
preference in an HTTP request ([RFC7230]). At most one DNT header field preference in an HTTP request ([RFC7230]). At most one DNT header field
can be present in a valid request. can be present in a valid request.
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 7. 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 6.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
skipping to change at line 523 skipping to change at line 531
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 at-risk because no known extensions have
been defined, implementors that don't read specifications are likely to been defined; implementors 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 and
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 in requests to the effective script origin, taking
general preference (if any) and any user-granted exceptions applicable to into account the user's general preference (if any) and the current
that origin server. user-granted exceptions applicable to that target domain.
partial interface Navigator { partial interface Navigator {
readonly attribute DOMString? doNotTrack; readonly attribute DOMString? doNotTrack;
}; };
doNotTrack of type DOMString, readonly , nullable The value of Navigator.doNotTrack is the string value that would be sent
Returns the same string value that would be sent in a in a DNT field-value (section 5.2 DNT Header Field for HTTP Requests) in a
DNT-field-value (section 5.2 DNT Header Field for HTTP Requests) request to the effective script origin. The value is null if no DNT header
to a target that is the document-origin of the window, in the field would be sent (e.g., because a tracking preference is not enabled);
browser context of the current top-level origin. The value is null otherwise, the value is a string beginning with "0" or "1", possibly
if no DNT header field would be sent (e.g., because a tracking followed by DNT-extension characters.
preference is not enabled); otherwise, the value is a string
beginning with "0" or "1", possibly followed by DNT-extension
characters.
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. Communicating a Tracking Status
skipping to change at line 593 skipping to change at line 600
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 (!) 6.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.
skipping to change at line 738 skipping to change at line 746
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.2.11 Extensions to the Tracking Status Value
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
6.3 Tk Header Field for HTTP Responses 6.3 Tk Header Field for HTTP Responses
6.3.1 Definition 6.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).
skipping to change at line 767 skipping to change at line 799
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 6.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 835 skipping to change at line 867
/.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 6.4.4 Caching.
See section 6.7 Using the Tracking Status for examples of how tracking See section 6.7 Using the Tracking Status for examples of how tracking
status resources can be used to discover support for this protocol. status resources can be used to discover support for this protocol.
6.4.2 Request-specific Tracking Status 6.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 6.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}
skipping to change at line 895 skipping to change at line 927
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 6.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
skipping to change at line 1003 skipping to change at line 1035
{"tracking": "N"} {"tracking": "N"}
6.5.3 Compliance Property 6.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.
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.
6.5.4 Qualifiers Property 6.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.
skipping to change at line 1072 skipping to change at line 1111
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 6.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).
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.
6.5.9 Config Property 6.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 6.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.
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.
6.6 Status Code for Tracking Required 6.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 6.7 Using the Tracking Status
This section is non-normative.
Note 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 6.7.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
skipping to change at line 1144 skipping to change at line 1201
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 6.7.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 6.2 Tracking Status Value.
skipping to change at line 1167 skipping to change at line 1224
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 7. User-Granted Exceptions
7.1 Overview 7.1 Motivating Principles
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 The following principles guide the design of user-granted exceptions.
exceptions.
* Content providers might wish to prompt visitors to their properties to * Content providers might wish to prompt visitors to their properties to
opt back in to tracking for behavioral advertising or similar purposes opt back in to tracking for behavioral advertising or similar purposes
when they arrive with the Do Not Track setting enabled. when they arrive with the Do Not Track setting enabled.
* Privacy-conscious users might wish to view or edit all the exceptions * Privacy-conscious users might wish to view or edit all the exceptions
they've granted in a single, consistent user interface, rather than they've granted in a single, consistent user interface, rather than
managing preferences in a different way on every content provider or managing preferences in a different way on every content provider or
tracker's privacy page. tracker's privacy page.
* Granting an exception in one context (e.g., while browsing a news * Granting an exception in one context (e.g., while browsing a news
site) does not imply that exception is applicable to other contexts site) does not imply that exception is applicable to other contexts
(e.g., browsing an unrelated medical site). (e.g., browsing an unrelated medical site).
* Tracking providers ought to be able to avoid second-guessing a user's * Tracking providers ought to be able to avoid second-guessing a user's
expressed tracking preference. expressed tracking preference.
* The solution need not require cross-domain communication between a * The solution need not require cross-domain communication between a
first-party publisher and its third parties. first-party publisher and its third parties.
When asking for a site-specific exception, the top-level origin making the 7.2 Exception Model
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 A user-granted exception is the record of a decision by the user to grant
track them on any top-level origin. An API is provided so that a site consent for tracking (DNT:0) on future requests from a given context to a
might obtain such a web-wide exception from the user. set of target domains. Both context and target are scoped by domain,
similar to the existing domain scope of cookies (Section 5.3.1 of
[HTML5]), in order to avoid asking the user's exception for every
subdomain context of a site and every target resource that might be
referenced.
7.3 Exception Model 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 over their own consent
decisions, while also providing better persistence of those exceptions for
sites.
7.3.1 User Interaction There are potentially three different domain concepts involved in the
processing of user-granted exceptions:
The call to store an exception MUST reflect the user's intention to grant script domain
an exception at the time of that call. This intention MUST be determined the default context of a script when it accesses the exception
by the site prior to each call to store an exception, at the time of the database: specifically, the current document.domain of the
call. (This allows a user to change their mind and delete a stored script's responsible document.
exception, which might result in the site explaining and asking for the
exception again.) It is the sole responsibility of the site making the site domain
call to determine that a call to record an exception reflects the user's the context of a given reference for which the user-granted
informed consent at the time of that call. exceptions API might be queried: specifically, the current
document.domain of the top-level browsing context's active
document.
target domain
the uri-host subcomponent of the authority component of a
referenced "http" or "https" URI
A user-granted exception is site-specific if the context is limited to
requests embedded in, or referred by, a given site domain; otherwise, the
exception is web-wide and applies to all contexts. For example, a user
might wish to grant a target domain a web-wide exception for the purpose
of audience surveys, perhaps in exchange for some incentive.
When asking for a site-specific exception, the site making the request
might make some implicit or explicit claims as to the actions and behavior
of its third parties; for this reason, a site might want to establish
exceptions for only those target domains for which it can be 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, site-specific exceptions can either
be limited to a named set of target domains or applicable to any target
domain ("*").
7.3 Granting Exception
Note
This section is supposed to describe how a site would go about asking the
user for the various types of exception. The existing text is lacking that
necessary information.
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.
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
("*").
A site MAY ask for an exception, and have it stored, even when the user's 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 general preference is not enabled. This permits the sending of DNT only
allow tracking in jurisdictions where such permission cannot be assumed – for target resources for which an expressed preference is desired (see
see section 7.7 Exceptions without Interactive JavaScript.) section 7.9 Exceptions without an Expressed Preference).
The user agent MAY provide interfaces to 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.
* To indicate that a call to store an exception has just been made; A site MAY monitor for changes to its user-granted exceptions. If a user
* To allow the user to confirm a user-granted exception prior to revokes consent by deleting an exception, the site MUST respect that
storage; revocation, though it MAY ask again for a new exception. In other words, a
* To indicate that one or more exceptions exist for the current site MUST NOT resurrect a deleted exception without first interacting with
top-level origin; and receiving new exception from the user.
* 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 A site MUST have a site-wide tracking status resource with a valid
choose to provide no user interface regarding user-granted exceptions. tracking status representation when making an API call to store a
user-granted exception. This allows a user agent to obtain and possibly
store additional information about the calling site’s controller and
tracking policies at the time an exception is granted.
If the user revokes the consent by deleting the exception, the site MUST A user agent MAY choose to reject an API call if it cannot determine the
respect that revocation (though it MAY ask again for the exception). The script origin or if the script origin does not have a site-wide tracking
site MUST NOT use this exception mechanism if it will deem consent to status resource with a valid tracking status representation.
exist even after the exception has been revoked.
7.3.2 Processing Model 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.
This section describes the effect of the APIs in terms of a logical A user-agent MUST handle each API request as a 'unit', granting and
processing model; this model describes the behavior, but is not to be read maintaining it in its entirety, or not at all. That means that a user
as mandating any specific implementation. 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.
This API considers exceptions which are double-keyed to two domains: the There is no required user interface for a user agent regarding the
site, and the target. A user might — for instance — want AnalytiCo to be granting of exceptions; a user agent MAY choose to provide none.
allowed to track them on Example News, but not on Example Medical. To Alternatively, a user agent MAY:
simplify language used in this API specification, we define three terms:
* A top-level origin is the top-level browsing context, as defined by * indicate that a call to store an exception has just been made;
[HTML5]; * allow the user to confirm a user-granted exception prior to storage;
* A target site is the host subcomponent of the authority part in an * indicate that one or more exceptions exist for the current top-level
"http" or "https" URI, as defined by [RFC7230] and [RFC3986]; and, origin;
* The document origin of a script is the effective script origin, as * indicate that one or more exceptions exist for sites incorporated into
defined by [HTML5]. the current page; or,
* indicate how to manage the exceptions granted.
For instance, if the document at When an explicit list of domains is provided through the API, their names
http://web.exnews.com/news/story/2098373.html references the resources might mean little to the user. The user might, for example, be told that
http://exnews.analytico.net/1x1.gif and there is a stored exception for a specific set of sites on such-and-such
http://widgets.exsocial.org/good-job-button.js, the top-level origin is top-level origin, rather than listing them by name; or the user agent
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both might decide to store a site-wide exception, effectively ignoring any list
targets. of domain names.
The domains that enter into the behavior of the APIs include: 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.
* As described above, the document origin active at the time of the 7.4 Exception Management
call, and;
* Domain names passed to the API.
Domains that enter into the decision over what DNT header field to be sent User agents are free to implement exception management user interfaces as
in a given request include: 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 top-level origin of the current browser context; The API parameters siteName, explanationString, and detailURI are provided
* The target of the request. so that the user agent can use them in their user interface. If a user
Note 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.
Note that these strict, machine-discoverable concepts might not match the A user agent that chooses to highlight when tracking exceptions have been
definitions of first and third party; in particular, sites themselves need stored might provide an interface like the following:
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 * an icon in the status bar indicating that an exception has been
of the exception, if the user agent asks for it): stored, which, when clicked on, gives the user more information about
the exception and an option to revoke it.
* an infobar stating "Example News (news.example.com) has indicated to
Browser that you have consented to granting it exception for tracking.
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.5 Checking for Exception
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.
* 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 * 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 header field is to be sent to a target domain, if the duplet
[top-level origin, target domain] matches any duplet in the database, [top-level origin, target domain] matches any duplet in the database,
then a DNT:0 preference is sent, otherwise the user’s general then a DNT:0 preference is sent, otherwise the user’s general
preference is sent (if any). preference is sent (if any).
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A 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: pair of values A and X match if and only if one of the following is true:
* either A or X is "*"; * either A or X is "*";
* A and X are the same string; * A and X are the same string;
* A has the form '*.domain' and X is 'domain' or is of the form * A has the form '*.domain' and X is 'domain' or is of the form
'string.domain', where 'string' is any sequence of characters. 'string.domain', where 'string' is any sequence of characters.
In addition, responses to the JavaScript API indicated should be In addition, responses to the JavaScript API indicated should be
consistent with this user preference (see below). consistent with this user preference (see below). [The editor has no idea
what that is supposed to mean.]
User-agents MUST handle each API request as a 'unit', granting and For example, a user might grant exception for metrics.example.net to track
maintaining it in its entirety, or not at all. That means that a user their activity on news.example.com and weather.example.com, but not on
agent MUST NOT indicate to a site that a request for targets {a, b, c} medical.example.org. If the document at
exists in the database, and later remove only one or two of {a, b, c} from http://news.example.com/news/story/2098373.html has embedded references to
its logical database of remembered grants. This assures sites that the set http://metrics.example.net/1x1.gif and
of sites they need for operational integrity is treated as a unit. Each http://weather.example.com/widget.js, the site domain (context) for those
separate call to an API is a separate unit. references is news.example.com and the target domains are
metrics.example.net and weather.example.com, respectively.
It is left up to individual user agent implementations how to determine 7.6 Site-specific Exception
and how and whether to store users' tracking preferences.
When an explicit list of domains is provided through the API, their names Note
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 We currently specify six different APIs (plus the doNotTrack property
stored exception for all third-parties that are embedded by the indicated which now appears to be useless) with three distinct definitions of an
top-level origin. exception record and three distinct return types. Also, we use a single
(inappropriate) exception to signal all errors.
7.4 Site-specific Exceptions What we should have is one exception record and three APIs for
store/confirm/delete with a single Promise return type and a distinct
exception name for each error. The interfaces should be defined using an
algorithm similar to other specifications of promise-based interfaces. We
should also remove the expires field since it was intended to be replaced
(everywhere) by maxAge and is only kept in HTTP for legacy reasons.
7.4.1 API to Request a Site-specific Exception 7.6.1 API to Request a Site-specific Exception
Navigator.storeSiteSpecificTrackingException is called by a page to store
a site-specific tracking exception. A StoreExceptionPropertyBag dictionary
contains the information to be stored for that exception. It returns a
Promise resolving to a StoreExceptionResult result object.
partial interface Navigator { partial interface Navigator {
void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty Promise<StoreExceptionResult>
Bag properties); storeSiteSpecificTrackingException(StoreExceptionPropertyBag 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 { dictionary StoreExceptionPropertyBag {
DOMString? domain; DOMString? domain;
DOMString? siteName; DOMString? siteName;
DOMString? explanationString; DOMString? explanationString;
DOMString? detailURI; DOMString? detailURI;
DOMString? expires; DOMString? expires;
long? maxAge; long? maxAge;
sequence<DOMString> arrayOfDomainStrings;
}; };
detailURI of type DOMString, nullable dictionary StoreExceptionResult {
A location at which further information about this request can be boolean siteWide;
found. };
domain of type DOMString, nullable Navigator.storeSiteSpecificTrackingException passes a
StoreExceptionPropertyBag that can contain the following properties:
domain
a cookie-domain as defined in [RFC6265], to which the exception a cookie-domain as defined in [RFC6265], to which the exception
applies. applies.
expires of type DOMString, nullable siteName
A user-readable string for the name of the top-level origin.
explanationString
A short explanation of the request.
detailURI
A location at which further information about this request can be
found.
expires
A date and time, encoded as described for the cookie Expires A date and time, encoded as described for the cookie Expires
attribute described in [RFC6265], indicating the maximum lifetime attribute described in [RFC6265], indicating the maximum lifetime
of the remembered grant. of the remembered grant.
explanationString of type DOMString, nullable maxAge
A short explanation of the request.
maxAge of type long, nullable
A positive number of seconds indicating the maximum lifetime of A positive number of seconds indicating the maximum lifetime of
the remembered grant. the remembered grant.
siteName of type DOMString, nullable arrayOfDomainStrings
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. A JavaScript array of strings.
The storeSiteSpecificTrackingException method takes a dictionary argument Calling storeSiteSpecificTrackingException returns a Promise which either
of type StoreSiteSpecificExceptionPropertyBag that allows optional resolves to a StoreExceptionResult object, or is rejected with a
information to be provided. DOMException SYNTAX_ERR result. The Promise resolves immediately the
Tracking Exception request has been processed, with the property siteWide
set to true if the exception is site-wide.
If the request does not include the arrayOfDomainStrings, then this If the request does not include the arrayOfDomainStrings, then this
request is for a site-wide exception. Otherwise each string in request is for a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target. When called, arrayOfDomainStrings specifies a target domain.
storeSiteSpecificTrackingException MUST return immediately.
If the list arrayOfDomainStrings is supplied, the user agent MAY choose to 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 store a site-wide exception. If it does so it MUST indicate this by
return value. setting the siteWide property to true.
If domain is not specified or is null or empty then the execution of this If domain is not specified or is null or empty then the script domain is
API and the use of the resulting permission (if granted) use the used instead.
'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 If an exception is stored for an explicit list, then the set of duplets
per target): (one per target domain):
[document-origin, target] [script domain, target domain]
is added to the database of remembered grants. is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet: If an exception is stored for a site-wide exception, then the duplet:
[document-origin, * ] [script domain, * ]
is added to the database of remembered grants. is added to the database of remembered grants.
If domain is supplied and not empty then it is treated in the same way as 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 the domain parameter to cookies and allows setting for subdomains. The
domain argument can be set to fully-qualified right-hand segment of the domain argument can be set to a fully-qualified right-hand segment of the
document host name, up to one level below TLD. document host name, up to one level below TLD.
For example, www.foo.bar.example.com can set the domain parameter as as For example, www.foo.bar.example.com can set the domain parameter as as
"bar.example.com" or "example.com", but not to "bar.example.com" or "example.com", but not to
"something.else.example.com" or "com". "something.else.example.com" or "com".
If the document-origin would not be able to set a cookie on the domain If the effective script origin would not be able to set a cookie on the
following the cookie domain rules [RFC6265] (e.g. domain is not a 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 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. database and the returned Promise MUST be rejected with a DOMException
SYNTAX_ERR.
If permission is stored for an explicit list, then the set of duplets (one If an exception is stored for an explicit list, then the set of duplets
per target): (one per target domain):
[*.domain, target] [*.domain, target domain]
is added to the database of remembered grants. is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet: If an exception is stored for a site-wide exception, then the duplet:
[*.domain, * ] [*.domain, * ]
is added to the database of remembered grants. is added to the database of remembered grants.
A particular response to the API — like a DNT response header field — is A particular response to the API — like a DNT response header field — is
only valid immediately; a user might later choose to edit stored only valid immediately; a user might later choose to edit stored
exceptions and revoke some or all of them. exceptions and revoke some or all of them.
If expires is supplied and not null or empty the remembered grant will be 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) 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 no later than the specified date and time.
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 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 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. called) no later than the specified number of seconds following the grant.
If both maxAge and expires are supplied, maxAge has precedence. If neither If both maxAge and expires are supplied, maxAge has precedence. If neither
maxAge or expires are supplied, the user agent MAY retain the remembered maxAge or expires are supplied, the user agent MAY retain the remembered
grant until it is cancelled. grant until it is cancelled.
7.4.2 API to Cancel a Site-specific Exception 7.6.2 API to Cancel a Site-specific Exception
Navigator.removeSiteSpecificTrackingException is called by a page to
cancel a site-specific tracking exception. A RemoveExceptionPropertyBag
dictionary contains information to identify the exception.
partial interface Navigator { partial interface Navigator {
void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag proper Promise<void>
ties); removeSiteSpecificTrackingException(RemoveExceptionPropertyBag properties);
}; };
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 { dictionary RemoveExceptionPropertyBag {
DOMString? domain; DOMString? domain;
}; };
domain of type DOMString, nullable Navigator.removeSiteSpecificTrackingException passes a
RemoveExceptionPropertyBag that can contain the following property:
domain
a cookie-domain as defined in [RFC6265], to which the exception a cookie-domain as defined in [RFC6265], to which the exception
applies. applies.
When this method returns, the database of grants no longer contains the If domain is not supplied or is null or empty then the script domain is
indicated grant(s); if some kind of processing error occurred then an used instead. This asks for removal of all duplets in the grant database
appropriate exception will be thrown. for which the first part matches the script domain; i.e., no duplets
[script domain, target domain] for any target domain.
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 domain]
for any target domain.
A Promise resolving to void is returned. When the Promise has been
resolved, it is assumed that there are no site-specific or site-wide
exceptions for the given top-level origin.
When the returned Promise is resolved, 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 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 the method is called then this operation does nothing (and does not throw
an exception). an exception).
7.4.3 API to Confirm a Site-specific Exception 7.6.3 API to Confirm a Site-specific Exception
Navigator.confirmSiteSpecificTrackingException is called by a page to
confirm a site-specific exception. A ConfirmExceptionPropertyBag
dictionary contains information to identify the exception. It returns a
Promise resolving to a ConfirmExceptionResult result object.
partial interface Navigator { partial interface Navigator {
boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptionP Promise<ConfirmExceptionResult>
ropertyBag properties); confirmSiteSpecificTrackingException(ConfirmExceptionPropertyBag 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 { dictionary ConfirmExceptionPropertyBag {
DOMString? domain; DOMString? domain;
sequence<DOMString> arrayOfDomainStrings;
}; };
domain of type DOMString, nullable dictionary ConfirmExceptionResult {
boolean exists;
};
Navigator.confirmSiteSpecificTrackingException passes a
ConfirmExceptionPropertyBag that can contain the following properties:
domain
a cookie-domain as defined in [RFC6265], to which the exception a cookie-domain as defined in [RFC6265], to which the exception
applies. applies.
dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBa arrayOfDomainStrings
g {
sequence<DOMString> arrayOfDomainStrings;
};
arrayOfDomainStrings of type sequence<DOMString>,
A JavaScript array of strings. A JavaScript array of strings.
If the call does not include the arrayOfDomainStrings, then this call is If the call does not include the arrayOfDomainStrings, then this call is
to confirm a site-wide exception. Otherwise each string in to confirm a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target. arrayOfDomainStrings specifies a target domain.
If the list arrayOfDomainStrings is supplied, and the user agent stores If the list arrayOfDomainStrings is supplied, and the user agent stores
only site-wide exceptions, then the user agent MUST match by confirming a only site-wide exceptions, then the user agent MUST match by confirming a
site-wide exception. site-wide exception.
If the domain argument is not supplied or is null or empty then the If the domain argument is not supplied or is null or empty then the script
execution of this API uses the 'implicit' parameter, when the API is domain is used instead.
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 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): database is checked for the existence of all the duplets (one per target):
[document-origin, target] [script domain, target]
If the user agent stores only site-wide exceptions or the call did not 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: include an explicit list, the database is checked for the single duplet:
[document-origin, * ] [script domain, * ]
If the user agent stores explicit lists, the call includes one, and the 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 domain argument is provided and is not empty, then the database is checked
for the existence of all the duplets (one per target): for the existence of all the duplets (one per target):
[*.domain, target] [*.domain, target]
If the user agent stores only site-wide exceptions or the call did not 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 include an explicit list, and the domain argument is provided and is not
empty then the database is checked for the single duplet: empty then the database is checked for the single duplet:
[*.domain, * ] [*.domain, * ]
The returned boolean has the following possible values: The returned Promise resolves to a ConfirmExceptionResult object whose
boolean property exists has the following possible values:
* true all the duplets exist in the database; * true all the duplets exist in the database;
* false one or more of the duplets does not exist in the database. * false one or more of the duplets does not exist in the database.
7.5 Web-wide Exceptions 7.7 Web-wide Exceptions
7.5.1 API to Request a Web-wide Exception 7.7.1 API to Request a Web-wide Exception
Navigator.storeWebWideTrackingException is called by a page to request the
addition of a web-wide grant for a specific site to the database.
partial interface Navigator { partial interface Navigator {
void storeWebWideTrackingException (StoreExceptionPropertyBag properties); Promise<void> storeWebWideTrackingException(StoreExceptionPropertyBag
properties);
}; };
storeWebWideTrackingException Navigator.storeWebWideTrackingException passes a
The single duplet [ * , document-origin] or [ * , *.domain] (based StoreExceptionPropertyBag, as described in section 7.6.1 API to Request a
on if domain is provided and is not null and not empty) is added Site-specific Exception.
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 The single duplet [ * , script domain] or [ * , *.domain] (based on if
domain is provided and is not null and not empty) is added to the database
of remembered grants.
This API requests the addition of a web-wide grant for a specific site to 7.7.2 API to Cancel a Web-wide Exception
the database.
7.5.2 API to Cancel a Web-wide Exception Navigator.removeWebWideTrackingException is called by a page to request
the removal of a web-wide grant for a specific site from the database.
partial interface Navigator { partial interface Navigator {
void removeWebWideTrackingException (RemoveExceptionPropertyBag properties) Promise<void> removeWebWideTrackingException(RemoveExceptionPropertyBag
; properties);
}; };
removeWebWideTrackingException Navigator.removeWebWideTrackingException passes a
Ensures that the database of remembered grants no longer contains RemoveExceptionPropertyBag, as described in section 7.6.2 API to Cancel a
the duplet [ * , document-origin] or [ * , *.domain] (based on if Site-specific Exception.
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 Ensures that the database of remembered grants no longer contains the
properties RemoveExceptionPropertyBag ✘ ✘ duplet [ * , script domain] or [ * , *.domain] (based on if domain is
provided and is not null and not empty).
Return type: void A Promise resolving to void is returned. When the Promise is resolved, 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.
7.5.3 API to Confirm a Web-wide Exception 7.7.3 API to Confirm a Web-wide Exception
Navigator.confirmWebWideTrackingException is called by a page to confirm
that there exists in the database a web-wide exception for a specific
site.
partial interface Navigator { partial interface Navigator {
boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag proper Promise<ConfirmExceptionResult>
ties); confirmWebWideTrackingException(ConfirmSiteSpecificExceptionPropertyBag
properties);
}; };
confirmWebWideTrackingException dictionary ConfirmExceptionResult {
Confirms that there exists in the database a web-wide exception boolean exists;
for a specific site. };
Parameter Type Nullable Optional Description
properties ConfirmExceptionPropertyBag ✘ ✘
Return type: boolean Navigator.confirmWebWideTrackingException passes a
ConfirmExceptionPropertyBag, as described in section 7.6.3 API to Confirm
a Site-specific Exception.
The returned boolean indicates whether the duplet [ * , document-origin] The returned Promise resolves to a TrackingExceptionResult object with a
or [ * , *.domain] (based on if domain is provided and is not null and not boolean property exists indicating whether the duplet [ * , script domain]
or [ *, *.domain] (based on if domain is provided and is not null and not
empty) exists in the database. empty) exists in the database.
* true indicates that the web-wide exception exists; * true indicates that the web-wide exception exists;
* false indicates that the web-wide exception does not exist. * false indicates that the web-wide exception does not exist.
7.6 User Interface Guidelines 7.8 Exceptions without Interactive JavaScript
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. This section is non-normative.
Some third party servers that might wish to receive a user-granted Some third party servers that might wish to receive a user-granted
exception do not have the ability to invoke an interactive JavaScript exception do not have the ability to invoke an interactive JavaScript
presence on a page (for example, those that provide only images or presence on a page (for example, those that provide only images or
"tracking pixels"). They cannot request an exception under these "tracking pixels"). They cannot request an exception under these
circumstances, both because a script is needed, and because they would be circumstances because a script is needed to make the API call and it
required to explain to the user the need for and consequences of granting requires interaction to ensure the user is informed and to receive an
an exception, and get the user's consent. In general, this process of indication of their consent. In general, this process of informing,
informing, getting consent, and calling the API is not expected within getting consent, and calling the API is not expected within page elements
page elements where such trackers are invoked. where such trackers are invoked.
To obtain an exception, a document (page, frame, etc.) that loads the To obtain an exception, a document (page, frame, etc.) that loads the
Javascript is needed. The user might visit the site that desires an 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 exception directly, or the first party might provide a separate page that
desiring the exception, or that frame might be part of some other page could load script-enabled frames in which each third party could ask for
containing a number of frames, which allows aggregation of requests for an exception (allowing for aggregation of requests).
exceptions.
In all these ways, the site is contributing to informing the user and 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 obtaining their consent, while enabling a call to the Javascript API when
such consent is granted. such consent is granted.
7.8 Exceptions without an Expressed Preference 7.9 Exceptions without an Expressed Preference
Sites might wish to request exceptions even when a user arrives without a Sites might wish to request exceptions even when a user arrives without a
DNT header field. Users might wish to grant affirmative permission to DNT header field. Users might wish to grant affirmative exception to
tracking on or by certain sites even without expressing a general tracking tracking on or by certain sites even without expressing a general tracking
preference. preference.
User agents MAY instantiate navigator.storeSiteSpecificTrackingException User agents MAY instantiate Navigator.storeSiteSpecificTrackingException
even when window.doNotTrack is null. Scripts SHOULD test for the existence even when Navigator.doNotTrack is null. Scripts SHOULD test for the
of storeSiteSpecificTrackingException before calling the method. If an existence of storeSiteSpecificTrackingException before calling the method.
exception is granted and the user agent stores that preference, a user If an exception is granted and the user agent stores that preference, a
agent might send the DNT:0 tracking preference even if it has not enabled user agent might send the DNT:0 tracking preference even if it has not
preferences to be sent for other requests. Persisted preferences MAY enabled preferences to be sent for other requests. Persisted exceptions
affect which preference is transmitted if a user later chooses to express MAY affect which preference is transmitted if a user later chooses to
a tracking preference. configure a general 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 7.10 Exception Use by Sites
This section is non-normative. This section is non-normative.
This section is to inform the authors of sites on some considerations in This section is to inform the authors of sites on some considerations in
using the exceptions APIs to best effect; sites of particular interest using the user-granted exceptions APIs to best effect; sites of particular
here are those that need an exception in order to allow the user to interest here are those that need an exception in order to allow the user
perform some operation or to have some access. to perform some operation or to have some access.
The 'Store' calls return immediately, without a return value. If there is The 'Store' calls return immediately, without a return value. If there is
a problem with the calling parameters, then a Javascript exception will be a problem with the calling parameters, then a Javascript exception will be
raised. thrown.
A user agent might not store the exception immediately, possibly because 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 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 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 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 proceed but later remove it, or perhaps deny the storage by prior
configuration. configuration.
Nonetheless, at the time of the call, the site has acquired the user's Nonetheless, at the time of the call, the site has acquired the user's
consent and can proceed on that basis, whether or not the user-agent has consent and can proceed on that basis, whether or not the user-agent has
skipping to change at line 1796 skipping to change at line 1859
In this way the site: In this way the site:
* does not assume that the storage is instantaneous and mistakenly grant * does not assume that the storage is instantaneous and mistakenly grant
access when the exception does not (yet) stand; access when the exception does not (yet) stand;
* does not call the Confirm API repeatedly, in a loop, without a * does not call the Confirm API repeatedly, in a loop, without a
user-interaction between each call; and, user-interaction between each call; and,
* permits the user the opportunity to delete a previously granted * permits the user the opportunity to delete a previously granted
exception. exception.
7.10 Fingerprinting 8. Security Considerations
By storing a client-side configurable state and providing functionality to TBD.
learn about it later, this API might facilitate user fingerprinting and
9. Privacy Considerations
9.1 Fingerprinting
User-granted exceptions introduce a privacy risk. By storing client-side
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.
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
skipping to change at line 1852 skipping to change at line 1922
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 6.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 1956
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]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource
Identifier (URI): Generic Syntax. January 2005. Internet Standard.
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
[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 Jun 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.10 Feb 2015. URL:
http://orderly-json.org/ http://orderly-json.org/
[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. 158 change blocks. 
586 lines changed or deleted 645 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/