dnt-wd5.txt | dnt-20131207.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Preference Expression (DNT) | Tracking Preference Expression (DNT) | |||
W3C Working Draft 12 September 2013 | W3C Editor's Draft 07 December 2013 | |||
This version: | This version: | |||
http://www.w3.org/TR/2013/WD-tracking-dnt-20130912/ | http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | |||
Latest published version: | Latest published version: | |||
http://www.w3.org/TR/tracking-dnt/ | http://www.w3.org/TR/tracking-dnt/ | |||
Latest editor's draft: | Latest editor's draft: | |||
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | |||
Previous version: | ||||
http://www.w3.org/TR/2013/WD-tracking-dnt-20130430/ | ||||
Editors: | Editors: | |||
Roy T. Fielding, Adobe | Roy T. Fielding, Adobe | |||
David Singer, Apple | David Singer, Apple | |||
Copyright (c) 2013 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights | Copyright (c) 2013 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights | |||
Reserved. W3C liability, trademark and document use rules apply. | Reserved. W3C liability, trademark and document use rules apply. | |||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
Abstract | Abstract | |||
This specification defines the technical mechanisms for expressing a | This specification defines the DNT request header field as an HTTP | |||
tracking preference via the DNT request header field in HTTP, via an HTML | mechanism for expressing the user's preference regarding tracking, an HTML | |||
DOM property readable by embedded scripts, and via properties accessible | DOM property to make that expression readable by scripts, and APIs that | |||
to various user agent plug-in or extension APIs. It also defines | allow scripts to register site-specific exceptions granted by the user. It | |||
mechanisms for sites to signal whether and how they honor this preference, | also defines mechanisms for sites to communicate whether and how they | |||
both in the form of a machine-readable tracking status resource at a | honor a received preference through use of the Tk response header field | |||
well-known location and via a Tk response header field, and a mechanism | and well-known resources that provide a machine-readable tracking status. | |||
for allowing the user to approve exceptions to DNT as desired. | ||||
Status of This Document | Status of This Document | |||
This section describes the status of this document at the time of its | This section describes the status of this document at the time of its | |||
publication. Other documents may supersede this document. A list of | publication. Other documents may supersede this document. A list of | |||
current W3C publications and the latest revision of this technical report | current W3C publications and the latest revision of this technical report | |||
can be found in the W3C technical reports index at http://www.w3.org/TR/. | can be found in the W3C technical reports index at http://www.w3.org/TR/. | |||
This document is a snapshot of ongoing discussions within the Tracking | This document is an editors' strawman reflecting a snapshot of live | |||
Protection Working Group. It does not yet capture all of our work and does | discussions within the Tracking Protection Working Group. It does not yet | |||
not constitute Working Group consensus. Text in option boxes (highlighted | capture all of our work and does not constitute working group consensus. | |||
with light blue background color) present options that the group is | Text in option boxes (highlighted with light blue background color) | |||
currently considering, particularly where consensus is known to be | present options that the group is currently considering, particularly | |||
lacking, and should be read as a set of proposals rather than as | where consensus is known to be lacking, and should be read as a set of | |||
limitations on the potential outcome. Members of the Working Group wish to | proposals rather than as limitations on the potential outcome. An issue | |||
emphasize that this draft is a work in progress and not a decided outcome | ||||
or guaranteed direction for future versions of this document. | ||||
Readers may review changes from the previous Working Draft. An issue | ||||
tracking system is available for recording raised, open, pending review, | tracking system is available for recording raised, open, pending review, | |||
closed, and postponed issues regarding this document. | closed, and postponed issues regarding this document. | |||
This document was published by the Tracking Protection Working Group as a | Issue 136: Resolve dependencies of the TPE on the compliance specification | |||
Working Draft. This document is intended to become a W3C Recommendation. | ||||
If you wish to make comments regarding this document, please send them to | ||||
public-tracking-comments@w3.org (subscribe, archives). All comments are | ||||
welcome. | ||||
Publication as a Working Draft does not imply endorsement by the W3C | [OPEN] This draft removes all dependencies on TCS. | |||
This document was published by the Tracking Protection Working Group as an | ||||
Editor's Draft. If you wish to make comments regarding this document, | ||||
please send them to public-tracking@w3.org (subscribe, archives). All | ||||
comments are welcome. | ||||
Publication as an Editor's Draft does not imply endorsement by the W3C | ||||
Membership. This is a draft document and may be updated, replaced or | Membership. This is a draft document and may be updated, replaced or | |||
obsoleted by other documents at any time. It is inappropriate to cite this | obsoleted by other documents at any time. It is inappropriate to cite 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 | |||
skipping to change at line 97 | skipping to change at line 92 | |||
* 4. Expressing a Tracking Preference | * 4. Expressing a Tracking Preference | |||
* 4.1 Expression Format | * 4.1 Expression Format | |||
* 4.2 DNT Header Field for HTTP Requests | * 4.2 DNT Header Field for HTTP Requests | |||
* 4.3 JavaScript Property to Detect Preference | * 4.3 JavaScript Property to Detect Preference | |||
* 4.4 Plug-In APIs | * 4.4 Plug-In APIs | |||
* 4.5 Tracking Preference Expressed in Other Protocols | * 4.5 Tracking Preference Expressed in Other Protocols | |||
* 5. Communicating a Tracking Status | * 5. Communicating a Tracking Status | |||
* 5.1 Overview | * 5.1 Overview | |||
* 5.2 Tracking Status Value | * 5.2 Tracking Status Value | |||
* 5.2.1 Definition | * 5.2.1 Definition | |||
* 5.2.2 None (N) | * 5.2.2 Under Construction (!) | |||
* 5.2.3 First Party (1) | * 5.2.3 Dynamic (?) | |||
* 5.2.4 Third Party (3) | * 5.2.4 Not Tracking (N) | |||
* 5.2.5 Dynamic (X) | * 5.2.5 Tracking (T) | |||
* 5.2.6 Consent (C) | * 5.2.6 Consent (C) | |||
* 5.2.7 Potential Consent (P) | * 5.2.7 Potential Consent (P) | |||
* 5.2.8 Disregarding (D) | * 5.2.8 Disregarding (D) | |||
* 5.2.9 Updated (U) | * 5.2.9 Updated (U) | |||
* 5.2.10 Non-compliant (!) | ||||
* 5.3 Tk Header Field for HTTP Responses | * 5.3 Tk Header Field for HTTP Responses | |||
* 5.3.1 Definition | * 5.3.1 Definition | |||
* 5.3.2 Referring to a Request-specific Tracking Status | * 5.3.2 Referring to a Request-specific Tracking Status | |||
Resource | Resource | |||
* 5.3.3 Indicating an Interactive Status Change | * 5.3.3 Indicating an Interactive Status Change | |||
* 5.4 Tracking Status Resource | * 5.4 Tracking Status Resource | |||
* 5.4.1 Site-wide Tracking Status | * 5.4.1 Site-wide Tracking Status | |||
* 5.4.2 Request-specific Tracking Status | * 5.4.2 Request-specific Tracking Status | |||
* 5.4.3 Representation | * 5.4.3 Representation | |||
* 5.4.4 Status Checks are Not Tracked | * 5.4.4 Status Checks are Not Tracked | |||
skipping to change at line 160 | skipping to change at line 154 | |||
page-oriented view of a wide variety of information that can be traversed | page-oriented view of a wide variety of information that can be traversed | |||
by selecting links, manipulating controls, and supplying data via forms | by selecting links, manipulating controls, and supplying data via forms | |||
and search dialogs. A Web page is usually composed of many different | and search dialogs. A Web page is usually composed of many different | |||
information sources beyond the initial resource request, including | information sources beyond the initial resource request, including | |||
embedded references to stylesheets, inline images, javascript, and other | embedded references to stylesheets, inline images, javascript, and other | |||
elements that might be automatically requested as part of the rendering or | elements that might be automatically requested as part of the rendering or | |||
behavioral processing defined for that page. | behavioral processing defined for that page. | |||
Each of the hypertext actions and each of the embedded resource references | Each of the hypertext actions and each of the embedded resource references | |||
might refer to any site on the Web, leading to a seamless interaction with | might refer to any site on the Web, leading to a seamless interaction with | |||
the user even though the pages might be composed of information requested | the user even when a page might be composed of information requested from | |||
from many different and possibly independent Web sites. From the user's | many different and possibly independent Web sites. From the user's | |||
perspective, they are simply visiting and interacting with a single brand | perspective, they are simply visiting and interacting with a single Web | |||
- the first-party Web property - and all of the technical details and | property: all of the technical details and protocol mechanisms used to | |||
protocol mechanisms that are used to compose a page representing that | compose a page to represent that property are hidden behind the scenes. | |||
brand are hidden behind the scenes. | ||||
It has become common for Web site owners to collect data regarding the | It has become common for Web site owners to collect data regarding the | |||
usage of their sites for a variety of purposes, including what led the | usage of their sites for a variety of purposes, including what led the | |||
user to visit their site (referrals), how effective the user experience is | user to visit their site (referrals), how effective the user experience is | |||
within the site (web analytics), and the nature of who is using their site | within the site (web analytics), and the nature of who is using their site | |||
(audience segmentation). In some cases, the data collected is used to | (audience segmentation). In some cases, the data collected is used to | |||
dynamically adapt the content (personalization) or the advertising | dynamically adapt the content (personalization) or the advertising | |||
presented to the user (targeted advertising). Data collection can occur | presented to the user (targeted advertising). Data collection can occur | |||
both at the first-party site and via third-party providers through the | both at the first-party site and via third-party providers through the | |||
insertion of tracking elements on each page. A survey of these techniques | insertion of tracking elements on each page. A survey of these techniques | |||
skipping to change at line 187 | skipping to change at line 180 | |||
People have the right to know how data about them will be collected and | People have the right to know how data about them will be collected and | |||
how it will be used. Empowered with that knowledge, individuals can decide | how it will be used. Empowered with that knowledge, individuals can decide | |||
whether to allow their online activities to be tracked and data about them | whether to allow their online activities to be tracked and data about them | |||
to be collected. Many Internet companies use data gathered about people's | to be collected. Many Internet companies use data gathered about people's | |||
online activities to personalize content and target advertising based on | online activities to personalize content and target advertising based on | |||
their perceived interests. While some people appreciate this | their perceived interests. While some people appreciate this | |||
personalization of content and ads in certain contexts, others are | personalization of content and ads in certain contexts, others are | |||
troubled by what they perceive as an invasion of their privacy. For them, | troubled by what they perceive as an invasion of their privacy. For them, | |||
the benefit of personalization is not worth their concerns about allowing | the benefit of personalization is not worth their concerns about allowing | |||
entities with whom they have no direct relationship to amass detailed | entities with whom they have no direct relationship to amass profiles | |||
profiles about their activities. | about their activities. | |||
Therefore, users need a mechanism to express their own preference | Therefore, users need a mechanism to express their own preference | |||
regarding tracking that is both simple to configure and efficient when | regarding tracking that is both simple to configure and efficient when | |||
implemented. In turn, Web sites that are unwilling or unable to offer | implemented. In turn, Web sites that are unwilling or unable to offer | |||
content without such targeted advertising or data collection need a | content without such data collection need a mechanism to indicate that | |||
mechanism to indicate those requirements to the user and allow them (or | status to the user and allow them (or their user agent) to make an | |||
their user agent) to make an individual choice regarding exceptions. | individual choice regarding exceptions. | |||
This specification defines the HTTP request header field DNT for | ||||
expressing a tracking preference on the Web, a well-known location (URI) | ||||
for providing a machine-readable tracking status resource that describes a | ||||
service's DNT compliance, the HTTP response header field Tk for resources | ||||
to communicate their compliance or non-compliance with the user's | ||||
expressed preference, and JavaScript APIs for determining DNT status and | ||||
requesting a user-granted exception. | ||||
A companion document, [TRACKING-COMPLIANCE], more precisely defines the | ||||
terminology of tracking preferences, the scope of its applicability, and | ||||
the requirements on compliant first-party and third-party participants | ||||
when an indication of tracking preference is received. | ||||
Issue 136: Resolve dependencies of the TPE on the compliance specification | ||||
[OPEN] The WG has not come to consensus regarding the definition of | This specification defines protocol elements for use within the Hypertext | |||
tracking and the scope of DNT. As such, a site cannot actually say with | Transfer Protocol [HTTP] which allow a user to express a tracking | |||
any confidence whether or not it is tracking, let alone describe the finer | preference, via the DNT request header field, and allow a server to | |||
details in a tracking status resource. This issue will be resolved by | describe their tracking behavior via a well-known tracking status resource | |||
progress on the TCS document, though its resolution is a necessary | and the Tk response header field. In addition, JavaScript APIs are defined | |||
prerequisite to understanding and correctly implementing the protocol | for enabling scripts to determine DNT status and to register a | |||
defined by this document. | user-granted exception. | |||
2. Notational Conventions | 2. Notational Conventions | |||
2.1 Requirements | 2.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]. | |||
2.2 Formal Syntax | 2.2 Formal Syntax | |||
This specification uses Augmented Backus-Naur Form [ABNF] to define | This specification uses Augmented Backus-Naur Form [ABNF] to define | |||
network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. | network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. | |||
2.3 Terminology | 2.3 Terminology | |||
This specification uses the term user agent to refer to any of the various | This specification uses the term user agent to refer to any of the various | |||
client programs capable of initiating HTTP requests, including, but not | client programs capable of initiating HTTP requests, including, but not | |||
limited to, browsers, spiders (web-based robots), command-line tools, | limited to, browsers, spiders (web-based robots), command-line tools, | |||
native applications, and mobile apps [HTTP11]. | native applications, and mobile apps [HTTP]. | |||
The term permitted use is used to indicate a restricted set of conditions | ||||
under which tracking is allowed in spite of the user's DNT preference. | ||||
The term user-granted exception is used when the user has permitted | The term user-granted exception is used when the user has permitted | |||
tracking by a given third party. | tracking by a given third party. | |||
A companion document, [TRACKING-COMPLIANCE], defines many of the terms | Issue 5: What is the definition of tracking? | |||
used here, notably 'party', 'first party', and 'third party'. | ||||
[OPEN] Definition of tracking awaiting WG decision following call for | ||||
objections. | ||||
Issue 10: What is a first party? | ||||
[OPEN] Definitions for party, first party, and third party are awaiting WG | ||||
decision following call for objections. | ||||
Issue 16: What does it mean to collect, retain, use and share data? | ||||
[OPEN] Definitions for collect, retain, use, and share are awaiting WG | ||||
decision following call for objections. | ||||
3. Determining User Preference | 3. Determining User Preference | |||
The goal of this protocol is to allow a user to express their personal | The goal of this protocol is to allow a user to express their personal | |||
preference regarding tracking to each server and web application that they | preference regarding tracking to each server and web application that they | |||
communicate with via HTTP, thereby allowing each service to either adjust | communicate with via HTTP, thereby allowing each service to either adjust | |||
their behavior to meet the user's expectations or reach a separate | their behavior to meet the user's expectations or reach a separate | |||
agreement with the user to satisfy all parties. | agreement with the user to satisfy all parties. | |||
Key to that notion of expression is that the signal sent MUST reflect the | Key to that notion of expression is that the signal sent MUST reflect the | |||
skipping to change at line 297 | skipping to change at line 284 | |||
software also MUST ensure the transmitted preference reflects the | software also MUST ensure the transmitted preference reflects the | |||
individual user's preference. | individual user's preference. | |||
We do not specify how tracking preference choices are offered to the user | We do not specify how tracking preference choices are offered to the user | |||
or how the preference is enabled: each implementation is responsible for | or how the preference is enabled: each implementation is responsible for | |||
determining the user experience by which a tracking preference is enabled. | determining the user experience by which a tracking preference is enabled. | |||
For example, a user might select a check-box in their user agent's | For example, a user might select a check-box in their user agent's | |||
configuration, install an extension or add-on that is specifically | configuration, install an extension or add-on that is specifically | |||
designed to add a tracking preference expression, or make a choice for | designed to add a tracking preference expression, or make a choice for | |||
privacy that then implicitly includes a tracking preference (e.g., Privacy | privacy that then implicitly includes a tracking preference (e.g., Privacy | |||
settings: high). The user-agent might ask the user for their preference | settings: high). The user agent might ask the user for their preference | |||
during startup, perhaps on first use or after an update adds the tracking | during startup, perhaps on first use or after an update adds the tracking | |||
protection feature. Likewise, a user might install or configure a proxy to | protection feature. Likewise, a user might install or configure a proxy to | |||
add the expression to their own outgoing requests. | add the expression to their own outgoing requests. | |||
Although some controlled network environments, such as public access | Although some controlled network environments, such as public access | |||
terminals or managed corporate intranets, might impose restrictions on the | terminals or managed corporate intranets, might impose restrictions on the | |||
use or configuration of installed user agents, such that a user might only | use or configuration of installed user agents, such that a user might only | |||
have access to user agents with a predetermined preference enabled, the | have access to user agents with a predetermined preference enabled, the | |||
user is at least able to choose whether to make use of those user agents. | user is at least able to choose whether to make use of those user agents. | |||
In contrast, if a user brings their own Web-enabled device to a library or | In contrast, if a user brings their own Web-enabled device to a library or | |||
skipping to change at line 355 | skipping to change at line 342 | |||
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. | |||
4.2 DNT Header Field for HTTP Requests | 4.2 DNT Header Field for HTTP Requests | |||
The DNT header field is hereby defined as the means for expressing a | The DNT header field is hereby defined as the means for expressing a | |||
user's tracking preference via HTTP [HTTP11]. | user's tracking preference via HTTP [HTTP]. | |||
DNT-field-name = "DNT" | DNT-field-name = "DNT" | |||
DNT-field-value = ( "0" / "1" ) *DNT-extension | DNT-field-value = ( "0" / "1" ) *DNT-extension | |||
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 | |||
A user agent MUST send the DNT header field on all HTTP requests if (and | A user agent MUST send the DNT header field on all HTTP requests if (and | |||
only if) a tracking preference is enabled. A user agent MUST NOT send the | only if) a tracking preference is enabled. A user agent MUST NOT send the | |||
DNT header field if a tracking preference is not enabled. | DNT header field if a tracking preference is not enabled. | |||
skipping to change at line 413 | skipping to change at line 400 | |||
The extension syntax is restricted to visible ASCII characters that can be | The extension syntax is restricted to visible ASCII characters that can be | |||
parsed as a single word in HTTP and safely embedded in a JSON string | parsed as a single word in HTTP and safely embedded in a JSON string | |||
without further encoding (section 5.4.3 Representation). Since the DNT | without further encoding (section 5.4.3 Representation). Since the DNT | |||
header field is intended to be sent on every request, when enabled, | header field is intended to be sent on every request, when enabled, | |||
designers of future extensions ought to use as few extension characters as | designers of future extensions ought to use as few extension characters as | |||
possible. | possible. | |||
Note | Note | |||
This document does not have any implied or specified behavior for the | This document does not have any implied or specified behavior for the user | |||
user-agent treatment of cookies when DNT is enabled. | agent treatment of cookies when DNT is enabled. | |||
Note | Note | |||
The HTTP specification [HTTP11] permits multiple headers with the same | At most one DNT header can be present in a valid HTTP request [HTTP]. | |||
field-name only under restricted circumstances which do not apply here; | ||||
hence, at most one DNT header may be present in a valid HTTP request. | ||||
Issue 176: Requirements on intermediaries/isps and header insertion that | Issue 176: Requirements on intermediaries/isps and header insertion that | |||
might affect tracking | might affect tracking | |||
[OPEN] | [OPEN] | |||
Issue 153: What are the implications on software that changes requests but | Issue 153: What are the implications on software that changes requests but | |||
does not necessarily initiate them? | does not necessarily initiate them? | |||
[PENDING REVIEW] | [PENDING REVIEW] | |||
skipping to change at line 468 | skipping to change at line 453 | |||
have read access to the browser configuration. | have read access to the browser configuration. | |||
Note | Note | |||
It is unclear whether we need to standardize the plug-in APIs or if we | It is unclear whether we need to standardize the plug-in APIs or if we | |||
should rely on it being defined per user agent based on general advice | should rely on it being defined per user agent based on general advice | |||
here. No plug-in APIs have been proposed yet. | here. No plug-in APIs have been proposed yet. | |||
4.5 Tracking Preference Expressed in Other Protocols | 4.5 Tracking Preference Expressed in Other Protocols | |||
A user's tracking preference is intended to apply in general, regardless | It is beyond the scope of this specification to define how a user's | |||
of the protocols being used for Internet communication. The protocol | tracking preference might be communicated via protocols other than HTTP. | |||
expressed here is specific to HTTP communication; however, the semantics | However, the semantics of a user's tracking preference is intended to | |||
are not restricted to use in HTTP; the same semantics may be carried by | apply in general, regardless of the protocols being used for Internet | |||
other protocols, either in future revisions of this specification, or in | communication. | |||
other specifications. | ||||
When it is known that the user's preference is for no tracking, compliant | ||||
services are still required to honor that preference, even if other | ||||
protocols are used. For example, redirecting to another protocol in order | ||||
to avoid receipt of the header is not compliant. | ||||
Note | ||||
The last paragraph may be more appropriate in the compliance document, as | ||||
it discusses compliance. | ||||
5. Communicating a Tracking Status | 5. Communicating a Tracking Status | |||
5.1 Overview | 5.1 Overview | |||
The primary goals of this protocol-expressing the user's preference and | This protocol has the dual goals of expressing the user's preference | |||
adhering to that preference-can be accomplished without any response from | regarding tracking and providing transparency by communicating | |||
the server. However, the protocol also seeks to improve the transparency | machine-readable claims that a server might wish to make regarding its own | |||
of tracking behavior by providing a machine-readable means for discovering | tracking behavior. However, providing a dynamic tracking status on every | |||
claims of compliance and determining the current tracking status. | response would effectively disable caching for the entire Web. Instead, | |||
this protocol defines a combination of response mechanisms that allow this | ||||
Unfortunately, providing a dynamic indication of tracking compliance on | information to be communicated without making every response dynamic. | |||
every HTTP response is not feasible, since it would have the effect of | ||||
disabling caching for the entire Web. Instead, this protocol defines a | ||||
combination of response mechanisms that allow the information to be | ||||
communicated without making every response dynamic. | ||||
This section explains how a user agent MAY discover an origin server's | This section explains how a user agent MAY discover an origin server's | |||
tracking status for a given resource. It defines a REQUIRED site-wide | tracking status for a given resource. It defines a REQUIRED site-wide | |||
tracking status resource at a specific well-known location and an OPTIONAL | tracking status resource at a specific well-known location and an OPTIONAL | |||
space of request-specific tracking status resources for sites where the | space of request-specific tracking status resources for sites where the | |||
tracking status might vary based on data within the request. It also | tracking status might vary based on data within the request. It also | |||
defines a Tk response header field that MAY be sent in any HTTP response, | defines a Tk response header field that MAY be sent in any response, MUST | |||
MUST be sent in responses to requests that modify the tracking status, and | be sent in responses to requests that modify the tracking status, and MAY | |||
MAY direct the user to a request-specific tracking status resource | direct the user to a request-specific tracking status resource applicable | |||
applicable to the current request. | to the current request. | |||
5.2 Tracking Status Value | 5.2 Tracking Status Value | |||
5.2.1 Definition | 5.2.1 Definition | |||
A tracking status value (TSV) is a short notation for communicating how a | A tracking status value (TSV) is a short notation for communicating the | |||
designated resource conforms to the tracking protection protocol, as | tracking behavior regarding data collected via a designated resource. | |||
defined by this document and [TRACKING-COMPLIANCE]. For a site-wide | ||||
tracking status resource, the designated resource to which the tracking | For a site-wide tracking status resource, the designated resource is any | |||
status applies is any resource on the same origin server. For a Tk | resource on the same origin server. For a Tk response header field, the | |||
response header field, the corresponding request target is the designated | target resource of the corresponding request is the designated resource, | |||
resource and remains so for any subsequent request-specific tracking | and remains so for any subsequent request-specific tracking status | |||
status resource referred to by that field. | resource referred to by the Tk field value. | |||
The tracking status value is case sensitive, as defined formally by the | The tracking status value is case sensitive, as defined formally by the | |||
following ABNF. | following ABNF. | |||
TSV = "1" ; "1" - first-party | TSV = %x21 ; "!" - under construction | |||
/ "3" ; "3" - third-party | / %x3F ; "?" - dynamic | |||
/ %x43 ; "C" - consent | / %x4E ; "N" - not tracking | |||
/ %x44 ; "D" - disregarding | / %x54 ; "T" - tracking | |||
/ %x4E ; "N" - none | / %x43 ; "C" - tracking with consent | |||
/ %x50 ; "P" - potential consent | / %x50 ; "P" - tracking only if consented | |||
/ %x55 ; "U" - updated | / %x44 ; "D" - disregarding DNT | |||
/ %x58 ; "X" - dynamic | / %x55 ; "U" - updated | |||
/ ( "!" [testv] ) ; "!" - non-compliant | ||||
testv = id-char | ||||
Note | ||||
[Editorial: The previous values of "1" and "3" to indicate the designated | ||||
resource complies with first or third party requirements, respectively, | ||||
have been removed because they are dependent on a specific compliance | ||||
regime. They can still be communicated via the qualifiers.] | ||||
Issue 137: Does hybrid tracking status need to distinguish between first | Issue 137: Does hybrid tracking status need to distinguish between first | |||
party (1) and outsourcing service provider acting as a first party (s) | party (1) and outsourcing service provider acting as a first party (s) | |||
[PENDING REVIEW] No, in practice there may be dozens of service providers | [PENDING REVIEW] No, in practice there may be dozens of service providers | |||
on any given request. If the designated resource is operated by a service | on any given request. If the designated resource is operated by a service | |||
provider acting as a first party, then the responsible first party is | provider acting as a first party, then the responsible first party is | |||
identified by the controller member or the owner of the origin server | identified by the controller member or the owner of the origin server | |||
domain. This satisfies the use case of distinguishing between a service | domain. This satisfies the use case of distinguishing between a service | |||
provider acting for some other site and the same service provider acting | provider acting for some other site and the same service provider acting | |||
on one of its own sites. | on one of its own sites. | |||
5.2.2 None (N) | 5.2.2 Under Construction (!) | |||
A tracking status value of N means the origin server claims that the | A tracking status value of ! means that the origin server is currently | |||
designated resource does not perform tracking of any kind, not even for a | testing its communication of tracking status. The ! value has been | |||
permitted use, and does not make use of any data collected from tracking. | provided to ease testing and deployment on production systems during the | |||
initial periods of testing compliance and during adjustment periods due to | ||||
future protocol changes or shifting regulatory constraints. Note that this | ||||
value does necessarily indicate that the DNT signal will be ignored, nor | ||||
that tracking will occur as a result of accessing the designated resource. | ||||
Issue 119: Specify "absolutely not tracking" | Issue 161: Do we need a tracking status value for partial compliance or | |||
rejecting DNT? | ||||
[OPEN] The N tracking status value corresponds to this notion of | [PENDING REVIEW] The ! tracking status value indicates that tracking | |||
absolutely not tracking. | status is under construction. | |||
5.2.3 First Party (1) | 5.2.3 Dynamic (?) | |||
A tracking status value of 1 means that the origin server claims that the | A tracking status value of ? means the origin server needs more | |||
designated resource is designed for use only within a first-party context | information to determine tracking status, usually because the designated | |||
and conforms to the requirements on a first party. If the designated | resource dynamically adjusts behavior based on information in a request. | |||
resource is operated by an outsourced service provider, the service | ||||
provider claims that it conforms to the requirements on a third party | ||||
acting as a first party. | ||||
For the site-wide tracking status and Tk header field, the tracking status | If ? is present in the site-wide tracking status, more information MUST be | |||
values 1 and 3 indicate how the designated resource is designed to | provided via the Tk response header field when accessing a designated | |||
conform, not the nature of the request. Hence, if a user agent is making a | resource. If ? is present in the Tk header field, more information will be | |||
request in what appears to be a third-party context and the tracking | provided in a request-specific tracking status resource referred to by the | |||
status value indicates that the designated resource is designed only for | status-id. An origin server MUST NOT send ? as the tracking status value | |||
first-party conformance, then either the context has been misunderstood | in the representation of a request-specific tracking status resource. | |||
(both are actually the same party) or the resource has been referenced | ||||
incorrectly. | ||||
For the request-specific tracking status resource, an indication of first | 5.2.4 Not Tracking (N) | |||
or third party as the status value describes how the resource conformed to | ||||
that specific request, and thus indicates the applicable set of | ||||
requirements to which the origin server claims to conform. | ||||
5.2.4 Third Party (3) | A tracking status value of N means the origin server claims that data | |||
collected via the designated resource is not used for tracking and will | ||||
not be combined with other data in a form that would enable tracking. | ||||
A tracking status value of 3 means that the origin server claims that the | Issue 119: Specify "absolutely not tracking" | |||
designated resource conforms to the requirements on a third party. | ||||
5.2.5 Dynamic (X) | [OPEN] The N tracking status value replaces the notion of absolutely not | |||
tracking. | ||||
A tracking status value of X means that the origin server claims that the | 5.2.5 Tracking (T) | |||
designated resource is designed for use in both first and third-party | ||||
contexts and dynamically adjusts tracking status accordingly. | ||||
If X is present in the site-wide tracking status, more information MUST be | A tracking status value of T means the origin server might perform or | |||
provided via the Tk response header field when accessing a designated | enable tracking using data collected via the designated resource. | |||
resource. If X is present in the Tk header field, more information will be | Information provided in the tracking status representation might indicate | |||
provided in a request-specific tracking status resource referred to by the | whether such tracking is limited to a set of commonly accepted uses or | |||
status-id. An origin server MUST NOT send X as the tracking status value | adheres to one or more compliance regimes. | |||
in the representation of a request-specific tracking status resource. | ||||
5.2.6 Consent (C) | 5.2.6 Consent (C) | |||
A tracking status value of C means that the origin server believes it has | A tracking status value of C means that the origin server believes it has | |||
received prior consent for tracking this user, user agent, or device, | received prior consent for tracking this user, user agent, or device, | |||
perhaps via some mechanism not defined by this specification, and that | perhaps via some mechanism not defined by this specification, and that | |||
prior consent overrides the tracking preference expressed by this | prior consent overrides the tracking preference expressed by this | |||
protocol. | protocol. An origin server that sends this tracking status value for a | |||
designated resource MUST provide a reference for controlling consent | ||||
If the consent was signaled to the origin server 'out of band', that is, | within the edit member of its corresponding tracking status representation | |||
by some other mechanism than the receipt of a DNT:0 header, then the | (section 5.4.3 Representation). | |||
'edit' member of the well-known-resource MUST provide both documentation | ||||
of how the consent was established and documentation of the means, or the | ||||
means, to revoke that consent. | ||||
Issue 152: User Agent Compliance: feedback for out-of-band consent | Issue 152: User Agent Compliance: feedback for out-of-band consent | |||
[PENDING REVIEW] Proposal is to not add UA requirements. | [PENDING REVIEW] Proposal is to not add UA requirements. | |||
5.2.7 Potential Consent (P) | 5.2.7 Potential Consent (P) | |||
A tracking status value of P means that the origin server does not know, | A tracking status value of P means that the origin server does not know, | |||
in real-time, whether it has received prior consent for tracking this | in real-time, whether it has received prior consent for tracking this | |||
user, user agent, or device, but promises not to use or share any DNT:1 | user, user agent, or device, but promises not to use or share any DNT:1 | |||
skipping to change at line 646 | skipping to change at line 613 | |||
survey systems for which determining consent at the time of a request is | survey systems for which determining consent at the time of a request is | |||
either impractical, due to legacy systems not being able to keep up with | either impractical, due to legacy systems not being able to keep up with | |||
Web traffic, or potentially "gamed" by first party sites if they can | Web traffic, or potentially "gamed" by first party sites if they can | |||
determine which of their users have consented. The data cannot be used for | determine which of their users have consented. The data cannot be used for | |||
the sake of personalization. If consent can be determined at the time of a | the sake of personalization. If consent can be determined at the time of a | |||
request, the C tracking status is preferred. | request, the C tracking status is preferred. | |||
Issue 195: Flows and signals for handling out of band consent | Issue 195: Flows and signals for handling out of band consent | |||
[OPEN] | [OPEN] | |||
Alternative 1: The P tracking status value indicates a special case of | The P tracking status value indicates a special case of general data | |||
general data collection which is then trimmed to exclude those without out | collection which is then trimmed to exclude those without out of band | |||
of band consent. | consent. | |||
Alternative 2: If there is a permitted use for short-term retention, then | ||||
a third party could respond 3 instead; the edit link would then be an | ||||
optional means for the user to manually check consent status. | ||||
5.2.8 Disregarding (D) | 5.2.8 Disregarding (D) | |||
A tracking status value of D means that the origin server is unable or | A tracking status value of D means that the origin server is unable or | |||
unwilling to respect a tracking preference received from the requesting | unwilling to respect a tracking preference received from the requesting | |||
user agent. An origin server that sends this tracking status value MUST | user agent. An origin server that sends this tracking status value MUST | |||
detail within the server's corresponding privacy policy the conditions | detail within the server's corresponding privacy policy the conditions | |||
under which a tracking preference might be disregarded. | under which a tracking preference might be disregarded. | |||
For example, an origin server might disregard the DNT field received from | For example, an origin server might disregard the DNT field received from | |||
specific user agents (or via specific network intermediaries) that are | specific user agents (or via specific network intermediaries) that are | |||
deemed to be non-conforming, might be collecting additional data from | deemed to be non-conforming, might be collecting additional data from | |||
specific source network locations due to prior security incidents, or | specific source network locations due to prior security incidents, or | |||
might be compelled to disregard certain DNT requests to comply with a | might be compelled to disregard certain DNT requests to comply with a | |||
local law, regulation, or order. | local law, regulation, or order. | |||
Note that the D tracking status value does not indicate that the origin | Note that the D tracking status value is meant to be used only in | |||
server complies with this protocol [TRACKING-COMPLIANCE]. It is meant to | situations that can be adequately described to users as an exception to | |||
be used only in situations that can be adequately described to users as an | normal behavior. An origin server that responds with D in ways that are | |||
exception to compliance. An origin server that always responds with D is | inconsistent with their other published and unexpired claims regarding | |||
not considered compliant even if that response is compelled by factors | tracking is likely to be considered misleading. | |||
beyond the origin server's control. An origin server that responds with D | ||||
in ways that are inconsistent with their other published and unexpired | ||||
claims of compliance is likely to be considered misleading. | ||||
Issue 161: Do we need a tracking status value for partial compliance or | Issue 161: Do we need a tracking status value for partial compliance or | |||
rejecting DNT? | rejecting DNT? | |||
[PENDING REVIEW] The D tracking status value indicates rejection. Note | [PENDING REVIEW] The D tracking status value indicates rejection. | |||
that parts of the last paragraph above are really the domain of TCS, but | ||||
we can't seem to agree on what the protocol means without mentioning them | ||||
here. | ||||
5.2.9 Updated (U) | 5.2.9 Updated (U) | |||
A tracking status value of U means that the request resulted in a | A tracking status value of U means that the request resulted in a | |||
potential change to the tracking status applicable to this user, user | potential change to the tracking status applicable to this user, user | |||
agent, or device. A user agent that relies on a cached tracking status | agent, or device. A user agent that relies on a cached tracking status | |||
SHOULD update the cache entry with the current status by making a new | SHOULD update the cache entry with the current status by making a new | |||
request on the applicable tracking status resource. | request on the applicable tracking status resource. | |||
An origin server MUST NOT send U as a tracking status value anywhere other | An origin server MUST NOT send U as a tracking status value anywhere other | |||
than a Tk header field that is in response to a state-changing request. | than a Tk header field that is in response to a state-changing request. | |||
5.2.10 Non-compliant (!) | ||||
A tracking status value of ! means that the origin server is unable or | ||||
unwilling to claim that the designated resource conforms to the tracking | ||||
protection protocol, but is providing a tracking response for the sake of | ||||
testing and transparency. | ||||
The ! value has been provided to ease testing and deployment on production | ||||
systems during the initial periods of testing compliance and during | ||||
adjustment periods due to future protocol changes or shifting regulatory | ||||
constraints. Note that this value does not indicate that the DNT signal | ||||
will be ignored, nor that tracking will occur as a result of accessing the | ||||
designated resource, but rather that the site makes no claim to | ||||
conformance at this time. | ||||
This ! value MAY be followed by an optional testv character in order to | ||||
communicate further information for testing, such as what tracking status | ||||
the server intends to deploy for the designated resource at some point in | ||||
the future, but that cannot be relied upon as an indication of | ||||
conformance. | ||||
Issue 161: Do we need a tracking status value for partial compliance or | ||||
rejecting DNT? | ||||
[PENDING REVIEW] The ! tracking status value indicates non-compliance in a | ||||
format that conforms to the response syntax. | ||||
5.3 Tk Header Field for HTTP Responses | 5.3 Tk Header Field for HTTP Responses | |||
5.3.1 Definition | 5.3.1 Definition | |||
The Tk response header field is hereby defined as an OPTIONAL means for | The Tk response header field is hereby defined as an OPTIONAL means for | |||
indicating the tracking status that applied to the corresponding request | indicating the tracking status that applied to the corresponding request | |||
and as a REQUIRED means for indicating that a state-changing request has | and as a REQUIRED means for indicating that a state-changing request has | |||
resulted in an interactive change to the tracking status. | resulted in an interactive change to the tracking status. | |||
Tk-field-name = "Tk" | Tk-field-name = "Tk" | |||
skipping to change at line 767 | skipping to change at line 697 | |||
status resource applies to the current request. | status resource applies to the current request. | |||
status-id = 1*id-char | status-id = 1*id-char | |||
id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" | id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" | |||
For example, a response containing | For example, a response containing | |||
Example 3 | Example 3 | |||
Tk: 1;fRx42 | Tk: T;fRx42 | |||
indicates that the target resource claims to conform to the first-party | indicates that data collected via the target resource might be used for | |||
requirements of [TRACKING-COMPLIANCE] and that an applicable tracking | tracking and that an applicable tracking status representation can be | |||
status representation can be obtained by performing a retrieval request on | obtained by performing a retrieval request on | |||
/.well-known/dnt/fRx42 | /.well-known/dnt/fRx42 | |||
If a Tk field-value has a tracking status value of X (dynamic), then a | If a Tk field-value has a tracking status value of ? (dynamic), then a | |||
status-id MUST be included in the field-value. The status-id is | status-id MUST be included in the field-value. The status-id is | |||
case-sensitive. | case-sensitive. | |||
5.3.3 Indicating an Interactive Status Change | 5.3.3 Indicating an Interactive Status Change | |||
We anticipate that interactive mechanisms might be used, beyond the scope | We anticipate that interactive mechanisms might be used, beyond the scope | |||
of this specification, that have the effect of asking for and obtaining | of this specification, that have the effect of asking for and obtaining | |||
prior consent for tracking, or for modifying prior indications of consent. | prior consent for tracking, or for modifying prior indications of consent. | |||
For example, the tracking status resource's status-object defines an edit | For example, the tracking status resource's status-object defines an edit | |||
member that can refer to such a mechanism. Although such out-of-band | member that can refer to such a mechanism. Although such out-of-band | |||
skipping to change at line 844 | skipping to change at line 774 | |||
Template [URI-TEMPLATE]: | Template [URI-TEMPLATE]: | |||
/.well-known/dnt/{+status-id} | /.well-known/dnt/{+status-id} | |||
where the value of status-id is a string of URI-safe characters provided | where the value of status-id is a string of URI-safe characters provided | |||
by a Tk field-value in response to a prior request. For example, a prior | by a Tk field-value in response to a prior request. For example, a prior | |||
response containing | response containing | |||
Example 5 | Example 5 | |||
Tk: 1;ahoy | Tk: ?;ahoy | |||
refers to the specific tracking status resource | refers to the specific tracking status resource | |||
/.well-known/dnt/ahoy | /.well-known/dnt/ahoy | |||
Resources within the request-specific tracking status resource space are | Resources within the request-specific tracking status resource space are | |||
represented using the same format as a site-wide tracking status resource. | represented using the same format as a site-wide tracking status resource. | |||
5.4.3 Representation | 5.4.3 Representation | |||
skipping to change at line 866 | skipping to change at line 796 | |||
resource in the JSON format [RFC4627] that conforms to the ABNF for | resource in the JSON format [RFC4627] that conforms to the ABNF for | |||
status-object (except that the members within each member-list MAY be | status-object (except that the members within each member-list MAY be | |||
provided in any order). | provided in any order). | |||
The following example tracking status representation illustrates all of | The following example tracking status representation illustrates all of | |||
the fields defined by this specification, most of which are optional. | the fields defined by this specification, most of which are optional. | |||
Example 6 | Example 6 | |||
{ | { | |||
"tracking": "1", | "tracking": "T", | |||
"compliance": ["https://acme.example.org/tracking101"], | ||||
"qualifiers": "afc", | "qualifiers": "afc", | |||
"controller": ["https://www.example.com/privacy"], | "controller": ["https://www.example.com/privacy"], | |||
"same-party": [ | "same-party": [ | |||
"example.com", | "example.com", | |||
"example_vids.net", | "example_vids.net", | |||
"example_stats.com" | "example_stats.com" | |||
], | ], | |||
"third-party": [ | ||||
"api.example.net" | ||||
], | ||||
"audit": [ | "audit": [ | |||
"http://auditor.example.org/727073" | "http://auditor.example.org/727073" | |||
], | ], | |||
"policy": "/privacy.html#tracking", | "policy": "/privacy.html#tracking", | |||
"edit": "http://example.com/your/data" | "edit": "http://example.com/your/data" | |||
} | } | |||
A tracking status representation consists of a single status-object | A tracking status representation consists of a single status-object | |||
containing members that describe the tracking status applicable to the | containing members that describe the tracking status applicable to the | |||
designated resource. | designated resource. | |||
status-object = begin-object member-list end-object | status-object = begin-object member-list end-object | |||
member-list = tracking ns tracking-v | member-list = tracking ns tracking-v | |||
[ vs qualifiers ns qualifiers-v ] | [ vs compliance ns compliance-v ] | |||
[ vs controller ns controller-v ] | [ vs qualifiers ns qualifiers-v ] | |||
[ vs same-party ns same-party-v ] | [ vs controller ns controller-v ] | |||
[ vs third-party ns third-party-v ] | [ vs same-party ns same-party-v ] | |||
[ vs audit ns audit-v ] | [ vs audit ns audit-v ] | |||
[ vs policy ns policy-v ] | [ vs policy ns policy-v ] | |||
[ vs edit ns edit-v ] | [ vs edit ns edit-v ] | |||
*( vs extension ) | *( vs extension ) | |||
A status-object always has a member named tracking with a string value | A status-object always has a member named tracking with a string value | |||
that consists of the tracking status value applicable to the designated | that consists of the tracking status value applicable to the designated | |||
resource (section 5.2 Tracking Status Value). | resource (section 5.2 Tracking Status Value). | |||
tracking = %x22 "tracking" %x22 | tracking = %x22 "tracking" %x22 | |||
tracking-v = %x22 TSV %x22 | tracking-v = %x22 TSV %x22 | |||
For example, the following demonstrates a minimal tracking status | For example, the following demonstrates a minimal tracking status | |||
representation that is applicable to any resource that does not perform | representation that is applicable to any resource that does not perform | |||
tracking. | tracking. | |||
Example 7 | Example 7 | |||
{"tracking": "N"} | {"tracking": "N"} | |||
An origin server MAY send a status-object member named qualifiers with a | An origin server MAY send a member named compliance with an array value | |||
string value containing a sequence of case sensitive characters | containing a list of URI references that identify specific regimes to | |||
corresponding to each of the permitted uses (as defined in | which the origin server claims to comply for the designated resource. | |||
[TRACKING-COMPLIANCE]) that might be in use for the designated resource. | Communicating such a claim of compliance is presumed to improve | |||
The purpose of this field is to provide additional transparency where | transparency, which might influence a user's decisions or configurations | |||
desired. | regarding allowed tracking, but does not have any direct impact on this | |||
protocol. | ||||
qualifier meaning | compliance = %x22 "compliance" %x22 | |||
Audit: Tracking is limited to that necessary for an external | compliance-v = array-of-refs | |||
a audit of the service context and the data collected is minimized | ||||
accordingly. | ||||
c Ad frequency capping: Tracking is limited to frequency capping | ||||
and the data collected is minimized accordingly. | ||||
Fraud prevention: Tracking is limited to that necessary for | ||||
f preventing or investigating fraudulent behavior and security | ||||
violations; the data collected is minimized accordingly. | ||||
Local constraints: Tracking is limited to what is required by | ||||
l local law, rule, or regulation and the data collected is | ||||
minimized accordingly. | ||||
r Referrals: Tracking is limited to collecting referral | ||||
information and the data collected is minimized accordingly. | ||||
Transferred consent: The origin server is satisfying the request | ||||
t on behalf of another server which had consent, and that consent | ||||
has been transferred. | ||||
Multiple qualifiers mean that multiple permitted uses of tracking might be | Issue 239: Should tracking status representation include an array of links | |||
present and that each such use conforms to the associated requirements. | for claiming compliance by reference? | |||
All qualifiers imply some form of tracking might be used and thus MUST NOT | ||||
be provided with a tracking status value of N (not tracking). | ||||
qualifiers = %x22 "qualifiers" %x22 | [RAISED] Text above is proposed resolution. | |||
qualifiers-v = %x22 0*5qualifier %x22 | ||||
qualifier = %x61 ; "a" - audit | ||||
/ %x63 ; "c" - capping | ||||
/ %x66 ; "f" - fraud | ||||
/ %x6C ; "l" - local | ||||
/ %x72 ; "r" - referral | ||||
/ %x72 ; "t" - transferred consent | ||||
Issue 136: Resolve dependencies of the TPE on the compliance specification | An origin server MAY send a status-object member named qualifiers with a | |||
string value containing a sequence of case sensitive characters | ||||
corresponding to explanations or limitations on the extent of tracking. | ||||
Multiple qualifiers indicate that multiple explanations or forms of | ||||
tracking might apply for the designated resource. The meaning of each | ||||
qualifier is presumed to be defined by one or more of the regimes listed | ||||
in compliance. | ||||
[OPEN] The list of qualifiers is intended to match one to one to the | qualifiers = %x22 "qualifiers" %x22 | |||
permitted uses identified by [TRACKING-COMPLIANCE], using references to | qualifiers-v = %x22 *qualifier %x22 | |||
the definitions there. The list will then be updated accordingly. | qualifier = id-char | |||
An origin server MAY send a member named controller with an array value | An origin server MAY send a member named controller with an array value | |||
containing a list of URI references indirectly identifying the party or | containing a list of URI references indirectly identifying the party or | |||
set of parties that claims to be the responsible data controller for | set of parties that claims to be the responsible data controller for | |||
personal data collected via the designated resource. An origin server MUST | personal data collected via the designated resource. An origin server MUST | |||
send a controller member if the responsible data controller does not own | send a controller member if the responsible data controller does not own | |||
the designated resource's domain name. | the designated resource's domain name. | |||
An origin server that does not send controller is implying that its domain | An origin server that does not send controller is implying that its domain | |||
owner is the sole data controller; information about the data controller | owner is the sole data controller; information about the data controller | |||
skipping to change at line 987 | skipping to change at line 899 | |||
parties have independent control over the collected data), the origin | parties have independent control over the collected data), the origin | |||
server MUST send a controller member that contains a reference for each | server MUST send a controller member that contains a reference for each | |||
data controller. | data controller. | |||
Each URI reference provided in controller MUST refer to a resource that, | Each URI reference provided in controller MUST refer to a resource that, | |||
if a retrieval action is performed on that URI, would provide the user | if a retrieval action is performed on that URI, would provide the user | |||
with information regarding (at a minimum) the identity of the | with information regarding (at a minimum) the identity of the | |||
corresponding party and its data collection practices. | corresponding party and its data collection practices. | |||
controller = %x22 "controller" %x22 | controller = %x22 "controller" %x22 | |||
controller-v = array-of-strings | controller-v = array-of-refs | |||
Since a user's experience on a given site might be composed of resources | Since a user's experience on a given site might be composed of resources | |||
that are assembled from multiple domains, it might be useful for a site to | that are assembled from multiple domains, it might be useful for a site to | |||
distinguish those domains that are subject to their own control (i.e., | distinguish those domains that are subject to their own control (i.e., | |||
share the same data controller as the referring site). An OPTIONAL member | share the same data controller as the referring site). An origin server | |||
named same-party MAY be provided with an array value containing a list of | MAY send a member named same-party with an array value containing a list | |||
domain names that the origin server claims are the same party, to the | of domain names that the origin server claims are the same party, to the | |||
extent they are referenced by the designated resource, if all data | extent they are referenced by the designated resource, if all data | |||
collected via those references share the same data controller as the | collected via those references share the same data controller as the | |||
designated resource. | designated resource. | |||
A user agent might use the same-party array, when provided, to inform or | A user agent might use the same-party array, when provided, to inform or | |||
enable different behavior for references that are claimed to be same-party | enable different behavior for references that are claimed to be same-party | |||
versus those for which no claim is made. For example, a user agent might | versus those for which no claim is made. For example, a user agent might | |||
choose to exclude, or perform additional pre-flight verification of, | choose to exclude, or perform additional pre-flight verification of, | |||
requests to other domains that have not been claimed as same-party by the | requests to other domains that have not been claimed as same-party by the | |||
referring site. | referring site. | |||
same-party = %x22 "same-party" %x22 | same-party = %x22 "same-party" %x22 | |||
same-party-v = array-of-strings | same-party-v = array-of-refs | |||
An OPTIONAL member named third-party MAY be provided with an array value | Issue 164: To what extent should the same-party attribute of tracking | |||
containing a list of domain names for third-party services that might be | status resource be required? | |||
invoked while using the designated resource but do not share the same data | ||||
controller as the designated resource. | ||||
third-party = %x22 "third-party" %x22 | [OPEN] 3 Alternatives - text is needed: | |||
third-party-v = array-of-strings | (A) Current draft: Resource is optional | |||
(B) Alternative proposal 1: If multiple domains on a page belong to the | ||||
same party, then this fact SHOULD be declared using the same-party | ||||
attribute | ||||
(C) Alternative proposal 2: State that user agents MAY assume that | ||||
additional elements that are hosted under a different URL and occur on a | ||||
page and declare "intended for 1st party use" are malicious unless this | ||||
URL is listed in the "same-party" attribute | ||||
An OPTIONAL member named audit MAY be provided with an array value | An origin server MAY send a member named audit with an array value | |||
containing a list of URI references to external audits of the designated | containing a list of URI references to external audits of the designated | |||
resource's privacy policy and tracking behavior in compliance with this | resource's privacy policy and tracking behavior. Preferably, the audit | |||
protocol. Preferably, the audit references are to resources that describe | references are to resources that describe the auditor and the results of | |||
the auditor and the results of that audit; however, if such a resource is | that audit; however, if such a resource is not available, a reference to | |||
not available, a reference to the auditor is sufficient. | the auditor is sufficient. | |||
audit = %x22 "audit" %x22 | audit = %x22 "audit" %x22 | |||
audit-v = array-of-strings | audit-v = array-of-refs | |||
An OPTIONAL member named policy MAY be provided with a string value | An origin server MAY send a member named policy with a string value | |||
containing a URI-reference to a human-readable document that describes the | containing a URI reference to a human-readable document that describes the | |||
relevant privacy policy for the designated resource. The content of such a | relevant privacy policy for the designated resource. The content of such a | |||
policy document is beyond the scope of this protocol and only supplemental | policy document is beyond the scope of this protocol and only supplemental | |||
to what is described in the machine-readable tracking status | to what is described in the machine-readable tracking status | |||
representation. If no policy member is provided, this information might be | representation. If no policy member is provided, this information might be | |||
obtained via the links provided in controller. | obtained via the links provided in controller. | |||
policy = %x22 "policy" %x22 | policy = %x22 "policy" %x22 | |||
policy-v = string ; URI-reference | policy-v = string ; URI-reference | |||
An OPTIONAL member named edit MAY be provided with a string value | An origin server MAY send a member named edit 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 by the designated resource (and possibly other | personal data collected via the designated resource (and possibly other | |||
resources); an edit member SHOULD be provided if the tracking status value | resources). If the tracking status value indicates prior consent (C), the | |||
indicates prior consent (C). If no edit member is provided, this | origin server MUST send an edit member referencing a resource that | |||
information might be obtained via the links provided in controller or | describes how such consent is established and how to revoke that consent. | |||
policy. | ||||
An edit resource might include the ability to review past data collected, | An edit 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 is beyond the scope of this protocol. | out-of-band consent mechanism are beyond the scope of this protocol. | |||
If no edit member is provided, this information might be obtained via the | ||||
links provided in controller or policy. | ||||
edit = %x22 "edit" %x22 | edit = %x22 "edit" %x22 | |||
edit-v = string ; URI-reference | edit-v = string ; URI-reference | |||
Additional extension members MAY be provided in the status-object to | An origin server MAY send additional extension members in the | |||
support future enhancements to this protocol. A user agent SHOULD ignore | status-object to support future enhancements to this protocol. A recipient | |||
extension members that it does not recognize. | MUST ignore extension members that it does not recognize. | |||
extension = object | extension = object | |||
array-of-strings = begin-array | array-of-refs = begin-array [ string *( vs string ) ] end-array | |||
[ string *( vs string ) ] | ||||
end-array | ||||
ns = <name-separator (:), as defined in [[!RFC4627]]> | ns = <name-separator (:), as defined in [[!RFC4627]]> | |||
vs = <value-separator (,), as defined in [[!RFC4627]]> | vs = <value-separator (,), as defined in [[!RFC4627]]> | |||
begin-array = <begin-array ([), as defined in [[!RFC4627]]> | begin-array = <begin-array ([), as defined in [[!RFC4627]]> | |||
end-array = <end-array (]), as defined in [[!RFC4627]]> | end-array = <end-array (]), as defined in [[!RFC4627]]> | |||
begin-object = <begin-object ({), as defined in [[!RFC4627]]> | begin-object = <begin-object ({), as defined in [[!RFC4627]]> | |||
end-object = <end-object (}), as defined in [[!RFC4627]]> | end-object = <end-object (}), as defined in [[!RFC4627]]> | |||
object = <object, as defined in [[!RFC4627]]> | object = <object, as defined in [[!RFC4627]]> | |||
string = <string, as defined in [[!RFC4627]]> | string = <string, as defined in [[!RFC4627]]> | |||
true = <true, as defined in [[!RFC4627]]> | true = <true, as defined in [[!RFC4627]]> | |||
false = <false, as defined in [[!RFC4627]]> | false = <false, as defined in [[!RFC4627]]> | |||
null = <null, as defined in [[!RFC4627]]> | null = <null, as defined in [[!RFC4627]]> | |||
Note that the tracking status resource space applies equally to both | ||||
first-party and third-party services. An example of a third-party tracking | ||||
status is | ||||
Example 8 | ||||
{ | ||||
"tracking": "3", | ||||
"policy": "/privacy.html", | ||||
"edit": "/your/data", | ||||
} | ||||
Issue 164: To what extent should the same-party attribute of tracking | ||||
status resource be required? | ||||
[OPEN] 3 Alternatives - text is needed: | ||||
(A) Current draft: Resource is optional | ||||
(B) Alternative proposal 1: If multiple domains on a page belong to the | ||||
same party, then this fact SHOULD be declared using the same-party | ||||
attribute | ||||
(C) Alternative proposal 2: State that user agents MAY assume that | ||||
additional elements that are hosted under a different URL and occur on a | ||||
page and declare "intended for 1st party use" are malicious unless this | ||||
URL is listed in the "same-party" attribute | ||||
5.4.4 Status Checks are Not Tracked | 5.4.4 Status Checks are Not Tracked | |||
When sending a request for the tracking status, a user agent SHOULD | When sending a request for the tracking status, a user agent SHOULD | |||
include any cookie data [COOKIES] (set prior to the request) that would be | include any cookie data [COOKIES] (set prior to the request) that would be | |||
sent in a normal request to that origin server, since that data might be | sent in a normal request to that origin server, since that data might be | |||
needed by the server to determine the current tracking status. For | needed by the server to determine the current tracking status. For | |||
example, the cookie data might indicate a prior out-of-band decision by | example, the cookie data might indicate a prior out-of-band decision by | |||
the user to opt-out or consent to tracking by that origin server. | the user to opt-out or consent to tracking by that origin server. | |||
All requests on the tracking status resource space, including the | All requests on the tracking status resource space, including the | |||
skipping to change at line 1134 | skipping to change at line 1025 | |||
requests, including the responses to redirected tracking status requests, | requests, including the responses to redirected tracking status requests, | |||
MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have | MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have | |||
content that initiates tracking beyond what was already present in the | content that initiates tracking beyond what was already present in the | |||
request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie | request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie | |||
or Set-Cookie2 header field received in such a response. | or Set-Cookie2 header field received in such a response. | |||
5.4.5 Caching | 5.4.5 Caching | |||
If the tracking status is applicable to all users, regardless of the | If the tracking status is applicable to all users, regardless of the | |||
received DNT-field-value or other data received via the request, then the | received DNT-field-value or other data received via the request, then the | |||
response SHOULD be marked as cacheable and assigned a time-to-live | origin server SHOULD mark the response as cacheable [HTTP-cache] and | |||
(expiration or max-use) that is sufficient to enable shared caching but | assign a time-to-live (expiration or max-use) that is sufficient to enable | |||
not greater than the earliest point at which the service's tracking | shared caching but not greater than the earliest point at which the | |||
behavior might increase. For example, if the tracking status response is | service's tracking behavior might increase. | |||
set to expire in seven days, then the earliest point in time that the | ||||
service's tracking behavior can be increased is seven days after the | For example, if the tracking status response is set to expire in seven | |||
tracking status representation has been updated to reflect the new | days, then the earliest point in time that the service's tracking behavior | |||
behavior, since old copies might persist in caches until the expiration is | can be increased is seven days after the tracking status representation | |||
triggered. A service's tracking behavior can be reduced at any time, with | has been updated to reflect the new behavior, since old copies might | |||
or without a corresponding change to the tracking status resource. | persist in caches until the expiration is triggered. A service's tracking | |||
behavior can be reduced at any time, with or without a corresponding | ||||
change to the tracking status resource. | ||||
If the tracking status is only applicable to all users that have the same | If the tracking status is only applicable to all users that have the same | |||
DNT-field-value, then the response MUST either be marked with a Vary | DNT-field-value, then the response MUST either be marked with a Vary | |||
header field that includes "DNT" in its field-value or marked as not | header field that includes "DNT" in its field-value or marked as not | |||
reusable by a shared cache without revalidation with a Cache-Control | reusable by a shared cache without revalidation with a Cache-Control | |||
header field containing one of the following directives: "private", | header field containing one of the following directives: "private", | |||
"no-cache", "no-store", or "max-age=0". | "no-cache", "no-store", or "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 response MUST include a Cache-Control header field | requested it, then the response MUST include a Cache-Control header field | |||
skipping to change at line 1175 | skipping to change at line 1068 | |||
tracking status, relying on cached tracking status responses to do so, | tracking status, relying on cached tracking status responses to do so, | |||
SHOULD check responses to its state-changing requests (e.g., POST, PUT, | SHOULD check responses to its state-changing requests (e.g., POST, PUT, | |||
DELETE, etc.) for a Tk header field with the U tracking status value, as | DELETE, etc.) for a Tk header field with the U tracking status value, as | |||
described in section 5.3.3 Indicating an Interactive Status Change. | described in section 5.3.3 Indicating an Interactive Status Change. | |||
5.5 Status Code for Tracking Required | 5.5 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 an | exception or consent for tracking, then the origin server SHOULD send a | |||
HTTP error response with a status code of 409 (Conflict) and a message | 409 (Conflict) response with a message payload that describes why the | |||
body that describes why the request has been refused and how one might | request has been refused and how one might supply the required consent or | |||
supply the required consent or exception to avoid this conflict [HTTP11]. | exception to avoid this conflict [HTTP-semantics]. | |||
The 409 response SHOULD 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. | |||
5.6 Using the Tracking Status | 5.6 Using the Tracking Status | |||
Note | Note | |||
This section is for collecting use cases that describe questions a user | This section is for collecting use cases that describe questions a user | |||
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. | |||
skipping to change at line 1215 | skipping to change at line 1108 | |||
5.6.2 Preflight Checks | 5.6.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 and prior to making | reviewed prior to making use of those services and prior to making | |||
requests on third-party resources referenced by those services. | requests on third-party resources referenced by those services. | |||
A user agent MAY check the tracking status for a designated resource by | A user agent MAY check the tracking status for a designated resource by | |||
first making a retrieval request for the site-wide tracking status | first making a retrieval request for the site-wide tracking status | |||
representation, as described above, and then parsing the representation as | representation, as described above, and then parsing the representation as | |||
JSON to extract the status-object. If retrieval is unsuccessful or parsing | JSON to extract the status-object. If the retrieval is unsuccessful or | |||
results in a syntax error, the user agent SHOULD consider the site to be | parsing results in a syntax error, the user agent ought to consider the | |||
non-conformant with this protocol. | site to be non-conformant with this protocol. | |||
The status-object is supposed to have a member named tracking containing | The status-object is supposed to have a member 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 5.2 Tracking Status Value. | defined in section 5.2 Tracking Status Value. | |||
If the tracking status value is N, then the origin server claims that no | If the tracking status value is N, then the origin server claims that no | |||
tracking is performed for the designated resource for at least the next 24 | tracking is performed for the designated resource for at least the next 24 | |||
hours or until the Cache-Control information indicates that this response | hours or until the Cache-Control information indicates that this response | |||
expires. | expires. | |||
skipping to change at line 1241 | skipping to change at line 1134 | |||
that this response expires. | that this response expires. | |||
6. User-Granted Exceptions | 6. User-Granted Exceptions | |||
6.1 Overview | 6.1 Overview | |||
This section is non-normative. | This section is non-normative. | |||
User-granted exceptions to Do Not Track, including site-specific | User-granted exceptions to Do Not Track, including site-specific | |||
exceptions, are agreed between the site and the user, and stored by the | exceptions, are agreed between the site and the user, and stored by the | |||
user agent. A resource should rely on the DNT header it receives to | user agent. A resource ought to rely on the DNT header it receives to | |||
determine the user's preference for tracking with respect to that | determine the user's preference for tracking with respect to that | |||
particular request. An API is provided so that sites may request and check | particular request. An API is provided so that sites may request and check | |||
the status of exceptions for tracking. | the status of exceptions for tracking. | |||
Note | Note | |||
We envisage that the exceptions may also be usable as a consent mechanism. | We envisage that the exceptions may also be usable as a consent mechanism. | |||
6.2 Motivating Principles and Use Cases | 6.2 Motivating Principles and Use Cases | |||
skipping to change at line 1312 | skipping to change at line 1205 | |||
needs to be ensured before a site is permitted to register an exception. | needs to be ensured before a site is permitted to register an exception. | |||
There is concern that the language above is insufficient to guarantee this | There is concern that the language above is insufficient to guarantee this | |||
desire. Potential language that is acceptable by the whole group is still | desire. Potential language that is acceptable by the whole group is still | |||
under discussion. | under discussion. | |||
Sites MAY ask for an exception, and have it stored, even when the user's | Sites MAY ask for an exception, and have it stored, even when the user's | |||
general preference is not enabled. (This permits recording a permission to | general preference is not enabled. (This permits recording a permission to | |||
allow tracking in jurisdictions where such permission cannot be assumed - | allow tracking in jurisdictions where such permission cannot be assumed - | |||
see section 6.8 Exceptions without interactive JavaScript.) | see section 6.8 Exceptions without interactive JavaScript.) | |||
The user-agent MAY provide interfaces to the user: | The user agent MAY provide interfaces to the user: | |||
* To indicate that a call to store an exception has just been made; | * To indicate that a call to store an exception has just been made; | |||
* To allow the user to confirm a user-granted exception prior to | * To allow the user to confirm a user-granted exception prior to | |||
storage; | storage; | |||
* To indicate that one or more exceptions exist for the current | * To indicate that one or more exceptions exist for the current | |||
top-level origin; | top-level origin; | |||
* To indicate that one or more exceptions exist for sites incorporated | * To indicate that one or more exceptions exist for sites incorporated | |||
into the current page; | into the current page; | |||
* To allow the user to see and possibly revoke stored exceptions; | * To allow the user to see and possibly revoke stored exceptions; | |||
* Other aspects of the exception mechanism, as desired. | * Other aspects of the exception mechanism, as desired. | |||
skipping to change at line 1341 | skipping to change at line 1234 | |||
Note | Note | |||
The requirement for the site to determine the user's intention is new; | The requirement for the site to determine the user's intention is new; | |||
previously the site was required to inform, but the final determination of | previously the site was required to inform, but the final determination of | |||
intention was the responsibility of the UA. This version removes that | intention was the responsibility of the UA. This version removes that | |||
split of user-determination, and leaves it solely with the site. | split of user-determination, and leaves it solely with the site. | |||
6.3.2 Processing Model | 6.3.2 Processing Model | |||
This section describes the effect of the APIs in terms of a logical | This section describes the effect of the APIs in terms of a logical | |||
processing model; this model describes the behavior, but should not be | processing model; this model describes the behavior, but is not to be read | |||
read as mandating any specific implementation. | as mandating any specific implementation. | |||
This API considers exceptions which are double-keyed to two domains: the | This API considers exceptions which are double-keyed to two domains: the | |||
site, and the target. A user might - for instance - want AnalytiCo to be | site, and the target. A user might - for instance - want AnalytiCo to be | |||
allowed to track them on Example News, but not on Example Medical. To | allowed to track them on Example News, but not on Example Medical. To | |||
simplify language used in this API specification, we define three terms: | simplify language used in this API specification, we define three terms: | |||
* top-level origin is the domain name of the top-level document origin | * top-level origin is the domain name of the top-level document origin | |||
of this DOM: essentially the fully qualified domain name in the | of this DOM: essentially the fully qualified domain name in the | |||
address bar. | address bar. | |||
* A target site is a domain name which is the target of an HTTP request, | * A target site is a domain name which is the target of an HTTP request, | |||
skipping to change at line 1378 | skipping to change at line 1271 | |||
[PENDING REVIEW] In the current proposal a domain parameter allows | [PENDING REVIEW] In the current proposal a domain parameter allows | |||
exceptions to apply to sub-domains in the same way as cookies. | exceptions to apply to sub-domains in the same way as cookies. | |||
The domains that enter into the behavior of the APIs include: | The domains that enter into the behavior of the APIs include: | |||
* As described above, the document origin active at the time of the | * As described above, the document origin active at the time of the | |||
call, and; | call, and; | |||
* Domain names passed to the API. | * Domain names passed to the API. | |||
Domains that enter into the decision over what DNT header to be sent in a | Domains that enter into the decision over what DNT header to be sent in a | |||
given HTTP request include: | given request include: | |||
* The top-level origin of the current context; | * The top-level origin of the current context; | |||
* The target of the HTTP request. | * The target of the request. | |||
Note | Note | |||
Note that these strict, machine-discoverable, concepts may not match the | Note that these strict, machine-discoverable, concepts may not match the | |||
definitions of first and third party; in particular, sites themselves need | definitions of first and third party; in particular, sites themselves need | |||
to determine (and signal) when they get 'promoted' to first party by | to determine (and signal) when they get 'promoted' to first party by | |||
virtue of user interaction; the UA will not change the DNT header it sends | virtue of user interaction; the UA will not change the DNT header it sends | |||
them. | them. | |||
The calls cause the following steps to occur (subject to user confirmation | The calls cause the following steps to occur (subject to user confirmation | |||
of the exception, if the user-agent asks for it): | of the exception, if the user agent asks for it): | |||
* The UA adds to its local database one or more site-pair duplets | * The UA adds to its local database one or more site-pair duplets | |||
[document-origin, target]; one or other of these may be a wild-card | [document-origin, target]; one or other of these may be a wild-card | |||
("*"); | ("*"); | |||
* While the user is browsing a given site (top-level origin), and a DNT | * While the user is browsing a given site (top-level origin), and a DNT | |||
header is to be sent to a target domain, if the duplet [top-level | header is to be sent to a target domain, if the duplet [top-level | |||
origin, target domain] matches any duplet in the database, then a | origin, target domain] matches any duplet in the database, then a | |||
DNT:0 header is sent, otherwise DNT:1 is sent. | DNT:0 header is sent, otherwise DNT:1 is sent. | |||
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 | |||
skipping to change at line 1428 | skipping to change at line 1321 | |||
maintain their own trusted third parties? | maintain their own trusted third parties? | |||
[POSTPONED] This model does not support mashed-up content which is in turn | [POSTPONED] This model does not support mashed-up content which is in turn | |||
supported by ads; it's not clear how to distinguish between embedded | supported by ads; it's not clear how to distinguish between embedded | |||
content which is embedding ads (and hence the top-level origin stays the | content which is embedding ads (and hence the top-level origin stays the | |||
same) and embedded content that should start a new context. | same) and embedded content that should start a new context. | |||
Proposal: For this version of the specification, we don't address this | Proposal: For this version of the specification, we don't address this | |||
corner case. | corner case. | |||
User-agents MUST handle each API request as a 'unit', granting and | User-agents MUST handle each API request as a 'unit', granting and | |||
maintaining it in its entirety, or not at all. That means that a | maintaining it in its entirety, or not at all. That means that a user | |||
user-agent MUST NOT indicate to a site that a request for targets {a, b, | agent MUST NOT indicate to a site that a request for targets {a, b, c} | |||
c} exists in the database, and later remove only one or two of {a, b, c} | exists in the database, and later remove only one or two of {a, b, c} from | |||
from its logical database of remembered grants. This assures sites that | its logical database of remembered grants. This assures sites that the set | |||
the set of sites they need for operational integrity is treated as a unit. | of sites they need for operational integrity is treated as a unit. Each | |||
Each separate call to an API is a separate unit. | separate call to an API is a separate unit. | |||
Note | Note | |||
It is left up to individual user-agent implementations how to determine | It is left up to individual user agent implementations how to determine | |||
and how and whether to store users' tracking preferences. | and how and whether to store users' tracking preferences. | |||
When an explicit list of domains is provided through the API, their names | When an explicit list of domains is provided through the API, their names | |||
might mean little to the user. The user might, for example, be told that | might mean little to the user. The user might, for example, be told that | |||
there is a stored exception for a specific set of sites on such-and-such | there is a stored exception for a specific set of sites on such-and-such | |||
top-level origin, rather than listing them by name; or the user-agent may | top-level origin, rather than listing them by name; or the user agent may | |||
decide to store, and show to the user, a site-wide exception, effectively | decide to store, and show to the user, a site-wide exception, effectively | |||
ignoring the list of domain names, if supplied. | ignoring the list of domain names, if supplied. | |||
Conversely, if a wild-card is used, the user may be told that there is a | Conversely, if a wild-card is used, the user may be told that there is a | |||
stored exception for all third-parties that are, or will be, embedded on | stored exception for all third-parties that are, or will be, embedded on | |||
the indicated the top-level origin. | the indicated the top-level origin. | |||
Issue 151: User Agent Requirement: Be able to handle an exception request | Issue 151: User Agent Requirement: Be able to handle an exception request | |||
[OPEN] There is software that in just a few lines of code just spawn DNT;1 | [OPEN] There is software that, in just a few lines of code, can spawn | |||
or DNT;0 headers regardless of user's will. A requirement on the user | DNT:1 or DNT:0 headers regardless of user's will. A requirement on the | |||
agent that they can handle the full exception mechanism will allow to | user agent that they can handle the full exception mechanism will allow to | |||
discard compliance statements by those agents. It will also allow also the | discard compliance statements by those agents. It will also allow also the | |||
site to test for conformance by requiring an exception. In case the UA | site to test for conformance by requiring an exception. In case the UA | |||
does not react on an exception request, the server could ignore DNT | does not react on an exception request, the server could ignore DNT | |||
signals from that UA. It would allow thus testing from the horizon of the | signals from that UA. It would allow thus testing from the horizon of the | |||
site without wild guessing; | site without wild guessing; | |||
However, there is no practical difference between a UA that hard-wires | However, there is no practical difference between a UA that hard-wires | |||
'no' to all exception requests, and a UA that does not implement the | 'no' to all exception requests, and a UA that does not implement the | |||
calls. | calls. | |||
Issue 167: Multiple site exceptions | Issue 167: Multiple site exceptions | |||
skipping to change at line 1522 | skipping to change at line 1415 | |||
The storeSiteSpecificTrackingException method takes a dictionary argument | The storeSiteSpecificTrackingException method takes a dictionary argument | |||
of type StoreSiteSpecificExceptionPropertyBag that allows optional | of type StoreSiteSpecificExceptionPropertyBag that allows optional | |||
information to be provided. | information to be provided. | |||
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. When called, | |||
storeSiteSpecificTrackingException MUST return immediately. | 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 in the | |||
return value. | return value. | |||
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 execution of this | |||
API and the use of the resulting permission (if granted) use the | API and the use of the resulting permission (if granted) use the | |||
'implicit' parameter, when the API is called, the document origin. This | '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 | forms the first part of the duplet in the logical model, and hence in | |||
operation will be compared with the top-level origin. | operation will be compared with the top-level origin. | |||
If permission is stored for an explicit list, then the set of duplets (one | If permission is stored for an explicit list, then the set of duplets (one | |||
skipping to change at line 1556 | skipping to change at line 1449 | |||
the domain parameter to cookies and allows setting for subdomains. The | the domain parameter to cookies and allows setting for subdomains. The | |||
domain argument can be set to fully-qualified right-hand segment of the | domain argument can be set to fully-qualified right-hand segment of the | |||
document host name, up to one level below TLD. | document host name, up to one level below TLD. | |||
Note | Note | |||
For example, www.foo.bar.example.com may set the domain parameter as as | For example, www.foo.bar.example.com may 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 permitted to set a cookie on the | If the document-origin would not be able to set a cookie on the domain | |||
domain following the cookie domain rules [COOKIES] (e.g. domain is not a | following the cookie domain rules [COOKIES] (e.g. domain is not a | |||
right-hand match or is a TLD) then the duplet MUST not be entered into the | right-hand match or is a TLD) then the duplet MUST not be entered into the | |||
database and a SYNTAX_ERR exception should be thrown. | database and a SYNTAX_ERR exception SHOULD be thrown. | |||
If permission is stored for an explicit list, then the set of duplets (one | If permission is stored for an explicit list, then the set of duplets (one | |||
per target): | per target): | |||
[*.domain, target] | [*.domain, target] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
If permission is stored for a site-wide exception, then the duplet: | If permission is stored for a site-wide exception, then the duplet: | |||
skipping to change at line 1582 | skipping to change at line 1475 | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
A particular response to the API - like a DNT response header - is only | A particular response to the API - like a DNT response header - is only | |||
valid immediately, and users may choose to edit the list of stored | valid immediately, and users may choose to edit the list of stored | |||
exceptions and revoke some or all of them. | exceptions and revoke some or all of them. | |||
Note | Note | |||
The prior version of this call was asynchronous with a call-back; the | The prior version of this call was asynchronous with a call-back; the | |||
change to require the site to determine the user's wishes, rather than the | change to require the site to determine the user's wishes, rather than the | |||
UA, enabled this to become synchronous. This is simpler; the user-agent | UA, enabled this to become synchronous. This is simpler; the user agent | |||
may still ask for the user's approval. Sites wishing to know whether an | may still ask for the user's approval. Sites wishing to know whether an | |||
exception stands, or the DNT header that they would receive, should call | exception stands, or the DNT header that they would receive, should call | |||
the appropriate enquiry API. | the appropriate enquiry API. | |||
6.4.2 API to Cancel a Site-specific Exception | 6.4.2 API to Cancel a Site-specific Exception | |||
partial interface Navigator { | partial interface Navigator { | |||
void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag prop erties); | void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag prop erties); | |||
}; | }; | |||
skipping to change at line 1663 | skipping to change at line 1556 | |||
sequence<DOMString> arrayOfDomainStrings; | sequence<DOMString> arrayOfDomainStrings; | |||
}; | }; | |||
arrayOfDomainStrings of type sequence<DOMString> | arrayOfDomainStrings of type sequence<DOMString> | |||
A JavaScript array of strings. | A JavaScript array of strings. | |||
If the call does not include the arrayOfDomainStrings, then this call is | If the call does not include the arrayOfDomainStrings, then this call is | |||
to confirm a site-wide exception. Otherwise each string in | to confirm a site-wide exception. Otherwise each string in | |||
arrayOfDomainStrings specifies a target. | arrayOfDomainStrings specifies a target. | |||
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 | |||
execution of this API uses the 'implicit' parameter, when the API is | execution of this API uses the 'implicit' parameter, when the API is | |||
called, the document origin. This forms the first part of the duplet in | called, the document origin. This forms the first part of the duplet in | |||
the logical model. | 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] | [document-origin, target] | |||
If the user-agent stores only site-wide exceptions or the call did not | If the user agent stores only site-wide exceptions or the call did not | |||
include an explicit list, the database is checked for the single duplet: | include an explicit list, the database is checked for the single duplet: | |||
[document-origin, * ] | [document-origin, * ] | |||
If the user-agent stores explicit lists, and the call includes one, and | If the user agent stores explicit lists, and the call includes one, and | |||
the domain argument is provided and is not empty then the database is | the domain argument is provided and is not empty then the database is | |||
checked for the existence of all the duplets (one per target): | checked for the existence of all the duplets (one per target): | |||
[*.domain, target] | [*.domain, target] | |||
If the user-agent stores only site-wide exceptions or the call did not | If the user agent stores only site-wide exceptions or the call did not | |||
include an explicit list, and the domain argument is provided and is not | include an explicit list, and the domain argument is provided and is not | |||
empty then the database is checked for the single duplet: | empty then the database is checked for the single duplet: | |||
[*.domain, * ] | [*.domain, * ] | |||
The returned boolean has the following possible values: | The returned boolean has the following possible values: | |||
* true all the duplets exist in the database; | * true all the duplets exist in the database; | |||
* false one or more of the duplets does not exist in the database. | * false one or more of the duplets does not exist in the database. | |||
skipping to change at line 1778 | skipping to change at line 1671 | |||
* false indicates that the web-wide exception does not exist. | * false indicates that the web-wide exception does not exist. | |||
6.6 Transfer of an exception to another third party | 6.6 Transfer of an exception to another third party | |||
A site may request an exception for one or more third party services used | A site may request an exception for one or more third party services used | |||
in conjunction with its own offer. Those third party services may wish to | in conjunction with its own offer. Those third party services may wish to | |||
use other third parties to complete the request in a chain of | use other third parties to complete the request in a chain of | |||
interactions. The first party will not necessarily know in advance whether | interactions. The first party will not necessarily know in advance whether | |||
a known third party will use some other third parties. | a known third party will use some other third parties. | |||
If a user-agent sends a tracking exception to a given combination of | If a user agent sends a tracking exception to a given combination of | |||
origin server and a named third party, the user agent will send DNT:0 to | origin server and a named third party, the user agent will send DNT:0 to | |||
that named third party. By receiving the DNT:0 header, the named third | that named third party. By receiving the DNT:0 header, the named third | |||
party acquires the permission to track the user agent and collect the data | party acquires the permission to track the user agent and collect the data | |||
and process it in any way allowed by the legal system it is operating in. | and process it in any way allowed by the legal system it is operating in. | |||
Furthermore, the named third party receiving the DNT:0 header acquires at | Furthermore, the named third party receiving the DNT:0 header acquires at | |||
least the right to collect data and process it for the given interaction | least the right to collect data and process it for the given interaction | |||
and any secondary use unless it receives a DNT:1 header from that | and any secondary use unless it receives a DNT:1 header from that | |||
particular identified user agent. | particular identified user agent. | |||
The named third party is also allowed to transmit the collected data for | The named third party is also allowed to transmit the collected data for | |||
uses related to this interaction to its own sub-services and | uses related to this interaction to its own sub-services and | |||
sub-sub-services (transitive permission). The tracking permission request | sub-sub-services (transitive permission). The tracking permission request | |||
triggered by the origin server is thus granted to the named third party | triggered by the origin server is thus granted to the named third party | |||
and its sub-services. This is even true for sub-services that would | and its sub-services. This is even true for sub-services that would | |||
normally receive a DNT:1 web-wide preference from the user-agent if the | normally receive a DNT:1 web-wide preference from the user agent if the | |||
user agent interacted with this service directly. | user agent interacted with this service directly. | |||
For advertisement networks this typically would mean that the collection | For advertisement networks this typically would mean that the collection | |||
and auction system chain can use the data for that interaction and combine | and auction system chain can use the data for that interaction and combine | |||
it with existing profiles and data. The sub-services to the named third | it with existing profiles and data. The sub-services to the named third | |||
party do not acquire an independent right to process the data for | party do not acquire an independent right to process the data for | |||
independent secondary uses unless they, themselves, receive a DNT:0 header | independent secondary uses unless they, themselves, receive a DNT:0 header | |||
from the user agent (as a result of their own request or the request of a | from the user agent (as a result of their own request or the request of a | |||
first-party). In our example of advertisement networks that means the | first-party). In our example of advertisement networks that means the | |||
sub-services can use existing profiles in combination with the data | sub-services can use existing profiles in combination with the data | |||
skipping to change at line 1840 | skipping to change at line 1733 | |||
It is expected that the site will explain, in its online content, the need | It is expected that the site will explain, in its online content, the need | |||
for an exception, and the consequences of granting or denying an | for an exception, and the consequences of granting or denying an | |||
exception, to the user. | exception, to the user. | |||
User agents are free to implement exception management user interfaces as | User agents are free to implement exception management user interfaces as | |||
they see fit. Some agents might provide a notification to the user at the | they see fit. Some agents might provide a notification to the user at the | |||
time of the request, or even not complete the storing of the exception | time of the request, or even not complete the storing of the exception | |||
until the user approves. Some agents might provide a user-interface to see | until the user approves. Some agents might provide a user-interface to see | |||
and edit the database of recorded exception grants. The API parameters | and edit the database of recorded exception grants. The API parameters | |||
siteName, explanationString, and detailURI are provided so that the | siteName, explanationString, and detailURI are provided so that the user | |||
user-agent may use them in their user interface. | agent may use them in their user interface. | |||
A user agent that chooses to highlight when tracking exceptions have been | A user agent that chooses to highlight when tracking exceptions have been | |||
stored might provide an interface like the following. | stored might provide an interface like the following. | |||
* an icon in the status bar indicating that an exception has been | * an icon in the status bar indicating that an exception has been | |||
stored, which, when clicked on, gives the user more information about | stored, which, when clicked on, gives the user more information about | |||
the exception and an option to revoke such an exception. | the exception and an option to revoke such an exception. | |||
* an infobar stating "Example News (news.example.com) has indicated to | * an infobar stating "Example News (news.example.com) has indicated to | |||
Browser that you have consented to granting it exceptions to your | Browser that you have consented to granting it exceptions to your | |||
general Do Not Track preference. If you believe this is incorrect, | general Do Not Track preference. If you believe this is incorrect, | |||
click Revoke." | click Revoke." | |||
* no UI at all. | * no UI at all. | |||
In some user-agent implementations, decisions to grant exceptions may have | In some user agent implementations, decisions to grant exceptions may have | |||
been made in the past (and since forgotten) or may have been made by other | been made in the past (and since forgotten) or may have been made by other | |||
users of the device. Thus, exceptions may not always represent the current | users of the device. Thus, exceptions may not always represent the current | |||
preferences of the user. Some user agents might choose to provide ambient | 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 | notice that user-opted tracking is ongoing, or easy access to view and | |||
control these preferences. Users may desire options to edit exceptions | control these preferences. Users may desire options to edit exceptions | |||
either at the time of tracking or in a separate user interface. This might | either at the time of tracking or in a separate user interface. This might | |||
allow the user to edit their preferences for a site they do not trust | allow the user to edit their preferences for a site they do not trust | |||
without visiting that site. | without visiting that site. | |||
6.8 Exceptions without interactive JavaScript | 6.8 Exceptions without interactive JavaScript | |||
This section is non-normative. | This section is non-normative. | |||
Some third party servers that comply with this standard may wish to | Some third party servers may wish to receive user-granted exceptions but | |||
receive user-granted exceptions but when they are invoked as third parties | when they are invoked as third parties (using, for example, images, or | |||
(using, for example, images, or "tracking pixels") do not have an | "tracking pixels") do not have an interactive JavaScript presence on the | |||
interactive JavaScript presence on the page. They cannot request an | page. They cannot request an exception under these circumstances, both | |||
exception under these circumstances, both because a script is needed, and | because a script is needed, and because they are required to explain to | |||
because they are required to explain to the user the need for and | the user the need for and consequences of granting an exception, and get | |||
consequences of granting an exception, and get the user's consent. In | the user's consent. In general this process of informing, getting consent, | |||
general this process of informing, getting consent, and calling the API is | and calling the API is not expected to be in the page where such trackers | |||
not expected to be in the page where such trackers are invoked. | are invoked. | |||
To obtain an exception, a document (page, frame, etc.) that loads the | To obtain an exception, a document (page, frame, etc.) that loads the | |||
Javascript is needed. The user may visit the site that desires an | Javascript is needed. The user may visit the site that desires an | |||
exception directly, the first party site could load a frame of the site | exception directly, the first party site could load a frame of the site | |||
desiring the exception, or that frame might be part of some other page | desiring the exception, or that frame might be part of some other page | |||
containing a number of frames, which allows aggregation of requests for | containing a number of frames, which allows aggregation of requests for | |||
exceptions. | exceptions. | |||
In all these ways, the site is contributing to informing the user and | In all these ways, the site is contributing to informing the user and | |||
getting their consent, and is also able to call the Javascript API when it | getting their consent, and is also able to call the Javascript API when it | |||
skipping to change at line 1903 | skipping to change at line 1796 | |||
section, this language might need to be updated to correspond. | section, this language might need to be updated to correspond. | |||
6.9 Exceptions without a DNT header | 6.9 Exceptions without a DNT header | |||
Sites might wish to request exceptions even when a user arrives without a | Sites might wish to request exceptions even when a user arrives without a | |||
DNT header. Users might wish to grant affirmative permission to tracking | DNT header. Users might wish to grant affirmative permission to tracking | |||
on or by certain sites even without expressing general tracking | on or by certain sites even without expressing general tracking | |||
preferences. | preferences. | |||
User agents MAY instantiate navigator.storeSiteSpecificTrackingException | User agents MAY instantiate navigator.storeSiteSpecificTrackingException | |||
even when navigator.doNotTrack is null. Sites SHOULD test for the | even when navigator.doNotTrack is null. Scripts SHOULD test for the | |||
existence of storeSiteSpecificTrackingException before calling the method. | existence of storeSiteSpecificTrackingException before calling the method. | |||
If an exception is granted in this context and the user-agent stores that | If an exception is granted in this context and the user agent stores that | |||
preference, a user agent may send a DNT:0 header even if a tracking | preference, a user agent may send a DNT:0 header even if a tracking | |||
preference isn't expressed for other requests. Persisted preferences MAY | preference isn't expressed for other requests. Persisted preferences MAY | |||
also affect which header is transmitted if a user later chooses to express | also affect which header is transmitted if a user later chooses to express | |||
a tracking preference. | a tracking preference. | |||
Note | Note | |||
Users might not configure their agents to have simple values for DNT, but | Users might not configure their agents to have simple values for DNT, but | |||
use different browsing modes or other contextual information to decide on | use different browsing modes or other contextual information to decide on | |||
a DNT value. What algorithm a user agent employs to determine DNT values | a DNT value. What algorithm a user agent employs to determine DNT values | |||
skipping to change at line 1929 | skipping to change at line 1822 | |||
This section is non-normative. | This section is non-normative. | |||
This section is to inform the authors of sites on some considerations in | This section is to inform the authors of sites on some considerations in | |||
using the exceptions APIs to best effect; sites of particular interest | using the exceptions APIs to best effect; sites of particular interest | |||
here are those that need an exception in order to allow the user to | here are those that need an exception in order to allow the user to | |||
perform some operation or to have some access. | perform some operation or to have some access. | |||
The 'Store' calls do not have a return value, and return immediately. If | The 'Store' calls do not have a return value, and return immediately. If | |||
there is a problem with the calling parameters, then a Javascript | there is a problem with the calling parameters, then a Javascript | |||
exception will be raised. In addition, it may be that the user-agent does | exception will be raised. In addition, it may be that the user agent does | |||
not immediately store the exception, possibly because it is allowing the | not immediately store the exception, possibly because it is allowing the | |||
user to confirm. Even though the site has acquired the user's informed | user to confirm. Even though the site has acquired the user's informed | |||
consent before calling the 'Store' API, it is possible that the user will | consent before calling the 'Store' API, it is possible that the user will | |||
change their mind, and allow the store to proceed but then later ask it be | change their mind, and allow the store to proceed but then later ask it be | |||
removed, or even by denying the storage in the first place. | removed, or even by denying the storage in the first place. | |||
Note | Note | |||
The use of the word 'exception' both to describe the user granting | The use of the word 'exception' both to describe the user granting | |||
something, and for a problem in Javascript, is an unfortunate clash here. | something, and for a problem in Javascript, is an unfortunate clash here. | |||
Sites can call the 'Confirm' APIs to enquire whether a specific exception | Sites can call the 'Confirm' APIs to enquire whether a specific exception | |||
has been granted and stands in the user-agent. This is the call to make to | has been granted and stands in the user agent. This is the call to make to | |||
determine whether the exception exists, and hence to control access to the | determine whether the exception exists, and hence to control access to the | |||
function or operation; if it fails (the exception has been deleted, or not | function or operation; if it fails (the exception has been deleted, or not | |||
yet granted), then the user is ideally again offered the information | yet granted), then the user is ideally again offered the information | |||
needed to give their informed consent, and again offered the opportunity | needed to give their informed consent, and again offered the opportunity | |||
to indicate that they grant it. As stated in the normative text, the site | to indicate that they grant it. As stated in the normative text, the site | |||
needs to explain and acquire consent immediately prior to calling the | needs to explain and acquire consent immediately prior to calling the | |||
Store API, and not remember some past consent; this allows the user to | Store API, and not remember some past consent; this allows the user to | |||
change their mind. | change their mind. | |||
If they do grant it (using some positive interaction such as a button), | If they do grant it (using some positive interaction such as a button), | |||
skipping to change at line 1970 | skipping to change at line 1863 | |||
between each call, in a loop; | between each call, in a loop; | |||
* permits the user the opportunity to delete a previously granted | * permits the user the opportunity to delete a previously granted | |||
exception. | exception. | |||
6.11 Fingerprinting | 6.11 Fingerprinting | |||
By storing a client-side configurable state and providing functionality to | By storing a client-side configurable state and providing functionality to | |||
learn about it later, this API might facilitate user fingerprinting and | learn about it later, this API might facilitate user fingerprinting and | |||
tracking. User agent developers ought to consider the possibility of | tracking. User agent developers ought to consider the possibility of | |||
fingerprinting during implementation and might consider rate-limiting | fingerprinting during implementation and might consider rate-limiting | |||
requests or using other heuristics to mitigate fingerprinting risk. User | requests or using other heuristics to mitigate fingerprinting risk. | |||
agents SHOULD clear stored user-granted exceptions when the user chooses | ||||
to clear cookies or other client-side state. | ||||
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), Nick Doty (W3C/MIT), | contributions from Adrian Bateman (Microsoft), Nick Doty (W3C/MIT), | |||
Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Tom Lowenthal | Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Tom Lowenthal | |||
(Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Stanford), | (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Stanford), | |||
Mike O'Neill (Baycloud Systems), Matthias Schunter (Intel), John Simpson | Mike O'Neill (Baycloud Systems), Matthias Schunter (Intel), John Simpson | |||
(Consumer Watchdog), David Singer (Apple), David Wainberg (Network | (Consumer Watchdog), David Singer (Apple), David Wainberg (Network | |||
skipping to change at line 2004 | skipping to change at line 1895 | |||
B.1 Normative references | B.1 Normative references | |||
[ABNF] | [ABNF] | |||
D. Crocker; P. Overell. Augmented BNF for Syntax Specifications: | D. Crocker; P. Overell. Augmented BNF for Syntax Specifications: | |||
ABNF. January 2008. STD. URL: http://www.ietf.org/rfc/rfc5234.txt | ABNF. January 2008. STD. URL: http://www.ietf.org/rfc/rfc5234.txt | |||
[COOKIES] | [COOKIES] | |||
A. Barth. HTTP State Management Mechanism. April 2011. RFC. URL: | A. Barth. HTTP State Management Mechanism. April 2011. RFC. URL: | |||
http://www.ietf.org/rfc/rfc6265.txt | http://www.ietf.org/rfc/rfc6265.txt | |||
[HTTP11] | [HTTP] | |||
R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June | Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol | |||
1999. RFC. URL: http://www.ietf.org/rfc/rfc2616.txt | (HTTP/1.1): Message Syntax and Routing. 17 November 2013. | |||
Internet-Draft. URL: | ||||
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ | ||||
[HTTP-cache] | ||||
Roy T. Fielding; Mark Nottingham; Julian Reschke. Hypertext | ||||
Transfer Protocol (HTTP/1.1): Caching. 17 November 2013. | ||||
Internet-Draft. URL: | ||||
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-cache/ | ||||
[HTTP-semantics] | ||||
Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol | ||||
(HTTP/1.1): Semantics and Content. 17 November 2013. | ||||
Internet-Draft. URL: | ||||
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/ | ||||
[RFC2119] | [RFC2119] | |||
S. Bradner. Key words for use in RFCs to Indicate Requirement | S. Bradner. Key words for use in RFCs to Indicate Requirement | |||
Levels. March 1997. Internet RFC 2119. URL: | Levels. March 1997. Internet RFC 2119. URL: | |||
http://www.ietf.org/rfc/rfc2119.txt | http://www.ietf.org/rfc/rfc2119.txt | |||
[RFC4627] | [RFC4627] | |||
D. Crockford. The application/json Media Type for JavaScript | D. Crockford. The application/json Media Type for JavaScript | |||
Object Notation (JSON) (RFC 4627). July 2006. RFC. URL: | Object Notation (JSON) (RFC 4627). July 2006. RFC. URL: | |||
http://www.ietf.org/rfc/rfc4627.txt | http://www.ietf.org/rfc/rfc4627.txt | |||
[TRACKING-COMPLIANCE] | ||||
Justin Brookman; Sean Harvey; Erica Newland; Heather West. | ||||
Tracking Compliance and Scope. 02 October 2012. W3C Working Draft. | ||||
URL: http://www.w3.org/TR/tracking-compliance/ | ||||
[WEBIDL] | [WEBIDL] | |||
Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate | Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate | |||
Recommendation. URL: http://www.w3.org/TR/WebIDL/ | Recommendation. URL: http://www.w3.org/TR/WebIDL/ | |||
B.2 Informative references | B.2 Informative references | |||
[KnowPrivacy] | [KnowPrivacy] | |||
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | |||
2009. URL: | 2009. URL: | |||
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | |||
End of changes. 105 change blocks. | ||||
415 lines changed or deleted | 315 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |