dnt-wd2.txt | dnt-wd3.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Preference Expression (DNT) | Tracking Preference Expression (DNT) | |||
W3C Working Draft 13 March 2012 | W3C Working Draft 02 October 2012 | |||
This version: | This version: | |||
http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ | http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/ | |||
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: | Previous version: | |||
http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/ | http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ | |||
Editors: | Editors: | |||
Roy T. Fielding, Adobe | Roy T. Fielding, Adobe | |||
David Singer, Apple | David Singer, Apple | |||
Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. | Copyright (c) 2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. W3C | |||
W3C liability, trademark and document use rules apply. | liability, trademark and document use rules apply. | |||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
Abstract | Abstract | |||
This specification defines the technical mechanisms for expressing a | This specification defines the technical mechanisms for expressing a | |||
tracking preference via the DNT request header field in HTTP, via an HTML | tracking preference via the DNT request header field in HTTP, via an HTML | |||
DOM property readable by embedded scripts, and via properties accessible | DOM property readable by embedded scripts, and via properties accessible | |||
to various user agent plug-in or extension APIs. It also defines | to various user agent plug-in or extension APIs. It also defines | |||
mechanisms for sites to signal whether and how they honor this preference, | mechanisms for sites to signal whether and how they honor this preference, | |||
skipping to change at line 50 | skipping to change at line 50 | |||
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 live discussions within the Tracking | This document is a snapshot of live discussions within the Tracking | |||
Protection Working Group. It does not yet capture all of our work. For | Protection Working Group. It does not yet capture all of our work. For | |||
example, we have issues that are [PENDING REVIEW] with complete text | example, we have issues that are [PENDING REVIEW] with complete text | |||
proposals that did not make it into this draft. Text in white is typically | proposals that have not yet made it into this draft. Text in blue boxes | |||
[CLOSED]: we have reached a consensus decision. Text in blue boxes | presents multiple options the group is considering. Options included in | |||
presents multiple options the group is considering. In some cases we are | this draft should not be read as limitations on the potential outcome, but | |||
close to agreement, and in others we have more to discuss. An issue | rather simply as possible options that are currently under consideration | |||
tracking system is available for recording raised, open, pending review, | by the working group. Readers may review changes from the previous Working | |||
closed, and postponed issues regarding this document. This draft, | Draft. An issue tracking system is available for recording raised, open, | |||
published 13 March 2012, is substantially different from and more complete | pending review, closed, and postponed issues regarding this document. | |||
than the First Public Working Draft. | ||||
We have not yet reviewed comments from the Community Group associated with | ||||
this work. We thank them for their time and detailed feedback, and will | ||||
address their comments in the near future. | ||||
This document was published by the Tracking Protection Working Group as a | This document was published by the Tracking Protection Working Group as a | |||
Working Draft. This document is intended to become a W3C Recommendation. | Working Draft. This document is intended to become a W3C Recommendation. | |||
If you wish to make comments regarding this document, please send them to | If you wish to make comments regarding this document, please send them to | |||
public-tracking@w3.org (subscribe, archives). All feedback is welcome. | public-tracking@w3.org (subscribe, archives). All feedback is welcome. | |||
Publication as a Working Draft does not imply endorsement by the W3C | Publication as a Working 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. | |||
skipping to change at line 93 | skipping to change at line 88 | |||
* 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 API to Detect Preference | * 4.3 JavaScript API to Detect Preference | |||
* 4.3.1 Interface | ||||
* 4.3.2 Attributes | ||||
* 4.3.3 Implements | ||||
* 4.4 Plug-In APIs | * 4.4 Plug-In APIs | |||
* 4.5 Tracking Preference Expressed in Other Protocols | * 4.5 Tracking Preference Expressed in Other Protocols | |||
* 5. Communicating a Tracking Status | * 5. Communicating a Tracking Status | |||
* 5.1 Tracking Status Resource | * 5.1 Overview | |||
* 5.1.1 Resource Definition | * 5.2 Tracking Status Value | |||
* 5.1.2 Tracking Status Representation | * 5.3 Tracking Status Qualifier Values | |||
* 5.1.3 Using the Tracking Status | * 5.4 Tk Header Field for HTTP Responses | |||
* 5.1.4 Tracking Status Caching | * 5.4.1 Definition | |||
* 5.1.5 Tracking Status ABNF | * 5.4.2 Referring to a Request-specific Tracking Status | |||
* 5.2 Tk Header Field for HTTP Responses | Resource | |||
* 5.2.1 Motivation | * 5.4.3 Indicating an Interactive Status Change | |||
* 5.2.2 Tk ABNF | * 5.5 Tracking Status Resource | |||
* 5.2.3 Tk Semantics | * 5.5.1 Site-wide Tracking Status | |||
* 5.2.4 More Information | * 5.5.2 Request-specific Tracking Status | |||
* 5.2.5 Implementation and Usage Considerations | * 5.5.3 Representation | |||
* 5.2.6 Examples | * 5.5.4 Status Checks are Not Tracked | |||
* 5.3 Status Code for Tracking Required | * 5.5.5 Caching | |||
* 6. Site-specific Exceptions | * 5.6 Status Code for Tracking Required | |||
* 5.7 Using the Tracking Status | ||||
* 5.7.1 Discovering Deployment | ||||
* 5.7.2 Preflight Checks | ||||
* 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 Site pairs | * 6.3.1 Introduction | |||
* 6.3.2 Exception use by browsers | * 6.3.2 Exception use by browsers | |||
* 6.4 JavaScript API for site-specific exceptions | * 6.4 JavaScript API for Site-specific Exceptions | |||
* 6.4.1 Methods | * 6.4.1 API to request site-specific exceptions | |||
* 6.4.2 Methods | * 6.4.2 API to Cancel a Site-specific Exception | |||
* 6.5 User interface guidelines | * 6.5 JavaScript API for Web-wide Exceptions | |||
* 6.6 Exceptions without a DNT header | * 6.5.1 API to Request a Web-wide Exception | |||
* 6.7 Web-wide exceptions | * 6.5.2 API to cancel a web-wide exception | |||
* 6.8 Fingerprinting | * 6.6 Querying a host's exception status | |||
* 6.7 Transfer of an exception to another third party | ||||
* 6.8 User interface guidelines | ||||
* 6.9 Exceptions without a DNT header | ||||
* 6.10 Fingerprinting | ||||
* A. Acknowledgements | * A. Acknowledgements | |||
* B. References | * B. References | |||
* B.1 Normative references | * B.1 Normative references | |||
* B.2 Informative references | * B.2 Informative references | |||
1. Introduction | 1. Introduction | |||
The World Wide Web (WWW, or Web) consists of millions of sites | The World Wide Web (WWW, or Web) consists of millions of sites | |||
interconnected through the use of hypertext. Hypertext provides a simple, | interconnected through the use of hypertext. Hypertext provides a simple, | |||
page-oriented view of a wide variety of information that can be traversed | page-oriented view of a wide variety of information that can be traversed | |||
skipping to change at line 188 | skipping to change at line 188 | |||
content without such targeted advertising or data collection need a | content without such targeted advertising or data collection need a | |||
mechanism to indicate those requirements to the user and allow them (or | mechanism to indicate those requirements to the user and allow them (or | |||
their user agent) to make an individual choice regarding exceptions. | their user agent) to make an individual choice regarding exceptions. | |||
This specification defines the HTTP request header field DNT for | This specification defines the HTTP request header field DNT for | |||
expressing a tracking preference on the Web, a well-known location (URI) | expressing a tracking preference on the Web, a well-known location (URI) | |||
for providing a machine-readable tracking status resource that describes a | for providing a machine-readable tracking status resource that describes a | |||
service's DNT compliance, the HTTP response header field Tk for resources | service's DNT compliance, the HTTP response header field Tk for resources | |||
to communicate their compliance or non-compliance with the user's | to communicate their compliance or non-compliance with the user's | |||
expressed preference, and JavaScript APIs for determining DNT status and | expressed preference, and JavaScript APIs for determining DNT status and | |||
requesting a site-specific exception. | requesting a user-granted exception. | |||
A companion document, [TRACKING-COMPLIANCE], more precisely defines the | A companion document, [TRACKING-COMPLIANCE], more precisely defines the | |||
terminology of tracking preferences, the scope of its applicability, and | terminology of tracking preferences, the scope of its applicability, and | |||
the requirements on compliant first-party and third-party participants | the requirements on compliant first-party and third-party participants | |||
when an indication of tracking preference is received. | when an indication of tracking preference is received. | |||
ISSUE-117: Terms: tracking v. cross-site tracking | Issue 136: Resolve dependencies of the TPE on the compliance specification | |||
The WG has not come to consensus regarding the definition of tracking and | The WG has not come to consensus regarding the definition of tracking and | |||
whether the scope of DNT includes all forms of user-identifying data | the scope of DNT. As such, a site cannot actually say with any confidence | |||
collection or just cross-site data collection/use. This issue will be | whether or not it is tracking, let alone describe the finer details in a | |||
resolved in the TCS document, though its resolution is a necessary | tracking status resource. This issue will be resolved by progress on the | |||
prerequisite to understanding and correctly implementing the protocol | TCS document, though its resolution is a necessary prerequisite to | |||
defined by this document. | understanding and correctly implementing the protocol defined by this | |||
document. | ||||
2. Notational Conventions | 2. Notational Conventions | |||
2.1 Requirements | 2.1 Requirements | |||
The key words must, must not, required, should, should not, recommended, | The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, | |||
may, and optional in this specification are to be interpreted as described | MAY, and OPTIONAL in this specification are to be interpreted as described | |||
in [RFC2119]. | in [RFC2119]. | |||
2.2 Formal Syntax | 2.2 Formal Syntax | |||
This specification uses Augmented Backus-Naur Form [ABNF] to define | This specification uses Augmented Backus-Naur Form [ABNF] to define | |||
network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. | network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. | |||
2.3 Terminology | 2.3 Terminology | |||
This specification uses the term user agent to refer to any of the various | This specification uses the term user agent to refer to any of the various | |||
client programs capable of initiating HTTP requests, including, but not | client programs capable of initiating HTTP requests, including, but not | |||
limited to, browsers, spiders (web-based robots), command-line tools, | limited to, browsers, spiders (web-based robots), command-line tools, | |||
native applications, and mobile apps [HTTP11]. | native applications, and mobile apps [HTTP11]. | |||
The term permitted use is used to indicate a restricted set of conditions | ||||
under which tracking is allowed in spite of the user's DNT preference. | ||||
The term user-granted exception is used when the user has permitted | ||||
tracking by a given third party, usually in the form of a site-specific | ||||
exception. | ||||
A companion document, [TRACKING-COMPLIANCE], defines many of the terms | ||||
used here, notably 'party', 'first party', and 'third party'. | ||||
3. Determining User Preference | 3. Determining User Preference | |||
The goal of this protocol is to allow a user to express their personal | The goal of this protocol is to allow a user to express their personal | |||
preference regarding tracking to each server and web application that they | preference regarding tracking to each server and web application that they | |||
communicate with via HTTP, thereby allowing each service to either adjust | communicate with via HTTP, thereby allowing each service to either adjust | |||
their behavior to meet the user's expectations or reach a separate | their behavior to meet the user's expectations or reach a separate | |||
agreement with the user to satisfy all parties. | agreement with the user to satisfy all parties. | |||
Key to that notion of expression is that it must reflect the user's | Key to that notion of expression is that it MUST reflect the user's | |||
preference, not the preference of some institutional or network-imposed | preference, not the choice of some vendor, institution, or network-imposed | |||
mechanism outside the user's control. Although some controlled network | mechanism outside the user's control. The basic principle is that a | |||
environments, such as public access terminals or managed corporate | tracking preference expression is only transmitted when it reflects a | |||
intranets, might impose restrictions on the use or configuration of | deliberate choice by the user. In the absence of user choice, there is no | |||
installed user agents, such that a user might only have access to user | tracking preference expressed. | |||
agents with a predetermined preference enabled, the user is at least able | ||||
to choose whether to make use of those user agents. In contrast, if a user | ||||
brings their own Web-enabled device to a library or cafe with wireless | ||||
Internet 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 sites can | ||||
or cannot be accessed through that network. | ||||
The remainder of this specification defines the protocol in terms of | A user agent MUST offer users a minimum of two alternative choices for a | |||
whether a tracking preference is enabled or not enabled. We do not specify | Do Not Track preference: unset or DNT:1. A user agent MAY offer a third | |||
how that preference is enabled: each implementation is responsible for | alternative choice: DNT:0. | |||
determining the user experience by which this preference is enabled. | ||||
If the user's choice is DNT:1 or DNT:0, the tracking preference is | ||||
enabled; otherwise, the tracking preference is not enabled. | ||||
A user agent MUST have a default tracking preference of unset (not | ||||
enabled) unless a specific tracking preference is implied by the decision | ||||
to use that agent. For example, use of a general-purpose browser would not | ||||
imply a tracking preference when invoked normally as SuperFred, but might | ||||
imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred. | ||||
Likewise, a user agent extension or add-on MUST NOT alter the tracking | ||||
preference unless the act of installing and enabling that extension or | ||||
add-on is an explicit choice by the user for that tracking preference. | ||||
We do not specify how 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 | For example, a user might select a check-box in their user agent's | |||
configuration, install a plug-in or extension that is specifically | configuration, install an extension or add-on that is specifically | |||
designed to add a tracking preference expression, or make a choice for | designed to add a tracking preference expression, or make a choice for | |||
privacy that then implicitly includes a tracking preference (e.g., Privacy | privacy that then implicitly includes a tracking preference (e.g., Privacy | |||
settings: high). Likewise, a user might install or configure a proxy to | settings: high). The user-agent might ask the user for their preference | |||
add the expression to their own outgoing requests. For each of these | during startup, perhaps on first use or after an update adds the tracking | |||
cases, we say that a tracking preference is enabled. | 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 | ||||
terminals or managed corporate intranets, might impose restrictions on the | ||||
use or configuration of installed user agents, such that a user might only | ||||
have access to user agents with a predetermined preference enabled, the | ||||
user is at least able to choose whether to make use of those user agents. | ||||
In contrast, if a user brings their own Web-enabled device to a library or | ||||
cafe with wireless Internet 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. Implementations of HTTP that are not under control of the user | ||||
MUST NOT generate or modify a tracking preference. | ||||
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 by | |||
third parties, including sites that the user agent communicates with via | third parties, including sites that the user agent communicates with via | |||
HTTP, scripts that can extend behavior on pages, and plug-ins or | HTTP, scripts that can extend behavior on pages, and plug-ins or | |||
extensions that might be installed and activated for various media types. | 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 | 1 This user prefers not to be tracked on the target site. | |||
site. | 0 This user prefers to allow tracking on the target site. | |||
0 This user prefers to allow tracking on the target | ||||
site. | ||||
If a tracking preference is not enabled, then no preference is expressed | A user agent MUST NOT send a tracking preference expression if a tracking | |||
by this protocol. This means that no expression is sent for each of the | preference is not enabled. This means that no expression is sent for each | |||
following cases: | of the following cases: | |||
* the user agent does not implement this protocol; or | * the user agent does not implement this protocol; | |||
* the user agent does implement the protocol, but the user does not wish | * the user has not yet made a choice for a specific preference; or, | |||
to indicate a preference at this time. | * the user has chosen not to transmit a preference. | |||
In the absence of regulatory, legal, or other requirements, servers may | ||||
In the absence of regulatory, legal, or other requirements, servers MAY | ||||
interpret the lack of an expressed tracking preference as they find most | interpret the lack of an expressed tracking preference as they find most | |||
appropriate for the given user, particularly when considered in light of | appropriate for the given user, particularly when considered in light of | |||
the user's privacy expectations and cultural circumstances. Likewise, | the user's privacy expectations and cultural circumstances. Likewise, | |||
servers might make use of other preference information outside the scope | servers might make use of other preference information outside the scope | |||
of this protocol, such as site-specific user preferences or third-party | of this protocol, such as site-specific user preferences or third-party | |||
registration services, to inform or adjust their behavior when no explicit | registration services, to inform or adjust their behavior when no explicit | |||
preference is expressed via this protocol. | preference is expressed via this protocol. | |||
ISSUE-111: Different DNT value to signify existence of site-specific | ||||
exception (also linked to 4.1 and 6 below) | ||||
4.2 DNT Header Field for HTTP Requests | 4.2 DNT Header Field for HTTP Requests | |||
The DNT header field is hereby defined as the means for expressing a | The DNT header field is hereby defined as the means for expressing a | |||
user's tracking preference via HTTP [HTTP11]. | user's tracking preference via HTTP [HTTP11]. | |||
DNT-field-name = "DNT" ; case-insensitive | DNT-field-name = "DNT" ; case-insensitive | |||
DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive | DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive | |||
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
; excludes CTL, SP, DQUOTE, comma, backslash | ; excludes CTL, SP, DQUOTE, comma, backslash | |||
A user agent must send the DNT header field on all HTTP requests if (and | A user agent MUST send the DNT header field on all HTTP requests if (and | |||
only if) a tracking preference is enabled. A user agent must not send the | only if) a tracking preference is enabled. A user agent MUST NOT send the | |||
DNT header field if a tracking preference is not enabled. | DNT header field if a tracking preference is not enabled. | |||
The DNT field-value sent by a user agent must begin with the numeric | The DNT field-value sent by a user agent MUST begin with the numeric | |||
character "1" (%x31) if a tracking preference is enabled, the preference | character "1" (%x31) if a tracking preference is enabled, the preference | |||
is for no tracking, and there is not a site-specific exception for the | is for no tracking, and there is not a site-specific exception for the | |||
origin server targeted by this request. | origin server targeted by this request. | |||
The DNT field-value sent by a user agent must begin with the numeric | The DNT field-value sent by a user agent MUST begin with the numeric | |||
character "0" (%x30) if a tracking preference is enabled and the | character "0" (%x30) if a tracking preference is enabled and the | |||
preference is to allow tracking in general or by specific exception for | preference is to allow tracking in general or by specific exception for | |||
the origin server targeted by this request. | the origin server targeted by this request. | |||
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 | An HTTP intermediary MUST NOT add, delete, or modify the DNT header field | |||
in requests forwarded through that intermediary unless that intermediary | in requests forwarded through that intermediary unless that intermediary | |||
has been specifically installed or configured to do so by the user making | has been specifically installed or configured to do so by the user making | |||
the requests. For example, an Internet Service Provider must not inject | the requests. For example, an Internet Service Provider MUST NOT inject | |||
DNT: 1 on behalf of all of their users who have not selected a choice. | 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 | The remainder of the DNT field-value after the initial character is | |||
reserved for future extensions. User agents that do not implement such | reserved for future extensions. User agents that do not implement such | |||
extensions must not send DNT-extension characters in the DNT field-value. | extensions MUST NOT send DNT-extension characters in the DNT field-value. | |||
Servers that do not implement such extensions should ignore anything | Servers that do not implement such extensions SHOULD ignore anything | |||
beyond the first character. | beyond the first character. | |||
DNT extensions are to be interpreted as modifiers to the main preference | 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 | expressed by the first digit, such that the main preference will be obeyed | |||
if the recipient does not understand the extension. Hence, a | 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 | 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 | understand the refinements defined by x, y, or z, then adjust my | |||
preferences according to those refinements. DNT extensions can only be | preferences according to those refinements. DNT extensions can only be | |||
transmitted when a tracking preference is enabled. | transmitted when a tracking preference is enabled. | |||
The extension syntax is restricted to visible ASCII characters that can be | The extension syntax is restricted to visible ASCII characters that can be | |||
parsed as a single word in HTTP and safely embedded in a JSON string | parsed as a single word in HTTP and safely embedded in a JSON string | |||
without further encoding (section 5.1.2 Tracking Status Representation). | without further encoding (section 5.5.3 Representation). Since the DNT | |||
Since the DNT header field is intended to be sent on every request, when | header field is intended to be sent on every request, when enabled, | |||
enabled, designers of future extensions ought to use as few extension | designers of future extensions ought to use as few extension characters as | |||
characters as possible. | possible. | |||
ISSUE-111: Different DNT value to signify existence of site-specific | ||||
exceptions | ||||
Should the user agent send a different DNT value to a first party site if | ||||
there exist site-specific exceptions for that first party? (e.g. DNT:2 | ||||
implies I have Do Not Track enabled but grant permissions to some third | ||||
parties while browsing this domain) [OPEN] | ||||
4.3 JavaScript API to Detect Preference | Note | |||
4.3.1 Interface | This document does not have any implied or specified behavior for the | |||
user-agent treatment of cookies when DNT is enabled. | ||||
The NavigatorDoNotTrack interface provides a means for the user's tracking | 4.3 JavaScript API to Detect Preference | |||
preference to be expressed to web applications running within a page | ||||
rendered by the user agent. | ||||
[NoInterfaceObject] | A doNotTrack attribute on the Navigator interface [NAVIGATOR] (e.g., the | |||
interface NavigatorDoNotTrack { | window.navigator object) is hereby defined as the means for expressing the | |||
user's general tracking preference to scripts running within a top-level | ||||
page. A user agent MUST provide a doNotTrack attribute on the Navigator | ||||
interface for each top-level page. | ||||
partial interface Navigator { | ||||
readonly attribute DOMString doNotTrack; | readonly attribute DOMString doNotTrack; | |||
}; | }; | |||
4.3.2 Attributes | ||||
doNotTrack of type DOMString, readonly | doNotTrack of type DOMString, readonly | |||
When a tracking preference is enabled, the doNotTrack attribute | When a tracking preference is enabled, the doNotTrack attribute | |||
must have a string value that is the same as the DNT-field-value | for each top-level page MUST have the same string value that would | |||
defined in section 4.2 DNT Header Field for HTTP Requests. If a | be sent in a DNT-field-value (section 4.2 DNT Header Field for | |||
tracking preference is not enabled, the value is null. | HTTP Requests) to an origin server that does not have any | |||
corresponding user-granted exceptions. When a tracking preference | ||||
4.3.3 Implements | is not enabled, the doNotTrack attribute for each top-level page | |||
MUST have a value of null. | ||||
Navigator implements NavigatorDoNotTrack; | ||||
Objects implementing the Navigator interface [NAVIGATOR] (e.g., the | The doNotTrack attribute only provides the user's general tracking | |||
window.navigator object) must also implement the NavigatorDoNotTrack | preference, independent of any user-granted exceptions or out-of-band | |||
interface. An instance of NavigatorDoNotTrack is obtained by using | consent. A script wishing to determine the specific tracking preference | |||
binding-specific casting methods on an instance of Navigator. | for a given document origin is expected to use the API in section 6.6 | |||
Querying a host's exception status. | ||||
ISSUE-84: Make DNT status available to JavaScript | A user agent MUST provide a doNotTrack attribute value that is consistent | |||
[OPEN] The API above has been deemed inadequate due to origin restrictions | with the user's current tracking preference that would be expressed via | |||
on embedded javascript by reference. We are awaiting new text to resolve | the DNT header field. However, changes to the user's preference might | |||
this issue. | occur between the time when the APIs are checked and an actual request is | |||
made. A server MUST treat the user's most recently received preference as | ||||
authoritative. | ||||
ISSUE-116: How can we build a JS DOM property which doesn't allow inline | Issue 116: How can we build a JS DOM property which doesn't allow inline | |||
JS to receive mixed signals? | JS to receive mixed signals? | |||
ISSUE-125: Way to test if a given user agent supports DNT | [PENDING REVIEW] Updated text in this section. | |||
4.4 Plug-In APIs | 4.4 Plug-In APIs | |||
User agents often include user-installable component parts, commonly known | User agents often include user-installable component parts, commonly known | |||
as plug-ins or browser extensions, that are capable of making their own | as plug-ins or browser extensions, that are capable of making their own | |||
network requests. From the user's perspective, these components are | network requests. From the user's perspective, these components are | |||
considered part of the user agent and thus ought to respect the user's | 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 | configuration of a tracking preference. However, plug-ins do not normally | |||
have read access to the browser configuration. | have read access to the browser configuration. | |||
Note | ||||
It is unclear whether we need to standardize the plug-in APIs or if we | It is unclear whether we need to standardize the plug-in APIs or if we | |||
should rely on it being defined per user agent based on general advice | should rely on it being defined per user agent based on general advice | |||
here. No plug-in APIs have been proposed yet. | here. No plug-in APIs have been proposed yet. | |||
4.5 Tracking Preference Expressed in Other Protocols | 4.5 Tracking Preference Expressed in Other Protocols | |||
A user's tracking preference is intended to apply in general, regardless | A user's tracking preference is intended to apply in general, regardless | |||
of the protocols being used for Internet communication. The protocol | of the protocols being used for Internet communication. The protocol | |||
expressed here is specific to HTTP communication; however, the semantics | expressed here is specific to HTTP communication; however, the semantics | |||
are not restricted to use in HTTP; the same semantics may be carried by | are not restricted to use in HTTP; the same semantics may be carried by | |||
other protocols, either in future revisions of this specification, or in | other protocols, either in future revisions of this specification, or in | |||
other specifications. | other specifications. | |||
When it is known that the user's preference is for no tracking, compliant | When it is known that the user's preference is for no tracking, compliant | |||
services are still required to honor that preference, even if other | services are still required to honor that preference, even if other | |||
protocols are used. For example, re-directing to another protocol in order | protocols are used. For example, redirecting to another protocol in order | |||
to avoid receipt of the header is not compliant. | to avoid receipt of the header is not compliant. | |||
ISSUE-108: Should/could the tracking preference expression be extended to | Note | |||
other protocols beyond HTTP? | ||||
[PENDING REVIEW] Text in this section; but the last paragraph may be more | ||||
appropriate in the compliance document, as it discusses compliance. | ||||
5. Communicating a Tracking Status | ||||
The next two sections detail two proposals how to communicate tracking | ||||
status: | ||||
* Well-known URI to allow user agent to retrieve tracking status for a | ||||
site | ||||
* HTTP Response header to communicate tracking status for a request | ||||
This is work in progress. The WG has not yet decided which of these | ||||
options (or both) to choose. The WG is currently working on a resolution | ||||
but nevertheless appreciates input on this open issue. We are currently | ||||
working on a proposal which combines the Tk response header and Tracking | ||||
Status Resource. It would make the TSR compulsory and the Tk header | ||||
optional. However, it would be required to use the Tk header to notify the | ||||
user when something in the TSR has changed in real time. | ||||
5.1 Tracking Status Resource | ||||
5.1.1 Resource Definition | ||||
An origin server must provide a tracking status resource at the well-known | ||||
identifier [RFC5785] | ||||
/.well-known/dnt | ||||
(relative to the URI of that origin server) for obtaining information | ||||
about the potential tracking behavior of services provided by that origin | ||||
server. A tracking status resource may be used for verification of DNT | ||||
support, as described in section 5.1.3 Using the Tracking Status. | ||||
A valid retrieval request (e.g., a GET in [HTTP11]) on the well-known URI | ||||
must result in either a successful response containing a machine-readable | ||||
representation of the site-wide tracking status, as defined below, or a | ||||
sequence of redirects that leads to such a representation. A user agent | ||||
may consider failure to provide access to such a representation equivalent | ||||
to the origin server not implementing this protocol. The representation | ||||
might be cached, as described in section 5.1.4 Tracking Status Caching. | ||||
If an origin server contains multiple services that are controlled by | The last paragraph may be more appropriate in the compliance document, as | |||
distinct parties or that might have differing behavior or policies | it discusses compliance. | |||
regarding tracking, then it may also provide a space of well-known | ||||
resources for obtaining information about the potential tracking behavior | ||||
of each specific service. This parallel tree of resources is called the | ||||
tracking status resource space. | ||||
The tracking status resource space is defined by the following URI | 5. Communicating a Tracking Status | |||
Template [URI-TEMPLATE]: | ||||
/.well-known/dnt{+pathinfo} | 5.1 Overview | |||
where the value of pathinfo is equal to the path component [RFC3986] of a | The primary goals of this protocol-expressing the user's preference and | |||
given reference to that origin server, excluding those references already | adhering to that preference-can be accomplished without any response from | |||
within the above resource space. For example, a reference to | the server. However, the protocol also seeks to improve the transparency | |||
of tracking behavior by providing a machine-readable means for discovering | ||||
claims of compliance and determining the current tracking status. | ||||
http://example.com/over/here?q=hello#top | Unfortunately, providing a dynamic indication of tracking compliance on | |||
every HTTP response is not feasible, since it would have the effect of | ||||
disabling caching for the entire Web. Instead, this protocol defines a | ||||
combination of response mechanisms that allow the information to be | ||||
communicated without making every response dynamic. | ||||
may have a corresponding tracking status resource identified by | 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 HTTP 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. | ||||
http://example.com/.well-known/dnt/over/here | 5.2 Tracking Status Value | |||
Resources within the tracking status resource space are represented using | A tracking status value is a short notation for communicating how a | |||
the same format as a site-wide tracking status resource. | designated resource conforms to the tracking protection protocol, as | |||
defined by this document and [TRACKING-COMPLIANCE]. There is no form of | ||||
negative response; i.e., an origin server that does not wish to claim | ||||
conformance to this protocol would not supply a tracking status resource | ||||
and would not send a Tk header field in responses. | ||||
All requests for well-known URIs defined here must not be tracked, | For a site-wide tracking status resource, the designated resource to which | |||
irrespective of the presence, value, or absence of a DNT header, cookies, | the tracking status applies is any resource on the same origin server. For | |||
or any other information in the request. In addition, all responses to | a Tk response header field, the corresponding request target is the | |||
requests on a tracking status resource, including redirected requests, | designated resource and remains so for any subsequent request-specific | |||
must not include Set-Cookie or Set-Cookie2 header fields [COOKIES] and | tracking status resource referred to by that field. | |||
must not include content that would have the effect of initiating tracking | ||||
beyond what is already present for the request. A user agent should ignore | ||||
or treat as an error any Set-Cookie or Set-Cookie2 header field received | ||||
in such a response. | ||||
5.1.2 Tracking Status Representation | All of the tracking status mechanisms use a common format for the tracking | |||
status value: a single character from a limited set. The meaning of each | ||||
allowed character is defined in the following table. | ||||
The representation of a tracking status resource shall be provided in the | status meaning | |||
"application/json" format [RFC4627] and must conform to the ABNF in | None: The designated resource does not perform tracking of any | |||
section 5.1.5 Tracking Status ABNF. The following is an example tracking | N kind, not even for a permitted use, and does not make use of any | |||
status representation that illustrates all of the fields defined by this | data collected from tracking. | |||
specification, most of which are optional. | First party: The designated resource is designed for use within a | |||
first-party context and conforms to the requirements on a first | ||||
1 party. If the designated resource is operated by an outsourced | ||||
service provider, the service provider claims that it conforms to | ||||
the requirements on a third party acting as a first party. | ||||
Third party: The designated resource is designed for use within a | ||||
3 third-party context and conforms to the requirements on a third | ||||
party. | ||||
Dynamic: The designated resource is designed for use in both first | ||||
and third-party contexts and dynamically adjusts tracking status | ||||
accordingly. If X is present in the site-wide tracking status, more | ||||
information MUST be provided via the Tk response header field when | ||||
X accessing a designated resource. If X is present in the Tk header | ||||
field, more information will be provided in a request-specific | ||||
tracking status resource referred to by the status-id. An origin | ||||
server MUST NOT send X as the tracking status value in the | ||||
representation of a request-specific tracking status resource. | ||||
Consent: The designated resource believes it has received prior | ||||
consent for tracking this user, user agent, or device, perhaps via | ||||
C some mechanism not defined by this specification, and that prior | ||||
consent overrides the tracking preference expressed by this | ||||
protocol. | ||||
Updated: The request resulted in a potential change to the tracking | ||||
status applicable to this user, user agent, or device. A user agent | ||||
that relies on a cached tracking status SHOULD update the cache | ||||
U entry with the current status by making a new request on the | ||||
applicable tracking status resource. An origin server MUST NOT send | ||||
U as a tracking status value anywhere other than a Tk header field | ||||
that is in response to a state-changing request. | ||||
{ | For the site-wide tracking status and Tk header field, the tracking status | |||
"path": "/", | values 1 and 3 indicate how the designated resource is designed to | |||
"tracking": true, | conform, not the nature of the request. Hence, if a user agent is making a | |||
"received": "1", | request in what appears to be a third-party context and the tracking | |||
"response": "t1", | status value indicates that the designated resource is designed only for | |||
"same-site": [ | first-party conformance, then either the context has been misunderstood | |||
"example.com", | (both are actually the same party) or the resource has been referenced | |||
"example_vids.net", | incorrectly. For the request-specific tracking status resource, an | |||
"example_stats.com" | indication of first or third party as the status value describes how the | |||
], | resource conformed to that specific request, and thus indicates both the | |||
"partners": [ | nature of the request (as viewed by the origin server) and the applicable | |||
"api.example-third-party.com" | set of requirements to which the origin server claims to conform. | |||
], | ||||
"policy": "/tracking.html", | ||||
"edit": "http://example-third-party.com/your/data", | ||||
"options": "http://example-third-party.com/your/consent" | ||||
} | ||||
A tracking status representation consists of a single status-object | The tracking status value is case sensitive, as defined formally by the | |||
containing members that describe the tracking status applicable to this | following ABNF. | |||
user agent's request. | ||||
If the status-object has an optional path member, then this object | tracking-v = "1" ; "1" - first-party | |||
describes the tracking status for the entire space of resources that share | / "3" ; "3" - third-party | |||
the same path prefix as the value of path. The user agent must interpret | / %x43 ; "C" - consent | |||
the path value relative to the originally referenced resource, not the | / %x4E ; "N" - none | |||
resource where it obtained the tracking status representation. | / %x55 ; "U" - updated | |||
/ %x58 ; "X" - dynamic | ||||
For the site-wide tracking status resource, the presence of a path member | Issue 137: Does hybrid tracking status need to distinguish between first | |||
with a value of "/" indicates that this status-object applies for the | party (1) and outsourcing service provider acting as a first party (s) | |||
entire origin server of the originally referenced resource. If the | ||||
originally referenced resource's path component does not share the same | ||||
prefix as the value of path, or if the path member is absent, then the | ||||
tracking status for the referenced resource may be obtained via a request | ||||
on the corresponding tracking status resource space. | ||||
A status-object must have a member named tracking with a boolean value. A | [PENDING REVIEW] No, in practice there may be dozens of service providers | |||
value of false indicates that the corresponding resources do not perform | on any given request. If the designated resource is operated by a service | |||
tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true | provider acting as a first party, then the responsible first party is | |||
indicates that the corresponding resource performs tracking and claims to | identified by the policy link or the owner of the origin server domain. | |||
conform to all tracking compliance requirements applicable to this site. | This satisfies the use case of distinguishing between a service provider | |||
acting for some other site and the same service provider acting on one of | ||||
its own sites. | ||||
For example, the following demonstrates a minimal tracking status | 5.3 Tracking Status Qualifier Values | |||
representation that is applicable to any resource that does not perform | ||||
tracking. | ||||
{"tracking": false} | When present, the tracking status qualifier member's value consists of a | |||
string of characters indicating what permitted uses for tracking are being | ||||
used. Multiple qualifiers can be provided. | ||||
The following status-object would indicate that the entire site does not | Issue 136: Resolve dependencies of the TPE on the compliance specification | |||
perform tracking. | ||||
{"path": "/", "tracking": false} | The list of qualifiers is intended to match one to one to the permitted | |||
uses identified by [TRACKING-COMPLIANCE], using references to the | ||||
definitions there. The list will then be updated accordingly. | ||||
If tracking is true, the status-object must include two additional | qualifier meaning | |||
members, named received and response, and may include other members as | Audit: Tracking is limited to that necessary for an external | |||
described below. | a audit of the service context and the data collected is minimized | |||
accordingly. | ||||
c Ad frequency capping: Tracking is limited to frequency capping | ||||
and the data collected is minimized accordingly. | ||||
Fraud prevention: Tracking is limited to that necessary for | ||||
f preventing or investigating fraudulent behavior and security | ||||
violations; the data collected is minimized accordingly. | ||||
Local constraints: Tracking is limited to what is required by | ||||
l local law, rule, or regulation and the data collected is | ||||
minimized accordingly. | ||||
r Referrals: Tracking is limited to collecting referral | ||||
information and the data collected is minimized accordingly. | ||||
The received member must have either a string value equal to the | Qualifiers that indicate limitations on tracking correspond to the | |||
DNT-field-value received in that request or the value null if no | specific permitted uses in [TRACKING-COMPLIANCE]. An origin server | |||
DNT-field-value was received. Any invalid characters received in the | indicating one or more of those permitted uses also indicates that it | |||
DNT-field-value must be elided from the string value to ensure that | conforms to the requirements associated with those permitted uses. | |||
invalid data is not injected into the JSON result. | Multiple limitation qualifiers mean that multiple permitted uses of | |||
tracking might be present and that each such use conforms to the | ||||
associated requirements. All limitation qualifiers imply some form of | ||||
tracking might be used and thus MUST NOT be provided with a tracking | ||||
status value of N (not tracking). | ||||
The response member must have a string value that indicates the status of | Future extensions to this protocol might define additional characters as | |||
tracking applicable specifically to this user in light of the received | qualifiers from the ext-qualifier set (consisting of the remaining unused | |||
DNT-field-value. The string value begins with "t" (tracking) or "n" (not | lowercase letters, dot, dash, and underscore). Recipients SHOULD ignore | |||
tracking) and may be followed by alphanumeric characters that indicate | extension qualifiers that they do not understand. | |||
reasons for that status, as described in the following table. | ||||
reasons meaning | The tracking qualifier value is case sensitive, as defined formally by the | |||
1 Designed for use as a first-party only | following ABNF. | |||
3 Designed for use as a third-party | ||||
a Limited to advertising audits | ||||
c Prior consent received from this user agent | ||||
f Limited to fraud prevention | ||||
g For compliance with regional/geographic | ||||
constraints | ||||
q Limited to advertising frequency capping | ||||
r Limited to referral information | ||||
An optional member named same-site may be provided with an array value | tracking-q = tracking-q-v* | |||
containing a list of domain names that the origin server claims are the | tracking-q-v = %x61 ; "a" - audit | |||
same site, to the extent they are referenced on this site, since all data | / %x63 ; "c" - capping | |||
collected via those references share the same data controller. | / %x66 ; "f" - fraud | |||
/ %x6C ; "l" - local | ||||
/ %x72 ; "r" - referral | ||||
An optional member named partners may be provided with an array value | 5.4 Tk Header Field for HTTP Responses | |||
containing a list of domain names for third-party services that might | ||||
track the user as a result of using this site and which do not have the | ||||
same data controller as this site. | ||||
An optional member named policy may be provided with a string value | 5.4.1 Definition | |||
containing a URI-reference to a human-readable document that describes the | ||||
tracking policy for this site. The content of such a policy document is | ||||
beyond the scope of this protocol and only supplemental to what is | ||||
described by this machine-readable tracking status representation. | ||||
An optional member named edit may be provided with a string value | The Tk response header field is hereby defined as an OPTIONAL means for | |||
containing a URI-reference to a resource intended to allow a tracked user | indicating the tracking status that applied to the corresponding request | |||
agent to review or delete data collected by this site, if any such data | and as a REQUIRED means for indicating that a state-changing request has | |||
remains associated with this user agent. The design of such a resource and | resulted in an interactive change to the tracking status. | |||
the extent to which it can provide access to that data is beyond the scope | ||||
of this protocol. | ||||
An optional member named options may be provided with a string value | Tk-field-name = "Tk" ; case-insensitive | |||
containing a URI-reference to a resource intended to allow a user agent to | Tk-field-value = tracking-v [tracking-q] [ ";" status-id ] | |||
opt-in, opt-out, or otherwise modify their consent status regarding data | ||||
collection by this site. The design of such a resource and how it might | ||||
implement an out-of-band consent mechanism is beyond the scope of this | ||||
protocol. | ||||
Additional extension members may be provided in the status-object to | The Tk field-value begins with a tracking status value (section 5.2 | |||
support future enhancements to this protocol. A user agent should ignore | Tracking Status Value), optionally followed by one or more tracking | |||
extension members that it does not recognize. | qualifiers (section 5.3 Tracking Status Qualifier Values), and then | |||
optionally a semicolon and a status-id that refers to a request-specific | ||||
tracking status resource (section 5.4.2 Referring to a Request-specific | ||||
Tracking Status Resource). | ||||
Note that the tracking status resource space applies equally to both | For example, a Tk header field for a resource that claims not to be | |||
first-party and third-party services. An example of a third-party tracking | tracking would look like: | |||
status is | ||||
{ | Example 2 | |||
"tracking": true, | ||||
"received": "1", | ||||
"response": "n", | ||||
"policy": "/privacy.html", | ||||
"edit": "/your/data", | ||||
"options": "/your/consent" | ||||
} | ||||
ISSUE-47: Should the response from the server indicate a policy that | Tk: N | |||
describes the DNT practices of the server? | ||||
[PENDING REVIEW] The tracking status resource is a machine-readable policy | ||||
and provides a mechanism for supplying a link to a human-readable policy. | ||||
ISSUE-61: A site could publish a list of the other domains that are | whereas a Tk header field for a resource that might perform tracking | |||
associated with them | (though not necessarily for every request) and conforms to the third-party | |||
[PENDING REVIEW] The same-site and partners members provide a means to | requirements of [TRACKING-COMPLIANCE], while claiming the audit exception, | |||
list first-party and third-party domains, respectively. | would look like: | |||
ISSUE-124: Alternative DNT implementations that replace HTTP headers with | Example 3 | |||
something else | ||||
[PENDING REVIEW] The tracking status resource minimizes bandwidth usage | ||||
because only a small proportion of user agents are expected to perform | ||||
active verification, status would only be requested once per site per day, | ||||
and the response can be extensively cached. | ||||
5.1.3 Using the Tracking Status | Tk: 3a | |||
A key advantage of providing the tracking status at a resource separate | 5.4.2 Referring to a Request-specific Tracking Status Resource | |||
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 | ||||
requests on third-party resources referenced by those services. In | ||||
addition, the presence (or absence) of a site-wide tracking status | ||||
representation is a means for testing deployment of this standard and | ||||
verifying that a site's claims regarding tracking are consistent with the | ||||
site's observed behavior over time. | ||||
A user agent may check the tracking status for a given resource URI by | If an origin server has multiple, request-specific tracking policies, such | |||
making a retrieval request for the well-known address /.well-known/dnt | that the tracking status might differ depending on some aspect of the | |||
relative to that URI. | request (e.g., method, target URI, header fields, data, etc.), the origin | |||
server MAY provide an additional subtree of well-known resources | ||||
corresponding to each of those distinct tracking statuses. The OPTIONAL | ||||
status-id portion of the Tk field-value indicates which specific tracking | ||||
status resource applies to the current request. | ||||
If the response is an error, then the service does not implement this | status-id = 1*id-char ; case-sensitive | |||
standard. If the response is a redirect, then follow the redirect to | id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" | |||
obtain the tracking status (up to some reasonable maximum of redirects to | ||||
avoid misconfigured infinite request loops). If the response is | ||||
successful, obtain the tracking status representation from the message | ||||
payload, if possible, or consider it an error. | ||||
Once the tracking status representation is obtained, parse the | For example, a response containing | |||
representation as JSON to extract the Javascript status-object. If parsing | ||||
results in a syntax error, the user agent should consider the site to be | ||||
non-conformant with this protocol. | ||||
If the status-object does not have a member named path or if the value of | Example 4 | |||
path is not "/" and not a prefix of the path component for the URI being | ||||
checked, then find the service-specific tracking status resource by taking | ||||
the template /.well-known/dnt{+pathinfo} and replacing {+pathinfo} with | ||||
the path component of the URI being checked. Perform a retrieval request | ||||
on the service-specific tracking status resource and process the result as | ||||
described above to obtain the specific tracking status. | ||||
The status-object is supposed to have a member named tracking with a | Tk: 1;fRx42 | |||
boolean value. If the value is false, then no tracking is performed for | ||||
the URI being checked. If the value is true, then examine the member named | ||||
received to verify that the DNT header field sent by the user agent has | ||||
been correctly received by the server. If the received value is incorrect, | ||||
there may be an intermediary interfering with transmission of the DNT | ||||
request header field. | ||||
If the received value is correct, then examine the member named response | indicates that the target resource claims to conform to the first-party | |||
to see what the origin server has claimed regarding the tracking status | requirements of [TRACKING-COMPLIANCE] and that an applicable tracking | |||
for this user agent in light of the received DNT-field-value. | status representation can be obtained by performing a retrieval request on | |||
If the first character of the response value is "n", then the origin | /.well-known/dnt/fRx42 | |||
server claims that it will not track the user agent for requests on the | ||||
URI being checked, and for any URIs with a path prefix matching the path | ||||
member's value, for at least the next 24 hours or until the Cache-Control | ||||
information indicates that this response expires, as described below. | ||||
If the first character of the response value is "t", then the origin | If a Tk field-value has a tracking status value of X (dynamic), then a | |||
server claims that it might track the user agent for requests on the URI | status-id MUST be included in the field-value. | |||
being checked, and for any URIs with a path prefix matching the path | ||||
member's value, for at least the next 24 hours or until the Cache-Control | ||||
information indicates that this response expires. | ||||
The remaining characters of the response value might indicate reasons for | 5.4.3 Indicating an Interactive Status Change | |||
the above choices or limitations that the origin server will place on its | ||||
tracking. | ||||
The others members of the status-object may be used to help the user agent | We anticipate that interactive mechanisms might be used, beyond the scope | |||
differentiate between a site's first-party and third-party services, to | of this specification, that have the effect of asking for and obtaining | |||
provide links to additional human-readable information related to the | prior consent for tracking, or for modifying prior indications of consent. | |||
tracking policy, and to provide links for control over past data collected | For example, the tracking status resource's status-object defines a | |||
or over some consent mechanism outside the scope of this protocol. | control member that can refer to such a mechanism. Although such | |||
out-of-band mechanisms are not defined by this specification, their | ||||
presence might influence the tracking status object's response value. | ||||
5.1.4 Tracking Status Caching | When an origin server provides a mechanism via HTTP for establishing or | |||
modifying out-of-band tracking preferences, the origin server MUST | ||||
indicate within the mechanism's response when a state-changing request has | ||||
resulted in a change to the tracking status for that server. This | ||||
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). | ||||
If the tracking status is applicable to all users, regardless of the | Example 5 | |||
received DNT-field-value or other data received via the request, then the | ||||
response should be marked as cacheable and assigned a time-to-live | ||||
(expiration or max-use) that is sufficient to enable shared caching but | ||||
not greater than the earliest point at which the service's tracking | ||||
behavior might increase. 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 can be increased is seven days after the | ||||
policy has been updated to reflect the new behavior, since old copies | ||||
might persist in caches until the expiration is triggered. A service's | ||||
tracking behavior can be reduced at any time, with or without a | ||||
corresponding change to the tracking status resource. | ||||
If the tracking status is only applicable to all users that have the same | Tk: U | |||
DNT-field-value, then either the response must include a Cache-Control | ||||
header field with one of the directives "no-cache", "no-store", | ||||
"must-revalidate", or "max-age=0", or the response must include a Vary | ||||
header field that includes "DNT" in its field-value. | ||||
If the tracking status is only applicable to the specific user that | 5.5 Tracking Status Resource | |||
requested it, then the response must include a Cache-Control header field | ||||
with one of the directives "no-cache", "no-store", "must-revalidate", or | ||||
"max-age=0". | ||||
Regardless of the cache-control settings, it is expected that user agents | 5.5.1 Site-wide Tracking Status | |||
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 | ||||
to increase tracking behavior must update the tracking status resource in | ||||
accordance with that planned behavior at least twenty-four hours prior to | ||||
activating that new behavior on the service. | ||||
5.1.5 Tracking Status ABNF | An origin server MUST provide a site-wide tracking status resource at the | |||
well-known identifier [RFC5785] | ||||
The representation of a site's machine-readable tracking status must | /.well-known/dnt | |||
conform to the following ABNF for status-object, except that the members | ||||
within each member-list may be provided in any order. | ||||
status-object = begin-object member-list end-object | (relative to the URI of that origin server) for obtaining information | |||
member-list = [ path ns path-v vs ] | about the potential tracking behavior of resources provided by that origin | |||
tracking ns tracking-v | server. A tracking status resource MAY be used for verification of DNT | |||
[ vs received ns received-v ] | support, as described in section 5.7 Using the Tracking Status. | |||
[ vs response ns response-v ] | ||||
[ vs same-site ns same-site-v ] | ||||
[ vs partners ns partners-v ] | ||||
[ vs policy ns policy-v ] | ||||
[ vs edit ns edit-v ] | ||||
[ vs options ns options-v ] | ||||
*( vs extension ) | ||||
path = %x22 "path" %x22 | A valid retrieval request (e.g., a GET in HTTP) on the well-known URI MUST | |||
path-v = string ; URI absolute-path | result in either a successful response containing a machine-readable | |||
representation of the site-wide tracking status, as defined below, or a | ||||
sequence of redirects that leads to such a representation. A user agent | ||||
MAY consider failure to provide access to such a representation equivalent | ||||
to the origin server not implementing this protocol. The representation | ||||
MAY be cached, as described in section 5.5.5 Caching. | ||||
tracking = %x22 "tracking" %x22 | 5.5.2 Request-specific Tracking Status | |||
tracking-v = true / false | ||||
If an origin server has multiple, request-specific tracking policies, such | ||||
that the tracking status might differ depending on some aspect of the | ||||
request (e.g., method, target URI, header fields, data, etc.), the origin | ||||
server MAY provide an additional subtree of well-known resources | ||||
corresponding to each of those distinct tracking statuses. The Tk response | ||||
header field (section 5.4 Tk Header Field for HTTP Responses) can include | ||||
a status-id to indicate which specific tracking status resource applies to | ||||
the current request. | ||||
received = %x22 "received" %x22 | The tracking status resource space is defined by the following URI | |||
received-v = null / string | Template [URI-TEMPLATE]: | |||
response = %x22 "response" %x22 | /.well-known/dnt{/status-id} | |||
response-v = %x22 r-codes %x22 | ||||
r-codes = ("t" / "n") *reasons | 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 | ||||
response containing | ||||
Example 6 | ||||
reasons = "1" ; first-party | Tk: 1;ahoy | |||
/ "3" ; third-party | ||||
/ "a" ; advertising audits | ||||
/ "c" ; prior consent | ||||
/ "f" ; fraud prevention | ||||
/ "g" ; geographic/regional compliance | ||||
/ "q" ; frequency capping | ||||
/ "r" ; referrals | ||||
/ ALPHA / DIGIT ; TBD | ||||
same-site = %x22 "same-site" %x22 | refers to the specific tracking status resource | |||
same-site-v = array-of-strings | ||||
partners = %x22 "partners" %x22 | /.well-known/dnt/ahoy | |||
partners-v = array-of-strings | ||||
policy = %x22 "policy" %x22 | Resources within the request-specific tracking status resource space are | |||
represented using the same format as a site-wide tracking status resource. | ||||
policy-v = string ; URI-reference | 5.5.3 Representation | |||
edit = %x22 "edit" %x22 | The representation of a tracking status resource shall be provided in the | |||
edit-v = string ; URI-reference | "application/json" format [RFC4627] and MUST conform to the ABNF for | |||
status-object (except that the members within each member-list MAY be | ||||
provided in any order). | ||||
options = %x22 "options" %x22 | The following example tracking status representation illustrates all of | |||
options-v = string ; URI-reference | the fields defined by this specification, most of which are optional. | |||
extension = object | Example 7 | |||
{ | ||||
"tracking": "1", | ||||
"same-party": [ | ||||
"example.com", | ||||
"example_vids.net", | ||||
"example_stats.com" | ||||
], | ||||
"third-party": [ | ||||
"api.example.net" | ||||
], | ||||
"audit": [ | ||||
"http://auditor.example.org/727073" | ||||
], | ||||
"policy": "/tracking.html", | ||||
"control": "http://example.com/your/data" | ||||
} | ||||
array-of-strings = begin-array | A tracking status representation consists of a single status-object | |||
[ string *( vs string ) ] | containing members that describe the tracking status applicable to the | |||
end-array | designated resource. | |||
ns = <name-separator (:), as defined in [RFC4627]> | status-object = begin-object member-list end-object | |||
vs = <value-separator (,), as defined in [RFC4627]> | ||||
begin-array = <begin-array ([), as defined in [RFC4627]> | member-list = tracking ns tracking-v [tracking-q] | |||
end-array = <end-array (]), as defined in [RFC4627]> | [ vs same-party ns same-party-v ] | |||
begin-object = <begin-object ({), as defined in [RFC4627]> | [ vs third-party ns third-party-v ] | |||
[ vs audit ns audit-v ] | ||||
[ vs policy ns policy-v ] | ||||
[ vs control ns control-v ] | ||||
*( vs extension ) | ||||
end-object = <end-object (}), as defined in [RFC4627]> | A status-object MUST have a member named tracking that contains a single | |||
object = <object, as defined in [RFC4627]> | character tracking status value (section 5.2 Tracking Status Value), | |||
string = <string, as defined in [RFC4627]> | optionally followed by one or more tracking qualifiers (section 5.3 | |||
Tracking Status Qualifier Values) . | ||||
true = <true, as defined in [RFC4627]> | tracking = %x22 "tracking" %x22 | |||
false = <false, as defined in [RFC4627]> | ||||
null = <null, as defined in [RFC4627]> | ||||
For example, the following demonstrates a minimal tracking status | ||||
representation that is applicable to any resource that does not perform | ||||
tracking. | ||||
5.2 Tk Header Field for HTTP Responses | Example 8 | |||
5.2.1 Motivation | {"tracking": "N"} | |||
This specification defines an HTTP response header, in order to meet the | An OPTIONAL member named same-party MAY be provided with an array value | |||
following needs: | containing a list of domain names that the origin server claims are the | |||
same party, to the extent they are referenced by the designated resource, | ||||
since all data collected via those references share the same data | ||||
controller. | ||||
* User-agents can confirm that the server with which they are | same-party = %x22 "same-party" %x22 | |||
communicating has received their DNT request. | same-party-v = array-of-strings | |||
* User-agents can determine which class of practices the server intends | ||||
to follow when processing this particular request. | ||||
* User-agents can determine if a server believes that the user has | ||||
out-of-band consented to let them do additional tracking, and may be | ||||
able to review or modify that consent. | ||||
* Servers make a clear promise about how they will process data gathered | ||||
from this particular request. | ||||
* Servers have a well-known place to point to more information about | ||||
their tracking/privacy practice. | ||||
* Servers can provide customized information to clients if desired. | ||||
An origin server may indicate the tracking status for a particular request | An OPTIONAL member named third-party MAY be provided with an array value | |||
by including a Tk header field in the corresponding response. If a request | containing a list of domain names for third-party services that might be | |||
contains a DNT-field-value starting with "1", an origin server should send | invoked while using the designated resource but do not share the same data | |||
a Tk header field in the corresponding response. | controller as the designated resource. | |||
If an origin server chooses not to send a Tk header field, then the user | third-party = %x22 "third-party" %x22 | |||
agent will not know if the tracking preference has been received or if it | third-party-v = array-of-strings | |||
will be honored. This may have negative consequences for the site, such as | ||||
triggering preventive measures on the user agent or being flagged as | ||||
non-compliant by tools that look for response header fields. | ||||
ISSUE-107: Exact format of the response header? | An OPTIONAL member named audit MAY be provided with an array value | |||
[PENDING REVIEW] See the proposal in this section. | containing a list of URI references to external audits of the designated | |||
resource's tracking policy and tracking behavior in compliance with this | ||||
protocol. Preferably, the audit references are to resources that describe | ||||
the auditor and the results of that audit; however, if such a resource is | ||||
not available, a reference to the auditor is sufficient. | ||||
ISSUE-120: Should the response header be mandatory (must) or recommended | audit = %x22 "audit" %x22 | |||
(should) | audit-v = array-of-strings | |||
[PENDING REVIEW] Text in above paragraphs. | ||||
5.2.2 Tk ABNF | An OPTIONAL member named policy MAY be provided with a string value | |||
containing a URI-reference to a human-readable document that describes the | ||||
tracking policy for the designated resource. The content of such a policy | ||||
document is beyond the scope of this protocol and only supplemental to | ||||
what is described by this machine-readable tracking status representation. | ||||
The Tk header field is defined as follows: | policy = %x22 "policy" %x22 | |||
policy-v = string ; URI-reference | ||||
Tk-Response = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [C | If the tracking status value is 1 and the designated resource is being | |||
FWS] [ reason-code ] | operated by an outsourced service provider on behalf of a first party, the | |||
Tk-Status = no-dnt | origin server MUST identify the responsible first party via the domain of | |||
/ not-tracking | the policy URI, if present, or by the domain owner of the origin server. | |||
/ first-party | If no policy URI is provided and the origin server domain is owned by the | |||
/ service-provider | service provider, then the service provider is the first party. | |||
no-dnt = "0" | ||||
not-tracking = "1" | ||||
first-party = %x66 ; lowercase f | ||||
service-provider = %x73 ; lowercase s | ||||
opt-in-flag = "1" | ||||
reason-code = ALPHA | ||||
5.2.3 Tk Semantics | An OPTIONAL member named control MAY be provided with a string value | |||
containing a URI-reference to a resource for giving the user control over | ||||
personal data collected by the designated resource (and possibly other | ||||
resources); a control member SHOULD be provided if the tracking status | ||||
value indicates prior consent (C). Such a control resource might include | ||||
the ability to review past data collected, 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 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 out-of-band consent mechanism is | ||||
beyond the scope of this protocol. | ||||
Tk: 0 (no-dnt) indicates that this party does not comply with | control = %x22 "control" %x22 | |||
[TRACKING-COMPLIANCE]. | control-v = string ; URI-reference | |||
Tk: 1 (not-tracking) indicates that: | Additional extension members MAY be provided in the status-object to | |||
support future enhancements to this protocol. A user agent SHOULD ignore | ||||
extension members that it does not recognize. | ||||
* this party complies with [TRACKING-COMPLIANCE], and | extension = object | |||
* this party will process this request according to the specification | ||||
for 3rd parties in [TRACKING-COMPLIANCE]. | ||||
Tk: f (first-party) indicates that: | array-of-strings = begin-array | |||
[ string *( vs string ) ] | ||||
end-array | ||||
* this party complies with [TRACKING-COMPLIANCE], | ns = <name-separator (:), as defined in [[!RFC4627]]> | |||
* this resource is intended to be served as a first party, and | vs = <value-separator (,), as defined in [[!RFC4627]]> | |||
* this party will process this request according to the specifications | ||||
for 1st parties in [TRACKING-COMPLIANCE]. | ||||
Tk: s (service-provider) indicates that: | begin-array = <begin-array ([), as defined in [[!RFC4627]]> | |||
end-array = <end-array (]), as defined in [[!RFC4627]]> | ||||
begin-object = <begin-object ({), as defined in [[!RFC4627]]> | ||||
end-object = <end-object (}), as defined in [[!RFC4627]]> | ||||
object = <object, as defined in [[!RFC4627]]> | ||||
string = <string, as defined in [[!RFC4627]]> | ||||
true = <true, as defined in [[!RFC4627]]> | ||||
false = <false, as defined in [[!RFC4627]]> | ||||
null = <null, as defined in [[!RFC4627]]> | ||||
* this party complies with [TRACKING-COMPLIANCE], | Note that the tracking status resource space applies equally to both | |||
* this resource is intended to be used in the context of third party | first-party and third-party services. An example of a third-party tracking | |||
acting as an outsourced service provider for a first party, and | status is | |||
* this party will process this request according to the exemption for a | ||||
third party acting as an outsourced service provider for a first | ||||
party, as described in [TRACKING-COMPLIANCE]. | ||||
The opt-in-flag indicates that the server believes that the user has | Example 9 | |||
affirmatively consented to allow this party additional permission to track | ||||
them. Unless the opt-in-flag is included, the server asserts that will act | ||||
in responding to this request as if the user has not affirmatively | ||||
consented to allow this party additional permission to track them. | ||||
The reason-code can be used when requesting more information (see below). | { | |||
"tracking": "3", | ||||
"policy": "/privacy.html", | ||||
"control": "/your/data", | ||||
} | ||||
5.2.4 More Information | 5.5.4 Status Checks are Not Tracked | |||
If a reason code is specified in the response, the well-known resource | When sending a request for the tracking status, a user agent SHOULD | |||
defined here must exist; if an opt-in-flag is included, the wel--known | include any cookie data [COOKIES] (set prior to the request) that would be | |||
resource defined here should exist; otherwise it may exist. | 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 | ||||
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 can understand and manage their opt-in by visiting the well-known | All requests on the tracking status resource space, including the | |||
URI | site-wide tracking status resource, MUST NOT be tracked, irrespective of | |||
the presence, value, or absence of a DNT header field, cookies, or any | ||||
other information in the request. In addition, all responses to those | ||||
requests, including the responses to redirected tracking status requests, | ||||
MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have | ||||
content that initiates tracking beyond what was already present in the | ||||
request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie | ||||
or Set-Cookie2 header field received in such a response. | ||||
/.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code} | 5.5.5 Caching | |||
relative to the request-target. | 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 | ||||
response SHOULD be marked as cacheable and assigned 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 service's tracking | ||||
behavior might increase. 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 can be increased is seven days after the | ||||
policy has been updated to reflect the new behavior, since old copies | ||||
might persist in caches until the expiration is triggered. A service's | ||||
tracking behavior can be reduced at any time, with or without a | ||||
corresponding change to the tracking status resource. | ||||
The information at this URI provides additional information about this | If the tracking status is only applicable to all users that have the same | |||
party's privacy practices and practices, particularly concerning the | DNT-field-value, then the response MUST either be marked with a Vary | |||
opt-in-flag. | header field that includes "DNT" in its field-value or marked as not | |||
reusable by a shared cache without revalidation with a Cache-Control | ||||
header field containing one of the following directives: "private", | ||||
"no-cache", "no-store", or "max-age=0". | ||||
The above well-known URI has not yet been reconciled with the similar but | If the tracking status is only applicable to the specific user that | |||
distinct definition for the tracking status resource. We anticipate that | requested it, then the response MUST include a Cache-Control header field | |||
one or the other will be adopted, or the two proposals will be merged. | containing one of the following directives: "private", "no-cache", or | |||
"no-store". | ||||
5.2.5 Implementation and Usage Considerations | 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 | ||||
most). A public Internet site that intends to change its tracking status | ||||
to increase tracking behavior MUST update the tracking status resource in | ||||
accordance with that planned behavior at least twenty-four hours prior to | ||||
activating that new behavior on the service. | ||||
Implementers should use caution when allowing caching of resources on | A user agent that adjusts behavior based on active verification of | |||
which an opt-in flag is included. If caching is not carefully managed, | tracking status, relying on cached tracking status responses to do so, | |||
there is a risk of sending a response intended for opted-in users to users | SHOULD check responses to its state-changing requests (e.g., POST, PUT, | |||
who haven't opted in. | DELETE, etc.) for a Tk header field with the U tracking status value, as | |||
described in section 5.4.3 Indicating an Interactive Status Change. | ||||
Implementers should carefully choose the cache properties of the items at | 5.6 Status Code for Tracking Required | |||
the well-known URI. The content at these locations must be correct for the | ||||
entire cache duration, otherwise users who load stale cached copies of | ||||
these resources may be misled. | ||||
Any party can use the not-tracking response: this response just indicates | If an origin server receives a request with DNT:1, does not have | |||
a behavior. If a first party complies with the third-party definition, | out-of-band consent for tracking this user, and wishes to deny access to | |||
they are free to send this response. However, the first-party and service | the requested resource until the user provides some form of user-granted | |||
provider responses indicate both a behavior and an intention about that | exception or consent for tracking, then the origin server SHOULD send an | |||
party's status. It would be deceptive to send the first-party header on a | HTTP error response with a status code of 409 (Conflict) and a message | |||
resource which is only ever embedded as a third party. | body that describes why the request has been refused and how one might | |||
supply the required consent or exception to avoid this conflict [HTTP11]. | ||||
The no-dnt response should not be used on requests which are processed in | The 409 response SHOULD include a user authentication mechanism in the | |||
accordance with [TRACKING-COMPLIANCE]. An entity which implements DNT | header fields and/or message body if user login is one of the ways through | |||
should not use this response. | which access is granted. | |||
When embedding content from other sites, consider how that site expects | 5.7 Using the Tracking Status | |||
their content to be used. If you embed/link to an object on another site, | ||||
it's possible that the resource will send a first-party response even | ||||
though it is now in a third-party context because the designer of that | ||||
site never intended that object to be embedded. If a resource always sends | ||||
a third-party response, there is no risk of this inconsistent response. | ||||
Only the first-party outsourcer of service-provider objects should ever | ||||
embed them. | ||||
5.2.6 Examples | Note | |||
Tk: 1 | This section is for collecting use cases that describe questions a user | |||
agent might have about tracking status and how the protocol can be used to | ||||
answer such questions. More cases are needed. | ||||
The site is a third or first party, in compliance with the definitions of | 5.7.1 Discovering Deployment | |||
a 3rd party that is not tracking. | ||||
Tk: 1 1 agreed | The presence of a site-wide tracking status representation is a claim that | |||
the service conforms to this protocol for a given user agent. Hence, | ||||
deployment of this protocol for a given service can be discovered by | ||||
making a retrieval request on the site-wide tracking resource | ||||
/.well-known/dnt relative to the service URI. | ||||
The site is a third party, that believes it has an explicit opt-in from | If the response is an error, then the service does not implement this | |||
the user; more information can be found at: | standard. If the response is a redirect, then follow the redirect to | |||
obtain the tracking status (up to some reasonable maximum of redirects to | ||||
avoid misconfigured infinite request loops). If the response is | ||||
successful, obtain the tracking status representation from the message | ||||
payload, if possible, or consider it an error. | ||||
/.well-known/dnt?status=1&opt-in=1&r=agreed | 5.7.2 Preflight Checks | |||
5.3 Status Code for Tracking Required | 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 | ||||
reviewed prior to making use of those services and prior to making | ||||
requests on third-party resources referenced by those services. | ||||
An HTTP error response status code might be useful for indicating that the | A user agent MAY check the tracking status for a designated resource by | |||
site refuses service unless the user either logs into a subscription | first making a retrieval request for the site-wide tracking status | |||
account or agrees to an exception to DNT for this site and its contracted | representation, as described above, and then parsing the representation as | |||
third-party sites. | JSON to extract the Javascript status-object. If retrieval is unsuccessful | |||
or parsing results in a syntax error, the user agent SHOULD consider the | ||||
site to be non-conformant with this protocol. | ||||
6. Site-specific Exceptions | The status-object is supposed to have a member named tracking containing | |||
the tracking status value. The meaning of each tracking status value is | ||||
defined in section 5.2 Tracking Status Value. | ||||
ISSUE-118: Should requesting a user-agent-managed site-specific exception | If the tracking status value is N, then the origin server claims that no | |||
be asynchronous? | tracking is performed for the designated resource for at least the next 24 | |||
[PENDING REVIEW] As proposed below. | hours or until the Cache-Control information indicates that this response | |||
expires. | ||||
ISSUE-115: Should sites be able to manage site-specific tracking | If the tracking status value is not N, then the origin server claims that | |||
exceptions outside of the user-agent-managed system? | it might track the user agent for requests on the URI being checked for at | |||
least the next 24 hours or until the Cache-Control information indicates | ||||
that this response expires. | ||||
ISSUE-111: Different DNT values to signify existence of site-specific | 6. User-Granted Exceptions | |||
exception | ||||
6.1 Overview | 6.1 Overview | |||
This section is non-normative. | This section is non-normative. | |||
Exceptions to Do Not Track, including site-specific exceptions, are | User-granted exceptions to Do Not Track, including site-specific | |||
managed by the user agent. A resource should rely on the DNT header it | exceptions, are managed by the user agent. A resource should rely on the | |||
receives to determine the user's preference for tracking with respect to | DNT header it receives to determine the user's preference for tracking | |||
that particular request. An API is provided so that sites may request and | with respect to that particular request. An API is provided so that sites | |||
check the status of exceptions for tracking. | may request and check the status of exceptions for tracking. | |||
We anticipate that many user-agents might provide a prompt to users when | We anticipate that many user-agents might provide a prompt to users when | |||
this API is used, or to store exceptions. Questions of user interface | this API is used, or to store exceptions. Questions of user interface | |||
specifics - for granting, configuring, storing, syncing and revoking | specifics - for granting, configuring, storing, syncing and revoking | |||
exceptions - are explicitly left open to implementers. | exceptions - are explicitly left open to implementers. | |||
6.2 Motivating principles and use cases | Issue 144: What constraints on user agents should be imposed for | |||
user/granted exceptions | ||||
[OPEN] but mostly addressed in the proposal here. | ||||
6.2 Motivating Principles and Use Cases | ||||
This section is non-normative. | This section is non-normative. | |||
The following principles guide the design of the user-agent-managed | The following principles guide the design of user-agent-managed | |||
site-specific exceptions proposal. | exceptions. | |||
* Content providers may wish to prompt visitors to their properties to | * Content providers may wish to prompt visitors to their properties to | |||
"opt back in" to tracking for behavioral advertising or similar | opt back in to tracking for behavioral advertising or similar purposes | |||
purposes when they arrive with the Do Not Track setting enabled. | when they arrive with the Do Not Track setting enabled. | |||
* Privacy-conscious users may wish to view or edit all the site-specific | * Privacy-conscious users may wish to view or edit all the exceptions | |||
exceptions they've granted in a single, consistent user interface, | they've granted in a single, consistent user interface, rather than | |||
rather than managing preferences in a different way on every content | managing preferences in a different way on every content provider or | |||
provider or tracker's privacy page. | tracker's privacy page. | |||
* Granting an exception in one context (while browsing a news site) | * Granting an exception in one context (while browsing a news site) | |||
should not apply that exception to other contexts (browsing a medical | should not apply that exception to other contexts (browsing a medical | |||
site) that may not be expected. | site) that may not be expected. | |||
* Tracking providers should not ever have to second-guess a user's | * Tracking providers should not ever have to second-guess a user's | |||
expressed Do Not Track preference. | expressed Do Not Track preference. | |||
* The solution should not require cross-domain communication between a | * The solution should not require cross-domain communication between a | |||
first party publisher and its third party trackers. | first-party publisher and its third parties. | |||
When asking for a site-specific exception, the top-level domain making the | ||||
request may be making some implicit or explicit claims as to the actions | ||||
and behavior of its third parties; for this reason, it might want to | ||||
establish exceptions for only those for which it is sure that those claims | ||||
are true. (Consider a site that has some trusted advertisers and analytics | ||||
providers, and some mashed-up content from less-trusted sites). For this | ||||
reason, there is support both for explicitly named sites, as well as | ||||
support for granting an exception to all third-parties on a given site | ||||
(site-wide exception, using the conceptual wild-card "*"). | ||||
There are some cases in which a user may desire a site to be allowed to | ||||
track them on any top-level domain. An API is provided so that the site | ||||
and the user may establish such a web-wide exception. | ||||
6.3 Exception model | 6.3 Exception model | |||
6.3.1 Site pairs | 6.3.1 Introduction | |||
This section describes the effect of the APIs in terms of a logical | ||||
processing model; this model describes the behavior, but should not be | ||||
read 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 tracker. A user might - for instance - want AnalytiCo to | site, and the target. A user might - for instance - want AnalytiCo to be | |||
track them on Example News, but not on Example Medical. To simplify | allowed to track them on Example News, but not on Example Medical. To | |||
language used in this API specification, we define two terms: | simplify language used in this API specification, we define three terms: | |||
* This site is the domain name of the top-level document origin of this | * Top-Level Domain (TLD) is the domain name of the top-level document | |||
DOM: essentially the fully qualified domain name in the address bar. | origin of this DOM: essentially the fully qualified domain name in the | |||
* A tracker is a domain name which is not operated by the same party | address bar. | |||
which operates this site, and which may be an origin for embedded | * A target site is a domain name which is the target of an HTTP request, | |||
resources on this site. | and which may be an origin for embedded resources on the indicated | |||
top-level domain. | ||||
* The document origin of a script is the domain of origin of the | ||||
document that caused that script to be loaded (not necessarily the | ||||
same as the origin of the script itself). | ||||
For instance, if the document at | For instance, if the document at | |||
http://web.exnews.com/news/story/2098373.html references the resources | http://web.exnews.com/news/story/2098373.html references the resources | |||
http://exnews.analytico.net/1x1.gif and | http://exnews.analytico.net/1x1.gif and | |||
http://widgets.exsocial.org/good-job-button.js, this site is | http://widgets.exsocial.org/good-job-button.js, the top-level domain is | |||
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both | web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both | |||
trackers. | targets. | |||
ISSUE-112: How are sub-domains handled for site-specific exceptions? | Issue 112: How are sub-domains handled for site-specific exceptions? | |||
Should a request for a tracking exception apply to all subdomains of the | ||||
first party making the request? Or should a first party explicitly list | [PENDING REVIEW] Should a request for a tracking exception apply to all | |||
the subdomains that it's asking for? Similarly, should third party | subdomains of the first party making the request? Or should a first party | |||
subdomains be allowed (e.g. *.tracker.com)? | explicitly list the subdomains that it's asking for? Similarly, should | |||
third-party subdomains be allowed (e.g. *.tracker.com)? | ||||
Proposal: Exceptions are requested for fully-qualified domain names. | Proposal: Exceptions are requested for fully-qualified domain names. | |||
The domains that enter into the behavior of the APIs include: | ||||
* As described above, the document origin active at the time of the | ||||
call, and; | ||||
* Domain names passed to the API. | ||||
Domains that enter into the decision over what DNT header to be sent in a | ||||
given HTTP request include: | ||||
* The top-level domain of the current context; | ||||
* The target of the HTTP request. | ||||
Note | ||||
Note that these strict, machine-discoverable, concepts may not match the | ||||
definitions of first and third party; in particular, sites themselves need | ||||
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 | ||||
them. | ||||
The calls cause the following steps to occur: | ||||
* First, the UA somehow confirms with the user that they agree to the | ||||
grant of exception, if not already granted; | ||||
* If they agree, then the UA adds to its local database one or more | ||||
site-pair duplets [document-origin, target]; one or other of these may | ||||
be a wild-card ("*"); | ||||
* While the user is browsing a given site (top-level domain), and a DNT | ||||
header is to be sent to a target domain, if the duplet [top-level | ||||
domain, target domain] matches any duplet in the database, then a | ||||
DNT:0 header is sent, otherwise DNT:1 is sent. | ||||
Note | ||||
Note that a site may record no that it has previously asked for, and been | ||||
denied, an exception, if it wishes to avoid repeatedly asking the user for | ||||
an exception. | ||||
6.3.2 Exception use by browsers | 6.3.2 Exception use by browsers | |||
If a user wishes to be tracked by a tracker on this site, this should | If a user agrees to allow tracking by a target on the top-level domain, | |||
result in two user-agent behaviors: | this should result in two user-agent behaviors: | |||
1. If requests to the tracker for resources that are part of the DOM for | 1. If requests to the target for resources that are part of the DOM for | |||
pages on this site include a DNT header, that header must be DNT:OFF. | pages on top-level domain include a DNT header, that header MUST be | |||
DNT:0. | ||||
2. Responses to the JavaScript API indicated should be consistent with | 2. Responses to the JavaScript API indicated should be consistent with | |||
this user preference (see below). | this user preference (see below). | |||
Issue 159: How do we allow sites that mash-in ad-supported content to | ||||
maintain their own trusted third parties? | ||||
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 domain 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 | ||||
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} has been granted, and later remove only one or two of {a, b, c} from | ||||
its logical database of remembered grants. This assures sites that the set | ||||
of sites they need for operational integrity is treated as a unit. Each | ||||
separate call to an API is a separate unit. | ||||
When a user-agent receives an API request for an exception that already | ||||
exists (i.e. the grant is recorded in its database), it SHOULD bypass | ||||
asking the user to confirm, and simply re-confirm the grant to the caller. | ||||
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. | |||
ISSUE-111: Different DNT values to signify existence of site-specific | 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 | ||||
such-and-such top-level domain is asking for an exception for a specific | ||||
set of sites, rather than listing them by name; or the user-agent may | ||||
decide to ask the user for a site-wide exception, effectively ignoring the | ||||
list of domain names, if supplied. | ||||
Conversely, if a wild-card is used, the user may be told that the | ||||
top-level domain is asking for an exception for all third-parties that | ||||
are, or will be, embedded in it. | ||||
Issue 111: Different DNT values to signify existence of user-granted | ||||
exception | exception | |||
Should the user agent send a different DNT value to a first party site if | ||||
there exist site-specific exceptions for that first party? (e.g. DNT:2 | ||||
implies "I have Do Not Track enabled but grant permissions to some third | ||||
parties while browsing this domain") | ||||
Proposal: No, this API provides client-side means for sites to request | ||||
that information. Sites may also employ cookies to recall a user's past | ||||
response. | ||||
6.4 JavaScript API for site-specific exceptions | [POSTPONED] Should the user agent send a different DNT value to a first | |||
party site if there exist user-granted exceptions for that first party? | ||||
(e.g. DNT:2 implies "I have Do Not Track enabled but grant permissions to | ||||
some third parties while browsing this domain") | ||||
Proposal: A previous proposal was that it can add itself to the list (i.e. | ||||
an exception for [site, site]) and then it will get DNT:0, but DNT:0 to a | ||||
first party means something different (that it can pass data to third | ||||
parties, and tracking is permitted). It would be better to have an | ||||
indication in the DNT header that one or more site-specific exceptions | ||||
exist for the given target (i.e. that there is at least one duplet in the | ||||
database with target as its first host name), for example "DNT:1E" where E | ||||
means you are a first party with one or more active exceptions. | ||||
6.4 JavaScript API for Site-specific Exceptions | ||||
6.4.1 API to request site-specific exceptions | ||||
[NoInterfaceObject] | [NoInterfaceObject] | |||
interface NavigatorDoNotTrack { | interface NavigatorDoNotTrack { | |||
void requestSiteSpecificTrackingException (sequence<DOMString> arrayOfDom | void requestSiteSpecificTrackingException ( | |||
ainStrings, TrackingResponseCallback callback, optional siteName, optional e | TrackingResponseCallback callback, | |||
xplanationString, optional detailURI); | optional sequence<DOMString> arrayOfDomainStrings, | |||
optional optional siteName, | ||||
optional optional explanationString, | ||||
optional optional detailURI | ||||
); | ||||
}; | }; | |||
6.4.1 Methods | ||||
requestSiteSpecificTrackingException | requestSiteSpecificTrackingException | |||
Called by a page to request or confirm a site-specific tracking | Called by a page to request or confirm a user-granted tracking | |||
exception. | exception. | |||
Parameter Type Nullable Optional Descripti on | Parameter Type Nullable Optional Descripti on | |||
arrayOfDomainStrings sequence<DOMString> * * | ||||
callback TrackingResponseCallback * * | callback TrackingResponseCallback * * | |||
siteName * * | arrayOfDomainStrings sequence<DOMString> * * | |||
explanationString * * | siteName optional * * | |||
detailURI * * | explanationString optional * * | |||
detailURI optional * * | ||||
Return type: void | Return type: void | |||
[Callback, NoInterfaceObject] | [Callback, NoInterfaceObject] | |||
interface TrackingResponseCallback { | interface TrackingResponseCallback { | |||
void handleEvent (boolean granted); | void handleEvent (integer granted); | |||
}; | }; | |||
6.4.2 Methods | ||||
handleEvent | handleEvent | |||
The callback is called by the user agent to indicate the user's | The callback is called by the user agent to indicate the user's | |||
response. | response. | |||
Parameter Type Nullable Optional Description | Parameter Type Nullable Optional Description | |||
granted boolean * * | granted integer * * | |||
Return type: void | Return type: void | |||
The requestSiteSpecificTrackingException method takes two mandatory | The requestSiteSpecificTrackingException method takes one mandatory | |||
arguments: | argument: | |||
* arrayOfDomainStrings, a JavaScript array of strings, and | ||||
* callback, a method that will be called when the request is complete. | * callback, a method that will be called when the request is complete. | |||
It also takes three optional arguments: | It also takes four optional arguments: | |||
* siteName, a string for the name of this site, | * arrayOfDomainStrings, a JavaScript array of strings, | |||
* siteName, a user-readable string for the name of the top-level domain, | ||||
* explanationString, a short explanation of the request, and | * explanationString, a short explanation of the request, and | |||
* detailURI, a location at which further information about this request | * detailURI, a location at which further information about this request | |||
can be found. | can be found. | |||
Each string in arrayOfDomainStrings specifies a tracker. The special | If the request does not include the arrayOfDomainStrings, then this | |||
string "*" signifies all trackers. When called, | request is for a site-wide exception. Otherwise each string in | |||
requestSiteSpecificTrackingException must return immediately, then | arrayOfDomainStrings specifies a target. When called, | |||
asynchronously determine whether the user wants the requested exceptions. | requestSiteSpecificTrackingException MUST return immediately, then | |||
asynchronously determine whether the user grants the requested | ||||
exception(s). | ||||
The granted parameter passed to the callback is the user's response; true | If the list arrayOfDomainStrings is supplied, the user-agent MAY choose to | |||
indicates the user wants an exception on this site for all of the trackers | ask the user to grant a site-wide exception. If it does so, and the user | |||
specified in arrayOfDomainStrings. The response false indicates that the | agrees, it MUST indicate this in the response callback. | |||
user does not want an exception on this site for at least one of the | ||||
trackers specified in arrayOfDomainStrings. | The execution of this API and the use of the resulting permission (if | |||
granted) use the 'implicit' parameter, when the API is called, the | ||||
document origin. This forms the first part of the duplet in the logical | ||||
model, and hence in operation will be compared with the top-level domain. | ||||
The granted parameter passed to the callback is the user's response; The | ||||
response | ||||
* 0 indicates that user does not grant the exception on top-level domain | ||||
for the indicated targets. | ||||
* 1 indicates that the request was for specific targets and the the user | ||||
grants an exception on top-level domain for those specific targets. | ||||
* 2 indicates the user grants a site-wide exception on top-level domain | ||||
for all targets; the request may have been for specific targets or for | ||||
a site-wide exception. | ||||
If permission is granted for an explicit list, then the set of duplets | ||||
(one per target): | ||||
[document-origin, target] | ||||
is added to the database of remembered grants. | ||||
If permission is granted for a site-wide exception, then the duplets: | ||||
[document-origin, * ] | ||||
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' preferences may change. | valid immediately, and users' preferences may change. | |||
A user agent may use an interactive method to ask the user about their | A user agent MAY use an interactive method to ask the user about their | |||
preferences, so sites should not assume that the callback function will be | preferences, so sites SHOULD NOT assume that the callback function will be | |||
called immediately. | called immediately. | |||
ISSUE-109: siteSpecificTrackingExceptions property has fingerprinting | 6.4.2 API to Cancel a Site-specific Exception | |||
risks: is it necessary? | ||||
[PENDING REVIEW] It has been removed from the proposal. | ||||
6.5 User interface guidelines | [NoInterfaceObject] | |||
interface NavigatorDoNotTrack { | ||||
boolean removeSiteSpecificTrackingException (); | ||||
}; | ||||
removeSiteSpecificTrackingException | ||||
Ensures that the database of remembered grants no longer contains | ||||
any duplets for which the first part is the current document | ||||
origin; i.e., no duplets [document-origin, target] for any target. | ||||
There is no callback. After the call has been made, it is assured | ||||
that there are no site-specific or site-wide exceptions for the | ||||
given top-level-domain. | ||||
No parameters. | ||||
Return type: boolean | ||||
This returns a boolean indicating, when true, that the call has succeeded, | ||||
and that the database of grants no longer contains, or very soon will no | ||||
longer contain, the indicated grant(s); when false, some kind of | ||||
processing error occurred. | ||||
6.5 JavaScript API for Web-wide Exceptions | ||||
6.5.1 API to Request a Web-wide Exception | ||||
[NoInterfaceObject] | ||||
interface NavigatorDoNotTrack { | ||||
void requestWebWideTrackingException ( | ||||
TrackingResponseCallback callback, | ||||
optional siteName, | ||||
optional optional explanationString, | ||||
optional optional detailURI | ||||
); | ||||
}; | ||||
requestWebWideTrackingException | ||||
If permission is granted, then the single duplet [ * , | ||||
document-origin] is added to the database of remembered grants. | ||||
The parameters are as described above in the request for | ||||
site-specific exceptions. | ||||
Parameter Type Nullable Optional Descripti | ||||
on | ||||
callback TrackingResponseCallback * * | ||||
siteName * * | ||||
explanationString optional * * | ||||
detailURI optional * * | ||||
Return type: void | ||||
Users may wish to configure exceptions for a certain trusted tracker | ||||
across all sites. This API requests the addition of a web-wide grant for a | ||||
specific site, to the database. | ||||
6.5.2 API to cancel a web-wide exception | ||||
[NoInterfaceObject] | ||||
interface NavigatorDoNotTrack { | ||||
boolean removeWebWideTrackingException (); | ||||
}; | ||||
removeWebWideTrackingException | ||||
Ensures that the database of remembered grants no longer contains | ||||
the duplet [ * , document-origin]. There is no callback. After the | ||||
call has been made, the indicated pair is assured not to be in the | ||||
database. The same matching as is used for determining which | ||||
header to send is used to detect which entry (if any) to remove | ||||
from the database. | ||||
No parameters. | ||||
Return type: boolean | ||||
This returns a boolean indicating, when true, that the call has succeeded, | ||||
and that the database of grants no longer contains, or very soon will no | ||||
longer contain, the indicated grant; when false, some kind of processing | ||||
error occurred. | ||||
6.6 Querying a host's exception status | ||||
Issue 160: Do we need an exception-query API? | ||||
[PENDING REVIEW] It might be useful, and 'complete the model', if we had a | ||||
JS API that told a host what its current exception status is in a given | ||||
context. See proposal here. | ||||
Proposal: Specifically, an API QueryExceptionStatus() which examines the | ||||
document origin of the script, the current top-level domain and returns an | ||||
empty string if no DNT header would be sent to that document origin, or | ||||
the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise. | ||||
[NoInterfaceObject] | ||||
interface NavigatorDoNotTrack { | ||||
DOMString requestDNTStatus (); | ||||
}; | ||||
requestDNTStatus | ||||
Returns the same string value that would be sent in a | ||||
DNT-field-value (section 4.2 DNT Header Field for HTTP Requests) | ||||
to a target that is the document-origin of the request, in the | ||||
context of the current top-level domain. If no DNT header would be | ||||
sent (e.g. because a tracking preference is not enabled) the | ||||
return value is null. | ||||
No parameters. | ||||
Return type: DOMString | ||||
6.7 Transfer of an exception to another third party | ||||
A site may request an exception for one or more third party services used | ||||
in conjunction with its own offer. Those third party services may wish to | ||||
use other third parties to complete the request in a chain of | ||||
interactions. The first party will not necessarily know in advance whether | ||||
a known third party will use some other third parties. | ||||
If a user-agent sends a tracking exception to a given combination of | ||||
origin server and a named third party, the user agent will send DNT:0 to | ||||
that named third party. By receiving the DNT:0 header, the named third | ||||
party acquires the permission to track the user agent and collect the data | ||||
and process it in any way allowed by the legal system it is operating in. | ||||
Furthermore, the named third party receiving the DNT:0 header acquires at | ||||
least the right to collect data and process it for the given interaction | ||||
and any secondary use unless it receives a DNT:1 header from that | ||||
particular identified user agent. | ||||
The named third party is also allowed to transmit the collected data for | ||||
uses related to this interaction to its own sub-services and | ||||
sub-sub-services (transitive permission). The tracking permission request | ||||
triggered by the origin server is thus granted to the named third party | ||||
and its sub-services. This is even true for sub-services that would | ||||
normally receive a DNT:1 web-wide preference from the user-agent if the | ||||
user agent interacted with this service directly. | ||||
For advertisement networks this typically would mean that the collection | ||||
and auction system chain can use the data for that interaction and combine | ||||
it with existing profiles and data. The sub-services to the named third | ||||
party do not acquire an independent right to process the data for | ||||
independent secondary uses unless they, themselves, receive a DNT:0 header | ||||
from the user agent (as a result of their own request or the request of a | ||||
first-party). In our example of advertisement networks that means the | ||||
sub-services can use existing profiles in combination with the data | ||||
received, but they can not store the received information into a profile | ||||
until they have received a DNT:0 of their own. | ||||
A named third party acquiring an exception with this mechanism MUST make | ||||
sure that sub-services it uses acknowledge this constraint by requiring | ||||
the use of the appropriate tracking status value and qualifier, which is | ||||
"XX" (such as "tl"), from its sub-sub-services. | ||||
The permission acquired by the DNT mechanism does not override retention | ||||
limitations found in the legal system the content provider or the named | ||||
third party are operating in. | ||||
Issue 168: What is the correct way for sub-services to signal that they | ||||
are taking advantage of a transferred exception? | ||||
When the status values and qualifiers are fixed, the penultimate paragraph | ||||
will probably need adjusting to match. The use of "tl" (which meant | ||||
"tracking but only in accordance with local laws" when this text was | ||||
written) doesn't seem right, as the text talks, essentially, of the | ||||
sub-sub-service acting on behalf of the site that received the DNT:0 | ||||
header, which might suggest something more like "CS" (service provision to | ||||
a third-party that received consent). | ||||
6.8 User interface guidelines | ||||
This section is non-normative. | This section is non-normative. | |||
User agents are free to implement exception management user interfaces as | User agents are free to implement exception management user interfaces as | |||
they see fit. Some agents might provide a prompt to the user at the time | they see fit. Some agents might provide a prompt to the user at the time | |||
of the request. Some agents might allow users to configure this preference | of the request. Some agents might allow users to configure this preference | |||
in advance. In either case, the user agent responds with the user's | in advance. In either case, the user agent responds with the user's | |||
preference. | preference. | |||
In general, it is expected that the site will explain, in its online | ||||
content, the need for an exception, and the consequences of granting or | ||||
denying an exception, to the user, and guide. The call to the API and the | ||||
resulting request for user confirmation should not be a 'surprise' to the | ||||
user, or require much explanation on the part of the user-agent. | ||||
A user agent that chooses to implement a prompt to present tracking | A user agent that chooses to implement a prompt to present tracking | |||
exception requests to the user might provide an interface like the | exception requests to the user might provide an interface like the | |||
following: | following: | |||
Example News (web.exnews.com) would like to know | Example 10 | |||
whether you permit tracking by the following parties: | ||||
* exnews.analytico.net | Example News (web.exnews.com) would like to confirm | |||
* widgets.exsocial.org | that you permit tracking by a specific set of sites (click | |||
here for their names). | ||||
Example News says: | Example News says: | |||
"These sites allow Example News to see how we're | These sites allow Example News to see how we're | |||
doing, and provide useful features of the Example News | doing, and provide useful features of the Example News | |||
experience." [More info] | experience. [More info] | |||
[Allow Tracking] [Deny Tracking Request] | [Allow Tracking] [Deny Tracking Request] | |||
In this example, the domains listed are those specified in | In this example, the domains listed are those specified in | |||
arrayOfDomainStrings, the phrase "Example News" is from siteName, and the | arrayOfDomainStrings, the phrase Example News is from siteName, and the | |||
explanationString is displayed for the user with a "More info" link | explanationString is displayed for the user with a More info link pointing | |||
pointing to detailURI. | to detailURI. | |||
The user agent might then store that decision, and answer future requests | The user agent might then store that decision, and answer future requests | |||
based on this stored preference. User agents might provide users with | based on this stored preference. A user agent might provide the user with | |||
granular choice over which tracking origins are granted site-specific | an interface to explicitly remove (or add) user-granted exceptions. | |||
exceptions and which are not (using checkboxes, for example). User agents | ||||
might automatically clear site-specific exceptions after a period of time | ||||
or in response to user activity, like leaving a private browsing mode or | ||||
using a preference manager to edit their chosen exceptions. If a user | ||||
agent retains user preferences, it might provide the user with an | ||||
interface to explicitly add or remove site-specific exceptions. | ||||
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. | |||
In some user-agent implementations, decisions to grant exceptions may have | In some user-agent implementations, decisions to grant exceptions may have | |||
been made in the past (and since forgotten) or may have been made by other | been made in the past (and since forgotten) or may have been made by other | |||
users of the device. Thus, exceptions may not always represent the current | users of the device. Thus, exceptions may not always represent the current | |||
preferences of the user. Some user agents might choose to provide ambient | preferences of the user. Some user agents might choose to provide ambient | |||
notice that user-opted tracking is ongoing, or easy access to view and | notice that user-opted tracking is ongoing, or easy access to view and | |||
control these preferences. Users may desire options to edit exceptions | control these preferences. Users may desire options to edit exceptions | |||
either at the time of tracking or in a separate user interface. This might | either at the time of tracking or in a separate user interface. This might | |||
allow the user to edit their preferences for a site they do not trust | allow the user to edit their preferences for a site they do not trust | |||
without visiting that site. | without visiting that site. | |||
ISSUE: Should there be a normative requirement for the existence of a | Issue 140: Do we need site-specific exceptions, i.e., concrete list of | |||
revocation mechanism? (raised by npdoty) | permitted third parties for a site? | |||
6.6 Exceptions without a DNT header | [PENDING REVIEW] In this section; yes, as some sites may have a mix of | |||
trusted/needed third parties, and others that either don't need to track, | ||||
or aren't as trusted, or both. But all sites are (a) told what they got | ||||
granted (list, or *) and (b) are assured that requests will be treated | ||||
'atomically'. | ||||
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 | User agents MAY instantiate | |||
NavigatorDoNotTrack.requestSiteSpecificTrackingException even when | NavigatorDoNotTrack.requestSiteSpecificTrackingException even when | |||
navigator.doNotTrack is null. Sites should test for the existence of | navigator.doNotTrack is null. Sites SHOULD test for the existence of | |||
requestSiteSpecificTrackingException before calling the method. If an | requestSiteSpecificTrackingException before calling the method. If an | |||
exception is granted in this context and the user-agent stores that | exception is granted in this context and the user-agent stores that | |||
preference, a user agent may send a DNT:0 header even if a tracking | preference, a user agent may send a DNT:0 header even if a tracking | |||
preference isn't expressed for other requests. Persisted preferences may | preference isn't expressed for other requests. Persisted preferences MAY | |||
also affect which header is transmitted if a user later chooses to express | also affect which header is transmitted if a user later chooses to express | |||
a tracking preference. | a tracking preference. | |||
Note | ||||
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.7 Web-wide exceptions | 6.10 Fingerprinting | |||
Users may wish to configure exceptions for a certain trusted tracker | ||||
across several or all sites. User agent configuration of these preferences | ||||
is outside the scope of this specification. | ||||
ISSUE-113: Should there be a JavaScript API to prompt for a Web-wide | ||||
exception? | ||||
PROPOSAL: User agents can provide configuration options outside the scope | ||||
of this specification. | ||||
6.8 Fingerprinting | ||||
By storing a client-side configurable state and providing functionality to | By storing a client-side configurable state and providing functionality to | |||
learn about it later, this API might facilitate user fingerprinting and | learn about it later, this API might facilitate user fingerprinting and | |||
tracking. User agent developers ought to consider the possibility of | tracking. User agent developers ought to consider the possibility of | |||
fingerprinting during implementation and might consider rate-limiting | fingerprinting during implementation and might consider rate-limiting | |||
requests or using other heuristics to mitigate fingerprinting risk. User | requests or using other heuristics to mitigate fingerprinting risk. User | |||
agents should clear stored site-specific exceptions when the user chooses | agents SHOULD clear stored user-granted exceptions when the user chooses | |||
to clear cookies or other client-side state. | to clear cookies or other client-side state. | |||
ISSUE-114: Guidance or mitigation of fingerprinting risk for | ||||
user-agent-managed site-specific tracking exceptions | ||||
PENDING REVIEW Above text provides guidance for user agent developers. | ||||
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 Nick Doty (W3C/MIT), Roy T. Fielding (Adobe), Tom | contributions from Nick Doty (W3C/MIT), Rob van Eijk (Invited Expert), | |||
Lowenthal (Mozilla), Aleecia M. McDonald (Mozilla), Matthias Schunter | Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Jonathan Mayer | |||
(IBM), John Simpson (Consumer Watchdog), David Singer (Apple), Shane Wiley | (Stanford), Aleecia M. McDonald (Mozilla), Matthias Schunter (IBM), | |||
John Simpson (Consumer Watchdog), David Singer (Apple), David Wainberg | ||||
(Network Advertising Initiative), Rigo Wenning (W3C/ERCIM), Shane Wiley | ||||
(Yahoo!), and Andy Zeigler (Microsoft). | (Yahoo!), 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 DOM API for NavigatorDoNotTrack is based on the Web | (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web | |||
Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot | Tracking Protection submission by Andy Zeigler, Adrian Bateman, and | |||
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 | |||
[ABNF] | [ABNF] | |||
D. Crocker and P. Overell. Augmented BNF for Syntax | D. Crocker and P. Overell. Augmented BNF for Syntax | |||
Specifications: ABNF. January 2008. Internet RFC 5234. URL: | Specifications: ABNF. January 2008. Internet RFC 5234. URL: | |||
http://www.ietf.org/rfc/rfc5234.txt | http://www.ietf.org/rfc/rfc5234.txt | |||
[HTTP11] | [HTTP11] | |||
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June | R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June | |||
1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt | 1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt | |||
[NAVIGATOR] | [NAVIGATOR] | |||
Ian Hickson, David Hyatt. Navigator interface in HTML5. 15 April | Robin Berjon; Travis Leithead; Silvia Pfeiffer; Erika Doyle | |||
2011. Editors' draft. (Work in progress.) URL: | Navara; Edward O'Connor; Ian Hickson. The Navigator object - | |||
http://dev.w3.org/html5/spec/timers.html#navigator | System state and capabilities - HTML5. 28 September 2012. Editors' | |||
draft. (Work in progress.) URL: | ||||
http://dev.w3.org/html5/spec/system-state-and-capabilities.html#the | ||||
-navigator-object | ||||
[RFC2119] | [RFC2119] | |||
S. Bradner. Key words for use in RFCs to Indicate Requirement | S. Bradner. Key words for use in RFCs to Indicate Requirement | |||
Levels. March 1997. Internet RFC 2119. URL: | Levels. March 1997. Internet RFC 2119. URL: | |||
http://www.ietf.org/rfc/rfc2119.txt | http://www.ietf.org/rfc/rfc2119.txt | |||
[RFC4627] | [RFC4627] | |||
D. Crockford. The application/json Media Type for JavaScript | D. Crockford. The application/json Media Type for JavaScript | |||
Object Notation (JSON) July 2006. Internet RFC 4627. URL: | Object Notation (JSON) July 2006. Internet RFC 4627. URL: | |||
http://www.ietf.org/rfc/rfc4627.txt | http://www.ietf.org/rfc/rfc4627.txt | |||
[TRACKING-COMPLIANCE] | [TRACKING-COMPLIANCE] | |||
Justin Brookman; Sean Harvey; Erica Newland; Heather West. | Justin Brookman; Sean Harvey; Erica Newland; Heather West. | |||
Tracking Compliance and Scope. 13 March 2012. W3C Working Draft. | Tracking Compliance and Scope. 2 October 2012. W3C Working Draft. | |||
(Work in progress.) URL: | (Work in progress.) URL: | |||
http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ | http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/ | |||
[WEBIDL] | [WEBIDL] | |||
Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. | Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. | |||
(Work in progress.) URL: | (Work in progress.) URL: | |||
http://www.w3.org/TR/2011/WD-WebIDL-20110927/ | http://www.w3.org/TR/2011/WD-WebIDL-20110927/ | |||
B.2 Informative references | B.2 Informative references | |||
[COOKIES] | [COOKIES] | |||
Adam Barth. HTTP State Management Mechanism. April 2011. Internet | Adam Barth. HTTP State Management Mechanism. April 2011. Internet | |||
Proposed Standard RFC 6265. URL: | Proposed Standard RFC 6265. URL: | |||
http://www.rfc-editor.org/rfc/rfc6265.txt | http://www.rfc-editor.org/rfc/rfc6265.txt | |||
[KnowPrivacy] | [KnowPrivacy] | |||
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | |||
2009. URL: | 2009. URL: | |||
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | |||
[RFC3986] | ||||
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource | ||||
Identifier (URI): Generic Syntax. January 2005. Internet RFC 3986. | ||||
URL: http://www.ietf.org/rfc/rfc3986.txt | ||||
[RFC5785] | [RFC5785] | |||
Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform | Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform | |||
Resource Identifiers (URIs). April 2010. Internet Proposed | Resource Identifiers (URIs). April 2010. Internet Proposed | |||
Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt | Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt | |||
[URI-TEMPLATE] | [URI-TEMPLATE] | |||
Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David | Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David | |||
Orchard. URI Template. 26 January 2012. Internet Draft (work in | Orchard. URI Template. March 2012. Internet RFC 6570. URL: | |||
progress). URL: | http://www.rfc-editor.org/rfc/rfc6570.txt | |||
http://tools.ietf.org/html/draft-gregorio-uritemplate-08 | ||||
End of changes. 226 change blocks. | ||||
741 lines changed or deleted | 1059 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/ |