tracking-dnt-LCWD.txt   tracking-dnt-20150324.txt 
W3C W3C
Tracking Preference Expression (DNT) Tracking Preference Expression (DNT)
W3C Last Call Working Draft 24 April 2014 W3C Candidate Recommendation 24 March 2015
This version: This version:
http://www.w3.org/TR/2014/WD-tracking-dnt-20140424/ http://www.w3.org/TR/2015/CR-tracking-dnt-20150324/
Latest published version: Latest published version:
http://www.w3.org/TR/tracking-dnt/ http://www.w3.org/TR/tracking-dnt/
Latest editor's draft: Latest editor's draft:
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
Implementation report:
http://www.w3.org/2011/tracking-protection/track/products/7
Previous version: Previous version:
http://www.w3.org/TR/2014/WD-tracking-dnt-20140128/ http://www.w3.org/TR/2014/LCWD-tracking-dnt-20140424/
Editors: Editors:
Roy T. Fielding, Adobe Roy T. Fielding, Adobe
David Singer, Apple David Singer, Apple
Copyright (c) 2014 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights Copyright (c) 2015 W3C(R) (MIT, ERCIM, Keio, Beihang). W3C liability,
Reserved. W3C liability, trademark and document use rules apply. trademark and document use 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 the 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 site-specific exceptions granted by the user. It
also defines mechanisms for sites to communicate whether and how they also defines mechanisms for sites to communicate whether and how they
honor a received preference through use of the Tk response header field honor a received preference through use of the Tk response header field
and well-known resources that provide a machine-readable tracking status. and well-known resources that provide a machine-readable 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 http://www.w3.org/TR/.
This document was published by the Tracking Protection Working Group as a This document is a TEST for pre-publication review. Do not cite.
Last Call Working Draft on 24 April 2014. 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). All comments are publicly archived; if you have not used W3C
mailing lists in the past, you will need to approve archiving
(instructions are sent via email auto-reply) before your comments will be
distributed. The Last Call period ends 18 June 2014. All comments are
welcome.
The Tracking Protection Working Group invites broad community review, Please send comments about this document to
especially of technical requirements and dependencies. Reviewers are public-tracking-comments@w3.org (archived). An issue tracking system is
encouraged to comment on the extent to which technical requirements of the available for recording raised, open, pending review, closed, and
group's charter have been met and how significant dependencies with groups postponed issues regarding this document. There is also a list of issues
inside and outside W3C have been satisfied. The Working Group will reported and addressed during the Last Call period.
evaluate all comments received and determine whether or how the
specification needs to be modified in light of the comments. Comments will
be most useful in identifying technical problems with the TPE that might
inhibit adoption, or where the TPE fails to further goals of user privacy
and user control, and whether the TPE creates or does not otherwise
resolve dependencies with other technical standards, practices, or
processes. The Chairs of the Working Group will issue written responses to
all comments received.
Of note, this document does not define site behavior for complying with a The following feature is at risk and might be cut from the specification
user's expressed tracking preference, but does provide sites with a during the CR period if there are no (correct) implementations:
mechanism for indicating compliance. The Tracking Compliance and Scope
[TCS] specification which standardizes how sites should respond to Do Not
Track requests, including what information may be collected for limited
permitted uses despite a Do Not Track signal, is under discussion. The
Tracking Protection Working Group expects that specification to proceed to
Last Call in the summer of 2014. Both specifications are currently
scheduled to go to Candidate Recommendation in December 2014.
Readers may review changes from the previous Working Draft; in particular, * DNT-extension
recent changes include: updated definitions, revised requirements on
determining a user preference, and a media type. An issue tracking system
is available for recording issues regarding this document and their
resolutions.
Publication as a Last Call Working Draft does not imply endorsement by the This document was published by the Tracking Protection Working Group as a
W3C Membership. This is a draft document and may be updated, replaced or Candidate Recommendation. This document is intended to become a W3C
obsoleted by other documents at any time. It is inappropriate to cite this Recommendation. If you wish to make comments regarding this document,
document as other than work in progress. please send them to public-tracking@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 24 June 2015. All comments are
welcome.
This is a Last Call Working Draft and thus the Working Group has Please see the Working Group's implementation report.
determined that this document has satisfied the relevant technical
requirements and is sufficiently stable to advance through the Technical Publication as a Candidate Recommendation does not imply endorsement by
Recommendation process. the W3C Membership. This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to cite
this 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 1 August 2014 W3C Process Document.
Table of Contents Table of Contents
* 1. Introduction * 1. Introduction
* 2. Terminology * 2. Terminology
* 2.1 HTTP
* 2.2 Activity
* 2.3 Participants
* 2.4 Data
* 2.5 Preferences
* 3. Notational Conventions * 3. Notational Conventions
* 3.1 Requirements * 3.1 Requirements
* 3.2 Formal Syntax * 3.2 Formal Syntax
* 4. Determining User Preference * 4. Determining User Preference
* 5. Expressing a Tracking Preference * 5. Expressing a Tracking Preference
* 5.1 Expression Format * 5.1 Expression Format
* 5.2 DNT Header Field for HTTP Requests * 5.2 DNT Header Field for HTTP Requests
* 5.2.1 DNT Extensions
* 5.3 JavaScript Property to Detect Preference * 5.3 JavaScript Property to Detect Preference
* 5.4 Tracking Preference Expressed in Other Protocols * 5.4 Tracking Preference Expressed in Other Protocols
* 6. Communicating a Tracking Status * 6. Communicating a Tracking Status
* 6.1 Overview * 6.1 Overview
* 6.2 Tracking Status Value * 6.2 Tracking Status Value
* 6.2.1 Definition * 6.2.1 Definition
* 6.2.2 Under Construction (!) * 6.2.2 Under Construction (!)
* 6.2.3 Dynamic (?) * 6.2.3 Dynamic (?)
* 6.2.4 Not Tracking (N) * 6.2.4 Gateway (G)
* 6.2.5 Tracking (T) * 6.2.5 Not Tracking (N)
* 6.2.6 Consent (C) * 6.2.6 Tracking (T)
* 6.2.7 Potential Consent (P) * 6.2.7 Consent (C)
* 6.2.8 Disregarding (D) * 6.2.8 Potential Consent (P)
* 6.2.9 Updated (U) * 6.2.9 Disregarding (D)
* 6.2.10 Updated (U)
* 6.3 Tk Header Field for HTTP Responses * 6.3 Tk Header Field for HTTP Responses
* 6.3.1 Definition * 6.3.1 Definition
* 6.3.2 Referring to a Request-specific Tracking Status * 6.3.2 Referring to a Request-specific Tracking Status
Resource Resource
* 6.3.3 Indicating an Interactive Status Change * 6.3.3 Indicating an Interactive Status Change
* 6.4 Tracking Status Resource * 6.4 Tracking Status Resource
* 6.4.1 Site-wide Tracking Status * 6.4.1 Site-wide Tracking Status
* 6.4.2 Request-specific Tracking Status * 6.4.2 Request-specific Tracking Status
* 6.4.3 Status Checks are Not Tracked * 6.4.3 Status Checks are Not Tracked
* 6.4.4 Caching * 6.4.4 Caching
skipping to change at line 156 skipping to change at line 148
* 6.5.8 Policy Property * 6.5.8 Policy Property
* 6.5.9 Config Property * 6.5.9 Config Property
* 6.5.10 Extensions * 6.5.10 Extensions
* 6.6 Status Code for Tracking Required * 6.6 Status Code for Tracking Required
* 6.7 Using the Tracking Status * 6.7 Using the Tracking Status
* 6.7.1 Discovering Deployment * 6.7.1 Discovering Deployment
* 6.7.2 Preflight Checks * 6.7.2 Preflight Checks
* 7. User-Granted Exceptions * 7. User-Granted Exceptions
* 7.1 Overview * 7.1 Overview
* 7.2 Motivating Principles and Use Cases * 7.2 Motivating Principles and Use Cases
* 7.3 Exception model * 7.3 Exception Model
* 7.3.1 User Interaction * 7.3.1 User Interaction
* 7.3.2 Processing Model * 7.3.2 Processing Model
* 7.4 JavaScript API for Site-specific Exceptions * 7.4 Site-specific Exceptions
* 7.4.1 API to Request a Site-specific Exception * 7.4.1 API to Request a Site-specific Exception
* 7.4.2 API to Cancel a Site-specific Exception * 7.4.2 API to Cancel a Site-specific Exception
* 7.4.3 API to Confirm a Site-specific Exception * 7.4.3 API to Confirm a Site-specific Exception
* 7.5 JavaScript API for Web-wide Exceptions * 7.5 Web-wide Exceptions
* 7.5.1 API to Request a Web-wide Exception * 7.5.1 API to Request a Web-wide Exception
* 7.5.2 API to Cancel a Web-wide Exception * 7.5.2 API to Cancel a Web-wide Exception
* 7.5.3 API to Confirm a Web-wide Exception * 7.5.3 API to Confirm a Web-wide Exception
* 7.6 Transfer of an exception to another third party * 7.6 User Interface Guidelines
* 7.7 User interface guidelines * 7.7 Exceptions without Interactive JavaScript
* 7.8 Exceptions without interactive JavaScript * 7.8 Exceptions without an Expressed Preference
* 7.9 Exceptions without a DNT header * 7.9 Exception Use by Sites
* 7.10 Exception use by sites * 7.10 Fingerprinting
* 7.11 Fingerprinting
* A. Acknowledgements * A. Acknowledgements
* B. Registrations * B. Registrations
* C. References * C. References
* C.1 Normative references * C.1 Normative references
* C.2 Informative references * C.2 Informative references
1. Introduction 1. Introduction
The World Wide Web consists of billions of resources interconnected The World Wide Web consists of billions of resources interconnected
through the use of hypertext. Hypertext provides a simple, page-oriented through the use of hypertext. Hypertext provides a simple, page-oriented
skipping to change at line 198 skipping to change at line 189
initial resource request, including embedded references to stylesheets, initial resource request, including embedded references to stylesheets,
inline images, javascript, and other elements that might be automatically inline images, javascript, and other elements that might be automatically
requested as part of the rendering or behavioral processing defined for requested as part of the rendering or behavioral processing defined for
that page. The user's experience is seamless, even if the page has been that page. The user's experience is seamless, even if the page has been
composed from the results of many network interactions with multiple composed from the results of many network interactions with multiple
servers. From the user's perspective, they are simply visiting and servers. From the user's perspective, they are simply visiting and
interacting with a single Web site: all of the technical details and interacting with a single Web site: all of the technical details and
protocol mechanisms used to compose a page to represent that site are protocol mechanisms used to compose a page to represent that site are
hidden behind the scenes. hidden behind the scenes.
It has become common for Web site owners to collect data regarding the Web site owners often collect data regarding usage of their sites, for a
usage of their sites for a variety of purposes, including what led the variety of purposes, including what led a user to visit the site
user to visit their site (referrals), how effective the user experience is (referrals), how effective the user experience is within the site (web
within the site (web analytics), and the nature of who is using their site analytics), and the nature of who is using the site (audience
(audience segmentation). In some cases, the data collected is used to segmentation). In some cases, the data collected is used to dynamically
dynamically adapt the content (personalization) or the advertising adapt content (personalization) or advertising presented to the user
presented to the user (targeted advertising). Data collection often occurs (targeted advertising). Data collection often occurs through insertion of
through the insertion of embedded elements on each page, which connect the embedded elements on each page, resulting in a stream of data that
user's activity across multiple pages. A survey of these techniques and connects a user's activity across multiple pages. A survey of these
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 be merely expressing a preference does not imply that all recipients will
able to comply. In some cases, a server might be dependent on some forms comply. In some cases, a server might be dependent on some forms of
of tracking and is 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. Servers need mechanisms for communicating their acceptable to most users. Therefore, servers need mechanisms for
tracking behavior and for storing user-granted exceptions after the user communicating their own tracking behavior, requesting an exception to a
has made an informed choice. user's general preference, and storing such a user-granted exception after
the user has made an informed choice.
This specification defines Hypertext Transfer Protocol [HTTP] elements for This specification extends Hypertext Transfer Protocol (HTTP) semantics
communicating the user's tracking preference (if any) and communicating [RFC7231] to communicate a user's tracking preference, if any, and an
the server's tracking behavior (if any). The DNT request header field is origin server's tracking behavior. The DNT request header field is defined
defined for communicating the user's tracking preference for the request for communicating the user's tracking preference for the target resource.
target. A well-known URI for a tracking status resource and the Tk A well-known URI for a tracking status resource and the Tk response header
response header field are defined for communicating the server's tracking field are defined for communicating the server's tracking behavior. In
behavior. In addition, JavaScript APIs are defined for enabling scripts to addition, JavaScript APIs are defined for enabling scripts to determine
determine DNT status and register a user-granted exception. DNT status and register a user-granted exception.
This specification does not define requirements on what a recipient needs This specification does not define requirements on what a recipient needs
to do to comply with a user's expressed tracking preference, except for to do to comply with a user's expressed tracking preference, except for
the means by which such compliance is communicated. Instead, the tracking the means by which such compliance is communicated. Instead, the tracking
status provides the ability to identify a set of compliance regimes to status provides the ability to identify a set of compliance regimes to
which the server claims to comply, with the assumption being that each which the server claims to comply, with the assumption being that each
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
The following terms are used as defined by HTTP/1.1 syntax [RFC7230] and
semantics [RFC7231]: client, server, origin server, user agent, sender,
recipient, request, response, message, intermediary, proxy, cache, header
field, target resource, resource, and representation.
2.2 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 user is a natural person who is making, or has made, use of the Web.
A user agent is any of the various client programs capable of initiating
HTTP requests [HTTP], including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and mobile
apps.
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
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.
With respect to a given user action, a first party is a party with which With respect to a given user action, a first party is a party with which
the user intends to interact, via one or more network interactions, as a the user intends to interact, via one or more network interactions, as a
result of making that action. Merely hovering over, muting, pausing, or result of making that action. Merely hovering over, muting, pausing, or
skipping to change at line 286 skipping to change at line 284
if a user would reasonably expect to communicate with all of them when if a user would reasonably expect to communicate with all of them when
accessing that resource. For example, prominent co-branding on the accessing that resource. For example, prominent co-branding on the
resource might lead a user to expect that multiple parties are responsible resource might lead a user to expect that multiple parties are responsible
for the content or functionality. for the content or functionality.
For any data collected as a result of one or more network interactions For any data collected as a result of one or more network interactions
resulting from a user's action, a third party is any party other than that resulting from a user's action, a third party is any party other than that
user, a first party for that user action, or a service provider acting on user, a first party for that user action, or a service provider acting on
behalf of either that user or that first party. behalf of either that user or that first party.
Access to Web resources often involves multiple parties that might process
the data received in a network interaction. For example, domain name
services, network access points, content distribution networks, load
balancing services, security filters, cloud platforms, and
software-as-a-service providers might be a party to a given network
interaction because they are contracted by either the user or the resource
owner to provide the mechanisms for communication. Likewise, additional
parties might be engaged after a network interaction, such as when
services or contractors are used to perform specialized data analysis or
records retention.
For the data received in a given network interaction, a service provider
is considered to be the same party as its contractee if the service
provider:
1. processes the data on behalf of the contractee;
2. ensures that the data is only retained, accessed, and used as directed
by the contractee;
3. has no independent right to use the data other than in a permanently
de-identified form (e.g., for monitoring service integrity, load
balancing, capacity planning, or billing); and,
4. has a contract in place with the contractee which is consistent with
the above limitations.
2.4 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
confidence that no human subject of the data can be identified, directly
or indirectly (e.g., via association with an identifier, user agent, or
device), by that data alone or in combination with other retained or
available information.
2.5 Preferences
A user-granted exception is a specific tracking preference, overriding a A user-granted exception is a specific tracking preference, overriding a
user's general tracking preference, that has been obtained and recorded user's general tracking preference, that has been obtained and recorded
using the mechanisms defined in section 7. User-Granted Exceptions. using the mechanisms defined in section 7. User-Granted Exceptions.
3. Notational Conventions 3. Notational Conventions
3.1 Requirements 3.1 Requirements
The key words must, must not, required, should, should not, recommended, The key words must, must not, required, should, should not, recommended,
may, and optional in this specification are to be interpreted as described may, and optional in this specification are to be interpreted as described
in [RFC2119]. in [RFC2119].
3.2 Formal Syntax 3.2 Formal Syntax
This specification uses Augmented Backus-Naur Form [ABNF] to define This specification uses the Augmented Backus-Naur Form (ABNF) notation of
network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. [RFC5234] to define network protocol syntax and WebIDL [WEBIDL] to define
scripting APIs. Conformance criteria and considerations regarding error
handling are defined in Section 2.5 of [RFC7230].
4. Determining User Preference 4. Determining User Preference
The goal of this protocol is to allow a user to express their personal The goal of this protocol is to allow a user to express their personal
preference regarding tracking to each server and web application that they preference regarding tracking to each server and web application that they
communicate with via HTTP, thereby allowing recipients of that preference communicate with via HTTP, thereby allowing recipients of that preference
to adjust tracking behavior accordingly or to reach a separate agreement to adjust tracking behavior accordingly or to reach a separate agreement
with the user that satisfies all parties. with the user that satisfies all parties.
Key to that notion of expression is that the signal sent MUST reflect the Key to that notion of expression is that the signal sent MUST reflect the
skipping to change at line 433 skipping to change at line 467
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.
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 [HTTP]. preference in an HTTP request ([RFC7230]). At most one DNT header field
can be present in a valid request.
DNT-field-name = "DNT" DNT-field-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" (%x31) if the user's tracking begins with the numeric character "1" if the user's tracking preference is
preference is enabled, their preference is for DNT:1, and no exception has enabled, their preference is for DNT:1, and no exception has been granted
been granted for the request target (see section 7. User-Granted for the request target (see section 7. User-Granted Exceptions).
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" (%x30) if the user's tracking begins with the numeric character "0" if the user's tracking preference is
preference is enabled and their preference is for DNT:0, or if an enabled and their preference is for DNT:0, or if an exception has been
exception has been granted for the request target. granted for the request target.
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
The remainder of the field-value, after the initial character, is reserved 5.2.1 DNT Extensions
for future extensions. DNT extensions can only be transmitted when a
tracking preference is enabled. The remainder of the DNT field-value, after the initial character, is
reserved for future extensions. DNT extensions can only be transmitted
when a tracking preference is enabled. The extension syntax is restricted
to visible ASCII characters that can be parsed as a single word in HTTP
and safely embedded in a JSON string without further encoding (section 6.5
Tracking Status Representation).
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash ; excludes CTL, SP, DQUOTE, comma, backslash
For example, additional characters might indicate modifiers to the main For example, additional characters might indicate modifiers to the main
preference expressed by the first digit, such that the main preference preference expressed by the first digit, such that the main preference
will be understood if the recipient does not understand the extension. will be understood if the recipient does not understand the extension.
Hence, a field-value of "1xyz" can be thought of as do not track, but if Hence, a field-value of "1xyz" can be thought of as do not track, but if
you understand the refinements defined by x, y, or z, then adjust my you understand the refinements defined by x, y, or z, then adjust my
preferences according to those refinements. preferences according to those refinements.
User agents that do not implement DNT extensions MUST NOT send User agents that do not implement DNT extensions MUST NOT send
DNT-extension characters in the DNT field-value. Servers that do not DNT-extension characters in the DNT field-value. Servers that do not
implement DNT extensions SHOULD ignore anything beyond the first implement DNT extensions SHOULD ignore anything beyond the first
character. character.
Note Note
The extension syntax is restricted to visible ASCII characters that can be The DNT-extension feature is considered at-risk. Since no extensions have
parsed as a single word in HTTP and safely embedded in a JSON string been defined, implementors that don't read specifications are likely to
without further encoding (section 6.5 Tracking Status Representation). At assume that DNT only has the fixed values of "0" or "1". Furthermore, the
most one DNT header field can be present in a valid request [HTTP]. potential benefits of this mechanism are unclear given that extension
information could be supplied using separate request header fields.
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 doNotTrack property enables a client-side script with read access to
the Window object to determine what DNT header field value would be sent the Navigator object to determine what DNT header field value would be
in requests to the document-origin, taking into account the user's general sent in requests to the document-origin, taking into account the user's
preference (if any) and any user-granted exceptions applicable to that general preference (if any) and any user-granted exceptions applicable to
origin server. that origin server.
partial interface Window { partial interface Navigator {
readonly attribute DOMString doNotTrack; readonly attribute DOMString? doNotTrack;
}; };
doNotTrack of type DOMString, readonly doNotTrack of type DOMString, readonly , nullable
Returns the same string value that would be sent in a Returns the same string value that would be sent in a
DNT-field-value (section 5.2 DNT Header Field for HTTP Requests) DNT-field-value (section 5.2 DNT Header Field for HTTP Requests)
to a target that is the document-origin of the window, in the to a target that is the document-origin of the window, in the
browser context of the current top-level origin. The value is null browser context of the current top-level origin. The value is null
if no DNT header field would be sent (e.g., because a tracking if no DNT header field would be sent (e.g., because a tracking
preference is not enabled). 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 545 skipping to change at line 585
resource is any resource on the same origin server. For a Tk response resource is any resource on the same origin server. For a Tk response
header field, the target resource of the corresponding request is the header field, the target resource of the corresponding request is the
designated resource, and remains so for any subsequent request-specific designated resource, and remains so for any subsequent request-specific
tracking status resource referred to by the Tk field value. tracking status resource referred to by the Tk field value.
The tracking status value is case sensitive, as defined formally by the The tracking status value is case sensitive, as defined formally by the
following ABNF. following ABNF.
TSV = %x21 ; "!" - under construction TSV = %x21 ; "!" - under construction
/ %x3F ; "?" - dynamic / %x3F ; "?" - dynamic
/ %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
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 576 skipping to change at line 616
information to determine tracking status, usually because the designated information to determine tracking status, usually because the designated
resource dynamically adjusts behavior based on information in a request. resource dynamically adjusts behavior based on information in a request.
If ? is present in the site-wide tracking status, the origin server MUST If ? is present in the site-wide tracking status, the origin server MUST
send a Tk header field in all responses to requests on the designated send a Tk header field in all responses to requests on the designated
resource. If ? is present in the Tk header field, more information will be resource. If ? is present in the Tk header field, more information will be
provided in a request-specific tracking status resource referred to by the provided in a request-specific tracking status resource referred to by the
status-id. An origin server MUST NOT send ? as the tracking status value status-id. An origin server MUST NOT send ? as the tracking status value
in the representation of a request-specific tracking status resource. in the representation of a request-specific tracking status resource.
6.2.4 Not Tracking (N) 6.2.4 Gateway (G)
A tracking status value of G means the server is acting as a gateway to an
exchange involving multiple parties. This might occur if a response to the
designated resource involves an automated selection process, such as
dynamic bidding, where the party that is selected determines how the
request data will be treated with respect to an expressed tracking
preference. Similar to the ? value, the G TSV indicates that the actual
tracking status is dynamic and will be provided in the response message's
Tk header field, presumably using information forwarded from the selected
party.
This tracking status value is only valid as a site-wide status. A server
MUST NOT send G as the tracking status value in a Tk header field or
within the representation of a request-specific tracking status resource.
If G is present in the site-wide tracking status:
* the gateway MUST send a link within its site-wide tracking status
representation to a privacy policy that explains what limitations are
placed on parties that might receive data via that gateway;
* the gateway MUST forward any expressed tracking preference in the
request to each party that receives data from that request;
* the gateway MUST have a contract in place with each of the parties to
whom it provides request data such that only the selected party is
allowed to retain tracking data from a request with an expressed
tracking preference of DNT:1; and,
* the gateway MUST send a Tk header field in responses to requests on
the designated resource and include within that field's value a
status-id specific to the selected party, such that information about
the selected party can be obtained via the request-specific tracking
status resource (see section 6.4.2 Request-specific Tracking Status).
With respect to tracking performed by the gateway itself, the G response
can be considered equivalent to the T (tracking) response defined below.
The other information within the site-wide tracking status representation
indicates how the gateway intends to comply with an expressed tracking
preference, aside from the potential sharing of data implied by the
gateway process.
6.2.5 Not Tracking (N)
A tracking status value of N means the origin server claims that data A tracking status value of N means the origin server claims that data
collected via the designated resource is not used for tracking and will collected via the designated resource is not used for tracking and will
not be combined with other data in a form that would enable tracking. not be combined with other data in a form that would enable tracking.
6.2.5 Tracking (T) 6.2.6 Tracking (T)
A tracking status value of T means the origin server might perform or A tracking status value of T means the origin server might perform or
enable tracking using data collected via the designated resource. enable tracking using data collected via the designated resource.
Information provided in the tracking status representation might indicate Information provided in the tracking status representation might indicate
whether such tracking is limited to a set of commonly accepted uses or whether such tracking is limited to a set of commonly accepted uses or
adheres to one or more compliance regimes. adheres to one or more compliance regimes.
6.2.6 Consent (C) 6.2.7 Consent (C)
A tracking status value of C means that the origin server believes it has A tracking status value of C means that the origin server believes it has
received prior consent for tracking this user, user agent, or device, received prior consent for tracking this user, user agent, or device,
perhaps via some mechanism not defined by this specification, and that perhaps via some mechanism not defined by this specification, and that
prior consent overrides the tracking preference expressed by this prior consent overrides the tracking preference expressed by this
protocol. An origin server that sends the C tracking status value for a protocol. An origin server that sends the C tracking status value for a
designated resource MUST provide a reference for controlling consent designated resource MUST provide a reference for controlling consent
within the config property of its corresponding tracking status within the config property of its corresponding tracking status
representation (section 6.5 Tracking Status Representation). representation (section 6.5 Tracking Status Representation).
6.2.7 Potential Consent (P) 6.2.8 Potential Consent (P)
A tracking status value of P means that the origin server does not know, A tracking status value of P means that the origin server does not know,
in real-time, whether it has received prior consent for tracking this in real-time, whether it has received prior consent for tracking this
user, user agent, or device, but promises not to use or share any DNT:1 user, user agent, or device, but promises not to use or share any DNT:1
data until such consent has been determined, and further promises to data until such consent has been determined, and further promises to
delete or de-identify within forty-eight hours any DNT:1 data received for delete or permanently de-identify within forty-eight hours any DNT:1 data
which such consent has not been received. received for which such consent has not been received.
Since this status value does not itself indicate whether a specific Since this status value does not itself indicate whether a specific
request is tracked, an origin server that sends a P tracking status value request is tracked, an origin server that sends a P tracking status value
MUST provide a config property in the corresponding tracking status MUST provide a config property in the corresponding tracking status
representation that links to a resource for obtaining consent status. representation that links to a resource for obtaining consent status.
The P tracking status value is specifically meant to address audience The P tracking status value is specifically meant to address audience
survey systems for which determining consent at the time of a request is survey systems for which determining consent at the time of a request is
either impractical, due to legacy systems not being able to keep up with either impractical, due to legacy systems not being able to keep up with
Web traffic, or potentially "gamed" by first party sites if they can Web traffic, or potentially "gamed" by first party sites if they can
determine which of their users have consented. The data cannot be used for determine which of their users have consented. The data cannot be used for
the sake of personalization. If consent can be determined at the time of a the sake of personalization. If consent can be determined at the time of a
request, the C tracking status is preferred. request, the C tracking status is preferred.
6.2.8 Disregarding (D) 6.2.9 Disregarding (D)
A tracking status value of D means that the origin server is unable or A tracking status value of D means that the origin server is unable or
unwilling to respect a tracking preference received from the requesting unwilling to respect a tracking preference received from the requesting
user agent. An origin server that sends the D tracking status value MUST user agent. An origin server that sends the D tracking status value MUST
detail within the server's corresponding privacy policy the conditions detail within the server's corresponding privacy policy the conditions
under which a tracking preference might be disregarded. under which a tracking preference might be disregarded.
For example, an origin server might disregard the DNT field received from For example, an origin server might disregard the DNT field received from
specific user agents (or via specific network intermediaries) that are specific user agents (or via specific network intermediaries) that are
deemed to be non-conforming, might be collecting additional data from deemed to be non-conforming, might be collecting additional data from
skipping to change at line 646 skipping to change at line 726
local law, regulation, or order. local law, regulation, or order.
Note Note
This specification is written with an assumption that the D tracking This specification is written with an assumption that the D tracking
status value would only be used in situations that can be adequately status value would only be used in situations that can be adequately
described to users as an exception to normal behavior. If this turns out described to users as an exception to normal behavior. If this turns out
not to be the case, either the server's decision to send the D signal not to be the case, either the server's decision to send the D signal
needs re-examination, or this specification, or both. needs re-examination, or this specification, or both.
6.2.9 Updated (U) 6.2.10 Updated (U)
A tracking status value of U means that the request resulted in a A tracking status value of U means that the request resulted in a
potential change to the tracking status applicable to this user, user potential change to the tracking status applicable to this user, user
agent, or device. A user agent that relies on a cached tracking status agent, or device. A user agent that relies on a cached tracking status
SHOULD update the cache entry with the current status by making a new SHOULD update the cache entry with the current status by making a new
request on the applicable tracking status resource. request on the applicable tracking status resource.
An origin server MUST NOT send U as a tracking status value anywhere other An origin server MUST NOT send U as a tracking status value anywhere other
than a Tk header field that is in response to a state-changing request. than a Tk header field that is in response to a state-changing request.
6.3 Tk Header Field for HTTP Responses 6.3 Tk Header Field for HTTP Responses
6.3.1 Definition 6.3.1 Definition
The Tk response header field is hereby defined as an OPTIONAL means for The Tk response header field is a means for indicating the tracking status
indicating the tracking status that applied to the corresponding request that applied to the corresponding request. An origin server is REQUIRED to
and as a REQUIRED means for indicating that a state-changing request has send a Tk header field if its site-wide tracking status value is ?
resulted in an interactive change to the tracking status. (dynamic) or G (gateway), or when an interactive change is made to the
tracking status and indicated by U (updated).
Tk-field-name = "Tk" Tk-field-name = "Tk"
Tk-field-value = TSV [ ";" status-id ] Tk-field-value = TSV [ ";" status-id ]
The Tk field-value begins with a tracking status value (section 6.2 The Tk field-value begins with a tracking status value (section 6.2
Tracking Status Value), optionally followed by a semicolon and a status-id Tracking Status Value), optionally followed by a semicolon and a status-id
that refers to a request-specific tracking status resource (section 6.3.2 that refers to a request-specific tracking status resource (section 6.3.2
Referring to a Request-specific Tracking Status Resource). Referring to a Request-specific Tracking Status Resource).
For example, a Tk header field for a resource that claims not to be For example, a Tk header field for a resource that claims not to be
tracking would look like: tracking would look like:
Example 2 Example 2
Tk: N Tk: N
6.3.2 Referring to a Request-specific Tracking Status Resource 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 URI, header fields, data, etc.), the origin
server MAY provide an additional subtree of well-known resources server can provide an additional subtree of well-known resources
corresponding to each of those distinct tracking statuses. The OPTIONAL corresponding to each of those distinct tracking statuses. The status-id
status-id portion of the Tk field-value indicates which specific tracking portion of the Tk field-value indicates which specific tracking status
status resource applies to the current request. 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
Tk: T;fRx42 Tk: T;fRx42
indicates that data collected via the target resource might be used for indicates that data collected via the target resource might be used for
tracking and that an applicable tracking status representation can be tracking and that an applicable tracking status representation can be
obtained by performing a retrieval request on obtained by performing a retrieval request on
/.well-known/dnt/fRx42 /.well-known/dnt/fRx42
If a Tk field-value has a tracking status value of ? (dynamic), then the Note that the status-id is resolved relative to the origin server of the
origin server MUST also send a status-id in the field-value. The status-id current request. A retrieval request targeting that URI can be redirected,
is case-sensitive. if desired, to some other server. The status-id has been intentionally
limited to a small set of characters to encourage use of short tokens
instead of potentially long, human-readable strings.
If a Tk field-value has a tracking status value of ? (dynamic), the origin
server MUST send a status-id in the field-value.
6.3.3 Indicating an Interactive Status Change 6.3.3 Indicating an Interactive Status Change
Interactive mechanisms might be used, beyond the scope of this Interactive mechanisms might be used, beyond the scope of this
specification, that have the effect of asking for and obtaining prior specification, that have the effect of asking for and obtaining prior
consent for tracking, or for modifying prior indications of consent. For consent for tracking, or for modifying prior indications of consent. For
example, the tracking status resource's status-object defines a config example, the tracking status resource's status object defines a config
property that can refer to such a mechanism. Although such out-of-band property that can refer to such a mechanism. Although such out-of-band
mechanisms are not defined by this specification, their presence might mechanisms are not defined by this specification, their presence might
influence the tracking status object's response value. influence the tracking status object's response value.
When an origin server provides a mechanism via HTTP for establishing or When an origin server provides a mechanism via HTTP for establishing or
modifying out-of-band tracking preferences, the origin server MUST modifying out-of-band tracking preferences, the origin server MUST
indicate within the mechanism's response when a state-changing request has indicate within the mechanism's response when a state-changing request has
resulted in a change to the tracking status for that server. This resulted in a change to the tracking status for that server. This
indication of an interactive status change is accomplished by sending a Tk indication of an interactive status change is accomplished by sending a Tk
header field in the response with a tracking status value of U (updated). header field in the response with a tracking status value of U (updated).
skipping to change at line 761 skipping to change at line 845
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 URI, header fields, data, etc.), the origin
server MAY provide an additional subtree of well-known resources 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
[URI-TEMPLATE]: [RFC6570]:
/.well-known/dnt/{+status-id} /.well-known/dnt/{+status-id}
where the value of status-id is a string of URI-safe characters provided where the value of status-id is a string of URI-safe characters provided
by a Tk field-value in response to a prior request. For example, a prior by a Tk field-value in response to a prior request. For example, a prior
response containing response containing
Example 5 Example 5
Tk: ?;ahoy Tk: ?;ahoy
skipping to change at line 790 skipping to change at line 874
refers to the specific tracking status resource refers to the specific tracking status resource
/.well-known/dnt/ahoy /.well-known/dnt/ahoy
Resources within the request-specific tracking status resource space are Resources within the request-specific tracking status resource space are
represented using the same format as a site-wide tracking status resource. represented using the same format as a site-wide tracking status resource.
6.4.3 Status Checks are Not Tracked 6.4.3 Status Checks are Not Tracked
When sending a request for the tracking status, a user agent SHOULD When sending a request for the tracking status, a user agent SHOULD
include any cookie data [COOKIES] (set prior to the request) that would be include any cookie data [RFC6265] (set prior to the request) that would be
sent in a normal request to that origin server, since that data might be sent in a normal request to that origin server, since that data might be
needed by the server to determine the current tracking status. For needed by the server to determine the current tracking status. For
example, the cookie data might indicate a prior out-of-band decision by example, the cookie data might indicate a prior out-of-band decision by
the user to opt-out or consent to tracking by that origin server. the user to opt-out or consent to tracking by that origin server.
An origin server MUST NOT retain tracking data regarding requests on the An origin server MUST NOT retain tracking data regarding requests on the
site-wide tracking status resource or within the tracking status resource site-wide tracking status resource or within the tracking status resource
space, regardless of the presence, absence, or value of a DNT header space, regardless of the presence, absence, or value of a DNT header
field, cookies, or any other information in the request. In addition, an field, cookies, or any other information in the request. In addition, an
origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in
responses to those requests, including the responses to redirected responses to those requests, including the responses to redirected
tracking status requests, and MUST NOT send a response having content that tracking status requests, and MUST NOT send a response having content that
initiates tracking beyond what was already present in the request. A user initiates tracking beyond what was already present in the request. A user
agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2
header field received in such a response. header field received in such a response.
6.4.4 Caching 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 or other data received via the request, then the
origin server SHOULD mark the response as cacheable [HTTP-cache] and origin server SHOULD mark the response as cacheable [RFC7234] and assign a
assign a time-to-live (expiration or max-use) that is sufficient to enable time-to-live (expiration or max-use) that is sufficient to enable shared
shared caching but not greater than the earliest point at which the caching but not greater than the earliest point at which the service's
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
skipping to change at line 852 skipping to change at line 936
A user agent that adjusts behavior based on active verification of A user agent that adjusts behavior based on active verification of
tracking status, relying on cached tracking status responses to do so, tracking status, relying on cached tracking status responses to do so,
SHOULD check responses to its state-changing requests (e.g., POST, PUT, SHOULD check responses to its state-changing requests (e.g., POST, PUT,
DELETE, etc.) for a Tk header field with the U tracking status value, as DELETE, etc.) for a Tk header field with the U tracking status value, as
described in section 6.3.3 Indicating an Interactive Status Change. described in section 6.3.3 Indicating an Interactive Status Change.
6.5 Tracking Status Representation 6.5 Tracking Status Representation
For each tracking status resource, an origin server MUST provide a valid For each tracking status resource, an origin server MUST provide a valid
representation using the application/tracking-status+json media type. This representation using the application/tracking-status+json media type. This
media type is defined as a JSON format [RFC7159] that conforms to the ABNF media type consists of a status object serialized as JSON [RFC7159]. More
for status-object (below) except that the properties within a information about the application/tracking-status+json media type can be
property-list can be provided in any order. More information about the found in section B. Registrations.
application/tracking-status+json media type can be found in section B.
Registrations.
6.5.1 Status Object 6.5.1 Status Object
A tracking status representation consists of a single status-object A tracking status representation consists of a single status object
containing properties that describe the tracking status applicable to the containing properties that describe the tracking status applicable to the
designated resource. designated resource. Most of the properties are optional and can be
extended over time, as illustrated by the following Orderly schema
status-object = begin-object property-list end-object [Orderly]:
property-list = tracking-p ns tracking-v object {
[ vs compliance ns compliance-v ] string tracking; // TSV
[ vs qualifiers ns qualifiers-v ] array { string; } compliance?; // hrefs
[ vs controller ns controller-v ] string qualifiers?; // compliance flags
[ vs same-party ns same-party-v ] array { string; } controller?; // hrefs
[ vs audit ns audit-v ] array { string; } same-party?; // domains
[ vs policy ns policy-v ] array { string; } audit?; // hrefs
[ vs config ns config-v ] string policy?; // href
*( vs extension ) string config?; // href
}*;
The following example tracking status representation illustrates a status The following example representation demonstrates a status object with all
object with all of the properties defined by this specification, most of of the properties defined by this specification.
which are optional.
Example 6 Example 6
{ {
"tracking": "T", "tracking": "T",
"compliance": ["https://acme.example.org/tracking101"], "compliance": ["https://acme.example.org/tracking101"],
"qualifiers": "afc", "qualifiers": "afc",
"controller": ["https://www.example.com/privacy"], "controller": ["https://www.example.com/privacy"],
"same-party": [ "same-party": [
"example.com", "example.com",
skipping to change at line 902 skipping to change at line 983
], ],
"audit": [ "audit": [
"http://auditor.example.org/727073" "http://auditor.example.org/727073"
], ],
"policy": "/privacy.html#tracking", "policy": "/privacy.html#tracking",
"config": "http://example.com/your/data" "config": "http://example.com/your/data"
} }
6.5.2 Tracking Property 6.5.2 Tracking Property
A status-object always has a property named tracking with a string value A status object MUST have a property named tracking with a string value
containing the tracking status value (section 6.2 Tracking Status Value) containing the tracking status value (section 6.2 Tracking Status Value)
applicable to the designated resource. applicable to the designated resource.
tracking-p = %x22 "tracking" %x22
tracking-v = %x22 TSV %x22
For example, the following demonstrates a minimal tracking status For example, the following demonstrates a minimal tracking status
representation that is applicable to any resource that does not perform representation that is applicable to any resource that does not perform
tracking. tracking.
Example 7 Example 7
{"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, but does not have any direct impact on this
protocol. protocol.
compliance = %x22 "compliance" %x22
compliance-v = array-of-refs
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.
qualifiers = %x22 "qualifiers" %x22
qualifiers-v = %x22 *qualifier %x22
qualifier = id-char
6.5.5 Controller Property 6.5.5 Controller Property
An origin server MAY send a property named controller with an array value An origin server MAY send a property named controller with an array value
containing a list of URI references indirectly identifying the party or containing a list of URI references indirectly identifying the party or
set of parties that claims to be the responsible data controller for set of parties that claims to be the responsible data controller for
personal data collected via the designated resource. An origin server MUST personal data collected via the designated resource. An origin server MUST
send a controller property if the responsible data controller does not own send a controller property if the responsible data controller does not own
the designated resource's domain name. the designated resource's domain name.
An origin server that does not send controller is implying that its domain An origin server that does not send controller is implying that its domain
skipping to change at line 971 skipping to change at line 1039
If the designated resource has joint data controllers (i.e., multiple If the designated resource has joint data controllers (i.e., multiple
parties have independent control over the collected data), the origin parties have independent control over the collected data), the origin
server MUST send a controller property that contains a reference for each server MUST send a controller property that contains a reference for each
data controller. data controller.
Each URI reference provided in controller ought to refer to a resource Each URI reference provided in controller ought to refer to a resource
that, if a retrieval action is performed on that URI, would provide the that, if a retrieval action is performed on that URI, would provide the
user with information regarding (at a minimum) the identity of the user with information regarding (at a minimum) the identity of the
corresponding party and its data collection practices. corresponding party and its data collection practices.
controller = %x22 "controller" %x22
controller-v = array-of-refs
6.5.6 Same-party Property 6.5.6 Same-party Property
Since a user's experience on a given site might be composed of resources Since a user's experience on a given site might be composed of resources
that are assembled from multiple domains, it might be useful for a site to that are assembled from multiple domains, it might be useful for a site to
distinguish those domains that are subject to their own control (i.e., distinguish those domains that are subject to their own control (i.e.,
share the same data controller as the referring site). An origin server share the same data controller as the referring site). An origin server
MAY send a property named same-party with an array value containing a list MAY send a property named same-party with an array value containing a list
of domain names that the origin server claims are the same party, to the of domain names that the origin server claims are the same party, to the
extent they are referenced by the designated resource, if all data extent they are referenced by the designated resource, if all data
collected via those references share the same data controller as the collected via those references share the same data controller as the
designated resource. designated resource.
A user agent might use the same-party array, when provided, to inform or A user agent might use the same-party array, when provided, to inform or
enable different behavior for references that are claimed to be same-party enable different behavior for references that are claimed to be same-party
versus those for which no claim is made. For example, a user agent might versus those for which no claim is made. For example, a user agent might
choose to exclude, or perform additional pre-flight verification of, choose to exclude, or perform additional pre-flight verification of,
requests to other domains that have not been claimed as same-party by the requests to other domains that have not been claimed as same-party by the
referring site. referring site.
same-party = %x22 "same-party" %x22
same-party-v = array-of-refs
6.5.7 Audit Property 6.5.7 Audit Property
An origin server MAY send a property named audit with an array value An origin server MAY send a property named audit with an array value
containing a list of URI references to external audits of the designated containing a list of URI references to external audits of the designated
resource's privacy policy and tracking behavior. Preferably, the audit resource's privacy policy and tracking behavior. Preferably, the audit
references are to resources that describe the auditor and the results of references are to resources that describe the auditor and the results of
that audit; however, if such a resource is not available, a reference to that audit; however, if such a resource is not available, a reference to
the auditor is sufficient. the auditor is sufficient.
audit = %x22 "audit" %x22
audit-v = array-of-refs
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. The content of such a
policy document is beyond the scope of this protocol and only supplemental policy document is beyond the scope of this protocol and only supplemental
to what is described in the machine-readable tracking status to what is described in the machine-readable tracking status
representation. If no policy property is provided, this information might representation. If no policy property is provided, this information might
be obtained via the links provided in controller. be obtained via the links provided in controller.
policy = %x22 "policy" %x22
policy-v = string ; URI-reference
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.
config = %x22 "config" %x22
config-v = string ; URI-reference
6.5.10 Extensions 6.5.10 Extensions
An origin server MAY send additional extension properties in the An origin server MAY send additional properties in the status object to
status-object to support future enhancements to this protocol. A recipient support future enhancements to this protocol. A recipient MUST ignore
MUST ignore extension properties that it does not recognize. extension properties that it does not recognize.
extension = object
array-of-refs = begin-array [ string *( vs string ) ] end-array
ns = <name-separator (:), as defined in [RFC7159]>
vs = <value-separator (,), as defined in [RFC7159]>
begin-array = <begin-array ([), as defined in [RFC7159]>
end-array = <end-array (]), as defined in [RFC7159]>
begin-object = <begin-object ({), as defined in [RFC7159]>
end-object = <end-object (}), as defined in [RFC7159]>
object = <object, as defined in [RFC7159]>
string = <string, as defined in [RFC7159]>
true = <true, as defined in [RFC7159]>
false = <false, as defined in [RFC7159]>
null = <null, as defined in [RFC7159]>
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 [HTTP-semantics]. 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
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
skipping to change at line 1117 skipping to change at line 1146
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 MAY 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.
If the tracking status value is N, then the origin server claims that no If the tracking status value is N, then the origin server claims that no
tracking is performed for the designated resource for at least the next 24 tracking is performed for the designated resource for at least the next 24
hours or until the Cache-Control information indicates that this response hours or until the Cache-Control information indicates that this response
expires. expires.
If the tracking status value is not N, then the origin server claims that If the tracking status value is not N, then the origin server claims that
it might track the user agent for requests on the URI being checked for at it might track the user agent for requests on the URI being checked for at
skipping to change at line 1143 skipping to change at line 1172
that this response expires. that this response expires.
7. User-Granted Exceptions 7. User-Granted Exceptions
7.1 Overview 7.1 Overview
This section is non-normative. This section is non-normative.
User-granted exceptions to Do Not Track, including site-specific User-granted exceptions to Do Not Track, including site-specific
exceptions, are agreed between the site and the user, and stored by the exceptions, are agreed between the site and the user, and stored by the
user agent. A resource ought to rely on the DNT header it receives to user agent. A resource ought to rely on the DNT header field it receives
determine the user's preference for tracking with respect to that to determine the user's preference for tracking with respect to that
particular request. An API is provided so that sites may request and check particular request. An API is provided so that sites can request and check
the status of exceptions for tracking. the status of exceptions for tracking.
Note Note
We envisage that the exceptions may also be usable as a consent mechanism. We envisage that the exceptions might also be usable as a consent
mechanism.
7.2 Motivating Principles and Use Cases 7.2 Motivating Principles and Use Cases
This section is non-normative. This section is non-normative.
The following principles guide the design of user-agent-managed The following principles guide the design of user-agent-managed
exceptions. exceptions.
* Content providers may wish to prompt visitors to their properties to * Content providers 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 may 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 (while browsing a news site) * Granting an exception in one context (e.g., while browsing a news
should not apply that exception to other contexts (browsing a medical site) does not imply that exception is applicable to other contexts
site) that may not be expected. (e.g., browsing an unrelated medical site).
* Tracking providers should not ever have to second-guess a user's * Tracking providers ought to be able to avoid second-guessing a user's
expressed Do Not Track preference. expressed tracking preference.
* The solution should 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 When asking for a site-specific exception, the top-level origin making the
request may be making some implicit or explicit claims as to the actions request might make some implicit or explicit claims as to the actions and
and behavior of its third parties; for this reason, it might want to behavior of its third parties; for this reason, it might want to establish
establish exceptions for only those for which it is sure that those claims exceptions for only those for which it is sure that those claims are true.
are true. (Consider a site that has some trusted advertisers and analytics (Consider a site that has some trusted advertisers and analytics
providers, and some mashed-up content from less-trusted sites). For this providers, along with some mashed-up content from less-trusted sites). For
reason, there is support both for explicitly named sites, as well as 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 support for granting an exception to all third-parties on a given site
(site-wide exception, using the conceptual wild-card "*"). (site-wide exception, using the conceptual wild-card "*").
There are some cases in which a user may desire a site to be allowed to There are some cases in which a user might desire a site to be allowed to
track them on any top-level origin. An API is provided so that the site track them on any top-level origin. An API is provided so that a site
and the user may establish such a web-wide exception. might obtain such a web-wide exception from the user.
7.3 Exception model 7.3 Exception Model
7.3.1 User Interaction 7.3.1 User Interaction
The call to store an exception MUST reflect the user's intention to grant The call to store an exception MUST reflect the user's intention to grant
an exception, at the time of the call. This intention MUST be determined an exception at the time of that call. This intention MUST be determined
by the site prior to each call to store an exception, at the time of the by the site prior to each call to store an exception, at the time of the
call. (This allows the user to change their mind, and delete a stored call. (This allows a user to change their mind and delete a stored
exception, which might then trigger the site to explain, and ask for, the exception, which might result in the site explaining and asking for the
exception again). It is the responsibility solely of the site making the exception again.) It is the sole responsibility of the site making the
call to determine that a call to record an exception reflects the user's call to determine that a call to record an exception reflects the user's
informed consent at the time of the call. informed consent at the time of that call.
Sites 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 recording a permission to
allow tracking in jurisdictions where such permission cannot be assumed - allow tracking in jurisdictions where such permission cannot be assumed -
see section 7.8 Exceptions without interactive JavaScript.) see section 7.7 Exceptions without Interactive JavaScript.)
The user agent MAY provide interfaces to the user: The user agent MAY provide interfaces to the user:
* To indicate that a call to store an exception has just been made; * To indicate that a call to store an exception has just been made;
* To allow the user to confirm a user-granted exception prior to * To allow the user to confirm a user-granted exception prior to
storage; storage;
* To indicate that one or more exceptions exist for the current * To indicate that one or more exceptions exist for the current
top-level origin; top-level origin;
* To indicate that one or more exceptions exist for sites incorporated * To indicate that one or more exceptions exist for sites incorporated
into the current page; into the current page;
* To allow the user to see and possibly revoke stored exceptions; * To allow the user to see and possibly revoke stored exceptions;
* Other aspects of the exception mechanism, as desired. * Other aspects of the exception mechanism, as desired.
There is no required user interface for the user agent; user agents MAY
There is no required user interface for the user agent; a user agent MAY
choose to provide no user interface regarding user-granted exceptions. choose to provide no user interface regarding user-granted exceptions.
If the user revokes the consent by deleting the exception, the site MUST If the user revokes the consent by deleting the exception, the site MUST
respect that revocation (though it may ask again for the exception). The respect that revocation (though it MAY ask again for the exception). The
exception mechanism MUST NOT be used when the site will deem consent to site MUST NOT use this exception mechanism if it will deem consent to
exist even after the exception has been revoked. exist even after the exception has been revoked.
7.3.2 Processing Model 7.3.2 Processing Model
This section describes the effect of the APIs in terms of a logical This section describes the effect of the APIs in terms of a logical
processing model; this model describes the behavior, but is not to be read processing model; this model describes the behavior, but is not to be read
as mandating any specific implementation. as mandating any specific implementation.
This API considers exceptions which are double-keyed to two domains: the This API considers exceptions which are double-keyed to two domains: the
site, and the target. A user might - for instance - want AnalytiCo to be site, and the target. A user might - for instance - want AnalytiCo to be
allowed to track them on Example News, but not on Example Medical. To allowed to track them on Example News, but not on Example Medical. To
simplify language used in this API specification, we define three terms: simplify language used in this API specification, we define three terms:
* top-level origin is the domain name of the top-level document origin * A top-level origin is the top-level browsing context, as defined by
of this DOM: essentially the fully qualified domain name in the [HTML5];
address bar. * A target site is the host subcomponent of the authority part in an
* A target site is a domain name which is the target of an HTTP request, "http" or "https" URI, as defined by [RFC7230] and [RFC3986]; and,
and which may be an origin for embedded resources on the indicated * The document origin of a script is the effective script origin, as
top-level origin. defined by [HTML5].
* The document origin of a script is the domain of origin of the
document that caused that script to be loaded (not necessarily the
same as the origin of the script itself).
For instance, if the document at For instance, if the document at
http://web.exnews.com/news/story/2098373.html references the resources http://web.exnews.com/news/story/2098373.html references the resources
http://exnews.analytico.net/1x1.gif and http://exnews.analytico.net/1x1.gif and
http://widgets.exsocial.org/good-job-button.js, the top-level origin is http://widgets.exsocial.org/good-job-button.js, the top-level origin is
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both
targets. targets.
The domains that enter into the behavior of the APIs include: The domains that enter into the behavior of the APIs include:
* As described above, the document origin active at the time of the * As described above, the document origin active at the time of the
call, and; call, and;
* Domain names passed to the API. * Domain names passed to the API.
Domains that enter into the decision over what DNT header to be sent in a Domains that enter into the decision over what DNT header field to be sent
given request include: in a given request include:
* The top-level origin of the current browser context; * The top-level origin of the current browser context;
* The target of the request. * The target of the request.
Note Note
Note that these strict, machine-discoverable, concepts may not match the Note that these strict, machine-discoverable concepts might not match the
definitions of first and third party; in particular, sites themselves need definitions of first and third party; in particular, sites themselves need
to determine (and signal) when they get 'promoted' to first party by to determine when they are a first party in relation to a given user
virtue of user interaction; the UA will not change the DNT header it sends action; the user agent does not change the DNT header field based on the
them. type of network interaction.
The calls cause the following steps to occur (subject to user confirmation The calls cause the following steps to occur (subject to user confirmation
of the exception, if the user agent asks for it): of the exception, if the user agent asks for it):
* The UA adds to its local database one or more site-pair duplets * The user agent adds to its local database one or more site-pair
[document-origin, target]; one or other of these may be a wild-card 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 is to be sent to a target domain, if the duplet [top-level header field is to be sent to a target domain, if the duplet
origin, target domain] matches any duplet in the database, then a [top-level origin, target domain] matches any duplet in the database,
DNT:0 header is sent, otherwise DNT:1 is sent. then a DNT:0 preference is sent, otherwise the user's general
preference is sent (if any).
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A 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
skipping to change at line 1308 skipping to change at line 1337
its logical database of remembered grants. This assures sites that the set 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 of sites they need for operational integrity is treated as a unit. Each
separate call to an API is a separate unit. separate call to an API is a separate unit.
It is left up to individual user agent implementations how to determine It is left up to individual user agent implementations how to determine
and how and whether to store users' tracking preferences. and how and whether to store users' tracking preferences.
When an explicit list of domains is provided through the API, their names When an explicit list of domains is provided through the API, their names
might mean little to the user. The user might, for example, be told that 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 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 may top-level origin, rather than listing them by name; or the user agent
decide to store, and show to the user, a site-wide exception, effectively might decide to store a site-wide exception, effectively ignoring any list
ignoring the list of domain names, if supplied. of domain names.
Conversely, if a wild-card is used, the user may be told that there is a Conversely, if a wild-card is used, the user might be told that there is a
stored exception for all third-parties that are, or will be, embedded on stored exception for all third-parties that are embedded by the indicated
the indicated the top-level origin. top-level origin.
7.4 JavaScript API for Site-specific Exceptions 7.4 Site-specific Exceptions
7.4.1 API to Request a Site-specific Exception 7.4.1 API to Request a Site-specific Exception
partial interface Navigator { partial interface Navigator {
void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty Bag properties); void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty Bag properties);
}; };
storeSiteSpecificTrackingException storeSiteSpecificTrackingException
Called by a page to store a site-specific tracking exception. Called by a page to store a site-specific tracking exception.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
properties StoreSiteSpecificExceptionPropertyBag * * properties StoreSiteSpecificExceptionPropertyBag * *
Return type: void 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;
long? maxAge;
}; };
detailURI of type DOMString, nullable detailURI of type DOMString, nullable
A location at which further information about this request can be A location at which further information about this request can be
found. found.
domain of type DOMString, nullable domain of type DOMString, nullable
Cookie-like domain string to which the exception applies. a cookie-domain as defined in [RFC6265], to which the exception
applies.
expires of type DOMString, nullable
A date and time, encoded as described for the cookie Expires
attribute described in [RFC6265], indicating the maximum lifetime
of the remembered grant.
explanationString of type DOMString, nullable explanationString of type DOMString, nullable
A short explanation of the request. A short explanation of the request.
maxAge of type long, nullable
A positive number of seconds indicating the maximum lifetime of
the remembered grant.
siteName of type DOMString, nullable siteName of type DOMString, nullable
A user-readable string for the name of the top-level origin. A user-readable string for the name of the top-level origin.
dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag { dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag {
sequence<DOMString> arrayOfDomainStrings; sequence<DOMString> arrayOfDomainStrings;
}; };
arrayOfDomainStrings of type sequence<DOMString> arrayOfDomainStrings of type sequence<DOMString>
A JavaScript array of strings. A JavaScript array of strings.
skipping to change at line 1396 skipping to change at line 1437
[document-origin, * ] [document-origin, * ]
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 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 may 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 document-origin would not be able to set a cookie on the domain
following the cookie domain rules [COOKIES] (e.g. domain is not a 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 a SYNTAX_ERR exception SHOULD be thrown.
If permission is stored for an explicit list, then the set of duplets (one If permission is stored for an explicit list, then the set of duplets (one
per target): per target):
[*.domain, target] [*.domain, target]
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 permission 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 - is only A particular response to the API - like a DNT response header field - is
valid immediately, and users may choose to edit the list of 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
cancelled (i.e. processed as if the relevant Cancel API had been called)
no later than the specified date and time. After this the database of
remembered grants will no longer contain any duplets for which the first
part is the current document origin; i.e., no duplets [document-origin,
target] for any target.
If maxAge is supplied and not null, empty or negative the remembered grant
will be cancelled (i.e. processed as if the relevant Cancel API had been
called) no later than the specified number of seconds following the grant.
If both maxAge and expires are supplied, maxAge has precedence. If neither
maxAge or expires are supplied, the user agent MAY retain the remembered
grant until it is cancelled.
7.4.2 API to Cancel a Site-specific Exception 7.4.2 API to Cancel a Site-specific Exception
partial interface Navigator { partial interface Navigator {
void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag proper ties); void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag proper ties);
}; };
removeSiteSpecificTrackingException removeSiteSpecificTrackingException
If domain is not supplied or is null or empty then this ensures If domain is not supplied or is null or empty then this ensures
that the database of remembered grants no longer contains any that the database of remembered grants no longer contains any
skipping to change at line 1454 skipping to change at line 1510
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
properties RemoveExceptionPropertyBag * * properties RemoveExceptionPropertyBag * *
Return type: void Return type: void
dictionary RemoveExceptionPropertyBag { dictionary RemoveExceptionPropertyBag {
DOMString? domain; DOMString? domain;
}; };
domain of type DOMString, nullable domain of type DOMString, nullable
Cookie-like domain string to which the exception applies. a cookie-domain as defined in [RFC6265], to which the exception
applies.
When this method returns the database of grants no longer contains the When this method returns, the database of grants no longer contains the
indicated grant(s); if some kind of processing error occurred then an indicated grant(s); if some kind of processing error occurred then an
appropriate exception will be thrown. 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.4.3 API to Confirm a Site-specific Exception
partial interface Navigator { partial interface Navigator {
skipping to change at line 1483 skipping to change at line 1540
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
properties ConfirmSiteSpecificExceptionPropertyBag * * properties ConfirmSiteSpecificExceptionPropertyBag * *
Return type: boolean Return type: boolean
dictionary ConfirmExceptionPropertyBag { dictionary ConfirmExceptionPropertyBag {
DOMString? domain; DOMString? domain;
}; };
domain of type DOMString, nullable domain of type DOMString, nullable
Cookie-like domain string to which the exception applies. a cookie-domain as defined in [RFC6265], to which the exception
applies.
dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBa g { dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBa g {
sequence<DOMString> arrayOfDomainStrings; sequence<DOMString> arrayOfDomainStrings;
}; };
arrayOfDomainStrings of type sequence<DOMString> 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
skipping to change at line 1515 skipping to change at line 1573
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] [document-origin, 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, * ] [document-origin, * ]
If the user agent stores explicit lists, and the call includes one, and If the user agent stores explicit lists, the call includes one, and the
the domain argument is provided and is not empty then the database is domain argument is provided and is not empty, then the database is checked
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 boolean 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 JavaScript API for Web-wide Exceptions 7.5 Web-wide Exceptions
7.5.1 API to Request a Web-wide Exception 7.5.1 API to Request a Web-wide Exception
partial interface Navigator { partial interface Navigator {
void storeWebWideTrackingException (StoreExceptionPropertyBag properties); void storeWebWideTrackingException (StoreExceptionPropertyBag properties);
}; };
storeWebWideTrackingException storeWebWideTrackingException
The single duplet [ * , document-origin] or [ * , *.domain] (based The single duplet [ * , document-origin] or [ * , *.domain] (based
on if domain is provided and is not null and not empty) is added on if domain is provided and is not null and not empty) is added
to the database of remembered grants. The properties of the to the database of remembered grants. The properties of the
StoreExceptionPropertyBag dictionary are as described above in the StoreExceptionPropertyBag dictionary are as described above in the
request for site-specific exceptions. request for site-specific exceptions.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
properties StoreExceptionPropertyBag * * properties StoreExceptionPropertyBag * *
Return type: void Return type: void
This API requests the addition of a web-wide grant for a specific site, to This API requests the addition of a web-wide grant for a specific site to
the database. the database.
7.5.2 API to Cancel a Web-wide Exception 7.5.2 API to Cancel a Web-wide Exception
partial interface Navigator { partial interface Navigator {
void removeWebWideTrackingException (RemoveExceptionPropertyBag properties) ; void removeWebWideTrackingException (RemoveExceptionPropertyBag properties) ;
}; };
removeWebWideTrackingException removeWebWideTrackingException
Ensures that the database of remembered grants no longer contains Ensures that the database of remembered grants no longer contains
the duplet [ * , document-origin] or [ * , *.domain] (based on if the duplet [ * , document-origin] or [ * , *.domain] (based on if
domain is provided and is not null and not empty). There is no domain is provided and is not null and not empty). There is no
callback. After the call has been made, the indicated pair is callback. After the call has been made, the indicated pair is
assured not to be in the database. The same matching as is used assured not to be in the database. The same matching process
for determining which header to send is used to detect which entry defined for determining which header field to send is also used to
(if any) to remove from the database. detect which entry (if any) to remove from the database.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
properties RemoveExceptionPropertyBag * * properties RemoveExceptionPropertyBag * *
Return type: void Return type: void
7.5.3 API to Confirm a Web-wide Exception 7.5.3 API to Confirm a Web-wide Exception
partial interface Navigator { partial interface Navigator {
boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag proper ties); boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag proper ties);
}; };
confirmWebWideTrackingException confirmWebWideTrackingException
Confirms that there exists in the database a web-wide exception
for a specific site.
Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description
properties ConfirmExceptionPropertyBag * * properties ConfirmExceptionPropertyBag * *
Return type: boolean Return type: boolean
This API confirms the existence of a web-wide grant for a specific site,
in the database.
The returned boolean indicates whether the duplet [ * , document-origin] The returned boolean indicates whether the duplet [ * , document-origin]
or [ * , *.domain] (based on if domain is provided and is not null and not 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 Transfer of an exception to another third party 7.6 User Interface Guidelines
A site may request an exception for one or more third party services used
in conjunction with its own offer. Those third party services may wish to
use other third parties to complete the request in a chain of
interactions. The first party will not necessarily know in advance whether
a known third party will use some other third parties.
If a user agent sends a tracking exception to a given combination of
origin server and a named third party, the user agent will send DNT:0 to
that named third party. By receiving the DNT:0 header, the named third
party acquires the permission to track the user agent and collect the data
and process it in any way allowed by the legal system it is operating in.
Furthermore, the named third party receiving the DNT:0 header acquires at
least the right to collect data and process it for the given interaction
and any other use unless it receives a DNT:1 header from that particular
identified user agent.
The named third party is also allowed to transmit the collected data for
uses related to this interaction to its own sub-services and
sub-sub-services (transitive permission). The tracking permission request
triggered by the origin server is thus granted to the named third party
and its sub-services. This is even true for sub-services that would
normally receive a DNT:1 web-wide preference from the user agent if the
user agent interacted with this service directly.
For advertisement networks this typically would mean that the collection
and auction system chain can use the data for that interaction and combine
it with existing profiles and data. The sub-services to the named third
party do not acquire an independent right to process the data for
independent secondary uses unless they, themselves, receive a DNT:0 header
from the user agent (as a result of their own request or the request of a
first-party). In our example of advertisement networks that means the
sub-services can use existing profiles in combination with the data
received, but they can not store the received information into a profile
until they have received a DNT:0 of their own.
A named third party acquiring an exception with this mechanism MUST make
sure that sub-services it uses acknowledge this constraint by requiring
the use of the appropriate tracking status value of 'C' (consent), and the
qualifier "t", from its sub-sub-services.
The permission acquired by the DNT mechanism does not override retention
limitations found in the legal system the content provider or the named
third party are operating in.
7.7 User interface guidelines
This section is non-normative. This section is non-normative.
As described above, it is the responsibility solely of the site making the As described above, it is the sole responsibility of the site making an
call to determine that an exception grant reflects the user's informed API call to determine that an exception grant reflects the user's informed
consent at the time of the call. consent at the time of the call.
It is expected that the site will explain, in its online content, the need It is expected that a site will explain to the user, in its online
for an exception, and the consequences of granting or denying an content, the need for an exception and the consequences of granting or
exception, to the user. denying that exception.
User agents are free to implement exception management user interfaces as User agents are free to implement exception management user interfaces as
they see fit. Some agents might provide a notification to the user at the 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 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 until the user approves. Some agents might provide a user-interface to see
and edit the database of recorded exception grants. The API parameters and edit the database of recorded exception grants. The API parameters
siteName, explanationString, and detailURI are provided so that the user siteName, explanationString, and detailURI are provided so that the user
agent may use them in their user interface. 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 A user agent that chooses to highlight when tracking exceptions have been
stored might provide an interface like the following. stored might provide an interface like the following:
* an icon in the status bar indicating that an exception has been * an icon in the status bar indicating that an exception has been
stored, which, when clicked on, gives the user more information about stored, which, when clicked on, gives the user more information about
the exception and an option to revoke such an exception. the exception and an option to revoke such an exception.
* an infobar stating "Example News (news.example.com) has indicated to * an infobar stating "Example News (news.example.com) has indicated to
Browser that you have consented to granting it exceptions to your Browser that you have consented to granting it exceptions to your
general Do Not Track preference. If you believe this is incorrect, general Do Not Track preference. If you believe this is incorrect,
click Revoke." click Revoke."
* no UI at all. * no UI at all.
In some user agent implementations, decisions to grant exceptions may have In some user agent implementations, decisions to grant exceptions might
been made in the past (and since forgotten) or may have been made by other have been made in the past (and since forgotten) or might have been made
users of the device. Thus, exceptions may not always represent the current by other users of the device. Thus, exceptions might not always represent
preferences of the user. Some user agents might choose to provide ambient the current preferences of the user. Some user agents might choose to
notice that user-opted tracking is ongoing, or easy access to view and provide ambient notice that user-opted tracking is ongoing, or easy access
control these preferences. Users may desire options to edit exceptions to view and control these preferences. Users might also desire to edit
either at the time of tracking or in a separate user interface. This might exceptions within a separate user interface, which would allow a user to
allow the user to edit their preferences for a site they do not trust modify their stored exceptions without visiting the target sites.
without visiting that site.
7.8 Exceptions without interactive JavaScript 7.7 Exceptions without Interactive JavaScript
This section is non-normative. This section is non-normative.
Some third party servers may wish to receive user-granted exceptions but Some third party servers that might wish to receive a user-granted
when they are invoked as third parties (using, for example, images, or exception do not have the ability to invoke an interactive JavaScript
"tracking pixels") do not have an interactive JavaScript presence on the presence on a page (for example, those that provide only images or
page. They cannot request an exception under these circumstances, both "tracking pixels"). They cannot request an exception under these
because a script is needed, and because they are required to explain to circumstances, both because a script is needed, and because they would be
the user the need for and consequences of granting an exception, and get required to explain to the user the need for and consequences of granting
the user's consent. In general this process of informing, getting consent, an exception, and get the user's consent. In general, this process of
and calling the API is not expected to be in the page where such trackers informing, getting consent, and calling the API is not expected within
are invoked. page elements 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 may 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, the first party site could load a frame of the site
desiring the exception, or that frame might be part of some other page desiring the exception, or that frame might be part of some other page
containing a number of frames, which allows aggregation of requests for containing a number of frames, which allows aggregation of requests for
exceptions. 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
getting their consent, and is also able to call the Javascript API when it obtaining their consent, while enabling a call to the Javascript API when
is granted. such consent is granted.
7.9 Exceptions without a DNT header 7.8 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. Users might wish to grant affirmative permission to tracking DNT header field. Users might wish to grant affirmative permission to
on or by certain sites even without expressing general tracking tracking on or by certain sites even without expressing a general tracking
preferences. 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 window.doNotTrack is null. Scripts SHOULD test for the existence
of storeSiteSpecificTrackingException before calling the method. If an of storeSiteSpecificTrackingException before calling the method. If an
exception is granted and the user agent stores that preference, a user exception is granted and the user agent stores that preference, a user
agent may send a DNT:0 header field even if a tracking preference isn't agent might send the DNT:0 tracking preference even if it has not enabled
expressed for other requests. Persisted preferences MAY also affect which preferences to be sent for other requests. Persisted preferences MAY
header is transmitted if a user later chooses to express a tracking affect which preference is transmitted if a user later chooses to express
preference. a tracking preference.
Note Note
Users might not configure their agents to have simple values for DNT, but Users might not configure their agents to have simple values for DNT, but
use different browsing modes or other contextual information to decide on use different browsing modes or other contextual information to decide on
a DNT value. What algorithm a user agent employs to determine DNT values a DNT value. What algorithm a user agent employs to determine DNT values
(or the lack thereof) is out of the scope of this specification. (or the lack thereof) is out of the scope of this specification.
7.10 Exception use by sites 7.9 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 exceptions APIs to best effect; sites of particular interest
here are those that need an exception in order to allow the user to here are those that need an exception in order to allow the user to
perform some operation or to have some access. perform some operation or to have some access.
The 'Store' calls do not have a return value, and return immediately. If The 'Store' calls return immediately, without a return value. If there is
there is a problem with the calling parameters, then a Javascript a problem with the calling parameters, then a Javascript exception will be
exception will be raised. In addition, it may be that the user agent does raised.
not immediately store the exception, possibly because it is allowing the
user to confirm. Even though the site has acquired the user's informed
consent before calling the 'Store' API, it is possible that the user will
change their mind, and allow the store to proceed but then later ask it be
removed, or even by denying the storage in the first place.
Sites can call the 'Confirm' APIs to enquire whether a specific exception A user agent might not store the exception immediately, possibly because
has been granted and stands in the user agent. This is the call to make to it is allowing the user to confirm. Even though the site has acquired the
determine whether the exception exists, and hence to control access to the user's informed consent before calling the 'Store' API, it is possible
function or operation; if it fails (the exception has been deleted, or not that the user will change their mind, allow the storing of an exception to
yet granted), then the user is ideally again offered the information proceed but later remove it, or perhaps deny the storage by prior
needed to give their informed consent, and again offered the opportunity configuration.
to indicate that they grant it. As stated in the normative text, the site
needs to explain and acquire consent immediately prior to calling the Nonetheless, at the time of the call, the site has acquired the user's
Store API, and not remember some past consent; this allows the user to consent and can proceed on that basis, whether or not the user-agent has
change their mind. stored the exception immediately. It is not necessary to call the confirm
API at the time of consent.
On other visits, a site can call the 'Confirm' APIs to enquire whether a
specific exception has been granted and stands in the user agent. This is
the call to make to determine whether the exception exists, and hence to
control access to the function or operation; if it fails (the exception
has been deleted or not yet granted), then the user is ideally again
offered the information needed to give their informed consent, and again
offered the opportunity to indicate that they grant it. As stated in the
normative text, the site needs to explain and acquire consent immediately
prior to calling the Store API, and not remember some past consent; this
allows a user to change their mind.
If they do grant it (using some positive interaction such as a button), If they do grant it (using some positive interaction such as a button),
the site can return to checking the 'Confirm' API. the site can return to checking the 'Confirm' API.
In this way the site: In this way the site:
* does not assume that the storage is instantaneous, and mistakenly * does not assume that the storage is instantaneous and mistakenly grant
grant access when the exception does not (yet) stand; access when the exception does not (yet) stand;
* does not call the Confirm API repeatedly without a user-interaction * does not call the Confirm API repeatedly, in a loop, without a
between each call, in a loop; 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.11 Fingerprinting 7.10 Fingerprinting
By storing a client-side configurable state and providing functionality to By storing a client-side configurable state and providing functionality to
learn about it later, this API might facilitate user fingerprinting and learn about it later, this API might facilitate user fingerprinting and
tracking. User agent developers ought to consider the possibility of tracking. User agent developers ought to consider the possibility of
fingerprinting during implementation and might consider rate-limiting fingerprinting during implementation and might consider rate-limiting
requests or using other heuristics to mitigate fingerprinting risk. 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
skipping to change at line 1865 skipping to change at line 1884
Author(s): Author(s):
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
[ABNF] [HTML5]
D. Crocker; P. Overell. Augmented BNF for Syntax Specifications: Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika
ABNF. January 2008. STD. URL: http://www.ietf.org/rfc/rfc5234.txt Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October
2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
[COOKIES]
A. Barth. HTTP State Management Mechanism. April 2011. RFC. URL:
http://www.ietf.org/rfc/rfc6265.txt
[HTTP] [RFC2119]
Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol S. Bradner. Key words for use in RFCs to Indicate Requirement
(HTTP/1.1): Message Syntax and Routing. 6 February 2014. Levels. March 1997. Best Current Practice. URL:
Internet-Draft. URL: https://tools.ietf.org/html/rfc2119
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/
[HTTP-cache] [RFC3986]
Roy T. Fielding; Mark Nottingham; Julian Reschke. Hypertext T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource
Transfer Protocol (HTTP/1.1): Caching. 6 February 2014. Identifier (URI): Generic Syntax. January 2005. Internet Standard.
Internet-Draft. URL: URL: https://tools.ietf.org/html/rfc3986
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p6-cache/
[HTTP-semantics] [RFC5234]
Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax
(HTTP/1.1): Semantics and Content. 6 February 2014. Specifications: ABNF. January 2008. Internet Standard. URL:
Internet-Draft. URL: https://tools.ietf.org/html/rfc5234
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/
[RFC2119] [RFC6265]
S. Bradner. Key words for use in RFCs to Indicate Requirement A. Barth. HTTP State Management Mechanism. April 2011. Proposed
Levels. March 1997. Internet RFC 2119. URL: Standard. URL: https://tools.ietf.org/html/rfc6265
http://www.ietf.org/rfc/rfc2119.txt
[RFC7159] [RFC7159]
Tim Bray, Ed.. The JavaScript Object Notation (JSON) Data T. Bray, Ed.. The JavaScript Object Notation (JSON) Data
Interchange Format. March 2014. Internet RFC 7159. URL: Interchange Format. March 2014. Proposed Standard. URL:
http://www.rfc-editor.org/rfc/rfc7159.txt https://tools.ietf.org/html/rfc7159
[RFC7230]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing. June 2014. Proposed
Standard. URL: https://tools.ietf.org/html/rfc7230
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content. June 2014. Proposed Standard.
URL: https://tools.ietf.org/html/rfc7231
[RFC7234]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. Hypertext
Transfer Protocol (HTTP/1.1): Caching. June 2014. Proposed
Standard. URL: https://tools.ietf.org/html/rfc7234
[WEBIDL] [WEBIDL]
Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate
Recommendation. URL: http://www.w3.org/TR/WebIDL/ Recommendation. URL: http://www.w3.org/TR/WebIDL/
C.2 Informative references C.2 Informative references
[KnowPrivacy] [KnowPrivacy]
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June
2009. URL: 2009. URL:
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf
[Orderly]
Lloyd Hilaiel. Orderly JSON. 10 Feb 2015. URL:
http://orderly-json.org/
[RFC5785] [RFC5785]
Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform M. Nottingham; E. Hammer-Lahav. Defining Well-Known Uniform
Resource Identifiers (URIs) (RFC 5785). April 2010. RFC. URL: Resource Identifiers (URIs). April 2010. Proposed Standard. URL:
http://www.rfc-editor.org/rfc/rfc5785.txt https://tools.ietf.org/html/rfc5785
[RFC6570]
J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard.
URI Template. March 2012. Proposed Standard. URL:
https://tools.ietf.org/html/rfc6570
[TCS] [TCS]
Heather West; Justin Brookman; Sean Harvey; Erica Newland. Heather West; Justin Brookman; Sean Harvey; Erica Newland.
Tracking Compliance and Scope. 08 April 2014. W3C Editor's Draft. Tracking Compliance and Scope. 25 November 2014. W3C Working
URL: Draft. URL: http://www.w3.org/TR/tracking-compliance/
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance
.html
[URI-TEMPLATE]
Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David
Orchard. URI Template. March 2012. RFC 6570. URL:
http://www.rfc-editor.org/rfc/rfc6570.txt
 End of changes. 145 change blocks. 
454 lines changed or deleted 490 lines changed or added

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