tpe_CR_20150321.txt | tpe_ED_20170702.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Preference Expression (DNT) | Tracking Preference Expression (DNT) | |||
W3C Candidate Recommendation 20 August 2015 | W3C Editor's Draft 02 July 2017 | |||
This version: | This version: | |||
http://www.w3.org/TR/2015/CR-tracking-dnt-20150820/ | https://w3c.github.io/dnt/drafts/tracking-dnt.html | |||
Latest published version: | Latest published version: | |||
http://www.w3.org/TR/tracking-dnt/ | https://www.w3.org/TR/tracking-dnt/ | |||
Latest editor's draft: | Latest editor's draft: | |||
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | https://w3c.github.io/dnt/drafts/tracking-dnt.html | |||
Implementation report: | ||||
http://www.w3.org/2011/tracking-protection/track/products/7 | ||||
Previous version: | Previous editor's draft: | |||
http://www.w3.org/TR/2014/WD-tracking-dnt-20140424/ | https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | |||
Editors: | Editors: | |||
Roy T. Fielding, Adobe | Roy T. Fielding, Adobe | |||
David Singer, Apple | David Singer, Apple | |||
Copyright © 2015 W3C^® (MIT, ERCIM, Keio, Beihang). W3C liability, | Repository and Participation: | |||
trademark and document use rules apply. | Mailing list archive | |||
Commit history | ||||
File a bug/issue | ||||
Copyright © 2017 W3C^® (MIT, ERCIM, Keio, Beihang). W3C liability, | ||||
trademark and permissive document license rules apply. | ||||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
Abstract | Abstract | |||
This specification defines the DNT request header field as an HTTP | This specification defines the DNT request header field as an HTTP | |||
mechanism for expressing the user's preference regarding tracking, an HTML | mechanism for expressing a user's preference regarding tracking, an HTML | |||
DOM property to make that expression readable by scripts, and APIs that | DOM property to make that expression readable by scripts, and APIs that | |||
allow scripts to register site-specific exceptions granted by the user. It | allow scripts to register exceptions granted by the user. It also defines | |||
also defines mechanisms for sites to communicate whether and how they | mechanisms for sites to communicate whether and how they honor a received | |||
honor a received preference through use of the Tk response header field | preference, including well-known resources for retrieving preflight | |||
and well-known resources that provide a machine-readable tracking status. | tracking status, a media type for representing tracking status | |||
information, and the Tk response header field for confirming tracking | ||||
status. | ||||
Status of This Document | Status of This Document | |||
This section describes the status of this document at the time of its | This section describes the status of this document at the time of its | |||
publication. Other documents may supersede this document. A list of | publication. Other documents may supersede this document. A list of | |||
current W3C publications and the latest revision of this technical report | current W3C publications and the latest revision of this technical report | |||
can be found in the W3C technical reports index at http://www.w3.org/TR/. | can be found in the W3C technical reports index at https://www.w3.org/TR/. | |||
This document was published by the Tracking Protection Working Group as a | ||||
Candidate Recommendation on 20 August 2015. This document is intended to | ||||
become a W3C Recommendation. If you wish to make comments regarding this | ||||
document, please send them to public-tracking-comments@w3.org (subscribe, | ||||
archives). W3C publishes a Candidate Recommendation to indicate that the | ||||
document is believed to be stable and to encourage implementation by the | ||||
developer community. This Candidate Recommendation is expected to advance | ||||
to Proposed Recommendation no earlier than 20 November 2015. The Working | ||||
Group expects to have sufficient implementation experience by 20 February | ||||
2016. All comments are welcome. | ||||
Readers may review changes from the Last Call Working Draft; changes | ||||
include: moving JavaScript property to navigator; addition of a tracking | ||||
status value for gateways; clarifications of terminology; and updated | ||||
references. An issue tracking system is available for recording raised, | ||||
open, pending review, closed, and postponed issues regarding this | ||||
document. There is also a list of issues reported and addressed during the | ||||
Last Call period. | ||||
The following feature is at risk and might be cut from the specification | ||||
during the CR period if there are no (correct) implementations: | ||||
* DNT-extension | This document is an editors' straw man reflecting a snapshot of live | |||
discussions within the Tracking Protection Working Group. It does not | ||||
necessarily constitute working group consensus. This draft has been | ||||
prepared using the DNT github repository and its associated issues list. | ||||
However, see the previous issue tracking system for working group | ||||
decisions prior to 2017. | ||||
Please see the Working Group's implementation report. | This document was published by the Tracking Protection Working Group as an | |||
Editor's Draft. Comments regarding this document are welcome. Please send | ||||
them to public-tracking@w3.org (subscribe, archives). | ||||
Publication as a Candidate Recommendation does not imply endorsement by | Publication as an Editor's Draft does not imply endorsement by the W3C | |||
the W3C Membership. This is a draft document and may be updated, replaced | Membership. This is a draft document and may be updated, replaced or | |||
or obsoleted by other documents at any time. It is inappropriate to cite | obsoleted by other documents at any time. It is inappropriate to cite this | |||
this document as other than work in progress. | document as other than work in progress. | |||
This document was produced by a group operating under the 5 February 2004 | This document was produced by a group operating under the 5 February 2004 | |||
W3C Patent Policy. W3C maintains a public list of any patent disclosures | W3C Patent Policy. W3C maintains a public list of any patent disclosures | |||
made in connection with the deliverables of the group; that page also | made in connection with the deliverables of the group; that page also | |||
includes instructions for disclosing a patent. An individual who has | includes instructions for disclosing a patent. An individual who has | |||
actual knowledge of a patent which the individual believes contains | actual knowledge of a patent which the individual believes contains | |||
Essential Claim(s) must disclose the information in accordance with | Essential Claim(s) must disclose the information in accordance with | |||
section 6 of the W3C Patent Policy. | section 6 of the W3C Patent Policy. | |||
This document is governed by the 14 October 2005 W3C Process Document. | This document is governed by the 1 March 2017 W3C Process Document. | |||
Table of Contents | Table of Contents | |||
* 1. Introduction | 1. 1. Introduction | |||
* 2. Terminology | 2. 2. Terminology | |||
* 2.1 HTTP | 1. 2.1 HTTP | |||
* 2.2 Activity | 2. 2.2 HTML | |||
* 2.3 Participants | 3. 2.3 Activity | |||
* 2.4 Data | 4. 2.4 Participants | |||
* 2.5 Preferences | 5. 2.5 Data | |||
* 3. Notational Conventions | 3. 3. Notational Conventions | |||
* 3.1 Requirements | 1. 3.1 Requirements | |||
* 3.2 Formal Syntax | 2. 3.2 Formal Syntax | |||
* 4. Determining User Preference | 4. 4. Determining User Preference | |||
* 5. Expressing a Tracking Preference | 5. 5. Expressing a Tracking Preference | |||
* 5.1 Expression Format | 1. 5.1 Expression Format | |||
* 5.2 DNT Header Field for HTTP Requests | 2. 5.2 DNT Header Field for HTTP Requests | |||
* 5.2.1 DNT Extensions | 1. 5.2.1 Extensions to the DNT Field Value | |||
* 5.3 JavaScript Property to Detect Preference | 3. 5.3 JavaScript Property to Detect Preference | |||
* 5.4 Tracking Preference Expressed in Other Protocols | 4. 5.4 Tracking Preference Expressed in Other Protocols | |||
* 6. Communicating a Tracking Status | 6. 6. Communicating a Tracking Status | |||
* 6.1 Overview | 1. 6.1 Overview | |||
* 6.2 Tracking Status Value | 2. 6.2 Tracking Status Value | |||
* 6.2.1 Definition | 1. 6.2.1 Definition | |||
* 6.2.2 Under Construction (!) | 2. 6.2.2 Under Construction (!) | |||
* 6.2.3 Dynamic (?) | 3. 6.2.3 Dynamic (?) | |||
* 6.2.4 Gateway (G) | 4. 6.2.4 Gateway (G) | |||
* 6.2.5 Not Tracking (N) | 5. 6.2.5 Not Tracking (N) | |||
* 6.2.6 Tracking (T) | 6. 6.2.6 Tracking (T) | |||
* 6.2.7 Consent (C) | 7. 6.2.7 Consent (C) | |||
* 6.2.8 Potential Consent (P) | 8. 6.2.8 Potential Consent (P) | |||
* 6.2.9 Disregarding (D) | 9. 6.2.9 Disregarding (D) | |||
* 6.2.10 Updated (U) | 10. 6.2.10 Updated (U) | |||
* 6.3 Tk Header Field for HTTP Responses | 11. 6.2.11 Extensions to the Tracking Status Value | |||
* 6.3.1 Definition | 3. 6.3 Tk Header Field for HTTP Responses | |||
* 6.3.2 Referring to a Request-specific Tracking Status | 1. 6.3.1 Definition | |||
2. 6.3.2 Referring to a Request-specific Tracking Status | ||||
Resource | Resource | |||
* 6.3.3 Indicating an Interactive Status Change | 3. 6.3.3 Indicating an Interactive Status Change | |||
* 6.4 Tracking Status Resource | 4. 6.4 Tracking Status Resource | |||
* 6.4.1 Site-wide Tracking Status | 1. 6.4.1 Site-wide Tracking Status | |||
* 6.4.2 Request-specific Tracking Status | 2. 6.4.2 Request-specific Tracking Status | |||
* 6.4.3 Status Checks are Not Tracked | 3. 6.4.3 Status Checks are Not Tracked | |||
* 6.4.4 Caching | 4. 6.4.4 Caching | |||
* 6.5 Tracking Status Representation | 5. 6.5 Tracking Status Representation | |||
* 6.5.1 Status Object | 1. 6.5.1 Status Object | |||
* 6.5.2 Tracking Property | 2. 6.5.2 Tracking Property | |||
* 6.5.3 Compliance Property | 3. 6.5.3 Compliance Property | |||
* 6.5.4 Qualifiers Property | 4. 6.5.4 Qualifiers Property | |||
* 6.5.5 Controller Property | 5. 6.5.5 Controller Property | |||
* 6.5.6 Same-party Property | 6. 6.5.6 Same-party Property | |||
* 6.5.7 Audit Property | 7. 6.5.7 Audit Property | |||
* 6.5.8 Policy Property | 8. 6.5.8 Policy Property | |||
* 6.5.9 Config Property | 9. 6.5.9 Config Property | |||
* 6.5.10 Extensions | 10. 6.5.10 Extensions to the Status Object | |||
* 6.6 Status Code for Tracking Required | 6. 6.6 Status Code for Tracking Required | |||
* 6.7 Using the Tracking Status | 7. 6.7 Using the Tracking Status | |||
* 6.7.1 Discovering Deployment | 1. 6.7.1 Discovering Deployment | |||
* 6.7.2 Preflight Checks | 2. 6.7.2 Preflight Checks | |||
* 7. User-Granted Exceptions | 7. 7. User-Granted Exceptions | |||
* 7.1 Overview | 1. 7.1 Motivating Principles | |||
* 7.2 Motivating Principles and Use Cases | 2. 7.2 Exception Model | |||
* 7.3 Exception Model | 3. 7.3 Granting Exception | |||
* 7.3.1 User Interaction | 4. 7.4 Exception Management | |||
* 7.3.2 Processing Model | 5. 7.5 Checking for Exception | |||
* 7.4 Site-specific Exceptions | 6. 7.6 Site-specific Exception | |||
* 7.4.1 API to Request a Site-specific Exception | 1. 7.6.1 API to Request a Site-specific Exception | |||
* 7.4.2 API to Cancel a Site-specific Exception | 2. 7.6.2 API to Cancel a Site-specific Exception | |||
* 7.4.3 API to Confirm a Site-specific Exception | 3. 7.6.3 API to Confirm a Site-specific Exception | |||
* 7.5 Web-wide Exceptions | 7. 7.7 Web-wide Exceptions | |||
* 7.5.1 API to Request a Web-wide Exception | 1. 7.7.1 API to Request a Web-wide Exception | |||
* 7.5.2 API to Cancel a Web-wide Exception | 2. 7.7.2 API to Cancel a Web-wide Exception | |||
* 7.5.3 API to Confirm a Web-wide Exception | 3. 7.7.3 API to Confirm a Web-wide Exception | |||
* 7.6 User Interface Guidelines | 8. 7.8 Exceptions without Interactive JavaScript | |||
* 7.7 Exceptions without Interactive JavaScript | 9. 7.9 Exceptions without an Expressed Preference | |||
* 7.8 Exceptions without an Expressed Preference | 10. 7.10 Exception Use by Sites | |||
* 7.9 Exception Use by Sites | 8. 8. Security Considerations | |||
* 7.10 Fingerprinting | 9. 9. Privacy Considerations | |||
* A. Acknowledgements | 1. 9.1 Fingerprinting | |||
* B. Registrations | 10. A. Acknowledgements | |||
* C. References | 11. B. Registrations | |||
* C.1 Normative references | 12. C. References | |||
* C.2 Informative references | 1. C.1 Normative references | |||
2. C.2 Informative references | ||||
1. Introduction | 1. Introduction | |||
The World Wide Web consists of billions of resources interconnected | The World Wide Web consists of billions of resources interconnected | |||
through the use of hypertext. Hypertext provides a simple, page-oriented | through the use of hypertext. Hypertext provides a simple, page-oriented | |||
view of the information provided by those resources, which can be | view of the information provided by those resources, which can be | |||
traversed by selecting links, manipulating controls, and supplying data | traversed by selecting links, manipulating controls, and supplying data | |||
via forms and search dialogs. | via forms and search dialogs. | |||
A Web page is often composed of many information sources beyond the | A Web page is often composed of many information sources beyond the | |||
skipping to change at line 208 | skipping to change at line 199 | |||
connects a user's activity across multiple pages. A survey of these | connects a user's activity across multiple pages. A survey of these | |||
techniques and their privacy implications can be found in [KnowPrivacy]. | techniques and their privacy implications can be found in [KnowPrivacy]. | |||
Users need a mechanism to express their own preferences regarding tracking | Users need a mechanism to express their own preferences regarding tracking | |||
that is both simple to configure and efficient when implemented. However, | that is both simple to configure and efficient when implemented. However, | |||
merely expressing a preference does not imply that all recipients will | merely expressing a preference does not imply that all recipients will | |||
comply. In some cases, a server might be dependent on some forms of | comply. In some cases, a server might be dependent on some forms of | |||
tracking and unwilling or unable to turn that off. In other cases, a | tracking and unwilling or unable to turn that off. In other cases, a | |||
server might perform only limited forms of tracking that would be | server might perform only limited forms of tracking that would be | |||
acceptable to most users. Therefore, servers need mechanisms for | acceptable to most users. Therefore, servers need mechanisms for | |||
communicating their own tracking behavior, requesting an exception to a | communicating their own tracking behavior, requesting consent, and storing | |||
user's general preference, and storing such a user-granted exception after | a user-granted exception once the user has made an informed choice. | |||
the user has made an informed choice. | ||||
This specification extends Hypertext Transfer Protocol (HTTP) semantics | This specification extends Hypertext Transfer Protocol (HTTP) semantics | |||
[RFC7231] to communicate a user's tracking preference, if any, and an | [RFC7231] to communicate a user's tracking preference, if any, and an | |||
origin server's tracking behavior. The DNT request header field is defined | origin server's tracking behavior. The DNT request header field is defined | |||
for communicating the user's tracking preference for the target resource. | for communicating the user's tracking preference for the target resource. | |||
A well-known URI for a tracking status resource and the Tk response header | A well-known URI for a tracking status resource and the Tk response header | |||
field are defined for communicating the server's tracking behavior. In | field are defined for communicating the server's tracking behavior. In | |||
addition, JavaScript APIs are defined for enabling scripts to determine | addition, JavaScript APIs are defined for enabling scripts to determine | |||
DNT status and register a user-granted exception. | DNT status and register a user-granted exception. | |||
skipping to change at line 236 | skipping to change at line 226 | |||
regime defines its own requirements on compliant behavior. For example, | regime defines its own requirements on compliant behavior. For example, | |||
[TCS] is a work-in-progress that intends to define such a compliance | [TCS] is a work-in-progress that intends to define such a compliance | |||
regime. | regime. | |||
2. Terminology | 2. Terminology | |||
2.1 HTTP | 2.1 HTTP | |||
The following terms are used as defined by HTTP/1.1 syntax [RFC7230] and | The following terms are used as defined by HTTP/1.1 syntax [RFC7230] and | |||
semantics [RFC7231]: client, server, origin server, user agent, sender, | semantics [RFC7231]: client, server, origin server, user agent, sender, | |||
recipient, request, response, message, intermediary, proxy, cache, header | recipient, request, response, message, intermediary, proxy, cache, | |||
field, target resource, resource, and representation. | uri-host, authority, header field, target resource, resource, and | |||
representation. | ||||
2.2 Activity | 2.2 HTML | |||
The following terms are used as defined by HTML [HTML5]: active document, | ||||
document.domain, effective script origin, responsible document, and | ||||
top-level browsing context. | ||||
2.3 Activity | ||||
Tracking is the collection of data regarding a particular user's activity | Tracking is the collection of data regarding a particular user's activity | |||
across multiple distinct contexts and the retention, use, or sharing of | across multiple distinct contexts and the retention, use, or sharing of | |||
data derived from that activity outside the context in which it occurred. | data derived from that activity outside the context in which it occurred. | |||
A context is a set of resources that are controlled by the same party or | A context is a set of resources that are controlled by the same party or | |||
jointly controlled by a set of parties. | jointly controlled by a set of parties. | |||
A network interaction is a single HTTP request and its corresponding | A network interaction is a single HTTP request and its corresponding | |||
response(s): zero or more interim (1xx) responses and a single final | response(s): zero or more interim (1xx) responses and a single final | |||
(2xx-5xx) response. | (2xx-5xx) response. | |||
A user action is a deliberate action by the user, via configuration, | A user action is a deliberate action by the user, via configuration, | |||
invocation, or selection, to initiate a network interaction. Selection of | invocation, or selection, to initiate a network interaction. Selection of | |||
a link, submission of a form, and reloading a page are examples of user | a link, submission of a form, and reloading a page are examples of user | |||
actions. User activity is any set of such user actions. | actions. User activity is any set of such user actions. | |||
2.3 Participants | 2.4 Participants | |||
A user is a natural person who is making, or has made, use of the Web. | A user is a natural person who is making, or has made, use of the Web. | |||
A party is a natural person, a legal entity, or a set of legal entities | A party is a natural person, a legal entity, or a set of legal entities | |||
that share common owner(s), common controller(s), and a group identity | that share common owner(s), common controller(s), and a group identity | |||
that is easily discoverable by a user. Common branding or providing a list | that is easily discoverable by a user. Common branding or providing a list | |||
of affiliates that is available via a link from a resource where a party | of affiliates that is available via a link from a resource where a party | |||
describes DNT practices are examples of ways to provide this | describes DNT practices are examples of ways to provide this | |||
discoverability. | discoverability. | |||
skipping to change at line 309 | skipping to change at line 306 | |||
1. processes the data on behalf of the contractee; | 1. processes the data on behalf of the contractee; | |||
2. ensures that the data is only retained, accessed, and used as directed | 2. ensures that the data is only retained, accessed, and used as directed | |||
by the contractee; | by the contractee; | |||
3. has no independent right to use the data other than in a permanently | 3. has no independent right to use the data other than in a permanently | |||
de-identified form (e.g., for monitoring service integrity, load | de-identified form (e.g., for monitoring service integrity, load | |||
balancing, capacity planning, or billing); and, | balancing, capacity planning, or billing); and, | |||
4. has a contract in place with the contractee which is consistent with | 4. has a contract in place with the contractee which is consistent with | |||
the above limitations. | the above limitations. | |||
2.4 Data | 2.5 Data | |||
A party collects data received in a network interaction if that data | A party collects data received in a network interaction if that data | |||
remains within the party’s control after the network interaction is | remains within the party’s control after the network interaction is | |||
complete. | complete. | |||
A party uses data if the party processes the data for any purpose other | A party uses data if the party processes the data for any purpose other | |||
than storage or merely forwarding it to another party. | than storage or merely forwarding it to another party. | |||
A party shares data if it transfers or provides a copy of that data to any | A party shares data if it transfers or provides a copy of that data to any | |||
other party. | other party. | |||
Data is permanently de-identified when there exists a high level of | Data is permanently de-identified when there exists a high level of | |||
confidence that no human subject of the data can be identified, directly | confidence that no human subject of the data can be identified, directly | |||
or indirectly (e.g., via association with an identifier, user agent, or | or indirectly (e.g., via association with an identifier, user agent, or | |||
device), by that data alone or in combination with other retained or | device), by that data alone or in combination with other retained or | |||
available information. | available information. | |||
2.5 Preferences | ||||
A user-granted exception is a specific tracking preference, overriding a | ||||
user's general tracking preference, that has been obtained and recorded | ||||
using the mechanisms defined in section 7. User-Granted Exceptions. | ||||
3. Notational Conventions | 3. Notational Conventions | |||
3.1 Requirements | 3.1 Requirements | |||
The key words must, must not, required, should, should not, recommended, | The key words must, must not, required, should, should not, recommended, | |||
may, and optional in this specification are to be interpreted as described | may, and optional in this specification are to be interpreted as described | |||
in [RFC2119]. | in [RFC2119]. | |||
3.2 Formal Syntax | 3.2 Formal Syntax | |||
skipping to change at line 444 | skipping to change at line 435 | |||
5. Expressing a Tracking Preference | 5. Expressing a Tracking Preference | |||
5.1 Expression Format | 5.1 Expression Format | |||
When a user has enabled a tracking preference, that preference needs to be | When a user has enabled a tracking preference, that preference needs to be | |||
expressed to all mechanisms that might perform or initiate tracking. | expressed to all mechanisms that might perform or initiate tracking. | |||
When enabled, a tracking preference is expressed as either: | When enabled, a tracking preference is expressed as either: | |||
DNT meaning | DNT meaning | |||
1 This user prefers not to be tracked on the target site. | 1 This user prefers not to be tracked on this request. | |||
0 This user prefers to allow tracking on the target site. | 0 This user prefers to allow tracking on this request. | |||
A user agent MUST NOT send a tracking preference expression if a tracking | A user agent MUST NOT send a tracking preference expression if a tracking | |||
preference is not enabled. This means that no expression is sent for each | preference is not enabled. This means that no expression is sent for each | |||
of the following cases: | of the following cases: | |||
* the user agent does not implement this protocol; | * the user agent does not implement this protocol; | |||
* the user has not yet made a choice for a specific preference; or, | * the user has not yet made a choice for a specific preference; or, | |||
* the user has chosen not to transmit a preference. | * the user has chosen not to transmit a preference. | |||
In the absence of regulatory, legal, or other requirements, servers MAY | In the absence of regulatory, legal, or other requirements, servers MAY | |||
interpret the lack of an expressed tracking preference as they find most | interpret the lack of an expressed tracking preference as they find most | |||
appropriate for the given user, particularly when considered in light of | appropriate for the given user, particularly when considered in light of | |||
the user's privacy expectations and cultural circumstances. Likewise, | the user's privacy expectations and cultural circumstances. Likewise, | |||
servers might make use of other preference information outside the scope | servers might make use of other preference information outside the scope | |||
of this protocol, such as site-specific user preferences or third-party | of this protocol, such as site-specific user preferences or third-party | |||
registration services, to inform or adjust their behavior when no explicit | registration services, to inform or adjust their behavior when no explicit | |||
preference is expressed via this protocol. | preference is expressed via this protocol. | |||
Note | ||||
This specification defines a protocol for communicating the user's | ||||
tracking preference, not a protocol that prevents tracking on its own. It | ||||
might be tempting to assume that design for privacy would justify calling | ||||
for DNT:1 to be preconfigured as the default for all user agents. However, | ||||
that would violate the field's semantics, make its presence in a request | ||||
meaningless, and add eight extra bytes to every HTTP request (with no | ||||
effect). | ||||
The DNT signal alone does nothing to enhance a user's privacy. It is only | ||||
when recipients believe that the signal has been deliberately and | ||||
knowingly configured, and not defined as a default, that they will | ||||
consider it to be the user's preference. Furthermore, when no signal is | ||||
sent, recipients remain subject to whatever regulatory, legal, or other | ||||
regional requirements regarding tracking exist in the absence of consent. | ||||
5.2 DNT Header Field for HTTP Requests | 5.2 DNT Header Field for HTTP Requests | |||
The DNT header field is a mechanism for expressing the user's tracking | The DNT header field is a mechanism for expressing the user's tracking | |||
preference in an HTTP request ([RFC7230]). At most one DNT header field | preference in an HTTP request ([RFC7230]). At most one DNT header field | |||
can be present in a valid request. | can be present in a valid request. | |||
DNT-field-name = "DNT" | DNT-field-name = "DNT" | |||
DNT-field-value = ( "0" / "1" ) *DNT-extension | DNT-field-value = ( "0" / "1" ) *DNT-extension | |||
A user agent MUST NOT generate a DNT header field if the user's tracking | A user agent MUST NOT generate a DNT header field if the user's tracking | |||
preference is not enabled. | preference is not enabled. | |||
A user agent MUST generate a DNT header field with a field-value that | A user agent MUST generate a DNT header field with a field-value that | |||
begins with the numeric character "1" if the user's tracking preference is | begins with the numeric character "1" if the user's tracking preference is | |||
enabled, their preference is for DNT:1, and no exception has been granted | enabled, their preference is for DNT:1, and no exception has been granted | |||
for the request target (see section 7. User-Granted Exceptions). | for the target resource (see section 7. User-Granted Exceptions). | |||
A user agent MUST generate a DNT header field with a field-value that | A user agent MUST generate a DNT header field with a field-value that | |||
begins with the numeric character "0" if the user's tracking preference is | begins with the numeric character "0" if the user's tracking preference is | |||
enabled and their preference is for DNT:0, or if an exception has been | enabled and their preference is for DNT:0, or if an exception has been | |||
granted for the request target. | granted for the target resource. | |||
A proxy MUST NOT generate a DNT header field unless it has been | A proxy MUST NOT generate a DNT header field unless it has been | |||
specifically installed or configured to do so by the user making the | specifically installed or configured to do so by the user making the | |||
request and adheres to the above requirements as if it were a user agent. | request and adheres to the above requirements as if it were a user agent. | |||
Example 1 | Example 1 | |||
GET /something/here HTTP/1.1 | GET /something/here HTTP/1.1 | |||
Host: example.com | Host: example.com | |||
DNT: 1 | DNT: 1 | |||
5.2.1 DNT Extensions | 5.2.1 Extensions to the DNT Field Value | |||
The remainder of the DNT field-value, after the initial character, is | The remainder of the DNT field-value, after the initial character, is | |||
reserved for future extensions. DNT extensions can only be transmitted | reserved for future extensions. DNT extensions can only be transmitted | |||
when a tracking preference is enabled. The extension syntax is restricted | when a tracking preference is enabled. The extension syntax is restricted | |||
to visible ASCII characters that can be parsed as a single word in HTTP | to visible ASCII characters that can be parsed as a single word in HTTP | |||
and safely embedded in a JSON string without further encoding (section 6.5 | and safely embedded in a JSON string without further encoding (section 6.5 | |||
Tracking Status Representation). | Tracking Status Representation). | |||
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
; excludes CTL, SP, DQUOTE, comma, backslash | ; excludes CTL, SP, DQUOTE, comma, backslash | |||
skipping to change at line 523 | skipping to change at line 531 | |||
you understand the refinements defined by x, y, or z, then adjust my | you understand the refinements defined by x, y, or z, then adjust my | |||
preferences according to those refinements. | preferences according to those refinements. | |||
User agents that do not implement DNT extensions MUST NOT send | User agents that do not implement DNT extensions MUST NOT send | |||
DNT-extension characters in the DNT field-value. Servers that do not | DNT-extension characters in the DNT field-value. Servers that do not | |||
implement DNT extensions SHOULD ignore anything beyond the first | implement DNT extensions SHOULD ignore anything beyond the first | |||
character. | character. | |||
Note | Note | |||
The DNT-extension feature is considered at-risk. Since no extensions have | This DNT-extension feature is at-risk because no known extensions have | |||
been defined, implementors that don't read specifications are likely to | been defined; implementors that do not read this specification are likely | |||
assume that DNT only has the fixed values of "0" or "1". Furthermore, the | to assume that DNT only has the fixed values of "0" or "1". Furthermore, | |||
potential benefits of this mechanism are unclear given that extension | the potential benefits of this mechanism are unclear given that extension | |||
information could be supplied using separate request header fields. | information could be supplied using separate request header fields and | |||
inappropriate extensions to the "1" value might cause the user's requests | ||||
to be more easily fingerprinted. | ||||
5.3 JavaScript Property to Detect Preference | 5.3 JavaScript Property to Detect Preference | |||
The doNotTrack property enables a client-side script with read access to | The Navigator.doNotTrack property enables a client-side script with read | |||
the Navigator object to determine what DNT header field value would be | access to the Navigator object [HTML5] to determine what DNT header field | |||
sent in requests to the document-origin, taking into account the user's | value would be sent in requests to the effective script origin, taking | |||
general preference (if any) and any user-granted exceptions applicable to | into account the user's general preference (if any) and the current | |||
that origin server. | user-granted exceptions applicable to that target domain. | |||
partial interface Navigator { | partial interface Navigator { | |||
readonly attribute DOMString? doNotTrack; | readonly attribute DOMString? doNotTrack; | |||
}; | }; | |||
doNotTrack of type DOMString, readonly , nullable | The value of Navigator.doNotTrack is the string value that would be sent | |||
Returns the same string value that would be sent in a | in a DNT field-value (section 5.2 DNT Header Field for HTTP Requests) in a | |||
DNT-field-value (section 5.2 DNT Header Field for HTTP Requests) | request to the effective script origin. The value is null if no DNT header | |||
to a target that is the document-origin of the window, in the | field would be sent (e.g., because a tracking preference is not enabled); | |||
browser context of the current top-level origin. The value is null | otherwise, the value is a string beginning with "0" or "1", possibly | |||
if no DNT header field would be sent (e.g., because a tracking | followed by DNT-extension characters. | |||
preference is not enabled); otherwise, the value is a string | ||||
beginning with "0" or "1", possibly followed by DNT-extension | ||||
characters. | ||||
5.4 Tracking Preference Expressed in Other Protocols | 5.4 Tracking Preference Expressed in Other Protocols | |||
A user's tracking preference is intended to apply in general, regardless | A user's tracking preference is intended to apply in general, regardless | |||
of the protocols being used for Internet communication. However, it is | of the protocols being used for Internet communication. However, it is | |||
beyond the scope of this specification to define how a user's tracking | beyond the scope of this specification to define how a user's tracking | |||
preference might be communicated via protocols other than HTTP. | preference might be communicated via protocols other than HTTP. | |||
6. Communicating a Tracking Status | 6. Communicating a Tracking Status | |||
skipping to change at line 593 | skipping to change at line 600 | |||
TSV = %x21 ; "!" — under construction | TSV = %x21 ; "!" — under construction | |||
/ %x3F ; "?" — dynamic | / %x3F ; "?" — dynamic | |||
/ %x47 ; "G" — gateway to multiple parties | / %x47 ; "G" — gateway to multiple parties | |||
/ %x4E ; "N" — not tracking | / %x4E ; "N" — not tracking | |||
/ %x54 ; "T" — tracking | / %x54 ; "T" — tracking | |||
/ %x43 ; "C" — tracking with consent | / %x43 ; "C" — tracking with consent | |||
/ %x50 ; "P" — tracking only if consented | / %x50 ; "P" — tracking only if consented | |||
/ %x44 ; "D" — disregarding DNT | / %x44 ; "D" — disregarding DNT | |||
/ %x55 ; "U" — updated | / %x55 ; "U" — updated | |||
/ TSV-extension | ||||
6.2.2 Under Construction (!) | 6.2.2 Under Construction (!) | |||
A tracking status value of ! means that the origin server is currently | A tracking status value of ! means that the origin server is currently | |||
testing its communication of tracking status. The ! value has been | testing its communication of tracking status. The ! value has been | |||
provided to ease testing and deployment on production systems during the | provided to ease testing and deployment on production systems during the | |||
initial periods of testing compliance and during adjustment periods due to | initial periods of testing compliance and during adjustment periods due to | |||
future protocol changes or shifting regulatory constraints. Note that this | future protocol changes or shifting regulatory constraints. Note that this | |||
value does not indicate that the user's preference will be ignored, nor | value does not indicate that the user's preference will be ignored, nor | |||
that tracking will occur as a result of accessing the designated resource. | that tracking will occur as a result of accessing the designated resource. | |||
skipping to change at line 738 | skipping to change at line 746 | |||
A tracking status value of U means that the request resulted in a | A tracking status value of U means that the request resulted in a | |||
potential change to the tracking status applicable to this user, user | potential change to the tracking status applicable to this user, user | |||
agent, or device. A user agent that relies on a cached tracking status | agent, or device. A user agent that relies on a cached tracking status | |||
SHOULD update the cache entry with the current status by making a new | SHOULD update the cache entry with the current status by making a new | |||
request on the applicable tracking status resource. | request on the applicable tracking status resource. | |||
An origin server MUST NOT send U as a tracking status value anywhere other | An origin server MUST NOT send U as a tracking status value anywhere other | |||
than a Tk header field that is in response to a state-changing request. | than a Tk header field that is in response to a state-changing request. | |||
6.2.11 Extensions to the Tracking Status Value | ||||
Extensibility of the TSV set ensures that this protocol will continue to | ||||
be usable as regional laws and regulatory environments evolve over time | ||||
and compliance specifications are developed accordingly. | ||||
An origin server MAY send a TSV-extension character as a TSV if that | ||||
extension has been defined by a future version of this specification or a | ||||
compliance regime identified within the compliance property. Aside from | ||||
storage or presentation of a server's response, a recipient MUST treat a | ||||
TSV-extension value that it does not recognize as if the value was P | ||||
(tracking only if consented). | ||||
TSV-extension = %x23-25 ; #$% | ||||
/ %x2A-3B ; *+,-./0-9:; | ||||
/ %x40-42 ; @AB | ||||
/ %x45-46 ; EF | ||||
/ %x48-4D ; HIJKLM | ||||
/ %x4F ; O | ||||
/ %x51-53 ; QRS | ||||
/ %x56-5A ; VWXYZ | ||||
/ %x5F ; _ | ||||
/ %x61-7A ; a-z | ||||
6.3 Tk Header Field for HTTP Responses | 6.3 Tk Header Field for HTTP Responses | |||
6.3.1 Definition | 6.3.1 Definition | |||
The Tk response header field is a means for indicating the tracking status | The Tk response header field is a means for indicating the tracking status | |||
that applied to the corresponding request. An origin server is REQUIRED to | that applied to the corresponding request. An origin server is REQUIRED to | |||
send a Tk header field if its site-wide tracking status value is ? | send a Tk header field if its site-wide tracking status value is ? | |||
(dynamic) or G (gateway), or when an interactive change is made to the | (dynamic) or G (gateway), or when an interactive change is made to the | |||
tracking status and indicated by U (updated). | tracking status and indicated by U (updated). | |||
skipping to change at line 767 | skipping to change at line 799 | |||
tracking would look like: | tracking would look like: | |||
Example 2 | Example 2 | |||
Tk: N | Tk: N | |||
6.3.2 Referring to a Request-specific Tracking Status Resource | 6.3.2 Referring to a Request-specific Tracking Status Resource | |||
If an origin server has multiple, request-specific tracking policies, such | If an origin server has multiple, request-specific tracking policies, such | |||
that the tracking status might differ depending on some aspect of the | that the tracking status might differ depending on some aspect of the | |||
request (e.g., method, target URI, header fields, data, etc.), the origin | request (e.g., method, target resource, header fields, data, etc.), the | |||
server can provide an additional subtree of well-known resources | origin server can provide an additional subtree of well-known resources | |||
corresponding to each of those distinct tracking statuses. The status-id | corresponding to each of those distinct tracking statuses. The status-id | |||
portion of the Tk field-value indicates which specific tracking status | portion of the Tk field-value indicates which specific tracking status | |||
resource applies to the current request. The status-id is case-sensitive. | resource applies to the current request. The status-id is case-sensitive. | |||
status-id = 1*id-char | status-id = 1*id-char | |||
id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" | id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" | |||
For example, a response containing | For example, a response containing | |||
Example 3 | Example 3 | |||
skipping to change at line 835 | skipping to change at line 867 | |||
/.well-known/dnt/ | /.well-known/dnt/ | |||
relative to the origin server's URI [RFC5785]. | relative to the origin server's URI [RFC5785]. | |||
An origin server that receives a valid GET request targeting its site-wide | An origin server that receives a valid GET request targeting its site-wide | |||
tracking status resource MUST send either a successful response containing | tracking status resource MUST send either a successful response containing | |||
a machine-readable representation of the site-wide tracking status, as | a machine-readable representation of the site-wide tracking status, as | |||
defined below, or a sequence of redirects that leads to such a | defined below, or a sequence of redirects that leads to such a | |||
representation. Failure to provide access to such a representation implies | representation. Failure to provide access to such a representation implies | |||
that the target origin server does not implement this protocol. The | that the origin server does not implement this protocol. The | |||
representation can be cached, as described in section 6.4.4 Caching. | representation can be cached, as described in section 6.4.4 Caching. | |||
See section 6.7 Using the Tracking Status for examples of how tracking | See section 6.7 Using the Tracking Status for examples of how tracking | |||
status resources can be used to discover support for this protocol. | status resources can be used to discover support for this protocol. | |||
6.4.2 Request-specific Tracking Status | 6.4.2 Request-specific Tracking Status | |||
If an origin server has multiple, request-specific tracking policies, such | If an origin server has multiple, request-specific tracking policies, such | |||
that the tracking status might differ depending on some aspect of the | that the tracking status might differ depending on some aspect of the | |||
request (e.g., method, target URI, header fields, data, etc.), the origin | request (e.g., method, target resource, header fields, data, etc.), the | |||
server can provide an additional subtree of well-known resources | origin server can provide an additional subtree of well-known resources | |||
corresponding to each of those distinct tracking statuses. The Tk response | corresponding to each of those distinct tracking statuses. The Tk response | |||
header field (section 6.3 Tk Header Field for HTTP Responses) can include | header field (section 6.3 Tk Header Field for HTTP Responses) can include | |||
a status-id to indicate which specific tracking status resource applies to | a status-id to indicate which specific tracking status resource applies to | |||
the current request. | the current request. | |||
A tracking status resource space is defined by the following URI Template | A tracking status resource space is defined by the following URI Template | |||
[RFC6570]: | [RFC6570]: | |||
/.well-known/dnt/{+status-id} | /.well-known/dnt/{+status-id} | |||
skipping to change at line 895 | skipping to change at line 927 | |||
origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in | origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in | |||
responses to those requests, including the responses to redirected | responses to those requests, including the responses to redirected | |||
tracking status requests, and MUST NOT send a response having content that | tracking status requests, and MUST NOT send a response having content that | |||
initiates tracking beyond what was already present in the request. A user | initiates tracking beyond what was already present in the request. A user | |||
agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 | agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 | |||
header field received in such a response. | header field received in such a response. | |||
6.4.4 Caching | 6.4.4 Caching | |||
If the tracking status is applicable to all users, regardless of the | If the tracking status is applicable to all users, regardless of the | |||
received DNT-field-value or other data received via the request, then the | received DNT field-value and other data received via the request, then the | |||
origin server SHOULD mark the response as cacheable [RFC7234] and assign a | origin server SHOULD mark the response as cacheable [RFC7234] and assign a | |||
time-to-live (expiration or max-use) that is sufficient to enable shared | time-to-live (expiration or max-use) that is sufficient to enable shared | |||
caching but not greater than the earliest point at which the service's | caching but not greater than the earliest point at which the service's | |||
tracking behavior might increase. | tracking behavior might increase. | |||
For example, if the tracking status response is set to expire in seven | For example, if the tracking status response is set to expire in seven | |||
days, then the earliest point in time that the service's tracking behavior | days, then the earliest point in time that the service's tracking behavior | |||
can be increased is seven days after the tracking status representation | can be increased is seven days after the tracking status representation | |||
has been updated to reflect the new behavior, since old copies might | has been updated to reflect the new behavior, since old copies might | |||
persist in caches until the expiration is triggered. A service's tracking | persist in caches until the expiration is triggered. A service's tracking | |||
behavior can be reduced at any time, with or without a corresponding | behavior can be reduced at any time, with or without a corresponding | |||
change to the tracking status resource. | change to the tracking status resource. | |||
If the tracking status is only applicable to users that have the same | If the tracking status is only applicable to users that have the same DNT | |||
DNT-field-value, the origin server MUST send a Vary header field that | field-value, the origin server MUST send a Vary header field that includes | |||
includes "DNT" in its field-value or a Cache-Control header field | "DNT" in its field-value or a Cache-Control header field containing one of | |||
containing one of the following directives: "private", "no-cache", | the following directives: "private", "no-cache", "no-store", or | |||
"no-store", or "max-age=0". | "max-age=0". | |||
If the tracking status is only applicable to the specific user that | If the tracking status is only applicable to the specific user that | |||
requested it, then the origin server MUST send a Cache-Control header | requested it, then the origin server MUST send a Cache-Control header | |||
field containing one of the following directives: "private", "no-cache", | field containing one of the following directives: "private", "no-cache", | |||
or "no-store". | or "no-store". | |||
Regardless of the cache-control settings, it is expected that user agents | Regardless of the cache-control settings, it is expected that user agents | |||
will check the tracking status of a service only once per session (at | will check the tracking status of a service only once per session (at | |||
most). A public Internet site that intends to change its tracking status | most). A public Internet site that intends to change its tracking status | |||
to increase tracking behavior MUST update the tracking status resource in | to increase tracking behavior MUST update the tracking status resource in | |||
skipping to change at line 1003 | skipping to change at line 1035 | |||
{"tracking": "N"} | {"tracking": "N"} | |||
6.5.3 Compliance Property | 6.5.3 Compliance Property | |||
An origin server MAY send a property named compliance with an array value | An origin server MAY send a property named compliance with an array value | |||
containing a list of URI references that identify specific regimes to | containing a list of URI references that identify specific regimes to | |||
which the origin server claims to comply for the designated resource. | which the origin server claims to comply for the designated resource. | |||
Communicating such a claim of compliance is presumed to improve | Communicating such a claim of compliance is presumed to improve | |||
transparency, which might influence a user's decisions or configurations | transparency, which might influence a user's decisions or configurations | |||
regarding allowed tracking, but does not have any direct impact on this | regarding allowed tracking. | |||
protocol. | ||||
If an origin server sends a TSV-extension or an extension property in the | ||||
status object that is not defined by successors of this specification, the | ||||
origin server MUST send a compliance property that contains a reference to | ||||
the definitive specification of that extension. If more than one reference | ||||
in the compliance array defines the same extension value, the origin | ||||
server SHOULD list the array of references in order by intended | ||||
precedence. | ||||
6.5.4 Qualifiers Property | 6.5.4 Qualifiers Property | |||
An origin server MAY send a property named qualifiers with a string value | An origin server MAY send a property named qualifiers with a string value | |||
containing a sequence of case sensitive characters corresponding to | containing a sequence of case sensitive characters corresponding to | |||
explanations or limitations on the extent of tracking. Multiple qualifiers | explanations or limitations on the extent of tracking. Multiple qualifiers | |||
indicate that multiple explanations or forms of tracking might apply for | indicate that multiple explanations or forms of tracking might apply for | |||
the designated resource. The meaning of each qualifier is presumed to be | the designated resource. The meaning of each qualifier is presumed to be | |||
defined by one or more of the regimes listed in compliance. | defined by one or more of the regimes listed in compliance. | |||
skipping to change at line 1072 | skipping to change at line 1111 | |||
containing a list of URI references to external audits of the designated | containing a list of URI references to external audits of the designated | |||
resource's privacy policy and tracking behavior. Preferably, the audit | resource's privacy policy and tracking behavior. Preferably, the audit | |||
references are to resources that describe the auditor and the results of | references are to resources that describe the auditor and the results of | |||
that audit; however, if such a resource is not available, a reference to | that audit; however, if such a resource is not available, a reference to | |||
the auditor is sufficient. | the auditor is sufficient. | |||
6.5.8 Policy Property | 6.5.8 Policy Property | |||
An origin server MAY send a property named policy with a string value | An origin server MAY send a property named policy with a string value | |||
containing a URI reference to a human-readable document that describes the | containing a URI reference to a human-readable document that describes the | |||
relevant privacy policy for the designated resource. The content of such a | relevant privacy policy for the designated resource. This document can | |||
policy document is beyond the scope of this protocol and only supplemental | inform users about data that might be collected when the designated | |||
to what is described in the machine-readable tracking status | resource is accessed and how collection, use, or sharing of such data | |||
representation. If no policy property is provided, this information might | might differ based on receipt of an expressed tracking preference (DNT:1 | |||
be obtained via the links provided in controller. | or DNT:0). | |||
The content of such a policy document is beyond the scope of this protocol | ||||
and only supplemental to what is described in the machine-readable | ||||
tracking status representation. If no policy property is provided, this | ||||
information might be obtained via the links provided in controller. | ||||
If the policy associated with a designated resource happens to be defined | ||||
as a common standard that is applicable to multiple sites, or includes | ||||
such a standard by reference, that standard ought to be referenced by a | ||||
URI within the machine-readable compliance property. | ||||
6.5.9 Config Property | 6.5.9 Config Property | |||
An origin server MAY send a property named config with a string value | An origin server MAY send a property named config with a string value | |||
containing a URI reference to a resource for giving the user control over | containing a URI reference to a resource for giving the user control over | |||
personal data collected via the designated resource (and possibly other | personal data collected via the designated resource (and possibly other | |||
resources). If the tracking status value indicates prior consent (C), the | resources). If the tracking status value indicates prior consent (C), the | |||
origin server MUST send a config property referencing a resource that | origin server MUST send a config property referencing a resource that | |||
describes how such consent is established and how to revoke that consent. | describes how such consent is established and how to revoke that consent. | |||
A config resource might include the ability to review past data collected, | A config resource might include the ability to review past data collected, | |||
delete some or all of the data, provide additional data (if desired), or | delete some or all of the data, provide additional data (if desired), or | |||
opt-in, opt-out, or otherwise modify an out-of-band consent status | opt-in, opt-out, or otherwise modify an out-of-band consent status | |||
regarding data collection. The design of such a resource, the extent to | regarding data collection. The design of such a resource, the extent to | |||
which it can provide access to that data, and how one might implement an | which it can provide access to that data, and how one might implement an | |||
out-of-band consent mechanism are beyond the scope of this protocol. | out-of-band consent mechanism are beyond the scope of this protocol. | |||
If no config property is provided, this information might be obtained via | If no config property is provided, this information might be obtained via | |||
the links provided in controller or policy. | the links provided in controller or policy. | |||
6.5.10 Extensions | 6.5.10 Extensions to the Status Object | |||
An origin server MAY send additional properties in the status object to | Extensibility of the status object ensures that this protocol will | |||
support future enhancements to this protocol. A recipient MUST ignore | continue to be usable as regional laws and regulatory environments evolve | |||
extension properties that it does not recognize. | over time and compliance specifications are developed accordingly. | |||
An origin server MAY send additional properties in the status object if | ||||
those extensions have been defined by a future version of this | ||||
specification or a compliance regime identified within the compliance | ||||
property. Aside from storage or presentation of a server's response, a | ||||
recipient MUST ignore extension properties that it does not recognize. | ||||
6.6 Status Code for Tracking Required | 6.6 Status Code for Tracking Required | |||
If an origin server receives a request with DNT:1, does not have | If an origin server receives a request with DNT:1, does not have | |||
out-of-band consent for tracking this user, and wishes to deny access to | out-of-band consent for tracking this user, and wishes to deny access to | |||
the requested resource until the user provides some form of user-granted | the requested resource until the user provides some form of user-granted | |||
exception or consent for tracking, then the origin server SHOULD send a | exception or consent for tracking, then the origin server SHOULD send a | |||
409 (Conflict) response with a message payload that describes why the | 409 (Conflict) response with a message payload that describes why the | |||
request has been refused and how one might supply the required consent or | request has been refused and how one might supply the required consent or | |||
exception to avoid this conflict [RFC7231]. | exception to avoid this conflict [RFC7231]. | |||
The 409 response ought to include a user authentication mechanism in the | The 409 response ought to include a user authentication mechanism in the | |||
header fields and/or message body if user login is one of the ways through | header fields and/or message body if user login is one of the ways through | |||
which access is granted. | which access is granted. | |||
6.7 Using the Tracking Status | 6.7 Using the Tracking Status | |||
This section is non-normative. | ||||
Note | Note | |||
This section is for collecting use cases that describe questions a user | This section is for collecting use cases that describe questions a user | |||
agent might have about tracking status and how the protocol can be used to | agent might have about tracking status and how the protocol can be used to | |||
answer such questions. More cases are needed. | answer such questions. More cases are needed. | |||
6.7.1 Discovering Deployment | 6.7.1 Discovering Deployment | |||
Deployment of this protocol for a given service can be discovered by | Deployment of this protocol for a given service can be discovered by | |||
making a retrieval request on the site-wide tracking resource | making a retrieval request on the site-wide tracking resource | |||
skipping to change at line 1144 | skipping to change at line 1201 | |||
avoid misconfigured infinite request loops). If the response is | avoid misconfigured infinite request loops). If the response is | |||
successful, obtain the tracking status representation from the message | successful, obtain the tracking status representation from the message | |||
payload, if possible, or consider it an error. | payload, if possible, or consider it an error. | |||
6.7.2 Preflight Checks | 6.7.2 Preflight Checks | |||
A key advantage of providing the tracking status at a resource separate | A key advantage of providing the tracking status at a resource separate | |||
from the site's normal services is that the status can be accessed and | from the site's normal services is that the status can be accessed and | |||
reviewed prior to making use of those services. | reviewed prior to making use of those services. | |||
A user agent MAY check the tracking status for a designated resource by | A user agent can check the tracking status for a designated resource by | |||
first making a retrieval request for the site-wide tracking status | first making a retrieval request for the site-wide tracking status | |||
representation, as described above, and then parsing the representation as | representation, as described above, and then parsing the representation as | |||
JSON to extract the status object. If the retrieval is unsuccessful or | JSON to extract the status object. If the retrieval is unsuccessful or | |||
parsing results in a syntax error, the user agent ought to consider the | parsing results in a syntax error, the user agent ought to consider the | |||
site to be non-conformant with this protocol. | site to be non-conformant with this protocol. | |||
The status object is supposed to have a property named tracking containing | The status object is supposed to have a property named tracking containing | |||
the tracking status value. The meaning of each tracking status value is | the tracking status value. The meaning of each tracking status value is | |||
defined in section 6.2 Tracking Status Value. | defined in section 6.2 Tracking Status Value. | |||
skipping to change at line 1167 | skipping to change at line 1224 | |||
hours or until the Cache-Control information indicates that this response | hours or until the Cache-Control information indicates that this response | |||
expires. | expires. | |||
If the tracking status value is not N, then the origin server claims that | If the tracking status value is not N, then the origin server claims that | |||
it might track the user agent for requests on the URI being checked for at | it might track the user agent for requests on the URI being checked for at | |||
least the next 24 hours or until the Cache-Control information indicates | least the next 24 hours or until the Cache-Control information indicates | |||
that this response expires. | that this response expires. | |||
7. User-Granted Exceptions | 7. User-Granted Exceptions | |||
7.1 Overview | 7.1 Motivating Principles | |||
This section is non-normative. | ||||
User-granted exceptions to Do Not Track, including site-specific | ||||
exceptions, are agreed between the site and the user, and stored by the | ||||
user agent. A resource ought to rely on the DNT header field it receives | ||||
to determine the user's preference for tracking with respect to that | ||||
particular request. An API is provided so that sites can request and check | ||||
the status of exceptions for tracking. | ||||
Note | ||||
We envisage that the exceptions might also be usable as a consent | ||||
mechanism. | ||||
7.2 Motivating Principles and Use Cases | ||||
This section is non-normative. | ||||
The following principles guide the design of user-agent-managed | The following principles guide the design of user-granted exceptions. | |||
exceptions. | ||||
* Content providers might wish to prompt visitors to their properties to | * Content providers might wish to prompt visitors to their properties to | |||
opt back in to tracking for behavioral advertising or similar purposes | opt back in to tracking for behavioral advertising or similar purposes | |||
when they arrive with the Do Not Track setting enabled. | when they arrive with the Do Not Track setting enabled. | |||
* Privacy-conscious users might wish to view or edit all the exceptions | * Privacy-conscious users might wish to view or edit all the exceptions | |||
they've granted in a single, consistent user interface, rather than | they've granted in a single, consistent user interface, rather than | |||
managing preferences in a different way on every content provider or | managing preferences in a different way on every content provider or | |||
tracker's privacy page. | tracker's privacy page. | |||
* Granting an exception in one context (e.g., while browsing a news | * Granting an exception in one context (e.g., while browsing a news | |||
site) does not imply that exception is applicable to other contexts | site) does not imply that exception is applicable to other contexts | |||
(e.g., browsing an unrelated medical site). | (e.g., browsing an unrelated medical site). | |||
* Tracking providers ought to be able to avoid second-guessing a user's | * Tracking providers ought to be able to avoid second-guessing a user's | |||
expressed tracking preference. | expressed tracking preference. | |||
* The solution need not require cross-domain communication between a | * The solution need not require cross-domain communication between a | |||
first-party publisher and its third parties. | first-party publisher and its third parties. | |||
When asking for a site-specific exception, the top-level origin making the | 7.2 Exception Model | |||
request might make some implicit or explicit claims as to the actions and | ||||
behavior of its third parties; for this reason, it might want to establish | ||||
exceptions for only those for which it is sure that those claims are true. | ||||
(Consider a site that has some trusted advertisers and analytics | ||||
providers, along with some mashed-up content from less-trusted sites). For | ||||
this reason, there is support both for explicitly named sites, as well as | ||||
support for granting an exception to all third-parties on a given site | ||||
(site-wide exception, using the conceptual wild-card "*"). | ||||
There are some cases in which a user might desire a site to be allowed to | A user-granted exception is the record of a decision by the user to grant | |||
track them on any top-level origin. An API is provided so that a site | consent for tracking (DNT:0) on future requests from a given context to a | |||
might obtain such a web-wide exception from the user. | set of target domains. Both context and target are scoped by domain, | |||
similar to the existing domain scope of cookies (Section 5.3.1 of | ||||
[HTML5]), in order to avoid asking the user's exception for every | ||||
subdomain context of a site and every target resource that might be | ||||
referenced. | ||||
7.3 Exception Model | A client-side database can be used for persistent storage of user-granted | |||
exceptions, such that permission to send DNT:0 is obtained by a site and | ||||
stored via a JavaScript API. However, we only define the API (below); the | ||||
choice of storage mechanism is left to each implementation. In comparison | ||||
to the use of cookies to manage consent, an exception database and APIs | ||||
provide more transparency and better user control over their own consent | ||||
decisions, while also providing better persistence of those exceptions for | ||||
sites. | ||||
7.3.1 User Interaction | There are potentially three different domain concepts involved in the | |||
processing of user-granted exceptions: | ||||
The call to store an exception MUST reflect the user's intention to grant | script domain | |||
an exception at the time of that call. This intention MUST be determined | the default context of a script when it accesses the exception | |||
by the site prior to each call to store an exception, at the time of the | database: specifically, the current document.domain of the | |||
call. (This allows a user to change their mind and delete a stored | script's responsible document. | |||
exception, which might result in the site explaining and asking for the | ||||
exception again.) It is the sole responsibility of the site making the | site domain | |||
call to determine that a call to record an exception reflects the user's | the context of a given reference for which the user-granted | |||
informed consent at the time of that call. | exceptions API might be queried: specifically, the current | |||
document.domain of the top-level browsing context's active | ||||
document. | ||||
target domain | ||||
the uri-host subcomponent of the authority component of a | ||||
referenced "http" or "https" URI | ||||
A user-granted exception is site-specific if the context is limited to | ||||
requests embedded in, or referred by, a given site domain; otherwise, the | ||||
exception is web-wide and applies to all contexts. For example, a user | ||||
might wish to grant a target domain a web-wide exception for the purpose | ||||
of audience surveys, perhaps in exchange for some incentive. | ||||
When asking for a site-specific exception, the site making the request | ||||
might make some implicit or explicit claims as to the actions and behavior | ||||
of its third parties; for this reason, a site might want to establish | ||||
exceptions for only those target domains for which it can be sure that | ||||
those claims are true. (Consider a site that has some trusted advertisers | ||||
and analytics providers, along with some mashed-up content from | ||||
less-trusted sites). For this reason, site-specific exceptions can either | ||||
be limited to a named set of target domains or applicable to any target | ||||
domain ("*"). | ||||
7.3 Granting Exception | ||||
Note | ||||
This section is supposed to describe how a site would go about asking the | ||||
user for the various types of exception. The existing text is lacking that | ||||
necessary information. | ||||
It is expected that a site will explain to the user, in its online | ||||
content, the need for an exception and the consequences of granting or | ||||
denying that exception. | ||||
The user agent adds to its local database one or more site-pair duplets | ||||
[document-origin, target]; one or the other of these MAY be a wild-card | ||||
("*"). | ||||
A site MAY ask for an exception, and have it stored, even when the user's | A site MAY ask for an exception, and have it stored, even when the user's | |||
general preference is not enabled. (This permits recording a permission to | general preference is not enabled. This permits the sending of DNT only | |||
allow tracking in jurisdictions where such permission cannot be assumed – | for target resources for which an expressed preference is desired (see | |||
see section 7.7 Exceptions without Interactive JavaScript.) | section 7.9 Exceptions without an Expressed Preference). | |||
The user agent MAY provide interfaces to the user: | A site MUST ensure that a call to store an exception reflects the user's | |||
intention to grant an exception at the time of that call. It is the sole | ||||
responsibility of the site to determine that a call to record an exception | ||||
reflects the user's informed consent at the time of that call. | ||||
* To indicate that a call to store an exception has just been made; | A site MAY monitor for changes to its user-granted exceptions. If a user | |||
* To allow the user to confirm a user-granted exception prior to | revokes consent by deleting an exception, the site MUST respect that | |||
storage; | revocation, though it MAY ask again for a new exception. In other words, a | |||
* To indicate that one or more exceptions exist for the current | site MUST NOT resurrect a deleted exception without first interacting with | |||
top-level origin; | and receiving new exception from the user. | |||
* To indicate that one or more exceptions exist for sites incorporated | ||||
into the current page; | ||||
* To allow the user to see and possibly revoke stored exceptions; | ||||
* Other aspects of the exception mechanism, as desired. | ||||
There is no required user interface for the user agent; a user agent MAY | A site MUST have a site-wide tracking status resource with a valid | |||
choose to provide no user interface regarding user-granted exceptions. | tracking status representation when making an API call to store a | |||
user-granted exception. This allows a user agent to obtain and possibly | ||||
store additional information about the calling site’s controller and | ||||
tracking policies at the time an exception is granted. | ||||
If the user revokes the consent by deleting the exception, the site MUST | A user agent MAY choose to reject an API call if it cannot determine the | |||
respect that revocation (though it MAY ask again for the exception). The | script origin or if the script origin does not have a site-wide tracking | |||
site MUST NOT use this exception mechanism if it will deem consent to | status resource with a valid tracking status representation. | |||
exist even after the exception has been revoked. | ||||
7.3.2 Processing Model | A user agent MAY choose to disregard a user-granted exception when the | |||
target resource does not have a corresponding tracking status resource | ||||
with a valid tracking status representation, since that would imply the | ||||
target resource does not conform to this specification. | ||||
This section describes the effect of the APIs in terms of a logical | A user-agent MUST handle each API request as a 'unit', granting and | |||
processing model; this model describes the behavior, but is not to be read | maintaining it in its entirety, or not at all. That means that a user | |||
as mandating any specific implementation. | agent MUST NOT indicate to a site that a request for targets {a, b, c} | |||
exists in the database, and later remove only one or two of {a, b, c} from | ||||
its logical database of remembered grants. This assures sites that the set | ||||
of sites they need for operational integrity is treated as a unit. Each | ||||
separate call to an API is a separate unit. | ||||
This API considers exceptions which are double-keyed to two domains: the | There is no required user interface for a user agent regarding the | |||
site, and the target. A user might — for instance — want AnalytiCo to be | granting of exceptions; a user agent MAY choose to provide none. | |||
allowed to track them on Example News, but not on Example Medical. To | Alternatively, a user agent MAY: | |||
simplify language used in this API specification, we define three terms: | ||||
* A top-level origin is the top-level browsing context, as defined by | * indicate that a call to store an exception has just been made; | |||
[HTML5]; | * allow the user to confirm a user-granted exception prior to storage; | |||
* A target site is the host subcomponent of the authority part in an | * indicate that one or more exceptions exist for the current top-level | |||
"http" or "https" URI, as defined by [RFC7230] and [RFC3986]; and, | origin; | |||
* The document origin of a script is the effective script origin, as | * indicate that one or more exceptions exist for sites incorporated into | |||
defined by [HTML5]. | the current page; or, | |||
* indicate how to manage the exceptions granted. | ||||
For instance, if the document at | When an explicit list of domains is provided through the API, their names | |||
http://web.exnews.com/news/story/2098373.html references the resources | might mean little to the user. The user might, for example, be told that | |||
http://exnews.analytico.net/1x1.gif and | there is a stored exception for a specific set of sites on such-and-such | |||
http://widgets.exsocial.org/good-job-button.js, the top-level origin is | top-level origin, rather than listing them by name; or the user agent | |||
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both | might decide to store a site-wide exception, effectively ignoring any list | |||
targets. | of domain names. | |||
The domains that enter into the behavior of the APIs include: | Conversely, if a wild-card is used, the user might be told that there is a | |||
stored exception for all third-parties that are embedded by the indicated | ||||
top-level origin. | ||||
* As described above, the document origin active at the time of the | 7.4 Exception Management | |||
call, and; | ||||
* Domain names passed to the API. | ||||
Domains that enter into the decision over what DNT header field to be sent | User agents are free to implement exception management user interfaces as | |||
in a given request include: | they see fit. Some agents might provide a notification to the user at the | |||
time of the request, or even not complete the storing of the exception | ||||
until the user approves. Some agents might provide a user-interface to see | ||||
and edit the database of recorded exception grants. | ||||
* The top-level origin of the current browser context; | The API parameters siteName, explanationString, and detailURI are provided | |||
* The target of the request. | so that the user agent can use them in their user interface. If a user | |||
Note | agent presents these parameters to the user, it ought to be clear that | |||
they are provided for informational value and are less important than the | ||||
exception's technical effect. | ||||
Note that these strict, machine-discoverable concepts might not match the | A user agent that chooses to highlight when tracking exceptions have been | |||
definitions of first and third party; in particular, sites themselves need | stored might provide an interface like the following: | |||
to determine when they are a first party in relation to a given user | ||||
action; the user agent does not change the DNT header field based on the | ||||
type of network interaction. | ||||
The calls cause the following steps to occur (subject to user confirmation | * an icon in the status bar indicating that an exception has been | |||
of the exception, if the user agent asks for it): | stored, which, when clicked on, gives the user more information about | |||
the exception and an option to revoke it. | ||||
* an infobar stating "Example News (news.example.com) has indicated to | ||||
Browser that you have consented to granting it exception for tracking. | ||||
If you believe this is incorrect, click Revoke." | ||||
* no UI at all. | ||||
In some user agent implementations, decisions to grant exceptions might | ||||
have been made in the past (and since forgotten) or might have been made | ||||
by other users of the device. Thus, exceptions might not always represent | ||||
the current preferences of the user. Some user agents might choose to | ||||
provide ambient notice that user-opted tracking is ongoing, or easy access | ||||
to view and control these preferences. Users might also desire to edit | ||||
exceptions within a separate user interface, which would allow a user to | ||||
modify their stored exceptions without visiting the target sites. | ||||
7.5 Checking for Exception | ||||
A user agent is expected to query the exceptions database at the time of a | ||||
request in order to determine what value (if any) to send as the user's | ||||
tracking preference. | ||||
* The user agent adds to its local database one or more site-pair | ||||
duplets [document-origin, target]; one or the other of these MAY be a | ||||
wild-card ("*"); | ||||
* While the user is browsing a given site (top-level origin), and a DNT | * While the user is browsing a given site (top-level origin), and a DNT | |||
header field is to be sent to a target domain, if the duplet | header field is to be sent to a target domain, if the duplet | |||
[top-level origin, target domain] matches any duplet in the database, | [top-level origin, target domain] matches any duplet in the database, | |||
then a DNT:0 preference is sent, otherwise the user’s general | then a DNT:0 preference is sent, otherwise the user’s general | |||
preference is sent (if any). | preference is sent (if any). | |||
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A | A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A | |||
pair of values A and X match if and only if one of the following is true: | pair of values A and X match if and only if one of the following is true: | |||
* either A or X is "*"; | * either A or X is "*"; | |||
* A and X are the same string; | * A and X are the same string; | |||
* A has the form '*.domain' and X is 'domain' or is of the form | * A has the form '*.domain' and X is 'domain' or is of the form | |||
'string.domain', where 'string' is any sequence of characters. | 'string.domain', where 'string' is any sequence of characters. | |||
In addition, responses to the JavaScript API indicated should be | In addition, responses to the JavaScript API indicated should be | |||
consistent with this user preference (see below). | consistent with this user preference (see below). [The editor has no idea | |||
what that is supposed to mean.] | ||||
User-agents MUST handle each API request as a 'unit', granting and | For example, a user might grant exception for metrics.example.net to track | |||
maintaining it in its entirety, or not at all. That means that a user | their activity on news.example.com and weather.example.com, but not on | |||
agent MUST NOT indicate to a site that a request for targets {a, b, c} | medical.example.org. If the document at | |||
exists in the database, and later remove only one or two of {a, b, c} from | http://news.example.com/news/story/2098373.html has embedded references to | |||
its logical database of remembered grants. This assures sites that the set | http://metrics.example.net/1x1.gif and | |||
of sites they need for operational integrity is treated as a unit. Each | http://weather.example.com/widget.js, the site domain (context) for those | |||
separate call to an API is a separate unit. | references is news.example.com and the target domains are | |||
metrics.example.net and weather.example.com, respectively. | ||||
It is left up to individual user agent implementations how to determine | 7.6 Site-specific Exception | |||
and how and whether to store users' tracking preferences. | ||||
When an explicit list of domains is provided through the API, their names | Note | |||
might mean little to the user. The user might, for example, be told that | ||||
there is a stored exception for a specific set of sites on such-and-such | ||||
top-level origin, rather than listing them by name; or the user agent | ||||
might decide to store a site-wide exception, effectively ignoring any list | ||||
of domain names. | ||||
Conversely, if a wild-card is used, the user might be told that there is a | We currently specify six different APIs (plus the doNotTrack property | |||
stored exception for all third-parties that are embedded by the indicated | which now appears to be useless) with three distinct definitions of an | |||
top-level origin. | exception record and three distinct return types. Also, we use a single | |||
(inappropriate) exception to signal all errors. | ||||
7.4 Site-specific Exceptions | What we should have is one exception record and three APIs for | |||
store/confirm/delete with a single Promise return type and a distinct | ||||
exception name for each error. The interfaces should be defined using an | ||||
algorithm similar to other specifications of promise-based interfaces. We | ||||
should also remove the expires field since it was intended to be replaced | ||||
(everywhere) by maxAge and is only kept in HTTP for legacy reasons. | ||||
7.4.1 API to Request a Site-specific Exception | 7.6.1 API to Request a Site-specific Exception | |||
Navigator.storeSiteSpecificTrackingException is called by a page to store | ||||
a site-specific tracking exception. A StoreExceptionPropertyBag dictionary | ||||
contains the information to be stored for that exception. It returns a | ||||
Promise resolving to a StoreExceptionResult result object. | ||||
partial interface Navigator { | partial interface Navigator { | |||
void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty | Promise<StoreExceptionResult> | |||
Bag properties); | storeSiteSpecificTrackingException(StoreExceptionPropertyBag properties); | |||
}; | }; | |||
storeSiteSpecificTrackingException | ||||
Called by a page to store a site-specific tracking exception. | ||||
Parameter Type Nullable Optional Description | ||||
properties StoreSiteSpecificExceptionPropertyBag ✘ ✘ | ||||
Return type: void | ||||
dictionary StoreExceptionPropertyBag { | dictionary StoreExceptionPropertyBag { | |||
DOMString? domain; | DOMString? domain; | |||
DOMString? siteName; | DOMString? siteName; | |||
DOMString? explanationString; | DOMString? explanationString; | |||
DOMString? detailURI; | DOMString? detailURI; | |||
DOMString? expires; | DOMString? expires; | |||
long? maxAge; | long? maxAge; | |||
sequence<DOMString> arrayOfDomainStrings; | ||||
}; | }; | |||
detailURI of type DOMString, nullable | dictionary StoreExceptionResult { | |||
A location at which further information about this request can be | boolean siteWide; | |||
found. | }; | |||
domain of type DOMString, nullable | Navigator.storeSiteSpecificTrackingException passes a | |||
StoreExceptionPropertyBag that can contain the following properties: | ||||
domain | ||||
a cookie-domain as defined in [RFC6265], to which the exception | a cookie-domain as defined in [RFC6265], to which the exception | |||
applies. | applies. | |||
expires of type DOMString, nullable | siteName | |||
A user-readable string for the name of the top-level origin. | ||||
explanationString | ||||
A short explanation of the request. | ||||
detailURI | ||||
A location at which further information about this request can be | ||||
found. | ||||
expires | ||||
A date and time, encoded as described for the cookie Expires | A date and time, encoded as described for the cookie Expires | |||
attribute described in [RFC6265], indicating the maximum lifetime | attribute described in [RFC6265], indicating the maximum lifetime | |||
of the remembered grant. | of the remembered grant. | |||
explanationString of type DOMString, nullable | maxAge | |||
A short explanation of the request. | ||||
maxAge of type long, nullable | ||||
A positive number of seconds indicating the maximum lifetime of | A positive number of seconds indicating the maximum lifetime of | |||
the remembered grant. | the remembered grant. | |||
siteName of type DOMString, nullable | arrayOfDomainStrings | |||
A user-readable string for the name of the top-level origin. | ||||
dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag { | ||||
sequence<DOMString> arrayOfDomainStrings; | ||||
}; | ||||
arrayOfDomainStrings of type sequence<DOMString>, | ||||
A JavaScript array of strings. | A JavaScript array of strings. | |||
The storeSiteSpecificTrackingException method takes a dictionary argument | Calling storeSiteSpecificTrackingException returns a Promise which either | |||
of type StoreSiteSpecificExceptionPropertyBag that allows optional | resolves to a StoreExceptionResult object, or is rejected with a | |||
information to be provided. | DOMException SYNTAX_ERR result. The Promise resolves immediately the | |||
Tracking Exception request has been processed, with the property siteWide | ||||
set to true if the exception is site-wide. | ||||
If the request does not include the arrayOfDomainStrings, then this | If the request does not include the arrayOfDomainStrings, then this | |||
request is for a site-wide exception. Otherwise each string in | request is for a site-wide exception. Otherwise each string in | |||
arrayOfDomainStrings specifies a target. When called, | arrayOfDomainStrings specifies a target domain. | |||
storeSiteSpecificTrackingException MUST return immediately. | ||||
If the list arrayOfDomainStrings is supplied, the user agent MAY choose to | If the list arrayOfDomainStrings is supplied, the user agent MAY choose to | |||
store a site-wide exception. If it does so it MUST indicate this in the | store a site-wide exception. If it does so it MUST indicate this by | |||
return value. | setting the siteWide property to true. | |||
If domain is not specified or is null or empty then the execution of this | If domain is not specified or is null or empty then the script domain is | |||
API and the use of the resulting permission (if granted) use the | used instead. | |||
'implicit' parameter, when the API is called, the document origin. This | ||||
forms the first part of the duplet in the logical model, and hence in | ||||
operation will be compared with the top-level origin. | ||||
If permission is stored for an explicit list, then the set of duplets (one | If an exception is stored for an explicit list, then the set of duplets | |||
per target): | (one per target domain): | |||
[document-origin, target] | [script domain, target domain] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
If permission is stored for a site-wide exception, then the duplet: | If an exception is stored for a site-wide exception, then the duplet: | |||
[document-origin, * ] | [script domain, * ] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
If domain is supplied and not empty then it is treated in the same way as | If domain is supplied and not empty then it is treated in the same way as | |||
the domain parameter to cookies and allows setting for subdomains. The | the domain parameter to cookies and allows setting for subdomains. The | |||
domain argument can be set to fully-qualified right-hand segment of the | domain argument can be set to a fully-qualified right-hand segment of the | |||
document host name, up to one level below TLD. | document host name, up to one level below TLD. | |||
For example, www.foo.bar.example.com can set the domain parameter as as | For example, www.foo.bar.example.com can set the domain parameter as as | |||
"bar.example.com" or "example.com", but not to | "bar.example.com" or "example.com", but not to | |||
"something.else.example.com" or "com". | "something.else.example.com" or "com". | |||
If the document-origin would not be able to set a cookie on the domain | If the effective script origin would not be able to set a cookie on the | |||
following the cookie domain rules [RFC6265] (e.g. domain is not a | domain following the cookie domain rules [RFC6265] (e.g. domain is not a | |||
right-hand match or is a TLD) then the duplet MUST NOT be entered into the | right-hand match or is a TLD) then the duplet MUST NOT be entered into the | |||
database and a SYNTAX_ERR exception SHOULD be thrown. | database and the returned Promise MUST be rejected with a DOMException | |||
SYNTAX_ERR. | ||||
If permission is stored for an explicit list, then the set of duplets (one | If an exception is stored for an explicit list, then the set of duplets | |||
per target): | (one per target domain): | |||
[*.domain, target] | [*.domain, target domain] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
If permission is stored for a site-wide exception, then the duplet: | If an exception is stored for a site-wide exception, then the duplet: | |||
[*.domain, * ] | [*.domain, * ] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
A particular response to the API — like a DNT response header field — is | A particular response to the API — like a DNT response header field — is | |||
only valid immediately; a user might later choose to edit stored | only valid immediately; a user might later choose to edit stored | |||
exceptions and revoke some or all of them. | exceptions and revoke some or all of them. | |||
If expires is supplied and not null or empty the remembered grant will be | If expires is supplied and not null or empty the remembered grant will be | |||
cancelled (i.e. processed as if the relevant Cancel API had been called) | cancelled (i.e. processed as if the relevant Cancel API had been called) | |||
no later than the specified date and time. After this the database of | no later than the specified date and time. | |||
remembered grants will no longer contain any duplets for which the first | ||||
part is the current document origin; i.e., no duplets [document-origin, | ||||
target] for any target. | ||||
If maxAge is supplied and not null, empty or negative the remembered grant | If maxAge is supplied and not null, empty or negative the remembered grant | |||
will be cancelled (i.e. processed as if the relevant Cancel API had been | will be cancelled (i.e. processed as if the relevant Cancel API had been | |||
called) no later than the specified number of seconds following the grant. | called) no later than the specified number of seconds following the grant. | |||
If both maxAge and expires are supplied, maxAge has precedence. If neither | If both maxAge and expires are supplied, maxAge has precedence. If neither | |||
maxAge or expires are supplied, the user agent MAY retain the remembered | maxAge or expires are supplied, the user agent MAY retain the remembered | |||
grant until it is cancelled. | grant until it is cancelled. | |||
7.4.2 API to Cancel a Site-specific Exception | 7.6.2 API to Cancel a Site-specific Exception | |||
Navigator.removeSiteSpecificTrackingException is called by a page to | ||||
cancel a site-specific tracking exception. A RemoveExceptionPropertyBag | ||||
dictionary contains information to identify the exception. | ||||
partial interface Navigator { | partial interface Navigator { | |||
void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag proper | Promise<void> | |||
ties); | removeSiteSpecificTrackingException(RemoveExceptionPropertyBag properties); | |||
}; | }; | |||
removeSiteSpecificTrackingException | ||||
If domain is not supplied or is null or empty then this ensures | ||||
that the database of remembered grants no longer contains any | ||||
duplets for which the first part is the current document origin; | ||||
i.e., no duplets [document-origin, target] for any target. | ||||
If domain is supplied and is not empty then this ensures that the | ||||
database of remembered grants no longer contains any duplets for | ||||
which the first part is the domain wildcard; i.e., no duplets | ||||
[*.domain, target] for any target. | ||||
There is no callback. After the call has been made, it is assured | ||||
that there are no site-specific or site-wide exceptions for the | ||||
given top-level origin. | ||||
Parameter Type Nullable Optional Description | ||||
properties RemoveExceptionPropertyBag ✘ ✘ | ||||
Return type: void | ||||
dictionary RemoveExceptionPropertyBag { | dictionary RemoveExceptionPropertyBag { | |||
DOMString? domain; | DOMString? domain; | |||
}; | }; | |||
domain of type DOMString, nullable | Navigator.removeSiteSpecificTrackingException passes a | |||
RemoveExceptionPropertyBag that can contain the following property: | ||||
domain | ||||
a cookie-domain as defined in [RFC6265], to which the exception | a cookie-domain as defined in [RFC6265], to which the exception | |||
applies. | applies. | |||
When this method returns, the database of grants no longer contains the | If domain is not supplied or is null or empty then the script domain is | |||
indicated grant(s); if some kind of processing error occurred then an | used instead. This asks for removal of all duplets in the grant database | |||
appropriate exception will be thrown. | for which the first part matches the script domain; i.e., no duplets | |||
[script domain, target domain] for any target domain. | ||||
If domain is supplied and is not empty then this ensures that the database | ||||
of remembered grants no longer contains any duplets for which the first | ||||
part is the domain wildcard; i.e., no duplets [*.domain, target domain] | ||||
for any target domain. | ||||
A Promise resolving to void is returned. When the Promise has been | ||||
resolved, it is assumed that there are no site-specific or site-wide | ||||
exceptions for the given top-level origin. | ||||
When the returned Promise is resolved, the database of grants no longer | ||||
contains the indicated grant(s); if some kind of processing error occurred | ||||
then an appropriate exception will be thrown. | ||||
If there are no matching duplets in the database of remembered grants when | If there are no matching duplets in the database of remembered grants when | |||
the method is called then this operation does nothing (and does not throw | the method is called then this operation does nothing (and does not throw | |||
an exception). | an exception). | |||
7.4.3 API to Confirm a Site-specific Exception | 7.6.3 API to Confirm a Site-specific Exception | |||
Navigator.confirmSiteSpecificTrackingException is called by a page to | ||||
confirm a site-specific exception. A ConfirmExceptionPropertyBag | ||||
dictionary contains information to identify the exception. It returns a | ||||
Promise resolving to a ConfirmExceptionResult result object. | ||||
partial interface Navigator { | partial interface Navigator { | |||
boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptionP | Promise<ConfirmExceptionResult> | |||
ropertyBag properties); | confirmSiteSpecificTrackingException(ConfirmExceptionPropertyBag properties); | |||
}; | }; | |||
confirmSiteSpecificTrackingException | ||||
Called by a page to confirm a site-specific tracking exception. | ||||
Parameter Type Nullable Optional Description | ||||
properties ConfirmSiteSpecificExceptionPropertyBag ✘ ✘ | ||||
Return type: boolean | ||||
dictionary ConfirmExceptionPropertyBag { | dictionary ConfirmExceptionPropertyBag { | |||
DOMString? domain; | DOMString? domain; | |||
sequence<DOMString> arrayOfDomainStrings; | ||||
}; | }; | |||
domain of type DOMString, nullable | dictionary ConfirmExceptionResult { | |||
boolean exists; | ||||
}; | ||||
Navigator.confirmSiteSpecificTrackingException passes a | ||||
ConfirmExceptionPropertyBag that can contain the following properties: | ||||
domain | ||||
a cookie-domain as defined in [RFC6265], to which the exception | a cookie-domain as defined in [RFC6265], to which the exception | |||
applies. | applies. | |||
dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBa | arrayOfDomainStrings | |||
g { | ||||
sequence<DOMString> arrayOfDomainStrings; | ||||
}; | ||||
arrayOfDomainStrings of type sequence<DOMString>, | ||||
A JavaScript array of strings. | A JavaScript array of strings. | |||
If the call does not include the arrayOfDomainStrings, then this call is | If the call does not include the arrayOfDomainStrings, then this call is | |||
to confirm a site-wide exception. Otherwise each string in | to confirm a site-wide exception. Otherwise each string in | |||
arrayOfDomainStrings specifies a target. | arrayOfDomainStrings specifies a target domain. | |||
If the list arrayOfDomainStrings is supplied, and the user agent stores | If the list arrayOfDomainStrings is supplied, and the user agent stores | |||
only site-wide exceptions, then the user agent MUST match by confirming a | only site-wide exceptions, then the user agent MUST match by confirming a | |||
site-wide exception. | site-wide exception. | |||
If the domain argument is not supplied or is null or empty then the | If the domain argument is not supplied or is null or empty then the script | |||
execution of this API uses the 'implicit' parameter, when the API is | domain is used instead. | |||
called, the document origin. This forms the first part of the duplet in | ||||
the logical model. | ||||
If the user agent stores explicit lists, and the call includes one, the | If the user agent stores explicit lists, and the call includes one, the | |||
database is checked for the existence of all the duplets (one per target): | database is checked for the existence of all the duplets (one per target): | |||
[document-origin, target] | [script domain, target] | |||
If the user agent stores only site-wide exceptions or the call did not | If the user agent stores only site-wide exceptions or the call did not | |||
include an explicit list, the database is checked for the single duplet: | include an explicit list, the database is checked for the single duplet: | |||
[document-origin, * ] | [script domain, * ] | |||
If the user agent stores explicit lists, the call includes one, and the | If the user agent stores explicit lists, the call includes one, and the | |||
domain argument is provided and is not empty, then the database is checked | domain argument is provided and is not empty, then the database is checked | |||
for the existence of all the duplets (one per target): | for the existence of all the duplets (one per target): | |||
[*.domain, target] | [*.domain, target] | |||
If the user agent stores only site-wide exceptions or the call did not | If the user agent stores only site-wide exceptions or the call did not | |||
include an explicit list, and the domain argument is provided and is not | include an explicit list, and the domain argument is provided and is not | |||
empty then the database is checked for the single duplet: | empty then the database is checked for the single duplet: | |||
[*.domain, * ] | [*.domain, * ] | |||
The returned boolean has the following possible values: | The returned Promise resolves to a ConfirmExceptionResult object whose | |||
boolean property exists has the following possible values: | ||||
* true all the duplets exist in the database; | * true all the duplets exist in the database; | |||
* false one or more of the duplets does not exist in the database. | * false one or more of the duplets does not exist in the database. | |||
7.5 Web-wide Exceptions | 7.7 Web-wide Exceptions | |||
7.5.1 API to Request a Web-wide Exception | 7.7.1 API to Request a Web-wide Exception | |||
Navigator.storeWebWideTrackingException is called by a page to request the | ||||
addition of a web-wide grant for a specific site to the database. | ||||
partial interface Navigator { | partial interface Navigator { | |||
void storeWebWideTrackingException (StoreExceptionPropertyBag properties); | Promise<void> storeWebWideTrackingException(StoreExceptionPropertyBag | |||
properties); | ||||
}; | }; | |||
storeWebWideTrackingException | Navigator.storeWebWideTrackingException passes a | |||
The single duplet [ * , document-origin] or [ * , *.domain] (based | StoreExceptionPropertyBag, as described in section 7.6.1 API to Request a | |||
on if domain is provided and is not null and not empty) is added | Site-specific Exception. | |||
to the database of remembered grants. The properties of the | ||||
StoreExceptionPropertyBag dictionary are as described above in the | ||||
request for site-specific exceptions. | ||||
Parameter Type Nullable Optional Description | ||||
properties StoreExceptionPropertyBag ✘ ✘ | ||||
Return type: void | The single duplet [ * , script domain] or [ * , *.domain] (based on if | |||
domain is provided and is not null and not empty) is added to the database | ||||
of remembered grants. | ||||
This API requests the addition of a web-wide grant for a specific site to | 7.7.2 API to Cancel a Web-wide Exception | |||
the database. | ||||
7.5.2 API to Cancel a Web-wide Exception | Navigator.removeWebWideTrackingException is called by a page to request | |||
the removal of a web-wide grant for a specific site from the database. | ||||
partial interface Navigator { | partial interface Navigator { | |||
void removeWebWideTrackingException (RemoveExceptionPropertyBag properties) | Promise<void> removeWebWideTrackingException(RemoveExceptionPropertyBag | |||
; | properties); | |||
}; | }; | |||
removeWebWideTrackingException | Navigator.removeWebWideTrackingException passes a | |||
Ensures that the database of remembered grants no longer contains | RemoveExceptionPropertyBag, as described in section 7.6.2 API to Cancel a | |||
the duplet [ * , document-origin] or [ * , *.domain] (based on if | Site-specific Exception. | |||
domain is provided and is not null and not empty). There is no | ||||
callback. After the call has been made, the indicated pair is | ||||
assured not to be in the database. The same matching process | ||||
defined for determining which header field to send is also used to | ||||
detect which entry (if any) to remove from the database. | ||||
Parameter Type Nullable Optional Description | Ensures that the database of remembered grants no longer contains the | |||
properties RemoveExceptionPropertyBag ✘ ✘ | duplet [ * , script domain] or [ * , *.domain] (based on if domain is | |||
provided and is not null and not empty). | ||||
Return type: void | A Promise resolving to void is returned. When the Promise is resolved, the | |||
indicated pair is assured not to be in the database. The same matching | ||||
process defined for determining which header field to send is also used to | ||||
detect which entry (if any) to remove from the database. | ||||
7.5.3 API to Confirm a Web-wide Exception | 7.7.3 API to Confirm a Web-wide Exception | |||
Navigator.confirmWebWideTrackingException is called by a page to confirm | ||||
that there exists in the database a web-wide exception for a specific | ||||
site. | ||||
partial interface Navigator { | partial interface Navigator { | |||
boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag proper | Promise<ConfirmExceptionResult> | |||
ties); | confirmWebWideTrackingException(ConfirmSiteSpecificExceptionPropertyBag | |||
properties); | ||||
}; | }; | |||
confirmWebWideTrackingException | dictionary ConfirmExceptionResult { | |||
Confirms that there exists in the database a web-wide exception | boolean exists; | |||
for a specific site. | }; | |||
Parameter Type Nullable Optional Description | ||||
properties ConfirmExceptionPropertyBag ✘ ✘ | ||||
Return type: boolean | Navigator.confirmWebWideTrackingException passes a | |||
ConfirmExceptionPropertyBag, as described in section 7.6.3 API to Confirm | ||||
a Site-specific Exception. | ||||
The returned boolean indicates whether the duplet [ * , document-origin] | The returned Promise resolves to a TrackingExceptionResult object with a | |||
or [ * , *.domain] (based on if domain is provided and is not null and not | boolean property exists indicating whether the duplet [ * , script domain] | |||
or [ *, *.domain] (based on if domain is provided and is not null and not | ||||
empty) exists in the database. | empty) exists in the database. | |||
* true indicates that the web-wide exception exists; | * true indicates that the web-wide exception exists; | |||
* false indicates that the web-wide exception does not exist. | * false indicates that the web-wide exception does not exist. | |||
7.6 User Interface Guidelines | 7.8 Exceptions without Interactive JavaScript | |||
This section is non-normative. | ||||
As described above, it is the sole responsibility of the site making an | ||||
API call to determine that an exception grant reflects the user's informed | ||||
consent at the time of the call. | ||||
It is expected that a site will explain to the user, in its online | ||||
content, the need for an exception and the consequences of granting or | ||||
denying that exception. | ||||
User agents are free to implement exception management user interfaces as | ||||
they see fit. Some agents might provide a notification to the user at the | ||||
time of the request, or even not complete the storing of the exception | ||||
until the user approves. Some agents might provide a user-interface to see | ||||
and edit the database of recorded exception grants. The API parameters | ||||
siteName, explanationString, and detailURI are provided so that the user | ||||
agent can use them in their user interface. If a user agent presents these | ||||
parameters to the user, it ought to be clear that they are provided for | ||||
informational value and are less important than the exception's technical | ||||
effect. | ||||
A user agent that chooses to highlight when tracking exceptions have been | ||||
stored might provide an interface like the following: | ||||
* an icon in the status bar indicating that an exception has been | ||||
stored, which, when clicked on, gives the user more information about | ||||
the exception and an option to revoke such an exception. | ||||
* an infobar stating "Example News (news.example.com) has indicated to | ||||
Browser that you have consented to granting it exceptions to your | ||||
general Do Not Track preference. If you believe this is incorrect, | ||||
click Revoke." | ||||
* no UI at all. | ||||
In some user agent implementations, decisions to grant exceptions might | ||||
have been made in the past (and since forgotten) or might have been made | ||||
by other users of the device. Thus, exceptions might not always represent | ||||
the current preferences of the user. Some user agents might choose to | ||||
provide ambient notice that user-opted tracking is ongoing, or easy access | ||||
to view and control these preferences. Users might also desire to edit | ||||
exceptions within a separate user interface, which would allow a user to | ||||
modify their stored exceptions without visiting the target sites. | ||||
7.7 Exceptions without Interactive JavaScript | ||||
This section is non-normative. | This section is non-normative. | |||
Some third party servers that might wish to receive a user-granted | Some third party servers that might wish to receive a user-granted | |||
exception do not have the ability to invoke an interactive JavaScript | exception do not have the ability to invoke an interactive JavaScript | |||
presence on a page (for example, those that provide only images or | presence on a page (for example, those that provide only images or | |||
"tracking pixels"). They cannot request an exception under these | "tracking pixels"). They cannot request an exception under these | |||
circumstances, both because a script is needed, and because they would be | circumstances because a script is needed to make the API call and it | |||
required to explain to the user the need for and consequences of granting | requires interaction to ensure the user is informed and to receive an | |||
an exception, and get the user's consent. In general, this process of | indication of their consent. In general, this process of informing, | |||
informing, getting consent, and calling the API is not expected within | getting consent, and calling the API is not expected within page elements | |||
page elements where such trackers are invoked. | where such trackers are invoked. | |||
To obtain an exception, a document (page, frame, etc.) that loads the | To obtain an exception, a document (page, frame, etc.) that loads the | |||
Javascript is needed. The user might visit the site that desires an | JavaScript is needed. The user might visit the site that desires an | |||
exception directly, the first party site could load a frame of the site | exception directly, or the first party might provide a separate page that | |||
desiring the exception, or that frame might be part of some other page | could load script-enabled frames in which each third party could ask for | |||
containing a number of frames, which allows aggregation of requests for | an exception (allowing for aggregation of requests). | |||
exceptions. | ||||
In all these ways, the site is contributing to informing the user and | In all these ways, the site is contributing to informing the user and | |||
obtaining their consent, while enabling a call to the Javascript API when | obtaining their consent, while enabling a call to the Javascript API when | |||
such consent is granted. | such consent is granted. | |||
7.8 Exceptions without an Expressed Preference | 7.9 Exceptions without an Expressed Preference | |||
Sites might wish to request exceptions even when a user arrives without a | Sites might wish to request exceptions even when a user arrives without a | |||
DNT header field. Users might wish to grant affirmative permission to | DNT header field. Users might wish to grant affirmative exception to | |||
tracking on or by certain sites even without expressing a general tracking | tracking on or by certain sites even without expressing a general tracking | |||
preference. | preference. | |||
User agents MAY instantiate navigator.storeSiteSpecificTrackingException | User agents MAY instantiate Navigator.storeSiteSpecificTrackingException | |||
even when window.doNotTrack is null. Scripts SHOULD test for the existence | even when Navigator.doNotTrack is null. Scripts SHOULD test for the | |||
of storeSiteSpecificTrackingException before calling the method. If an | existence of storeSiteSpecificTrackingException before calling the method. | |||
exception is granted and the user agent stores that preference, a user | If an exception is granted and the user agent stores that preference, a | |||
agent might send the DNT:0 tracking preference even if it has not enabled | user agent might send the DNT:0 tracking preference even if it has not | |||
preferences to be sent for other requests. Persisted preferences MAY | enabled preferences to be sent for other requests. Persisted exceptions | |||
affect which preference is transmitted if a user later chooses to express | MAY affect which preference is transmitted if a user later chooses to | |||
a tracking preference. | configure a general tracking preference. | |||
Note | ||||
Users might not configure their agents to have simple values for DNT, but | ||||
use different browsing modes or other contextual information to decide on | ||||
a DNT value. What algorithm a user agent employs to determine DNT values | ||||
(or the lack thereof) is out of the scope of this specification. | ||||
7.9 Exception Use by Sites | 7.10 Exception Use by Sites | |||
This section is non-normative. | This section is non-normative. | |||
This section is to inform the authors of sites on some considerations in | This section is to inform the authors of sites on some considerations in | |||
using the exceptions APIs to best effect; sites of particular interest | using the user-granted exceptions APIs to best effect; sites of particular | |||
here are those that need an exception in order to allow the user to | interest here are those that need an exception in order to allow the user | |||
perform some operation or to have some access. | to perform some operation or to have some access. | |||
The 'Store' calls return immediately, without a return value. If there is | The 'Store' calls return immediately, without a return value. If there is | |||
a problem with the calling parameters, then a Javascript exception will be | a problem with the calling parameters, then a Javascript exception will be | |||
raised. | thrown. | |||
A user agent might not store the exception immediately, possibly because | A user agent might not store the exception immediately, possibly because | |||
it is allowing the user to confirm. Even though the site has acquired the | it is allowing the user to confirm. Even though the site has acquired the | |||
user's informed consent before calling the 'Store' API, it is possible | user's informed consent before calling the 'Store' API, it is possible | |||
that the user will change their mind, allow the storing of an exception to | that the user will change their mind, allow the storing of an exception to | |||
proceed but later remove it, or perhaps deny the storage by prior | proceed but later remove it, or perhaps deny the storage by prior | |||
configuration. | configuration. | |||
Nonetheless, at the time of the call, the site has acquired the user's | Nonetheless, at the time of the call, the site has acquired the user's | |||
consent and can proceed on that basis, whether or not the user-agent has | consent and can proceed on that basis, whether or not the user-agent has | |||
skipping to change at line 1796 | skipping to change at line 1859 | |||
In this way the site: | In this way the site: | |||
* does not assume that the storage is instantaneous and mistakenly grant | * does not assume that the storage is instantaneous and mistakenly grant | |||
access when the exception does not (yet) stand; | access when the exception does not (yet) stand; | |||
* does not call the Confirm API repeatedly, in a loop, without a | * does not call the Confirm API repeatedly, in a loop, without a | |||
user-interaction between each call; and, | user-interaction between each call; and, | |||
* permits the user the opportunity to delete a previously granted | * permits the user the opportunity to delete a previously granted | |||
exception. | exception. | |||
7.10 Fingerprinting | 8. Security Considerations | |||
By storing a client-side configurable state and providing functionality to | TBD. | |||
learn about it later, this API might facilitate user fingerprinting and | ||||
9. Privacy Considerations | ||||
9.1 Fingerprinting | ||||
User-granted exceptions introduce a privacy risk. By storing client-side | ||||
configurable state and providing functionality to learn about it later, | ||||
the user-granted exceptions API might facilitate user fingerprinting and | ||||
tracking. User agent developers ought to consider the possibility of | tracking. User agent developers ought to consider the possibility of | |||
fingerprinting during implementation and might consider rate-limiting | fingerprinting during implementation and might consider rate-limiting | |||
requests or using other heuristics to mitigate fingerprinting risk. | requests or using other heuristics to mitigate fingerprinting risk. | |||
A. Acknowledgements | A. Acknowledgements | |||
This specification consists of input from many discussions within and | This specification consists of input from many discussions within and | |||
around the W3C Tracking Protection Working Group, along with written | around the W3C Tracking Protection Working Group, along with written | |||
contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), | contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), | |||
Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited | Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited | |||
skipping to change at line 1852 | skipping to change at line 1922 | |||
Security considerations: | Security considerations: | |||
See JSON [RFC7159], Section 12. | See JSON [RFC7159], Section 12. | |||
Interoperability considerations: | Interoperability considerations: | |||
N/A | N/A | |||
Published specification: | Published specification: | |||
Tracking Preference Expression (DNT), section 6.5 Tracking Status | Tracking Preference Expression (DNT), section 6.5 Tracking Status | |||
Representation. | Representation. | |||
http://www.w3.org/TR/tracking-dnt/ | https://www.w3.org/TR/tracking-dnt/ | |||
Applications that use this media type: | Applications that use this media type: | |||
N/A | N/A | |||
Fragment identifier considerations: | Fragment identifier considerations: | |||
N/A | N/A | |||
Additional information: | Additional information: | |||
Deprecated alias names for this type: N/A | Deprecated alias names for this type: N/A | |||
Magic number(s): N/A | Magic number(s): N/A | |||
skipping to change at line 1886 | skipping to change at line 1956 | |||
Roy T. Fielding and David Singer | Roy T. Fielding and David Singer | |||
Change controller: | Change controller: | |||
W3C | W3C | |||
C. References | C. References | |||
C.1 Normative references | C.1 Normative references | |||
[HTML5] | [HTML5] | |||
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika | HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; | |||
Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October | Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 28 | |||
2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/ | October 2014. W3C Recommendation. URL: | |||
https://www.w3.org/TR/html5/ | ||||
[RFC2119] | [RFC2119] | |||
S. Bradner. Key words for use in RFCs to Indicate Requirement | Key words for use in RFCs to Indicate Requirement Levels. S. | |||
Levels. March 1997. Best Current Practice. URL: | Bradner. IETF. March 1997. Best Current Practice. URL: | |||
https://tools.ietf.org/html/rfc2119 | https://tools.ietf.org/html/rfc2119 | |||
[RFC3986] | ||||
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource | ||||
Identifier (URI): Generic Syntax. January 2005. Internet Standard. | ||||
URL: https://tools.ietf.org/html/rfc3986 | ||||
[RFC5234] | [RFC5234] | |||
D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax | Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. | |||
Specifications: ABNF. January 2008. Internet Standard. URL: | Overell. IETF. January 2008. Internet Standard. URL: | |||
https://tools.ietf.org/html/rfc5234 | https://tools.ietf.org/html/rfc5234 | |||
[RFC6265] | [RFC6265] | |||
A. Barth. HTTP State Management Mechanism. April 2011. Proposed | HTTP State Management Mechanism. A. Barth. IETF. April 2011. | |||
Standard. URL: https://tools.ietf.org/html/rfc6265 | Proposed Standard. URL: https://tools.ietf.org/html/rfc6265 | |||
[RFC7159] | [RFC7159] | |||
T. Bray, Ed.. The JavaScript Object Notation (JSON) Data | The JavaScript Object Notation (JSON) Data Interchange Format. T. | |||
Interchange Format. March 2014. Proposed Standard. URL: | Bray, Ed.. IETF. March 2014. Proposed Standard. URL: | |||
https://tools.ietf.org/html/rfc7159 | https://tools.ietf.org/html/rfc7159 | |||
[RFC7230] | [RFC7230] | |||
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and | |||
(HTTP/1.1): Message Syntax and Routing. June 2014. Proposed | Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. | |||
Standard. URL: https://tools.ietf.org/html/rfc7230 | Proposed Standard. URL: https://tools.ietf.org/html/rfc7230 | |||
[RFC7231] | [RFC7231] | |||
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. | |||
(HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. | Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed | |||
URL: https://tools.ietf.org/html/rfc7231 | Standard. URL: https://tools.ietf.org/html/rfc7231 | |||
[RFC7234] | [RFC7234] | |||
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. Hypertext | Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; | |||
Transfer Protocol (HTTP/1.1): Caching. June 2014. Proposed | M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed | |||
Standard. URL: https://tools.ietf.org/html/rfc7234 | Standard. URL: https://tools.ietf.org/html/rfc7234 | |||
[WEBIDL] | [WEBIDL] | |||
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 4 August 2015. | Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 | |||
W3C Working Draft. URL: http://www.w3.org/TR/WebIDL-1/ | December 2016. W3C Editor's Draft. URL: | |||
https://heycam.github.io/webidl/ | ||||
C.2 Informative references | C.2 Informative references | |||
[KnowPrivacy] | [KnowPrivacy] | |||
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | KnowPrivacy. Joshua Gomez; Travis Pinnick; Ashkan Soltani. UC | |||
2009. URL: | Berkeley, School of Information. 01 Jun 2009. URL: | |||
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | |||
[Orderly] | [Orderly] | |||
Lloyd Hilaiel. Orderly JSON. 10 Feb 2015. URL: | Orderly JSON. Lloyd Hilaiel.10 Feb 2015. URL: | |||
http://orderly-json.org/ | http://orderly-json.org/ | |||
[RFC5785] | [RFC5785] | |||
M. Nottingham; E. Hammer-Lahav. Defining Well-Known Uniform | Defining Well-Known Uniform Resource Identifiers (URIs). M. | |||
Resource Identifiers (URIs). April 2010. Proposed Standard. URL: | Nottingham; E. Hammer-Lahav. IETF. April 2010. Proposed Standard. | |||
https://tools.ietf.org/html/rfc5785 | URL: https://tools.ietf.org/html/rfc5785 | |||
[RFC6570] | [RFC6570] | |||
J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard. | URI Template. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; | |||
URI Template. March 2012. Proposed Standard. URL: | D. Orchard. IETF. March 2012. Proposed Standard. URL: | |||
https://tools.ietf.org/html/rfc6570 | https://tools.ietf.org/html/rfc6570 | |||
[TCS] | [TCS] | |||
Nick Doty; Heather West; Justin Brookman; Sean Harvey; Erica | Tracking Compliance and Scope. Nick Doty; Heather West; Justin | |||
Newland. Tracking Compliance and Scope. 14 July 2015. W3C Last | Brookman; Sean Harvey; Erica Newland. W3C. 31 March 2015. W3C | |||
Call Working Draft. URL: http://www.w3.org/TR/tracking-compliance/ | Working Draft. URL: https://www.w3.org/TR/tracking-compliance/ | |||
End of changes. 158 change blocks. | ||||
586 lines changed or deleted | 645 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |