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