dnt-wd6.txt | dnt-20140402.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Preference Expression (DNT) | Tracking Preference Expression (DNT) | |||
W3C Working Draft 28 January 2014 | W3C Editor's Draft 02 April 2014 | |||
This version: | This version: | |||
http://www.w3.org/TR/2014/WD-tracking-dnt-20140128/ | 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-20130912/ | ||||
Editors: | Editors: | |||
Roy T. Fielding, Adobe | Roy T. Fielding, Adobe | |||
David Singer, Apple | David Singer, Apple | |||
Copyright (c) 2014 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights | Copyright (c) 2014 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 | |||
skipping to change at line 45 | skipping to change at line 42 | |||
honor a received preference through use of the Tk response header field | honor a received preference through use of the Tk response header field | |||
and well-known resources that provide a machine-readable tracking status. | and well-known resources that provide a machine-readable tracking status. | |||
Status of This Document | Status of This Document | |||
This section describes the status of this document at the time of its | This section describes the status of this document at the time of its | |||
publication. Other documents may supersede this document. A list of | publication. Other documents may supersede this document. A list of | |||
current W3C publications and the latest revision of this technical report | current W3C publications and the latest revision of this technical report | |||
can be found in the W3C technical reports index at http://www.w3.org/TR/. | can be found in the W3C technical reports index at http://www.w3.org/TR/. | |||
This document is a snapshot of ongoing discussions within the Tracking | This document is an editors' straw man 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 | tracking system is available for recording raised, open, pending review, | |||
or guaranteed direction for future versions of this document. | closed, and postponed issues regarding this document. | |||
Readers may review changes from the previous Working Draft; in particular, | ||||
recent changes have updated definitions of terms and indications of | ||||
compliance. An issue tracking system is available for recording raised, | ||||
open, pending review, closed, and postponed issues regarding this | ||||
document. | ||||
This document was published by the Tracking Protection Working Group as a | This document was published by the Tracking Protection Working Group as an | |||
Working Draft. This document is intended to become a W3C Recommendation. | Editor's Draft. If you wish to make comments regarding this document, | |||
If you wish to make comments regarding this document, please send them to | please send them to public-tracking@w3.org (subscribe, archives). All | |||
public-tracking-comments@w3.org (subscribe, archives). All comments are | comments are welcome. | |||
welcome. | ||||
Publication as a Working Draft does not imply endorsement by the W3C | 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 92 | skipping to change at line 82 | |||
* 1. Introduction | * 1. Introduction | |||
* 2. Notational Conventions | * 2. Notational Conventions | |||
* 2.1 Requirements | * 2.1 Requirements | |||
* 2.2 Formal Syntax | * 2.2 Formal Syntax | |||
* 2.3 Terminology | * 2.3 Terminology | |||
* 3. Determining User Preference | * 3. Determining User Preference | |||
* 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 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 Under Construction (!) | * 5.2.2 Under Construction (!) | |||
* 5.2.3 Dynamic (?) | * 5.2.3 Dynamic (?) | |||
* 5.2.4 Not Tracking (N) | * 5.2.4 Not Tracking (N) | |||
* 5.2.5 Tracking (T) | * 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) | |||
skipping to change at line 125 | skipping to change at line 114 | |||
* 5.4.4 Caching | * 5.4.4 Caching | |||
* 5.5 Tracking Status Representation | * 5.5 Tracking Status Representation | |||
* 5.5.1 Status Object | * 5.5.1 Status Object | |||
* 5.5.2 Tracking Property | * 5.5.2 Tracking Property | |||
* 5.5.3 Compliance Property | * 5.5.3 Compliance Property | |||
* 5.5.4 Qualifiers Property | * 5.5.4 Qualifiers Property | |||
* 5.5.5 Controller Property | * 5.5.5 Controller Property | |||
* 5.5.6 Same-party Property | * 5.5.6 Same-party Property | |||
* 5.5.7 Audit Property | * 5.5.7 Audit Property | |||
* 5.5.8 Policy Property | * 5.5.8 Policy Property | |||
* 5.5.9 Edit Property | * 5.5.9 Config Property | |||
* 5.5.10 Extensions | * 5.5.10 Extensions | |||
* 5.6 Status Code for Tracking Required | * 5.6 Status Code for Tracking Required | |||
* 5.7 Using the Tracking Status | * 5.7 Using the Tracking Status | |||
* 5.7.1 Discovering Deployment | * 5.7.1 Discovering Deployment | |||
* 5.7.2 Preflight Checks | * 5.7.2 Preflight Checks | |||
* 6. User-Granted Exceptions | * 6. User-Granted Exceptions | |||
* 6.1 Overview | * 6.1 Overview | |||
* 6.2 Motivating Principles and Use Cases | * 6.2 Motivating Principles and Use Cases | |||
* 6.3 Exception model | * 6.3 Exception model | |||
* 6.3.1 User Interaction | * 6.3.1 User Interaction | |||
skipping to change at line 182 | skipping to change at line 171 | |||
perspective, they are simply visiting and interacting with a single Web | perspective, they are simply visiting and interacting with a single Web | |||
property: all of the technical details and protocol mechanisms used to | property: all of the technical details and protocol mechanisms used to | |||
compose a page to represent that property are hidden behind the scenes. | compose a page to represent that property 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 often occurs | |||
both at the first-party site and via third-party providers through the | through the insertion of tracking elements on each page. A survey of these | |||
insertion of tracking elements on each page. A survey of these techniques | techniques and their privacy implications can be found in [KnowPrivacy]. | |||
and their privacy implications can be found in [KnowPrivacy]. | ||||
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, others are troubled by what they | |||
troubled by what they perceive as an invasion of their privacy. For them, | perceive as an invasion of their privacy. For them, the benefit of | |||
the benefit of personalization is not worth their concerns about allowing | personalization is not worth their concerns about allowing entities with | |||
entities with whom they have no direct relationship to amass profiles | whom they have no direct relationship to amass profiles about their | |||
about their activities. | 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 data collection need a mechanism to indicate that | content without such data collection need a mechanism to indicate that | |||
status to the user and allow them (or their user agent) to make an | status to the user and allow them (or their user agent) to make an | |||
individual choice regarding exceptions. | individual choice regarding exceptions. | |||
This specification defines protocol elements for use within the Hypertext | This specification defines protocol elements for use within the Hypertext | |||
Transfer Protocol [HTTP] which allow a user to express a tracking | Transfer Protocol [HTTP] which allow a user to express a tracking | |||
skipping to change at line 222 | skipping to change at line 210 | |||
user-granted exception. | 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]. | |||
Issue 136: Resolve dependencies of the TPE on the compliance specification | ||||
[OPEN] This draft removes all dependencies on TCS. | ||||
Issue 141: Do a review according to qaframe-spec | ||||
[POSTPONED] | ||||
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 | |||
A user is a natural person who is making, or has made, use of the Web. A | Tracking is the collection of data regarding a particular user's activity | |||
user action is a deliberate act by the user to invoke, command, or | across multiple distinct contexts and the retention, use, or sharing of | |||
manipulate a user agent to perform a network interaction, including the | data derived from that activity outside the context in which it occurred. | |||
intended consequences of that action. User activity is any set of such | A context is a set of resources that are controlled by the same party or | |||
user actions. | jointly controlled by a set of parties. | |||
A user is a natural person who is making, or has made, use of the Web. | ||||
A user agent is any of the various client programs capable of initiating | A user agent is any of the various client programs capable of initiating | |||
HTTP requests [HTTP], including (but not limited to) browsers, spiders | HTTP requests [HTTP], including (but not limited to) browsers, spiders | |||
(web-based robots), command-line tools, custom applications, and mobile | (web-based robots), command-line tools, custom applications, and mobile | |||
apps. | apps. | |||
Tracking is the collection of data regarding a particular user's activity | A network interaction is a single HTTP request and its corresponding | |||
across multiple distinct contexts and the retention, use, or sharing of | response(s): zero or more interim (1xx) responses and a single final | |||
data derived from that activity outside the context in which it occurred. | (2xx-5xx) response. | |||
Issue 240: Do we need to define context? | A user action is a deliberate action by the user, via configuration, | |||
invocation, or selection, to initiate a network interaction. Selection of | ||||
a link, submission of a form, and reloading a page are examples of user | ||||
actions. User activity is any set of such user actions. | ||||
[RAISED] The above definition depends on there being a definition of | A subrequest is any network interaction that is not directly initiated by | |||
context that bounds a scope of user activity, though it is not dependent | user action. For example, an initial response in a hypermedia format that | |||
on any particular definition of that term. For example, something along | contains embedded references to stylesheets, images, frame sources, and | |||
the lines of: For the purpose of this definition, a context is a set of | onload actions will cause a browser, depending on its capabilities and | |||
resources that share the same data controller, same privacy policy, and a | configuration, to perform a corresponding set of automated subrequests to | |||
common branding, such that a user would expect that data collected by one | fetch those references using additional network interactions. | |||
of those resources is available to all other resources within the same | ||||
context. | ||||
A party is a natural person, a legal entity, or a set of legal entities | A party is a natural person, a legal entity, or a set of legal entities | |||
that share common owner(s), common controller(s), and a group identity | that share common owner(s), common controller(s), and a group identity | |||
that is easily discoverable by a user. Common branding or providing a list | that is easily discoverable by a user. Common branding or providing a list | |||
of affiliates that is available via a link from a resource where a party | of affiliates that is available via a link from a resource where a party | |||
describes DNT practices are examples of ways to provide this | describes DNT practices are examples of ways to provide this | |||
discoverability. | discoverability. | |||
Within the context of a given user action, a first party is a party with | With respect to a given user action, a first party is a party with which | |||
which the user intends to interact, via one or more network interactions, | the user intends to interact, via one or more network interactions, as a | |||
as a result of making that action. Merely hovering over, muting, pausing, | result of making that action. Merely hovering over, muting, pausing, or | |||
or closing a given piece of content does not constitute a user's intent to | closing a given piece of content does not constitute a user's intent to | |||
interact with another party. | interact with another party. | |||
In some cases, a resource on the Web will be jointly controlled by two or | In some cases, a resource on the Web will be jointly controlled by two or | |||
more distinct parties. Each of those parties is considered a first party | more distinct parties. Each of those parties is considered a first party | |||
if a user would reasonably expect to communicate with all of them when | if a user would reasonably expect to communicate with all of them when | |||
accessing that resource. For example, prominent co-branding on the | accessing that resource. For example, prominent co-branding on the | |||
resource might lead a user to expect that multiple parties are responsible | resource might lead a user to expect that multiple parties are responsible | |||
for the content or functionality. | for the content or functionality. | |||
For any data collected as a result of one or more network interactions | For any data collected as a result of one or more network interactions | |||
skipping to change at line 298 | skipping to change at line 281 | |||
A party collects data received in a network interaction if that data | A party collects data received in a network interaction if that data | |||
remains within the party's control after the network interaction is | remains within the party's control after the network interaction is | |||
complete. | complete. | |||
A party uses data if the party processes the data for any purpose other | A party uses data if the party processes the data for any purpose other | |||
than storage or merely forwarding it to another party. | than storage or merely forwarding it to another party. | |||
A party shares data if it transfers or provides a copy of that data to any | A party shares data if it transfers or provides a copy of that data to any | |||
other party. | other party. | |||
A party facilitates any other party's collection of data if it enables | ||||
such party to collect data and engage in tracking. | ||||
A user-granted exception is a specific tracking preference, overriding a | A user-granted exception is a specific tracking preference, overriding a | |||
user's general tracking preference, that has been obtained and recorded | user's general tracking preference, that has been obtained and recorded | |||
using the mechanisms defined in section 6. User-Granted Exceptions. | using the mechanisms defined in section 6. User-Granted Exceptions. | |||
Issue 217: Terminology for user action, interaction, and network | ||||
interaction | ||||
[OPEN] Waiting on result from call for objections. | ||||
Issue 228: Revise the Network Interaction definition | ||||
[OPEN] Waiting on result from 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 recipients of that preference | |||
their behavior to meet the user's expectations or reach a separate | to adjust tracking behavior accordingly or to reach a separate agreement | |||
agreement with the user to satisfy all parties. | with the user that satisfies all parties. | |||
Key to that notion of expression is that the signal sent MUST reflect the | Key to that notion of expression is that the signal sent MUST reflect the | |||
user's preference, not the choice of some vendor, institution, site, or | user's preference, not the choice of some vendor, institution, site, or | |||
any network-imposed mechanism outside the user's control; this applies | network-imposed mechanism outside the user's control; this applies equally | |||
equally to both the general preference and exceptions. The basic principle | to both the general preference and exceptions. The basic principle is that | |||
is that a tracking preference expression is only transmitted when it | a tracking preference expression is only transmitted when it reflects a | |||
reflects a deliberate choice by the user. In the absence of user choice, | deliberate choice by the user. In the absence of user choice, there is no | |||
there is no tracking preference expressed. | tracking preference expressed. | |||
A user agent MUST offer users a minimum of two alternative choices for a | A user agent MUST offer users a minimum of two alternative choices for a | |||
Do Not Track preference: unset or DNT:1. A user agent MAY offer a third | Do Not Track preference: unset or DNT:1. A user agent MAY offer a third | |||
alternative choice: DNT:0. | alternative choice: DNT:0. | |||
If the user's choice is DNT:1 or DNT:0, the tracking preference is | If the user's choice is DNT:1 or DNT:0, the tracking preference is | |||
enabled; otherwise, the tracking preference is not enabled. | enabled; otherwise, the tracking preference is not enabled. | |||
A user agent MUST have a default tracking preference of unset (not | A user agent MUST have a default tracking preference of unset (not | |||
enabled) unless a specific tracking preference is implied by the decision | enabled) unless a specific tracking preference is implied by the user's | |||
to use that agent. For example, use of a general-purpose browser would not | decision to use that agent. For example, use of a general-purpose browser | |||
imply a tracking preference when invoked normally as SuperFred, but might | would not imply a tracking preference when invoked normally as SuperFred, | |||
imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred. | but might imply a preference if invoked as SuperDoNotTrack or | |||
Likewise, a user agent extension or add-on MUST NOT alter the tracking | UltraPrivacyFred. | |||
preference unless the act of installing and enabling that extension or | ||||
add-on is an explicit choice by the user for that tracking preference. | ||||
A user agent extension or add-on MUST NOT alter the user's tracking | Implementations of HTTP that are not under control of the user MUST NOT | |||
preference setting unless it complies with the requirements in this | add, delete, or modify a tracking preference. Some controlled network | |||
document, including but not limited to this section (Determining a User | environments, such as public access terminals or managed corporate | |||
Preference). Software outside of the user agent that causes a DNT header | intranets, might impose restrictions on the use or configuration of | |||
to be sent (or causes existing headers to be modified) MUST NOT do so | installed user agents, such that a user might only have access to user | |||
without ensuring that the requirements of this section are met; such | agents with a predetermined preference enabled. However, if a user brings | |||
software also MUST ensure the transmitted preference reflects the | their own Web-enabled device to a library or cafe with wireless Internet | |||
individual user's preference. | access, the expectation will be that their chosen user agent and personal | |||
preferences regarding Web site behavior will not be altered by the network | ||||
environment (aside from blanket limitations on what resources can or | ||||
cannot be accessed through that network). | ||||
We do not specify how tracking preference choices are offered to the user | An HTTP intermediary MUST NOT add, delete, or modify a tracking preference | |||
or how the preference is enabled: each implementation is responsible for | expression in a request forwarded through that intermediary unless the | |||
determining the user experience by which a tracking preference is enabled. | intermediary has been specifically installed or configured to do so by the | |||
For example, a user might select a check-box in their user agent's | user making the request. For example, an Internet Service Provider MUST | |||
configuration, install an extension or add-on that is specifically | NOT inject DNT:1 on behalf of all users who have not expressed a | |||
designed to add a tracking preference expression, or make a choice for | preference. | |||
privacy that then implicitly includes a tracking preference (e.g., Privacy | ||||
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 | ||||
protection feature. Likewise, a user might install or configure a proxy to | ||||
add the expression to their own outgoing requests. | ||||
Although some controlled network environments, such as public access | User agents often include user-installable extensions, also known as | |||
terminals or managed corporate intranets, might impose restrictions on the | add-ons or plug-ins, that are capable of modifying configurations and | |||
use or configuration of installed user agents, such that a user might only | making network requests. From the user's perspective, these extensions are | |||
have access to user agents with a predetermined preference enabled, the | considered part of the user agent and ought to respect the user's | |||
user is at least able to choose whether to make use of those user agents. | configuration of a tracking preference. However, there is no single | |||
In contrast, if a user brings their own Web-enabled device to a library or | standard for extension interfaces. A user agent that allows extensions to | |||
cafe with wireless Internet access, the expectation will be that their | directly make or modify HTTP requests MUST provide a corresponding API to | |||
chosen user agent and personal preferences regarding Web site behavior | those extensions for determining the user's tracking preference. | |||
will not be altered by the network environment, aside from blanket | ||||
limitations on what resources can or cannot be accessed through that | A user agent extension MUST NOT alter the tracking preference expression | |||
network. Implementations of HTTP that are not under control of the user | or its associated configuration unless the act of installing and enabling | |||
MUST NOT generate or modify a tracking preference. | that extension is an explicit choice by the user for that tracking | |||
preference, or the extension itself complies with all of the requirements | ||||
this protocol places on a user agent. | ||||
Likewise, software outside of the user agent might filter network traffic | ||||
or cause a user agent's configuration to be changed. Software that alters | ||||
a user agent configuration MUST adhere to the above requirements on a user | ||||
agent extension. Software that filters network traffic MUST adhere to the | ||||
above requirements on an HTTP intermediary. | ||||
Aside from the above requirements, we do not specify how the tracking | ||||
preference choices are offered to the user or how the preference is | ||||
enabled: each implementation is responsible for 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 | ||||
configuration, install an extension that is specifically designed to add a | ||||
tracking preference expression, or make a choice for privacy that then | ||||
implicitly includes a tracking preference (e.g., Privacy settings: high). | ||||
A user agent might ask the user for their preference 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 add the | ||||
expression to their own outgoing requests. | ||||
4. Expressing a Tracking Preference | 4. Expressing a Tracking Preference | |||
4.1 Expression Format | 4.1 Expression Format | |||
When a user has enabled a tracking preference, that preference needs to be | When a user has enabled a tracking preference, that preference needs to be | |||
expressed to all mechanisms that might perform or initiate tracking by | expressed to all mechanisms that might perform or initiate tracking. | |||
third parties, including sites that the user agent communicates with via | ||||
HTTP, scripts that can extend behavior on pages, and plug-ins or | ||||
extensions that might be installed and activated for various media types. | ||||
When enabled, a tracking preference is expressed as either: | When enabled, a tracking preference is expressed as either: | |||
DNT meaning | DNT meaning | |||
1 This user prefers not to be tracked on the target site. | 1 This user prefers not to be tracked on the target site. | |||
0 This user prefers to allow tracking on the target site. | 0 This user prefers to allow tracking on the target site. | |||
A user agent MUST NOT send a tracking preference expression if a tracking | A user agent MUST NOT send a tracking preference expression if a tracking | |||
preference is not enabled. This means that no expression is sent for each | preference is not enabled. This means that no expression is sent for each | |||
of the following cases: | of the following cases: | |||
skipping to change at line 415 | skipping to change at line 401 | |||
interpret the lack of an expressed tracking preference as they find most | interpret the lack of an expressed tracking preference as they find most | |||
appropriate for the given user, particularly when considered in light of | appropriate for the given user, particularly when considered in light of | |||
the user's privacy expectations and cultural circumstances. Likewise, | the user's privacy expectations and cultural circumstances. Likewise, | |||
servers might make use of other preference information outside the scope | servers might make use of other preference information outside the scope | |||
of this protocol, such as site-specific user preferences or third-party | of this protocol, such as site-specific user preferences or third-party | |||
registration services, to inform or adjust their behavior when no explicit | registration services, to inform or adjust their behavior when no explicit | |||
preference is expressed via this protocol. | preference is expressed via this protocol. | |||
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 a mechanism for expressing the user's tracking | |||
user's tracking preference via HTTP [HTTP]. | preference in an HTTP request [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 | ||||
; 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 NOT generate a DNT header field if the user's tracking | |||
only if) a tracking preference is enabled. A user agent MUST NOT send the | preference is not enabled. | |||
DNT header field if a tracking preference is not enabled. | ||||
The DNT field-value sent by a user agent MUST begin with the numeric | A user agent MUST generate a DNT header field with a field-value that | |||
character "1" (%x31) if a tracking preference is enabled, the preference | begins with the numeric character "1" (%x31) if the user's tracking | |||
is for no tracking, and there is not an exception for the origin server | preference is enabled, their preference is for DNT:1, and no exception has | |||
targeted by this request. | been granted for the request target (see section 6. User-Granted | |||
Exceptions). | ||||
The DNT field-value sent by a user agent MUST begin with the numeric | A user agent MUST generate a DNT header field with a field-value that | |||
character "0" (%x30) if a tracking preference is enabled and the | begins with the numeric character "0" (%x30) if the user's tracking | |||
preference is to allow tracking in general or by specific exception for | preference is enabled and their preference is for DNT:0, or if an | |||
the origin server targeted by this request. | exception has been granted for the request target. | |||
A proxy MUST NOT generate a DNT header field unless it has been | ||||
specifically installed or configured to do so by the user making the | ||||
request and adheres to the above requirements as if it were a user agent. | ||||
Example 1 | Example 1 | |||
GET /something/here HTTP/1.1 | GET /something/here HTTP/1.1 | |||
Host: example.com | Host: example.com | |||
DNT: 1 | DNT: 1 | |||
An HTTP intermediary MUST NOT add, delete, or modify the DNT header field | The remainder of the field-value, after the initial character, is reserved | |||
in requests forwarded through that intermediary unless that intermediary | for future extensions. DNT extensions can only be transmitted when a | |||
has been specifically installed or configured to do so by the user making | tracking preference is enabled. | |||
the requests. For example, an Internet Service Provider MUST NOT inject | ||||
DNT: 1 on behalf of all of their users who have not expressed a | ||||
preference. | ||||
The remainder of the DNT field-value after the initial character is | ||||
reserved for future extensions. User agents that do not implement such | ||||
extensions MUST NOT send DNT-extension characters in the DNT field-value. | ||||
Servers that do not implement such extensions SHOULD ignore anything | ||||
beyond the first character. | ||||
DNT extensions are to be interpreted as modifiers to the main preference | ||||
expressed by the first digit, such that the main preference will be obeyed | ||||
if the recipient does not understand the extension. Hence, a | ||||
DNT-field-value of "1xyz" can be thought of as do not track, but if you | ||||
understand the refinements defined by x, y, or z, then adjust my | ||||
preferences according to those refinements. DNT extensions can only be | ||||
transmitted when a tracking preference is enabled. | ||||
The extension syntax is restricted to visible ASCII characters that can be | DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
parsed as a single word in HTTP and safely embedded in a JSON string | ; excludes CTL, SP, DQUOTE, comma, backslash | |||
without further encoding (section 5.5 Tracking Status Representation). | ||||
Since the DNT header field is intended to be sent on every request, when | ||||
enabled, designers of future extensions ought to use as few extension | ||||
characters as possible. | ||||
Note | For example, additional characters might indicate modifiers to the main | |||
preference expressed by the first digit, such that the main preference | ||||
will be understood if the recipient does not understand the extension. | ||||
Hence, a field-value of "1xyz" can be thought of as do not track, but if | ||||
you understand the refinements defined by x, y, or z, then adjust my | ||||
preferences according to those refinements. | ||||
This document does not have any implied or specified behavior for the user | User agents that do not implement DNT extensions MUST NOT send | |||
agent treatment of cookies when DNT is enabled. | DNT-extension characters in the DNT field-value. Servers that do not | |||
implement DNT extensions SHOULD ignore anything beyond the first | ||||
character. | ||||
Note | Note | |||
At most one DNT header can be present in a valid HTTP request [HTTP]. | 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 | ||||
Issue 153: What are the implications on software that changes requests but | without further encoding (section 5.5 Tracking Status Representation). At | |||
does not necessarily initiate them? | most one DNT header field can be present in a valid request [HTTP]. | |||
[PENDING REVIEW] | ||||
4.3 JavaScript Property to Detect Preference | 4.3 JavaScript Property to Detect Preference | |||
This property enables a site executing code in its own origin to determine | The doNotTrack property enables a client-side script with read access to | |||
what DNT header would be sent to it in the current context, taking into | the Window object to determine what DNT header field value would be sent | |||
account the user's general preference (if any) and any user-granted | in requests to the document-origin, taking into account the user's general | |||
exceptions. | preference (if any) and any user-granted exceptions applicable to that | |||
origin server. | ||||
partial interface Window { | partial interface Window { | |||
readonly attribute DOMString doNotTrack; | readonly attribute DOMString doNotTrack; | |||
}; | }; | |||
doNotTrack of type DOMString, readonly | doNotTrack of type DOMString, readonly | |||
Returns the same string value that would be sent in a | Returns the same string value that would be sent in a | |||
DNT-field-value (section 4.2 DNT Header Field for HTTP Requests) | DNT-field-value (section 4.2 DNT Header Field for HTTP Requests) | |||
to a target that is the document-origin of the window, in the | to a target that is the document-origin of the window, in the | |||
context of the current top-level origin. The value is null if no | browser context of the current top-level origin. The value is null | |||
DNT header field would be sent (e.g., because a tracking | if no DNT header field would be sent (e.g., because a tracking | |||
preference is not enabled). | preference is not enabled). | |||
4.4 Plug-In APIs | 4.4 Tracking Preference Expressed in Other Protocols | |||
User agents often include user-installable component parts, commonly known | ||||
as plug-ins or browser extensions, that are capable of making their own | ||||
network requests. From the user's perspective, these components are | ||||
considered part of the user agent and thus ought to respect the user's | ||||
configuration of a tracking preference. However, plug-ins do not normally | ||||
have read access to the browser configuration. | ||||
Note | ||||
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 | ||||
here. No plug-in APIs have been proposed yet. | ||||
4.5 Tracking Preference Expressed in Other Protocols | ||||
It is beyond the scope of this specification to define how a user's | A user's tracking preference is intended to apply in general, regardless | |||
tracking preference might be communicated via protocols other than HTTP. | of the protocols being used for Internet communication. However, it is | |||
However, the semantics of a user's tracking preference is intended to | beyond the scope of this specification to define how a user's tracking | |||
apply in general, regardless of the protocols being used for Internet | preference might be communicated via protocols other than HTTP. | |||
communication. | ||||
5. Communicating a Tracking Status | 5. Communicating a Tracking Status | |||
5.1 Overview | 5.1 Overview | |||
This protocol has the dual goals of expressing the user's preference | In addition to expressing the user's preference regarding tracking, this | |||
regarding tracking and providing transparency by communicating | protocol enables servers to communicate machine-readable claims regarding | |||
machine-readable claims that a server might wish to make regarding its own | their own tracking behavior. Since a personalized tracking status on every | |||
tracking behavior. However, providing a dynamic tracking status on every | response would disable caching, a combination of response mechanisms are | |||
response would effectively disable caching for the entire Web. Instead, | defined to allow the tracking status to be communicated prior to making a | |||
this protocol defines a combination of response mechanisms that allow this | trackable request and without making every response dynamic. | |||
information to be communicated without making every response dynamic. | ||||
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 resource at a specific well-known location and an OPTIONAL | ||||
space of request-specific tracking status resources for sites where the | ||||
tracking status might vary based on data within the request. It also | ||||
defines a Tk response header field that MAY be sent in any response, MUST | ||||
be sent in responses to requests that modify the tracking status, and MAY | ||||
direct the user to a request-specific tracking status resource applicable | ||||
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 the | A tracking status value (TSV) is a single character response to the user's | |||
tracking behavior regarding data collected via a designated resource. | tracking preference with regard to data collected via the designated | |||
resource. For a site-wide tracking status resource, the designated | ||||
For a site-wide tracking status resource, the designated resource is any | resource is any resource on the same origin server. For a Tk response | |||
resource on the same origin server. For a Tk response header field, the | header field, the target resource of the corresponding request is the | |||
target resource of the corresponding request is the designated resource, | designated resource, and remains so for any subsequent request-specific | |||
and remains so for any subsequent request-specific tracking status | tracking status resource referred to by the Tk field value. | |||
resource referred to by the Tk field value. | ||||
The tracking status value is case sensitive, as defined formally by the | The tracking status value is case sensitive, as defined formally by the | |||
following ABNF. | following ABNF. | |||
TSV = %x21 ; "!" - under construction | TSV = %x21 ; "!" - under construction | |||
/ %x3F ; "?" - dynamic | / %x3F ; "?" - dynamic | |||
/ %x4E ; "N" - not tracking | / %x4E ; "N" - not tracking | |||
/ %x54 ; "T" - tracking | / %x54 ; "T" - tracking | |||
/ %x43 ; "C" - tracking with consent | / %x43 ; "C" - tracking with consent | |||
/ %x50 ; "P" - tracking only if consented | / %x50 ; "P" - tracking only if consented | |||
/ %x44 ; "D" - disregarding DNT | / %x44 ; "D" - disregarding DNT | |||
/ %x55 ; "U" - updated | / %x55 ; "U" - updated | |||
Issue 241: Distinguish elements for site-internal use and elements that | ||||
can be re-used by others (1/3) | ||||
[OPEN] 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. | ||||
5.2.2 Under Construction (!) | 5.2.2 Under Construction (!) | |||
A tracking status value of ! means that the origin server is currently | A tracking status value of ! means that the origin server is currently | |||
testing its communication of tracking status. The ! value has been | testing its communication of tracking status. The ! value has been | |||
provided to ease testing and deployment on production systems during the | provided to ease testing and deployment on production systems during the | |||
initial periods of testing compliance and during adjustment periods due to | initial periods of testing compliance and during adjustment periods due to | |||
future protocol changes or shifting regulatory constraints. Note that this | future protocol changes or shifting regulatory constraints. Note that this | |||
value does necessarily indicate that the DNT signal will be ignored, nor | value does not indicate that the user's preference will be ignored, nor | |||
that tracking will occur as a result of accessing the designated resource. | that tracking will occur as a result of accessing the designated resource. | |||
5.2.3 Dynamic (?) | 5.2.3 Dynamic (?) | |||
A tracking status value of ? means the origin server needs more | A tracking status value of ? means the origin server needs more | |||
information to determine tracking status, usually because the designated | information to determine tracking status, usually because the designated | |||
resource dynamically adjusts behavior based on information in a request. | resource dynamically adjusts behavior based on information in a request. | |||
If ? is present in the site-wide tracking status, more information MUST be | If ? is present in the site-wide tracking status, the origin server MUST | |||
provided via the Tk response header field when accessing a designated | send a Tk header field in all responses to requests on the designated | |||
resource. If ? is present in the Tk header field, more information will be | resource. If ? is present in the Tk header field, more information will be | |||
provided in a request-specific tracking status resource referred to by the | provided in a request-specific tracking status resource referred to by the | |||
status-id. An origin server MUST NOT send ? as the tracking status value | status-id. An origin server MUST NOT send ? as the tracking status value | |||
in the representation of a request-specific tracking status resource. | in the representation of a request-specific tracking status resource. | |||
5.2.4 Not Tracking (N) | 5.2.4 Not Tracking (N) | |||
A tracking status value of N means the origin server claims that data | A tracking status value of N means the origin server claims that data | |||
collected via the designated resource is not used for tracking and will | collected via the designated resource is not used for tracking and will | |||
not be combined with other data in a form that would enable tracking. | not be combined with other data in a form that would enable tracking. | |||
skipping to change at line 625 | skipping to change at line 562 | |||
Information provided in the tracking status representation might indicate | Information provided in the tracking status representation might indicate | |||
whether such tracking is limited to a set of commonly accepted uses or | whether such tracking is limited to a set of commonly accepted uses or | |||
adheres to one or more compliance regimes. | adheres to one or more compliance regimes. | |||
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. An origin server that sends this tracking status value for a | protocol. An origin server that sends the C tracking status value for a | |||
designated resource MUST provide a reference for controlling consent | designated resource MUST provide a reference for controlling consent | |||
within the edit property of its corresponding tracking status | within the config property of its corresponding tracking status | |||
representation (section 5.5 Tracking Status Representation). | representation (section 5.5 Tracking Status Representation). | |||
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 | |||
data until such consent has been determined, and further promises to | data until such consent has been determined, and further promises to | |||
delete or de-identify within forty-eight hours any DNT:1 data received for | delete or de-identify within forty-eight hours any DNT:1 data received for | |||
which such consent has not been received. | which such consent has not been received. | |||
Since this status value does not itself indicate whether a specific | Since this status value does not itself indicate whether a specific | |||
request is tracked, an origin server that sends a P tracking status value | request is tracked, an origin server that sends a P tracking status value | |||
MUST provide an edit property in the corresponding tracking status | MUST provide a config property in the corresponding tracking status | |||
representation that links to a resource for obtaining consent status. | representation that links to a resource for obtaining consent status. | |||
The P tracking status value is specifically meant to address audience | The P tracking status value is specifically meant to address audience | |||
survey systems for which determining consent at the time of a request is | survey systems for which determining consent at the time of a request is | |||
either impractical, due to legacy systems not being able to keep up with | either impractical, due to legacy systems not being able to keep up with | |||
Web traffic, or potentially "gamed" by first party sites if they can | Web traffic, or potentially "gamed" by first party sites if they can | |||
determine which of their users have consented. The data cannot be used for | determine which of their users have consented. The data cannot be used for | |||
the sake of personalization. If consent can be determined at the time of a | the sake of personalization. If consent can be determined at the time of a | |||
request, the C tracking status is preferred. | request, the C tracking status is preferred. | |||
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 the D tracking status value MUST | |||
detail within the server's corresponding privacy policy the conditions | detail within the server's corresponding privacy policy the conditions | |||
under which a tracking preference might be disregarded. | under which a tracking preference might be disregarded. | |||
For example, an origin server might disregard the DNT field received from | For example, an origin server might disregard the DNT field received from | |||
specific user agents (or via specific network intermediaries) that are | specific user agents (or via specific network intermediaries) that are | |||
deemed to be non-conforming, might be collecting additional data from | deemed to be non-conforming, might be collecting additional data from | |||
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 is meant to be used only in | Note | |||
situations that can be adequately described to users as an exception to | ||||
normal behavior. An origin server that responds with D in ways that are | ||||
inconsistent with their other published and unexpired claims regarding | ||||
tracking is likely to be considered misleading. | ||||
Issue 197: How do we notify the user why a Disregard signal is received? | ||||
[OPEN] | This specification is written with an assumption that the D tracking | |||
status value would only be used in situations that can be adequately | ||||
described to users as an exception to normal behavior. If this turns out | ||||
not to be the case, either the server's decision to send the D signal | ||||
needs re-examination, or this specification, or both. | ||||
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 | |||
skipping to change at line 737 | skipping to change at line 672 | |||
Example 3 | Example 3 | |||
Tk: T;fRx42 | Tk: T;fRx42 | |||
indicates that data collected via the target resource might be used for | indicates that data collected via the target resource might be used for | |||
tracking and that an applicable tracking status representation can be | tracking and that an applicable tracking status representation can be | |||
obtained by performing a retrieval request on | obtained by performing a retrieval request on | |||
/.well-known/dnt/fRx42 | /.well-known/dnt/fRx42 | |||
If a Tk field-value has a tracking status value of ? (dynamic), then a | If a Tk field-value has a tracking status value of ? (dynamic), then the | |||
status-id MUST be included in the field-value. The status-id is | origin server MUST also send a status-id in the field-value. The status-id | |||
case-sensitive. | is 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 | Interactive mechanisms might be used, beyond the scope of this | |||
of this specification, that have the effect of asking for and obtaining | specification, that have the effect of asking for and obtaining prior | |||
prior consent for tracking, or for modifying prior indications of consent. | consent for tracking, or for modifying prior indications of consent. For | |||
For example, the tracking status resource's status-object defines an edit | example, the tracking status resource's status-object defines a config | |||
property that can refer to such a mechanism. Although such out-of-band | property that can refer to such a mechanism. Although such out-of-band | |||
mechanisms are not defined by this specification, their presence might | mechanisms are not defined by this specification, their presence might | |||
influence the tracking status object's response value. | influence the tracking status object's response value. | |||
When an origin server provides a mechanism via HTTP for establishing or | When an origin server provides a mechanism via HTTP for establishing or | |||
modifying out-of-band tracking preferences, the origin server MUST | modifying out-of-band tracking preferences, the origin server MUST | |||
indicate within the mechanism's response when a state-changing request has | indicate within the mechanism's response when a state-changing request has | |||
resulted in a change to the tracking status for that server. This | resulted in a change to the tracking status for that server. This | |||
indication of an interactive status change is accomplished by sending a Tk | indication of an interactive status change is accomplished by sending a Tk | |||
header field in the response with a tracking status value of U (updated). | header field in the response with a tracking status value of U (updated). | |||
Example 4 | Example 4 | |||
Tk: U | Tk: U | |||
5.4 Tracking Status Resource | 5.4 Tracking Status Resource | |||
5.4.1 Site-wide Tracking Status | 5.4.1 Site-wide Tracking Status | |||
An origin server MUST provide a site-wide tracking status resource at the | A site-wide tracking status resource provides information about the | |||
well-known identifier [RFC5785] | potential tracking behavior of resources located at that origin server. A | |||
site-wide tracking status resource has the well-known identifier | ||||
/.well-known/dnt/ | /.well-known/dnt/ | |||
(relative to the URI of that origin server) for obtaining information | relative to the origin server's URI [RFC5785]. | |||
about the potential tracking behavior of resources provided by that origin | ||||
server. A tracking status resource can be used for verification of DNT | ||||
support, as described in section 5.7 Using the Tracking Status. | ||||
A valid retrieval request (e.g., a GET in HTTP) on the well-known URI MUST | An origin server that receives a valid GET request targeting its site-wide | |||
result in either a successful response containing a machine-readable | tracking status resource MUST send either a successful response containing | |||
representation of the site-wide tracking status, as defined below, or a | a machine-readable representation of the site-wide tracking status, as | |||
sequence of redirects that leads to such a representation. A user agent | defined below, or a sequence of redirects that leads to such a | |||
MAY consider failure to provide access to such a representation equivalent | representation. Failure to provide access to such a representation implies | |||
to the origin server not implementing this protocol. The representation | that the target origin server does not implement this protocol. The | |||
can be cached, as described in section 5.4.4 Caching. | representation can be cached, as described in section 5.4.4 Caching. | |||
See section 5.7 Using the Tracking Status for examples of how tracking | ||||
status resources can be used to discover support for this protocol. | ||||
5.4.2 Request-specific Tracking Status | 5.4.2 Request-specific Tracking Status | |||
If an origin server has multiple, request-specific tracking policies, such | If an origin server has multiple, request-specific tracking policies, such | |||
that the tracking status might differ depending on some aspect of the | that the tracking status might differ depending on some aspect of the | |||
request (e.g., method, target URI, header fields, data, etc.), the origin | request (e.g., method, target URI, header fields, data, etc.), the origin | |||
server MAY provide an additional subtree of well-known resources | server MAY provide an additional subtree of well-known resources | |||
corresponding to each of those distinct tracking statuses. The Tk response | corresponding to each of those distinct tracking statuses. The Tk response | |||
header field (section 5.3 Tk Header Field for HTTP Responses) can include | header field (section 5.3 Tk Header Field for HTTP Responses) can include | |||
a status-id to indicate which specific tracking status resource applies to | a status-id to indicate which specific tracking status resource applies to | |||
the current request. | the current request. | |||
The tracking status resource space is defined by the following URI | A tracking status resource space is defined by the following URI Template | |||
Template [URI-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: ?;ahoy | Tk: ?;ahoy | |||
skipping to change at line 824 | skipping to change at line 760 | |||
5.4.3 Status Checks are Not Tracked | 5.4.3 Status Checks are Not Tracked | |||
When sending a request for the tracking status, a user agent SHOULD | When sending a request for the tracking status, a user agent SHOULD | |||
include any cookie data [COOKIES] (set prior to the request) that would be | include any cookie data [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 | An origin server MUST NOT retain tracking data regarding requests on the | |||
site-wide tracking status resource, MUST NOT be tracked, irrespective of | site-wide tracking status resource or within the tracking status resource | |||
the presence, value, or absence of a DNT header field, cookies, or any | space, regardless of the presence, absence, or value of a DNT header | |||
other information in the request. In addition, all responses to those | field, cookies, or any other information in the request. In addition, an | |||
requests, including the responses to redirected tracking status requests, | origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in | |||
MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have | responses to those requests, including the responses to redirected | |||
content that initiates tracking beyond what was already present in the | tracking status requests, and MUST NOT send a response having content that | |||
request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie | initiates tracking beyond what was already present in the request. A user | |||
or Set-Cookie2 header field received in such a response. | agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 | |||
header field received in such a response. | ||||
5.4.4 Caching | 5.4.4 Caching | |||
If the tracking status is applicable to all users, regardless of the | If the tracking status is applicable to all users, regardless of the | |||
received DNT-field-value or other data received via the request, then the | received DNT-field-value or other data received via the request, then the | |||
origin server SHOULD mark the response as cacheable [HTTP-cache] and | origin server SHOULD mark the response as cacheable [HTTP-cache] and | |||
assign a time-to-live (expiration or max-use) that is sufficient to enable | assign a time-to-live (expiration or max-use) that is sufficient to enable | |||
shared caching but not greater than the earliest point at which the | shared caching but not greater than the earliest point at which the | |||
service's tracking behavior might increase. | service's tracking behavior might increase. | |||
For example, if the tracking status response is set to expire in seven | For example, if the tracking status response is set to expire in seven | |||
days, then the earliest point in time that the service's tracking behavior | days, then the earliest point in time that the service's tracking behavior | |||
can be increased is seven days after the tracking status representation | can be increased is seven days after the tracking status representation | |||
has been updated to reflect the new behavior, since old copies might | has been updated to reflect the new behavior, since old copies might | |||
persist in caches until the expiration is triggered. A service's tracking | persist in caches until the expiration is triggered. A service's tracking | |||
behavior can be reduced at any time, with or without a corresponding | behavior can be reduced at any time, with or without a corresponding | |||
change to the tracking status resource. | change to the tracking status resource. | |||
If the tracking status is only applicable to all users that have the same | If the tracking status is only applicable to users that have the same | |||
DNT-field-value, then the response MUST either be marked with a Vary | DNT-field-value, the origin server MUST send a Vary header field that | |||
header field that includes "DNT" in its field-value or marked as not | includes "DNT" in its field-value or a Cache-Control header field | |||
reusable by a shared cache without revalidation with a Cache-Control | containing one of the following directives: "private", "no-cache", | |||
header field containing one of the following directives: "private", | "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 origin server MUST send a Cache-Control header | |||
containing one of the following directives: "private", "no-cache", or | field containing one of the following directives: "private", "no-cache", | |||
"no-store". | or "no-store". | |||
Regardless of the cache-control settings, it is expected that user agents | Regardless of the cache-control settings, it is expected that user agents | |||
will check the tracking status of a service only once per session (at | will check the tracking status of a service only once per session (at | |||
most). A public Internet site that intends to change its tracking status | most). A public Internet site that intends to change its tracking status | |||
to increase tracking behavior MUST update the tracking status resource in | to increase tracking behavior MUST update the tracking status resource in | |||
accordance with that planned behavior at least twenty-four hours prior to | accordance with that planned behavior at least twenty-four hours prior to | |||
activating that new behavior on the service. | activating that new behavior on the service. | |||
A user agent that adjusts behavior based on active verification of | A user agent that adjusts behavior based on active verification of | |||
tracking status, relying on cached tracking status responses to do so, | tracking status, relying on cached tracking status responses to do so, | |||
SHOULD check responses to its state-changing requests (e.g., POST, PUT, | SHOULD check responses to its state-changing requests (e.g., POST, PUT, | |||
DELETE, etc.) for a Tk header field with the U tracking status value, as | DELETE, etc.) for a Tk header field with the U tracking status value, as | |||
described in section 5.3.3 Indicating an Interactive Status Change. | described in section 5.3.3 Indicating an Interactive Status Change. | |||
5.5 Tracking Status Representation | 5.5 Tracking Status Representation | |||
An origin server MUST provide a representation of each tracking status | An origin server MUST provide a representation of each tracking status | |||
resource in a JSON format [RFC4627] that conforms to the ABNF for | resource in a JSON format [RFC7159] that conforms to the ABNF for | |||
status-object (except that the properties within a property-list MAY be | status-object (except that the properties within a property-list MAY be | |||
provided in any order). | provided in any order). | |||
5.5.1 Status Object | 5.5.1 Status Object | |||
A tracking status representation consists of a single status-object | A tracking status representation consists of a single status-object | |||
containing properties that describe the tracking status applicable to the | containing properties that describe the tracking status applicable to the | |||
designated resource. | designated resource. | |||
status-object = begin-object property-list end-object | status-object = begin-object property-list end-object | |||
property-list = tracking-p ns tracking-v | property-list = tracking-p ns tracking-v | |||
[ vs compliance ns compliance-v ] | [ vs compliance ns compliance-v ] | |||
[ vs qualifiers ns qualifiers-v ] | [ vs qualifiers ns qualifiers-v ] | |||
[ vs controller ns controller-v ] | [ vs controller ns controller-v ] | |||
[ vs same-party ns same-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 config ns config-v ] | |||
*( vs extension ) | *( vs extension ) | |||
The following example tracking status representation illustrates a status | The following example tracking status representation illustrates a status | |||
object with all of the properties defined by this specification, most of | object with all of the properties defined by this specification, most of | |||
which are optional. | which are optional. | |||
Example 6 | Example 6 | |||
{ | { | |||
"tracking": "T", | "tracking": "T", | |||
skipping to change at line 921 | skipping to change at line 857 | |||
"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" | |||
], | ], | |||
"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" | "config": "http://example.com/your/data" | |||
} | } | |||
5.5.2 Tracking Property | 5.5.2 Tracking Property | |||
A status-object always has a property named tracking with a string value | A status-object always has a property named tracking with a string value | |||
containing the tracking status value (section 5.2 Tracking Status Value) | containing the tracking status value (section 5.2 Tracking Status Value) | |||
applicable to the designated resource. | applicable to the designated resource. | |||
tracking-p = %x22 "tracking" %x22 | tracking-p = %x22 "tracking" %x22 | |||
tracking-v = %x22 TSV %x22 | tracking-v = %x22 TSV %x22 | |||
skipping to change at line 954 | skipping to change at line 890 | |||
containing a list of URI references that identify specific regimes to | containing a list of URI references that identify specific regimes to | |||
which the origin server claims to comply for the designated resource. | which the origin server claims to comply for the designated resource. | |||
Communicating such a claim of compliance is presumed to improve | Communicating such a claim of compliance is presumed to improve | |||
transparency, which might influence a user's decisions or configurations | transparency, which might influence a user's decisions or configurations | |||
regarding allowed tracking, but does not have any direct impact on this | regarding allowed tracking, but does not have any direct impact on this | |||
protocol. | protocol. | |||
compliance = %x22 "compliance" %x22 | compliance = %x22 "compliance" %x22 | |||
compliance-v = array-of-refs | compliance-v = array-of-refs | |||
Issue 239: Should tracking status representation include an array of links | ||||
for claiming compliance by reference? | ||||
[RAISED] Text above is proposed resolution. | ||||
Issue 242: URL Management for compliance regime URLs | ||||
[POSTPONED] | ||||
5.5.4 Qualifiers Property | 5.5.4 Qualifiers Property | |||
An origin server MAY send a property named qualifiers with a string value | An origin server MAY send a property named qualifiers with a string value | |||
containing a sequence of case sensitive characters corresponding to | containing a sequence of case sensitive characters corresponding to | |||
explanations or limitations on the extent of tracking. Multiple qualifiers | explanations or limitations on the extent of tracking. Multiple qualifiers | |||
indicate that multiple explanations or forms of tracking might apply for | indicate that multiple explanations or forms of tracking might apply for | |||
the designated resource. The meaning of each qualifier is presumed to be | the designated resource. The meaning of each qualifier is presumed to be | |||
defined by one or more of the regimes listed in compliance. | defined by one or more of the regimes listed in compliance. | |||
qualifiers = %x22 "qualifiers" %x22 | qualifiers = %x22 "qualifiers" %x22 | |||
skipping to change at line 988 | skipping to change at line 915 | |||
An origin server MAY send a property named controller with an array value | An origin server MAY send a property named controller with an array value | |||
containing a list of URI references indirectly identifying the party or | containing a list of URI references indirectly identifying the party or | |||
set of parties that claims to be the responsible data controller for | set of parties that claims to be the responsible data controller for | |||
personal data collected via the designated resource. An origin server MUST | personal data collected via the designated resource. An origin server MUST | |||
send a controller property if the responsible data controller does not own | send a controller property if the responsible data controller does not own | |||
the designated resource's domain name. | the designated resource's domain name. | |||
An origin server that does not send controller is implying that its domain | An origin server that does not send controller is implying that its domain | |||
owner is the sole data controller; information about the data controller | owner is the sole data controller; information about the data controller | |||
ought to be found on the designated resource's site root page, or by way | ought to be found on the designated resource's site root page, or by way | |||
of a clearly indicated link from that page (i.e., no controller property | of a clearly indicated link from that page (i.e., an absent controller | |||
is considered equivalent to: "controller":["/"]). | property is equivalent to: "controller":["/"]). | |||
If the designated resource has joint data controllers (i.e., multiple | If the designated resource has joint data controllers (i.e., multiple | |||
parties have independent control over the collected data), the origin | parties have independent control over the collected data), the origin | |||
server MUST send a controller property that contains a reference for each | server MUST send a controller property that contains a reference for each | |||
data controller. | data controller. | |||
Each URI reference provided in controller MUST refer to a resource that, | Each URI reference provided in controller ought to refer to a resource | |||
if a retrieval action is performed on that URI, would provide the user | that, if a retrieval action is performed on that URI, would provide the | |||
with information regarding (at a minimum) the identity of the | user with information regarding (at a minimum) the identity of the | |||
corresponding party and its data collection practices. | corresponding party and its data collection practices. | |||
controller = %x22 "controller" %x22 | controller = %x22 "controller" %x22 | |||
controller-v = array-of-refs | controller-v = array-of-refs | |||
5.5.6 Same-party Property | 5.5.6 Same-party Property | |||
Since a user's experience on a given site might be composed of resources | Since a user's experience on a given site might be composed of resources | |||
that are assembled from multiple domains, it might be useful for a site to | that are assembled from multiple domains, it might be useful for a site to | |||
distinguish those domains that are subject to their own control (i.e., | distinguish those domains that are subject to their own control (i.e., | |||
skipping to change at line 1051 | skipping to change at line 978 | |||
containing a URI reference to a human-readable document that describes the | containing a URI reference to a human-readable document that describes the | |||
relevant privacy policy for the designated resource. The content of such a | relevant privacy policy for the designated resource. The content of such a | |||
policy document is beyond the scope of this protocol and only supplemental | policy document is beyond the scope of this protocol and only supplemental | |||
to what is described in the machine-readable tracking status | to what is described in the machine-readable tracking status | |||
representation. If no policy property is provided, this information might | representation. If no policy property is provided, this information might | |||
be obtained via the links provided in controller. | be obtained via the links provided in controller. | |||
policy = %x22 "policy" %x22 | policy = %x22 "policy" %x22 | |||
policy-v = string ; URI-reference | policy-v = string ; URI-reference | |||
5.5.9 Edit Property | 5.5.9 Config Property | |||
An origin server MAY send a property named edit with a string value | An origin server MAY send a property named config with a string value | |||
containing a URI reference to a resource for giving the user control over | containing a URI reference to a resource for giving the user control over | |||
personal data collected via the designated resource (and possibly other | personal data collected via the designated resource (and possibly other | |||
resources). If the tracking status value indicates prior consent (C), the | resources). If the tracking status value indicates prior consent (C), the | |||
origin server MUST send an edit property referencing a resource that | origin server MUST send a config property referencing a resource that | |||
describes how such consent is established and how to revoke that consent. | describes how such consent is established and how to revoke that consent. | |||
An edit resource might include the ability to review past data collected, | A config resource might include the ability to review past data collected, | |||
delete some or all of the data, provide additional data (if desired), or | delete some or all of the data, provide additional data (if desired), or | |||
opt-in, opt-out, or otherwise modify an out-of-band consent status | opt-in, opt-out, or otherwise modify an out-of-band consent status | |||
regarding data collection. The design of such a resource, the extent to | regarding data collection. The design of such a resource, the extent to | |||
which it can provide access to that data, and how one might implement an | which it can provide access to that data, and how one might implement an | |||
out-of-band consent mechanism are beyond the scope of this protocol. | out-of-band consent mechanism are beyond the scope of this protocol. | |||
If no edit property is provided, this information might be obtained via | If no config property is provided, this information might be obtained via | |||
the links provided in controller or policy. | the links provided in controller or policy. | |||
edit = %x22 "edit" %x22 | config = %x22 "config" %x22 | |||
edit-v = string ; URI-reference | config-v = string ; URI-reference | |||
5.5.10 Extensions | 5.5.10 Extensions | |||
An origin server MAY send additional extension properties in the | An origin server MAY send additional extension properties in the | |||
status-object to support future enhancements to this protocol. A recipient | status-object to support future enhancements to this protocol. A recipient | |||
MUST ignore extension properties that it does not recognize. | MUST ignore extension properties that it does not recognize. | |||
extension = object | extension = object | |||
array-of-refs = begin-array [ string *( vs string ) ] end-array | array-of-refs = begin-array [ string *( vs string ) ] end-array | |||
ns = <name-separator (:), as defined in [[!RFC4627]]> | ns = <name-separator (:), as defined in [[!RFC7159]]> | |||
vs = <value-separator (,), as defined in [[!RFC4627]]> | vs = <value-separator (,), as defined in [[!RFC7159]]> | |||
begin-array = <begin-array ([), as defined in [[!RFC4627]]> | begin-array = <begin-array ([), as defined in [[!RFC7159]]> | |||
end-array = <end-array (]), as defined in [[!RFC4627]]> | end-array = <end-array (]), as defined in [[!RFC7159]]> | |||
begin-object = <begin-object ({), as defined in [[!RFC4627]]> | begin-object = <begin-object ({), as defined in [[!RFC7159]]> | |||
end-object = <end-object (}), as defined in [[!RFC4627]]> | end-object = <end-object (}), as defined in [[!RFC7159]]> | |||
object = <object, as defined in [[!RFC4627]]> | object = <object, as defined in [[!RFC7159]]> | |||
string = <string, as defined in [[!RFC4627]]> | string = <string, as defined in [[!RFC7159]]> | |||
true = <true, as defined in [[!RFC4627]]> | true = <true, as defined in [[!RFC7159]]> | |||
false = <false, as defined in [[!RFC4627]]> | false = <false, as defined in [[!RFC7159]]> | |||
null = <null, as defined in [[!RFC4627]]> | null = <null, as defined in [[!RFC7159]]> | |||
5.6 Status Code for Tracking Required | 5.6 Status Code for Tracking Required | |||
If an origin server receives a request with DNT:1, does not have | If an origin server receives a request with DNT:1, does not have | |||
out-of-band consent for tracking this user, and wishes to deny access to | out-of-band consent for tracking this user, and wishes to deny access to | |||
the requested resource until the user provides some form of user-granted | the requested resource until the user provides some form of user-granted | |||
exception or consent for tracking, then the origin server SHOULD send a | exception or consent for tracking, then the origin server SHOULD send a | |||
409 (Conflict) response with a message payload that describes why the | 409 (Conflict) response with a message payload that describes why the | |||
request has been refused and how one might supply the required consent or | request has been refused and how one might supply the required consent or | |||
exception to avoid this conflict [HTTP-semantics]. | exception to avoid this conflict [HTTP-semantics]. | |||
skipping to change at line 1135 | skipping to change at line 1062 | |||
standard. If the response is a redirect, then follow the redirect to | standard. If the response is a redirect, then follow the redirect to | |||
obtain the tracking status (up to some reasonable maximum of redirects to | obtain the tracking status (up to some reasonable maximum of redirects to | |||
avoid misconfigured infinite request loops). If the response is | avoid misconfigured infinite request loops). If the response is | |||
successful, obtain the tracking status representation from the message | successful, obtain the tracking status representation from the message | |||
payload, if possible, or consider it an error. | payload, if possible, or consider it an error. | |||
5.7.2 Preflight Checks | 5.7.2 Preflight Checks | |||
A key advantage of providing the tracking status at a resource separate | A key advantage of providing the tracking status at a resource separate | |||
from the site's normal services is that the status can be accessed and | from the site's normal services is that the status can be accessed and | |||
reviewed prior to making use of those services and prior to making | reviewed prior to making use of 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 the retrieval is unsuccessful or | JSON to extract the status-object. If the retrieval is unsuccessful or | |||
parsing results in a syntax error, the user agent ought to consider the | parsing results in a syntax error, the user agent ought to consider the | |||
site to be non-conformant with this protocol. | site to be non-conformant with this protocol. | |||
The status-object is supposed to have a property named tracking containing | The status-object is supposed to have a property named tracking containing | |||
the tracking status value. The meaning of each tracking status value is | the tracking status value. The meaning of each tracking status value is | |||
skipping to change at line 1249 | skipping to change at line 1175 | |||
* To allow the user to see and possibly revoke stored exceptions; | * To allow the user to see and possibly revoke stored exceptions; | |||
* Other aspects of the exception mechanism, as desired. | * Other aspects of the exception mechanism, as desired. | |||
There is no required user interface for the user agent; user agents MAY | There is no required user interface for the user agent; user agents MAY | |||
choose to provide no user interface regarding user-granted exceptions. | choose to provide no user interface regarding user-granted exceptions. | |||
If the user revokes the consent by deleting the exception, the site MUST | If the user revokes the consent by deleting the exception, the site MUST | |||
respect that revocation (though it may ask again for the exception). The | respect that revocation (though it may ask again for the exception). The | |||
exception mechanism MUST NOT be used when the site will deem consent to | exception mechanism MUST NOT be used when the site will deem consent to | |||
exist even after the exception has been revoked. | exist even after the exception has been revoked. | |||
Note | ||||
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 | ||||
intention was the responsibility of the UA. This version removes that | ||||
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 is not to be read | processing model; this model describes the behavior, but is not to be read | |||
as mandating any specific implementation. | as mandating any specific implementation. | |||
This API considers exceptions which are double-keyed to two domains: the | This API considers exceptions which are double-keyed to two domains: the | |||
site, and the target. A user might - for instance - want AnalytiCo to be | site, and the target. A user might - for instance - want AnalytiCo to be | |||
allowed to track them on Example News, but not on Example Medical. To | allowed to track them on Example News, but not on Example Medical. To | |||
simplify language used in this API specification, we define three terms: | simplify language used in this API specification, we define three terms: | |||
skipping to change at line 1293 | skipping to change at line 1212 | |||
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 request include: | given request include: | |||
* The top-level origin of the current context; | * The top-level origin of the current browser context; | |||
* The target of the request. | * The target of the request. | |||
Note | Note | |||
Note that these strict, machine-discoverable, concepts may not match the | Note that these strict, machine-discoverable, concepts 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 | |||
skipping to change at line 1325 | skipping to change at line 1244 | |||
pair of values A and X match if and only if one of the following is true: | pair of values A and X match if and only if one of the following is true: | |||
* either A or X is "*"; | * either A or X is "*"; | |||
* A and X are the same string; | * A and X are the same string; | |||
* A has the form '*.domain' and X is 'domain' or is of the form | * A has the form '*.domain' and X is 'domain' or is of the form | |||
'string.domain', where 'string' is any sequence of characters. | 'string.domain', where 'string' is any sequence of characters. | |||
In addition, responses to the JavaScript API indicated should be | In addition, responses to the JavaScript API indicated should be | |||
consistent with this user preference (see below). | consistent with this user preference (see below). | |||
Note | ||||
The prior version of this required that the UA "somehow confirms with the | ||||
user that they agree to the grant of exception, if not already granted" | ||||
Issue 159: How do we allow sites that mash-in ad-supported content to | ||||
maintain their own trusted third parties? | ||||
[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 | ||||
content which is embedding ads (and hence the top-level origin stays the | ||||
same) and embedded content that should start a new context. | ||||
Proposal: For this version of the specification, we don't address this | ||||
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 user | maintaining it in its entirety, or not at all. That means that a user | |||
agent MUST NOT indicate to a site that a request for targets {a, b, c} | agent MUST NOT indicate to a site that a request for targets {a, b, c} | |||
exists in the database, and later remove only one or two of {a, b, c} from | exists in the database, and later remove only one or two of {a, b, c} from | |||
its logical database of remembered grants. This assures sites that the set | its logical database of remembered grants. This assures sites that the set | |||
of sites they need for operational integrity is treated as a unit. Each | of sites they need for operational integrity is treated as a unit. Each | |||
separate call to an API is a separate unit. | separate call to an API is a separate unit. | |||
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 | ||||
[OPEN] There is software that, in just a few lines of code, can spawn | ||||
DNT:1 or DNT:0 headers regardless of user's will. A requirement on the | ||||
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 | ||||
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 | ||||
signals from that UA. It would allow thus testing from the horizon of the | ||||
site without wild guessing; | ||||
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 | ||||
calls. | ||||
6.4 JavaScript API for Site-specific Exceptions | 6.4 JavaScript API for Site-specific Exceptions | |||
6.4.1 API to Request a Site-specific Exception | 6.4.1 API to Request a Site-specific Exception | |||
partial interface Navigator { | partial interface Navigator { | |||
void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty Bag properties); | void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProperty Bag properties); | |||
}; | }; | |||
storeSiteSpecificTrackingException | storeSiteSpecificTrackingException | |||
Called by a page to store a site-specific tracking exception. | Called by a page to store a site-specific tracking exception. | |||
skipping to change at line 1458 | skipping to change at line 1346 | |||
[document-origin, * ] | [document-origin, * ] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
If domain is supplied and not empty then it is treated in the same way as | If domain is supplied and not empty then it is treated in the same way as | |||
the domain parameter to cookies and allows setting for subdomains. The | the domain parameter to cookies and allows setting for subdomains. The | |||
domain argument can be set to fully-qualified right-hand segment of the | domain argument can be set to fully-qualified right-hand segment of the | |||
document host name, up to one level below TLD. | document host name, up to one level below TLD. | |||
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 able to set a cookie on the domain | If the document-origin would not be able to set a cookie on the domain | |||
following the cookie domain rules [COOKIES] (e.g. domain is not a | following the cookie domain rules [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 | |||
skipping to change at line 1486 | skipping to change at line 1372 | |||
If permission is stored for a site-wide exception, then the duplet: | If permission is stored for a site-wide exception, then the duplet: | |||
[*.domain, * ] | [*.domain, * ] | |||
is added to the database of remembered grants. | is added to the database of remembered grants. | |||
A particular response to the API - like a DNT response header - is only | A particular response to the API - like a DNT response header - 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 | ||||
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 | ||||
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 | ||||
exception stands, or the DNT header that they would receive, should call | ||||
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 proper ties); | void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag proper ties); | |||
}; | }; | |||
removeSiteSpecificTrackingException | removeSiteSpecificTrackingException | |||
If domain is not supplied or is null or empty then this ensures | If domain is not supplied or is null or empty then this ensures | |||
that the database of remembered grants no longer contains any | that the database of remembered grants no longer contains any | |||
skipping to change at line 1533 | skipping to change at line 1410 | |||
DOMString? domain; | DOMString? domain; | |||
}; | }; | |||
domain of type DOMString, nullable | domain of type DOMString, nullable | |||
Cookie-like domain string to which the exception applies. | Cookie-like domain string to which the exception applies. | |||
When this method returns the database of grants no longer contains the | When this method returns the database of grants no longer contains the | |||
indicated grant(s); if some kind of processing error occurred then an | indicated grant(s); if some kind of processing error occurred then an | |||
appropriate exception will be thrown. | appropriate exception will be thrown. | |||
Note | ||||
If there are no matching duplets in the database of remembered grants when | If there are no matching duplets in the database of remembered grants when | |||
the method is called then this operation does nothing (and does not throw | the method is called then this operation does nothing (and does not throw | |||
an exception). | an exception). | |||
6.4.3 API to Confirm a Site-specific Exception | 6.4.3 API to Confirm a Site-specific Exception | |||
partial interface Navigator { | partial interface Navigator { | |||
boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptionP ropertyBag properties); | boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptionP ropertyBag properties); | |||
}; | }; | |||
skipping to change at line 1630 | skipping to change at line 1505 | |||
request for site-specific exceptions. | request for site-specific exceptions. | |||
Parameter Type Nullable Optional Description | Parameter Type Nullable Optional Description | |||
properties StoreExceptionPropertyBag * * | properties StoreExceptionPropertyBag * * | |||
Return type: void | Return type: void | |||
This API requests the addition of a web-wide grant for a specific site, to | This API requests the addition of a web-wide grant for a specific site, to | |||
the database. | the database. | |||
Note | ||||
As above, this call used to be asynchronous, and the change to the UI | ||||
enabled it to be synchronous. | ||||
6.5.2 API to Cancel a Web-wide Exception | 6.5.2 API to Cancel a Web-wide Exception | |||
partial interface Navigator { | partial interface Navigator { | |||
void removeWebWideTrackingException (RemoveExceptionPropertyBag properties) ; | void removeWebWideTrackingException (RemoveExceptionPropertyBag properties) ; | |||
}; | }; | |||
removeWebWideTrackingException | removeWebWideTrackingException | |||
Ensures that the database of remembered grants no longer contains | Ensures that the database of remembered grants no longer contains | |||
the duplet [ * , document-origin] or [ * , *.domain] (based on if | the duplet [ * , document-origin] or [ * , *.domain] (based on if | |||
domain is provided and is not null and not empty). There is no | domain is provided and is not null and not empty). There is no | |||
skipping to change at line 1694 | skipping to change at line 1564 | |||
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 other use unless it receives a DNT:1 header from that particular | |||
particular identified user agent. | 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 | |||
skipping to change at line 1792 | skipping to change at line 1662 | |||
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 | |||
is granted. | is granted. | |||
Note | ||||
Depending on the resolution of options for the User-Granted Exceptions | ||||
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. Scripts SHOULD test for the | even when window.doNotTrack is null. Scripts SHOULD test for the existence | |||
existence of storeSiteSpecificTrackingException before calling the method. | of storeSiteSpecificTrackingException before calling the method. If an | |||
If an exception is granted in this context and the user agent stores that | exception is granted and the user agent stores that preference, a user | |||
preference, a user agent may send a DNT:0 header even if a tracking | agent may send a DNT:0 header field even if a tracking preference isn't | |||
preference isn't expressed for other requests. Persisted preferences MAY | expressed for other requests. Persisted preferences MAY also affect which | |||
also affect which header is transmitted if a user later chooses to express | header is transmitted if a user later chooses to express a tracking | |||
a tracking preference. | preference. | |||
Note | Note | |||
Users might not configure their agents to have simple values for DNT, but | Users might not configure their agents to have simple values for DNT, but | |||
use different browsing modes or other contextual information to decide on | use different browsing modes or other contextual information to decide on | |||
a DNT value. What algorithm a user agent employs to determine DNT values | a DNT value. What algorithm a user agent employs to determine DNT values | |||
(or the lack thereof) is out of the scope of this specification. | (or the lack thereof) is out of the scope of this specification. | |||
6.10 Exception use by sites | 6.10 Exception use by sites | |||
skipping to change at line 1838 | skipping to change at line 1703 | |||
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 | ||||
The use of the word 'exception' both to describe the user granting | ||||
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. | |||
skipping to change at line 1883 | skipping to change at line 1743 | |||
A. Acknowledgements | A. Acknowledgements | |||
This specification consists of input from many discussions within and | This specification consists of input from many discussions within and | |||
around the W3C Tracking Protection Working Group, along with written | around the W3C Tracking Protection Working Group, along with written | |||
contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), | contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), | |||
Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited | Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited | |||
Expert), Roy T. Fielding (Adobe), Vinay Goel (Adobe), Tom Lowenthal | Expert), Roy T. Fielding (Adobe), Vinay Goel (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), Rigo Wenning (W3C/ERCIM), | |||
Advertising Initiative), Rigo Wenning (W3C/ERCIM), Shane Wiley (Yahoo!), | Shane Wiley (Yahoo!), and Andy Zeigler (Microsoft). | |||
and Andy Zeigler (Microsoft). | ||||
The DNT header field is based on the original Do Not Track submission by | The DNT header field is based on the original Do Not Track submission by | |||
Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm | Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm | |||
(Mozilla). The JavaScript DOM property for doNotTrack is based on the Web | (Mozilla). The JavaScript DOM property for doNotTrack is based on the Web | |||
Tracking Protection submission by Andy Zeigler, Adrian Bateman, and | Tracking Protection submission by Andy Zeigler, Adrian Bateman, and | |||
Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. | Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. | |||
B. References | B. References | |||
B.1 Normative references | B.1 Normative references | |||
skipping to change at line 1907 | skipping to change at line 1766 | |||
[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 | |||
[HTTP] | [HTTP] | |||
Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol | Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol | |||
(HTTP/1.1): Message Syntax and Routing. 17 November 2013. | (HTTP/1.1): Message Syntax and Routing. 6 February 2014. | |||
Internet-Draft. URL: | Internet-Draft. URL: | |||
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ | http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ | |||
[HTTP-cache] | [HTTP-cache] | |||
Roy T. Fielding; Mark Nottingham; Julian Reschke. Hypertext | Roy T. Fielding; Mark Nottingham; Julian Reschke. Hypertext | |||
Transfer Protocol (HTTP/1.1): Caching. 17 November 2013. | Transfer Protocol (HTTP/1.1): Caching. 6 February 2014. | |||
Internet-Draft. URL: | Internet-Draft. URL: | |||
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p6-cache/ | http://datatracker.ietf.org/doc/draft-ietf-httpbis-p6-cache/ | |||
[HTTP-semantics] | [HTTP-semantics] | |||
Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol | Roy T. Fielding; Julian Reschke. Hypertext Transfer Protocol | |||
(HTTP/1.1): Semantics and Content. 17 November 2013. | (HTTP/1.1): Semantics and Content. 6 February 2014. | |||
Internet-Draft. URL: | Internet-Draft. URL: | |||
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/ | 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] | [RFC7159] | |||
D. Crockford. The application/json Media Type for JavaScript | Tim Bray, Ed.. The JavaScript Object Notation (JSON) Data | |||
Object Notation (JSON) (RFC 4627). July 2006. RFC. URL: | Interchange Format. March 2014. Internet RFC 7159. URL: | |||
http://www.ietf.org/rfc/rfc4627.txt | http://www.rfc-editor.org/rfc/rfc7159.txt | |||
[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: | |||
End of changes. 92 change blocks. | ||||
417 lines changed or deleted | 276 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/ |