dnt-wd-20120313.txt | dnt-20120914.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Preference Expression (DNT) | Tracking Preference Expression (DNT) | |||
W3C Working Draft 13 March 2012 | W3C Editor's Draft 14 September 2012 | |||
This version: | This version: | |||
http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ | http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | |||
Latest published version: | Latest published version: | |||
http://www.w3.org/TR/tracking-dnt/ | http://www.w3.org/TR/tracking-dnt/ | |||
Latest editor's draft: | Latest editor's draft: | |||
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html | |||
Previous version: | ||||
http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/ | ||||
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) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. | |||
W3C liability, trademark and document use rules apply. | W3C liability, trademark and document use rules apply. | |||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
Abstract | Abstract | |||
skipping to change at line 47 | skipping to change at line 44 | |||
for allowing the user to approve site-specific exceptions to DNT as | for allowing the user to approve site-specific exceptions to DNT as | |||
desired. | desired. | |||
Status of This Document | Status of This Document | |||
This section describes the status of this document at the time of its | This section describes the status of this document at the time of its | |||
publication. Other documents may supersede this document. A list of | publication. Other documents may supersede this document. A list of | |||
current W3C publications and the latest revision of this technical report | current W3C publications and the latest revision of this technical report | |||
can be found in the W3C technical reports index at http://www.w3.org/TR/. | can be found in the W3C technical reports index at http://www.w3.org/TR/. | |||
This document is a snapshot of live discussions within the Tracking | This document is an editors' strawman reflecting a snapshot of live | |||
Protection Working Group. It does not yet capture all of our work. For | discussions within the Tracking Protection Working Group. It does not yet | |||
example, we have issues that are [PENDING REVIEW] with complete text | capture all of our work. For example, we have issues that are [PENDING | |||
proposals that did not make it into this draft. Text in white is typically | REVIEW] with complete text proposals that have not yet made it into this | |||
[CLOSED]: we have reached a consensus decision. Text in blue boxes | draft. Text in blue boxes presents multiple options the group is | |||
presents multiple options the group is considering. In some cases we are | considering. An issue tracking system is available for recording raised, | |||
close to agreement, and in others we have more to discuss. An issue | open, pending review, closed, and postponed issues regarding this | |||
tracking system is available for recording raised, open, pending review, | document. | |||
closed, and postponed issues regarding this document. This draft, | ||||
published 13 March 2012, is substantially different from and more complete | ||||
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 an | |||
Working Draft. This document is intended to become a W3C Recommendation. | Editor's Draft. If you wish to make comments regarding this document, | |||
If you wish to make comments regarding this document, please send them to | please send them to public-tracking@w3.org (subscribe, archives). All | |||
public-tracking@w3.org (subscribe, archives). All feedback is welcome. | feedback is welcome. | |||
Publication as a Working Draft does not imply endorsement by the W3C | Publication as an Editor's Draft does not imply endorsement by the W3C | |||
Membership. This is a draft document and may be updated, replaced or | Membership. This is a draft document and may be updated, replaced or | |||
obsoleted by other documents at any time. It is inappropriate to cite this | obsoleted by other documents at any time. It is inappropriate to cite this | |||
document as other than work in progress. | document as other than work in progress. | |||
This document was produced by a group operating under the 5 February 2004 | This document was produced by a group operating under the 5 February 2004 | |||
W3C Patent Policy. W3C maintains a public list of any patent disclosures | W3C Patent Policy. W3C maintains a public list of any patent disclosures | |||
made in connection with the deliverables of the group; that page also | made in connection with the deliverables of the group; that page also | |||
includes instructions for disclosing a patent. An individual who has | includes instructions for disclosing a patent. An individual who has | |||
actual knowledge of a patent which the individual believes contains | actual knowledge of a patent which the individual believes contains | |||
Essential Claim(s) must disclose the information in accordance with | Essential Claim(s) must disclose the information in accordance with | |||
skipping to change at line 93 | skipping to change at line 83 | |||
* 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 183 | |||
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 | |||
skipping to change at line 223 | skipping to change at line 220 | |||
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 | 0 This user prefers to allow tracking on the target | |||
site. | 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; | ||||
* the user has not yet made a choice for a specific preference; or, | ||||
* the user has chosen not to transmit a preference. | ||||
* the user agent does not implement this protocol; or | ||||
* the user agent does implement the protocol, but the user does not wish | ||||
to indicate a preference at this time. | ||||
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, and the | |||
is for no tracking, and there is not a site-specific exception for the | preference is for no tracking, and there is not a site-specific exception | |||
origin server targeted by this request. | for the 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 | ||||
is not enabled, the doNotTrack attribute for each top-level page | ||||
MUST have a value of null. | ||||
4.3.3 Implements | The doNotTrack attribute only provides the user's general tracking | |||
preference, independent of any user-granted exceptions or out-of-band | ||||
consent. A script wishing to determine the specific tracking preference | ||||
for a given document origin is expected to use the API in section 6.6 | ||||
Querying a host's exception status. | ||||
Navigator implements NavigatorDoNotTrack; | A user agent MUST provide a doNotTrack attribute value that is consistent | |||
with the user's current tracking preference that would be expressed via | ||||
the DNT header field. However, changes to the user's preference might | ||||
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. | ||||
Objects implementing the Navigator interface [NAVIGATOR] (e.g., the | Issue 84: Make DNT status available to JavaScript | |||
window.navigator object) MUST also implement the NavigatorDoNotTrack | ||||
interface. An instance of NavigatorDoNotTrack is obtained by using | ||||
binding-specific casting methods on an instance of Navigator. | ||||
ISSUE-84: Make DNT status available to JavaScript | [PENDING REVIEW] Updated text in this section. | |||
[OPEN] The API above has been deemed inadequate due to origin restrictions | ||||
on embedded javascript by reference. We are awaiting new text to resolve | ||||
this issue. | ||||
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 | The last paragraph may be more appropriate in the compliance document, as | |||
appropriate in the compliance document, as it discusses compliance. | it discusses compliance. | |||
5. Communicating a Tracking Status | 5. Communicating a Tracking Status | |||
The next two sections detail two proposals how to communicate tracking | 5.1 Overview | |||
status: | ||||
* Well-known URI to allow user agent to retrieve tracking status for a | The primary goals of this protocol-expressing the user's preference and | |||
site | adhering to that preference-can be accomplished without any response from | |||
* HTTP Response header to communicate tracking status for a request | 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. | ||||
This is work in progress. The WG has not yet decided which of these | Unfortunately, providing a dynamic indication of tracking compliance on | |||
options (or both) to choose. The WG is currently working on a resolution | every HTTP response is not feasible, since it would have the effect of | |||
but nevertheless appreciates input on this open issue. We are currently | disabling caching for the entire Web. Instead, this protocol defines a | |||
working on a proposal which combines the Tk response header and Tracking | combination of response mechanisms that allow the information to be | |||
Status Resource. It would make the TSR compulsory and the Tk header | communicated without making every response dynamic. | |||
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 | 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. | ||||
5.1.1 Resource Definition | Issue 120: Should the response header be mandatory (MUST) or recommended | |||
(SHOULD) | ||||
An origin server MUST provide a tracking status resource at the well-known | [PENDING REVIEW] The site-wide resource is mandatory; the header field is | |||
identifier [RFC5785] | optional, except for the single MUST case above. | |||
Issue 124: Alternative DNT implementations that replace HTTP headers with | ||||
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.2 Tracking Status Value | ||||
A tracking status value is a short notation for communicating how a | ||||
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. | ||||
For a site-wide tracking status resource, the designated resource to which | ||||
the tracking status applies is any resource on the same origin server. For | ||||
a Tk response header field, the corresponding request target is the | ||||
designated resource and remains so for any subsequent request-specific | ||||
tracking status resource referred to by that field. | ||||
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. | ||||
status meaning | ||||
N None: The designated resource does not perform | ||||
tracking of any kind, not even for a permitted use, | ||||
and does not make use of any data collected from | ||||
tracking. | ||||
1 First party: The designated resource is designed for | ||||
use within a first-party context and conforms to the | ||||
requirements on a first 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. | ||||
3 Third party: The designated resource is designed for | ||||
use within a third-party context and conforms to the | ||||
requirements on a third party. | ||||
X 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 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. | ||||
C Consent: The designated resource believes it has | ||||
received prior consent for tracking this user, user | ||||
agent, or device, perhaps via some mechanism not | ||||
defined by this specification, and that prior | ||||
consent overrides the tracking preference expressed | ||||
by this protocol. | ||||
U 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 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 | ||||
values 1 and 3 indicate how the designated resource is designed to | ||||
conform, not the nature of the request. Hence, if a user agent is making a | ||||
request in what appears to be a third-party context and the tracking | ||||
status value indicates that the designated resource is designed only for | ||||
first-party conformance, then either the context has been misunderstood | ||||
(both are actually the same party) or the resource has been referenced | ||||
incorrectly. For the request-specific tracking status resource, an | ||||
indication of first or third party as the status value describes how the | ||||
resource conformed to that specific request, and thus indicates both the | ||||
nature of the request (as viewed by the origin server) and the applicable | ||||
set of requirements to which the origin server claims to conform. | ||||
The tracking status value is case sensitive, as defined formally by the | ||||
following ABNF. | ||||
tracking-v = "1" ; "1" - first-party | ||||
/ "3" ; "3" - third-party | ||||
/ %x43 ; "C" - consent | ||||
/ %x4E ; "N" - none | ||||
/ %x55 ; "U" - updated | ||||
/ %x58 ; "X" - dynamic | ||||
Issue 137: Does hybrid tracking status need to distinguish between first | ||||
party (1) and outsourcing service provider acting as a first party (s) | ||||
[PENDING REVIEW] No, in practice there may be dozens of service providers | ||||
on any given request. If the designated resource is operated by a service | ||||
provider acting as a first party, then the responsible first party is | ||||
identified by the policy link or the owner of the origin server domain. | ||||
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. | ||||
5.3 Tracking Status Qualifier Values | ||||
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. | ||||
Issue | ||||
ISSUE-136: Resolve dependencies of the TPE on the compliance | ||||
specification. | ||||
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. | ||||
qualifier meaning | ||||
Audit: Tracking is limited to that necessary for | ||||
a an external audit of the service context and the | ||||
data collected is minimized accordingly. | ||||
Ad frequency capping: Tracking is limited to | ||||
c frequency capping and the data collected is | ||||
minimized accordingly. | ||||
Fraud prevention: Tracking is limited to that | ||||
f necessary for preventing or investigating | ||||
fraudulent behavior and security violations; the | ||||
data collected is minimized accordingly. | ||||
Local constraints: Tracking is limited to what | ||||
l is required by local law, rule, or regulation | ||||
and the data collected is minimized accordingly. | ||||
Referrals: Tracking is limited to collecting | ||||
r referral information and the data collected is | ||||
minimized accordingly. | ||||
Qualifiers that indicate limitations on tracking correspond to the | ||||
specific permitted uses in [TRACKING-COMPLIANCE]. An origin server | ||||
indicating one or more of those permitted uses also indicates that it | ||||
conforms to the requirements associated with those permitted uses. | ||||
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). | ||||
Future extensions to this protocol might define additional characters as | ||||
qualifiers from the ext-qualifier set (consisting of the remaining unused | ||||
lowercase letters, dot, dash, and underscore). Recipients SHOULD ignore | ||||
extension qualifiers that they do not understand. | ||||
The tracking qualifier value is case sensitive, as defined formally by the | ||||
following ABNF. | ||||
tracking-q = tracking-q-v* | ||||
tracking-q-v = %x61 ; "a" - audit | ||||
/ %x63 ; "c" - capping | ||||
/ %x66 ; "f" - fraud | ||||
/ %x6C ; "l" - local | ||||
/ %x72 ; "r" - referral | ||||
5.4 Tk Header Field for HTTP Responses | ||||
5.4.1 Definition | ||||
The Tk response header field is hereby defined as an OPTIONAL means for | ||||
indicating the tracking status that applied to the corresponding request | ||||
and as a REQUIRED means for indicating that a state-changing request has | ||||
resulted in an interactive change to the tracking status. | ||||
Tk-field-name = "Tk" ; case-insensitive | ||||
Tk-field-value = tracking-v [tracking-q] [ ";" status-id ] | ||||
The Tk field-value begins with a tracking status value (section 5.2 | ||||
Tracking Status Value), optionally followed by one or more tracking | ||||
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). | ||||
For example, a Tk header field for a resource that claims not to be | ||||
tracking would look like: | ||||
Example 2 | ||||
Tk: N | ||||
whereas a Tk header field for a resource that might perform tracking | ||||
(though not necessarily for every request) and conforms to the third-party | ||||
requirements of [TRACKING-COMPLIANCE], while claiming the audit exception, | ||||
would look like: | ||||
Example 3 | ||||
Tk: 3a | ||||
Issue 107: Exact format of the response header? | ||||
[PENDING REVIEW] See the proposal in this section. | ||||
5.4.2 Referring to a Request-specific Tracking Status Resource | ||||
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 OPTIONAL | ||||
status-id portion of the Tk field-value indicates which specific tracking | ||||
status resource applies to the current request. | ||||
status-id = 1*id-char ; case-sensitive | ||||
id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" | ||||
For example, a response containing | ||||
Example 4 | ||||
Tk: 1;fRx42 | ||||
indicates that the target resource claims to conform to the first-party | ||||
requirements of [TRACKING-COMPLIANCE] and that an applicable tracking | ||||
status representation can be obtained by performing a retrieval request on | ||||
/.well-known/dnt/fRx42 | ||||
If a Tk field-value has a tracking status value of X (dynamic), then a | ||||
status-id MUST be included in the field-value. | ||||
5.4.3 Indicating an Interactive Status Change | ||||
We anticipate that interactive mechanisms might be used, beyond the scope | ||||
of this specification, that have the effect of asking for and obtaining | ||||
prior consent for tracking, or for modifying prior indications of consent. | ||||
For example, the tracking status resource's status-object defines a | ||||
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. | ||||
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). | ||||
Example 5 | ||||
Tk: U | ||||
5.5 Tracking Status Resource | ||||
5.5.1 Site-wide Tracking Status | ||||
An origin server MUST provide a site-wide tracking status resource at the | ||||
well-known identifier [RFC5785] | ||||
/.well-known/dnt | /.well-known/dnt | |||
(relative to the URI of that origin server) for obtaining information | (relative to the URI of that origin server) for obtaining information | |||
about the potential tracking behavior of services provided by that origin | about the potential tracking behavior of resources provided by that origin | |||
server. A tracking status resource MAY be used for verification of DNT | server. A tracking status resource MAY be used for verification of DNT | |||
support, as described in section 5.1.3 Using the Tracking Status. | support, as described in section 5.7 Using the Tracking Status. | |||
A valid retrieval request (e.g., a GET in [HTTP11]) on the well-known URI | A valid retrieval request (e.g., a GET in HTTP) on the well-known URI MUST | |||
MUST result in either a successful response containing a machine-readable | result in either a successful response containing a machine-readable | |||
representation of the site-wide tracking status, as defined below, or a | representation of the site-wide tracking status, as defined below, or a | |||
sequence of redirects that leads to such a representation. A user agent | sequence of redirects that leads to such a representation. A user agent | |||
MAY consider failure to provide access to such a representation equivalent | MAY consider failure to provide access to such a representation equivalent | |||
to the origin server not implementing this protocol. The representation | to the origin server not implementing this protocol. The representation | |||
might be cached, as described in section 5.1.4 Tracking Status Caching. | MAY be cached, as described in section 5.5.5 Caching. | |||
If an origin server contains multiple services that are controlled by | 5.5.2 Request-specific Tracking Status | |||
distinct parties or that might have differing behavior or policies | ||||
regarding tracking, then it MAY also provide a space of well-known | If an origin server has multiple, request-specific tracking policies, such | |||
resources for obtaining information about the potential tracking behavior | that the tracking status might differ depending on some aspect of the | |||
of each specific service. This parallel tree of resources is called the | request (e.g., method, target URI, header fields, data, etc.), the origin | |||
tracking status resource space. | 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. | ||||
The tracking status resource space is defined by the following URI | The tracking status resource space is defined by the following URI | |||
Template [URI-TEMPLATE]: | Template [URI-TEMPLATE]: | |||
/.well-known/dnt{+pathinfo} | /.well-known/dnt{/status-id} | |||
where the value of pathinfo is equal to the path component [RFC3986] of a | where the value of status-id is a string of URI-safe characters provided | |||
given reference to that origin server, excluding those references already | by a Tk field-value in response to a prior request. For example, a prior | |||
within the above resource space. For example, a reference to | response containing | |||
http://example.com/over/here?q=hello#top | Example 6 | |||
MAY have a corresponding tracking status resource identified by | Tk: 1;ahoy | |||
http://example.com/.well-known/dnt/over/here | refers to the specific tracking status resource | |||
Resources within the tracking status resource space are represented using | /.well-known/dnt/ahoy | |||
the same format as a site-wide tracking status resource. | ||||
All requests for well-known URIs defined here MUST NOT be tracked, | Resources within the request-specific tracking status resource space are | |||
irrespective of the presence, value, or absence of a DNT header, cookies, | represented using the same format as a site-wide tracking status resource. | |||
or any other information in the request. In addition, all responses to | ||||
requests on a tracking status resource, including redirected requests, | ||||
MUST NOT include Set-Cookie or Set-Cookie2 header fields [COOKIES] and | ||||
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 | 5.5.3 Representation | |||
The representation of a tracking status resource shall be provided in the | The representation of a tracking status resource shall be provided in the | |||
"application/json" format [RFC4627] and MUST conform to the ABNF in | "application/json" format [RFC4627] and MUST conform to the ABNF for | |||
section 5.1.5 Tracking Status ABNF. The following is an example tracking | status-object (except that the members within each member-list MAY be | |||
status representation that illustrates all of the fields defined by this | provided in any order). | |||
specification, most of which are optional. | ||||
The following example tracking status representation illustrates all of | ||||
the fields defined by this specification, most of which are optional. | ||||
Example 7 | ||||
{ | { | |||
"path": "/", | "tracking": "1", | |||
"tracking": true, | "same-party": [ | |||
"received": "1", | ||||
"response": "t1", | ||||
"same-site": [ | ||||
"example.com", | "example.com", | |||
"example_vids.net", | "example_vids.net", | |||
"example_stats.com" | "example_stats.com" | |||
], | ], | |||
"partners": [ | "third-party": [ | |||
"api.example-third-party.com" | "api.example.net" | |||
], | ||||
"audit": [ | ||||
"http://auditor.example.org/727073" | ||||
], | ], | |||
"policy": "/tracking.html", | "policy": "/tracking.html", | |||
"edit": "http://example-third-party.com/your/data", | "control": "http://example.com/your/data" | |||
"options": "http://example-third-party.com/your/consent" | ||||
} | } | |||
A tracking status representation consists of a single status-object | A tracking status representation consists of a single status-object | |||
containing members that describe the tracking status applicable to this | containing members that describe the tracking status applicable to the | |||
user agent's request. | designated resource. | |||
If the status-object has an OPTIONAL path member, then this object | status-object = begin-object member-list end-object | |||
describes the tracking status for the entire space of resources that share | ||||
the same path prefix as the value of path. The user agent MUST interpret | ||||
the path value relative to the originally referenced resource, not the | ||||
resource where it obtained the tracking status representation. | ||||
For the site-wide tracking status resource, the presence of a path member | member-list = tracking ns tracking-v [tracking-q] | |||
with a value of "/" indicates that this status-object applies for the | [ vs same-party ns same-party-v ] | |||
entire origin server of the originally referenced resource. If the | [ vs third-party ns third-party-v ] | |||
originally referenced resource's path component does not share the same | [ vs audit ns audit-v ] | |||
prefix as the value of path, or if the path member is absent, then the | [ vs policy ns policy-v ] | |||
tracking status for the referenced resource MAY be obtained via a request | [ vs control ns control-v ] | |||
on the corresponding tracking status resource space. | *( vs extension ) | |||
A status-object MUST have a member named tracking with a boolean value. A | A status-object MUST have a member named tracking that contains a single | |||
value of false indicates that the corresponding resources do not perform | character tracking status value (section 5.2 Tracking Status Value), | |||
tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true | optionally followed by one or more tracking qualifiers (section 5.3 | |||
indicates that the corresponding resource performs tracking and claims to | Tracking Status Qualifier Values) . | |||
conform to all tracking compliance requirements applicable to this site. | ||||
tracking = %x22 "tracking" %x22 | ||||
For example, the following demonstrates a minimal tracking status | For example, the following demonstrates a minimal tracking status | |||
representation that is applicable to any resource that does not perform | representation that is applicable to any resource that does not perform | |||
tracking. | tracking. | |||
{"tracking": false} | Example 8 | |||
The following status-object would indicate that the entire site does not | ||||
perform tracking. | ||||
{"path": "/", "tracking": false} | {"tracking": "N"} | |||
If tracking is true, the status-object MUST include two additional | An OPTIONAL member named same-party MAY be provided with an array value | |||
members, named received and response, and MAY include other members as | containing a list of domain names that the origin server claims are the | |||
described below. | same party, to the extent they are referenced by the designated resource, | |||
since all data collected via those references share the same data | ||||
controller. | ||||
The received member MUST have either a string value equal to the | same-party = %x22 "same-party" %x22 | |||
DNT-field-value received in that request or the value null if no | same-party-v = array-of-strings | |||
DNT-field-value was received. Any invalid characters received in the | ||||
DNT-field-value MUST be elided from the string value to ensure that | ||||
invalid data is not injected into the JSON result. | ||||
The response member MUST have a string value that indicates the status of | An OPTIONAL member named third-party MAY be provided with an array value | |||
tracking applicable specifically to this user in light of the received | containing a list of domain names for third-party services that might be | |||
DNT-field-value. The string value begins with "t" (tracking) or "n" (not | invoked while using the designated resource but do not share the same data | |||
tracking) and MAY be followed by alphanumeric characters that indicate | controller as the designated resource. | |||
reasons for that status, as described in the following table. | ||||
reasons meaning | third-party = %x22 "third-party" %x22 | |||
1 Designed for use as a first-party only | third-party-v = array-of-strings | |||
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 | An OPTIONAL member named audit MAY be provided with an array value | |||
containing a list of domain names that the origin server claims are the | containing a list of URI references to external audits of the designated | |||
same site, to the extent they are referenced on this site, since all data | resource's tracking policy and tracking behavior in compliance with this | |||
collected via those references share the same data controller. | 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. | ||||
An OPTIONAL member named partners MAY be provided with an array value | audit = %x22 "audit" %x22 | |||
containing a list of domain names for third-party services that might | audit-v = array-of-strings | |||
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 | An OPTIONAL member named policy MAY be provided with a string value | |||
containing a URI-reference to a human-readable document that describes the | containing a URI-reference to a human-readable document that describes the | |||
tracking policy for this site. The content of such a policy document is | tracking policy for the designated resource. The content of such a policy | |||
beyond the scope of this protocol and only supplemental to what is | document is beyond the scope of this protocol and only supplemental to | |||
described by this machine-readable tracking status representation. | what is described by this machine-readable tracking status representation. | |||
An OPTIONAL member named edit MAY be provided with a string value | policy = %x22 "policy" %x22 | |||
containing a URI-reference to a resource intended to allow a tracked user | policy-v = string ; URI-reference | |||
agent to review or delete data collected by this site, if any such data | ||||
remains associated with this user agent. The design of such a resource and | ||||
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 | If the tracking status value is 1 and the designated resource is being | |||
containing a URI-reference to a resource intended to allow a user agent to | operated by an outsourced service provider on behalf of a first party, the | |||
opt-in, opt-out, or otherwise modify their consent status regarding data | origin server MUST identify the responsible first party via the domain of | |||
collection by this site. The design of such a resource and how it might | the policy URI, if present, or by the domain owner of the origin server. | |||
implement an out-of-band consent mechanism is beyond the scope of this | If no policy URI is provided and the origin server domain is owned by the | |||
protocol. | service provider, then the service provider is the first party. | |||
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. | ||||
control = %x22 "control" %x22 | ||||
control-v = string ; URI-reference | ||||
Additional extension members MAY be provided in the status-object to | Additional extension members MAY be provided in the status-object to | |||
support future enhancements to this protocol. A user agent SHOULD ignore | support future enhancements to this protocol. A user agent SHOULD ignore | |||
extension members that it does not recognize. | extension members that it does not recognize. | |||
extension = object | ||||
array-of-strings = begin-array | ||||
[ string *( vs string ) ] | ||||
end-array | ||||
ns = <name-separator (:), as defined in [[!RFC4627]]> | ||||
vs = <value-separator (,), as defined in [[!RFC4627]]> | ||||
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]]> | ||||
Note that the tracking status resource space applies equally to both | Note that the tracking status resource space applies equally to both | |||
first-party and third-party services. An example of a third-party tracking | first-party and third-party services. An example of a third-party tracking | |||
status is | status is | |||
Example 9 | ||||
{ | { | |||
"tracking": true, | "tracking": "3", | |||
"received": "1", | ||||
"response": "n", | ||||
"policy": "/privacy.html", | "policy": "/privacy.html", | |||
"edit": "/your/data", | "control": "/your/data", | |||
"options": "/your/consent" | ||||
} | } | |||
ISSUE-47: Should the response from the server indicate a policy that | Issue 47: Should the response from the server indicate a policy that | |||
describes the DNT practices of the server? | describes the DNT practices of the server? | |||
[PENDING REVIEW] The tracking status resource is a machine-readable policy | [PENDING REVIEW] The tracking status resource is a machine-readable policy | |||
and provides a mechanism for supplying a link to a human-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 | Issue 61: A site could publish a list of the other domains that are | |||
associated with them | associated with them | |||
[PENDING REVIEW] The same-site and partners members provide a means to | ||||
list first-party and third-party domains, respectively. | ||||
ISSUE-124: Alternative DNT implementations that replace HTTP headers with | ||||
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 | [PENDING REVIEW] The same-party and third-party members provide a means to | |||
list first-party and third-party domains, respectively. | ||||
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. 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 | ||||
making a retrieval request for the well-known address /.well-known/dnt | ||||
relative to that URI. | ||||
If the response is an error, then the service does not implement this | ||||
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. | ||||
Once the tracking status representation is obtained, parse the | ||||
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 | ||||
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 | ||||
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 | ||||
to see what the origin server has claimed regarding the tracking status | ||||
for this user agent in light of the received DNT-field-value. | ||||
If the first character of the response value is "n", then the origin | ||||
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 | 5.5.4 Status Checks are Not Tracked | |||
server claims that it might 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. | ||||
The remaining characters of the response value might indicate reasons for | When sending a request for the tracking status, a user agent SHOULD | |||
the above choices or limitations that the origin server will place on its | include any cookie data [COOKIES] (set prior to the request) that would be | |||
tracking. | 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 others members of the status-object MAY be used to help the user agent | All requests on the tracking status resource space, including the | |||
differentiate between a site's first-party and third-party services, to | site-wide tracking status resource, MUST NOT be tracked, irrespective of | |||
provide links to additional human-readable information related to the | the presence, value, or absence of a DNT header field, cookies, or any | |||
tracking policy, and to provide links for control over past data collected | other information in the request. In addition, all responses to those | |||
or over some consent mechanism outside the scope of this protocol. | 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. | ||||
5.1.4 Tracking Status Caching | 5.5.5 Caching | |||
If the tracking status is applicable to all users, regardless of the | If the tracking status is applicable to all users, regardless of the | |||
received DNT-field-value or other data received via the request, then the | received DNT-field-value or other data received via the request, then the | |||
response SHOULD be marked as cacheable and assigned a time-to-live | response SHOULD be marked as cacheable and assigned a time-to-live | |||
(expiration or max-use) that is sufficient to enable shared caching but | (expiration or max-use) that is sufficient to enable shared caching but | |||
not greater than the earliest point at which the service's tracking | not greater than the earliest point at which the service's tracking | |||
behavior might increase. For example, if the tracking status response is | 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 | 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 | service's tracking behavior can be increased is seven days after the | |||
policy has been updated to reflect the new behavior, since old copies | policy has been updated to reflect the new behavior, since old copies | |||
might persist in caches until the expiration is triggered. A service's | might persist in caches until the expiration is triggered. A service's | |||
tracking behavior can be reduced at any time, with or without a | tracking behavior can be reduced at any time, with or without a | |||
corresponding change to the tracking status resource. | corresponding change to the tracking status resource. | |||
If the tracking status is only applicable to all users that have the same | If the tracking status is only applicable to all users that have the same | |||
DNT-field-value, then either the response MUST include a Cache-Control | DNT-field-value, then the response MUST either be marked with a Vary | |||
header field with one of the directives "no-cache", "no-store", | header field that includes "DNT" in its field-value or marked as not | |||
"must-revalidate", or "max-age=0", or the response MUST include a Vary | reusable by a shared cache without revalidation with a Cache-Control | |||
header field that includes "DNT" in its field-value. | header field containing one of the following directives: "private", | |||
"no-cache", "no-store", or "max-age=0". | ||||
If the tracking status is only applicable to the specific user that | If the tracking status is only applicable to the specific user that | |||
requested it, then the response MUST include a Cache-Control header field | requested it, then the response MUST include a Cache-Control header field | |||
with one of the directives "no-cache", "no-store", "must-revalidate", or | containing one of the following directives: "private", "no-cache", or | |||
"max-age=0". | "no-store". | |||
Regardless of the cache-control settings, it is expected that user agents | Regardless of the cache-control settings, it is expected that user agents | |||
will check the tracking status of a service only once per session (at | will check the tracking status of a service only once per session (at | |||
most). A public Internet site that intends to change its tracking status | most). A public Internet site that intends to change its tracking status | |||
to increase tracking behavior MUST update the tracking status resource in | to increase tracking behavior MUST update the tracking status resource in | |||
accordance with that planned behavior at least twenty-four hours prior to | accordance with that planned behavior at least twenty-four hours prior to | |||
activating that new behavior on the service. | activating that new behavior on the service. | |||
5.1.5 Tracking Status ABNF | A user agent that adjusts behavior based on active verification of | |||
tracking status, relying on cached tracking status responses to do so, | ||||
SHOULD check responses to its state-changing requests (e.g., POST, PUT, | ||||
DELETE, etc.) for a Tk header field with the U tracking status value, as | ||||
described in section 5.4.3 Indicating an Interactive Status Change. | ||||
The representation of a site's machine-readable tracking status MUST | 5.6 Status Code for Tracking Required | |||
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 | If an origin server receives a request with DNT:1, does not have | |||
member-list = [ path ns path-v vs ] | out-of-band consent for tracking this user, and wishes to deny access to | |||
tracking ns tracking-v | the requested resource until the user provides some form of user-granted | |||
[ vs received ns received-v ] | exception or consent for tracking, then the origin server SHOULD send an | |||
[ vs response ns response-v ] | HTTP error response with a status code of 409 (Conflict) and a message | |||
[ vs same-site ns same-site-v ] | body that describes why the request has been refused and how one might | |||
[ vs partners ns partners-v ] | supply the required consent or exception to avoid this conflict [HTTP11]. | |||
[ vs policy ns policy-v ] | ||||
[ vs edit ns edit-v ] | ||||
[ vs options ns options-v ] | ||||
*( vs extension ) | ||||
path = %x22 "path" %x22 | The 409 response SHOULD include a user authentication mechanism in the | |||
path-v = string ; URI absolute-path | header fields and/or message body if user login is one of the ways through | |||
which access is granted. | ||||
tracking = %x22 "tracking" %x22 | Issue 128: HTTP error status code to signal that tracking is required? | |||
tracking-v = true / false | ||||
received = %x22 "received" %x22 | [PENDING REVIEW] As defined by this section. | |||
received-v = null / string | ||||
response = %x22 "response" %x22 | 5.7 Using the Tracking Status | |||
response-v = %x22 r-codes %x22 | ||||
r-codes = ("t" / "n") *reasons | Note | |||
reasons = "1" ; first-party | This section is for collecting use cases that describe questions a user | |||
/ "3" ; third-party | agent might have about tracking status and how the protocol can be used to | |||
/ "a" ; advertising audits | answer such questions. More cases are needed. | |||
/ "c" ; prior consent | ||||
/ "f" ; fraud prevention | ||||
/ "g" ; geographic/regional compliance | ||||
/ "q" ; frequency capping | ||||
/ "r" ; referrals | ||||
/ ALPHA / DIGIT ; TBD | ||||
same-site = %x22 "same-site" %x22 | 5.7.1 Discovering Deployment | |||
same-site-v = array-of-strings | ||||
partners = %x22 "partners" %x22 | The presence of a site-wide tracking status representation is a claim that | |||
partners-v = array-of-strings | 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. | ||||
policy = %x22 "policy" %x22 | If the response is an error, then the service does not implement this | |||
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. | ||||
policy-v = string ; URI-reference | 5.7.2 Preflight Checks | |||
edit = %x22 "edit" %x22 | A key advantage of providing the tracking status at a resource separate | |||
edit-v = string ; URI-reference | 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. | ||||
options = %x22 "options" %x22 | A user agent MAY check the tracking status for a designated resource by | |||
options-v = string ; URI-reference | first making a retrieval request for the site-wide tracking status | |||
representation, as described above, and then parsing the representation as | ||||
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. | ||||
extension = object | 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. | ||||
array-of-strings = begin-array | If the tracking status value is N, then the origin server claims that no | |||
[ string *( vs string ) ] | tracking is performed for the designated resource for at least the next 24 | |||
end-array | hours or until the Cache-Control information indicates that this response | |||
expires. | ||||
ns = <name-separator (:), as defined in [RFC4627]> | If the tracking status value is not N, then the origin server claims that | |||
vs = <value-separator (,), as defined in [RFC4627]> | 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. | ||||
begin-array = <begin-array ([), as defined in [RFC4627]> | 6. User-Granted Exceptions | |||
end-array = <end-array (]), as defined in [RFC4627]> | ||||
begin-object = <begin-object ({), as defined in [RFC4627]> | ||||
end-object = <end-object (}), as defined in [RFC4627]> | 6.1 Overview | |||
object = <object, as defined in [RFC4627]> | ||||
string = <string, as defined in [RFC4627]> | ||||
true = <true, as defined in [RFC4627]> | This section is non-normative. | |||
false = <false, as defined in [RFC4627]> | ||||
null = <null, as defined in [RFC4627]> | ||||
5.2 Tk Header Field for HTTP Responses | User-granted exceptions to Do Not Track, including site-specific | |||
exceptions, are managed by the user agent. A resource should rely on the | ||||
DNT header it receives to determine the user's preference for tracking | ||||
with respect to that particular request. An API is provided so that sites | ||||
may request and check the status of exceptions for tracking. | ||||
5.2.1 Motivation | 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 | ||||
specifics - for granting, configuring, storing, syncing and revoking | ||||
exceptions - are explicitly left open to implementers. | ||||
This specification defines an HTTP response header, in order to meet the | Issue 144: What constraints on user agents should be imposed for | |||
following needs: | user/granted exceptions | |||
* User-agents can confirm that the server with which they are | [OPEN] but mostly addressed in the proposal here. | |||
communicating has received their DNT request. | ||||
* 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 | 6.2 Motivating Principles and Use Cases | |||
by including a Tk header field in the corresponding response. If a request | ||||
contains a DNT-field-value starting with "1", an origin server SHOULD send | ||||
a Tk header field in the corresponding response. | ||||
If an origin server chooses not to send a Tk header field, then the user | This section is non-normative. | |||
agent will not know if the tracking preference has been received or if it | ||||
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? | The following principles guide the design of user-agent-managed | |||
[PENDING REVIEW] See the proposal in this section. | exceptions. | |||
ISSUE-120: Should the response header be mandatory (MUST) or recommended | * Content providers may wish to prompt visitors to their properties to | |||
(SHOULD) | opt back in to tracking for behavioral advertising or similar purposes | |||
[PENDING REVIEW] Text in above paragraphs. | when they arrive with the Do Not Track setting enabled. | |||
* Privacy-conscious users may wish to view or edit all the exceptions | ||||
they've granted in a single, consistent user interface, rather than | ||||
managing preferences in a different way on every content provider or | ||||
tracker's privacy page. | ||||
* Granting an exception in one context (while browsing a news site) | ||||
should not apply that exception to other contexts (browsing a medical | ||||
site) that may not be expected. | ||||
* Tracking providers should not ever have to second-guess a user's | ||||
expressed Do Not Track preference. | ||||
* The solution should not require cross-domain communication between a | ||||
first-party publisher and its third parties. | ||||
5.2.2 Tk ABNF | 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 "*"). | ||||
The Tk header field is defined as follows: | 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. | ||||
Tk-Response = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [C | 6.3 Exception model | |||
FWS] [ reason-code ] | ||||
Tk-Status = no-dnt | ||||
/ not-tracking | ||||
/ first-party | ||||
/ service-provider | ||||
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 | 6.3.1 Introduction | |||
Tk: 0 (no-dnt) indicates that this party does not comply with | This section describes the effect of the APIs in terms of a logical | |||
[TRACKING-COMPLIANCE]. | processing model; this model describes the behavior, but should not be | |||
read as mandating any specific implementation. | ||||
Tk: 1 (not-tracking) indicates that: | This API considers exceptions which are double-keyed to two domains: the | |||
site, and the target. A user might - for instance - want AnalytiCo to be | ||||
allowed to track them on Example News, but not on Example Medical. To | ||||
simplify language used in this API specification, we define three terms: | ||||
* this party complies with [TRACKING-COMPLIANCE], and | * Top-Level Domain (TLD) is the domain name of the top-level document | |||
* this party will process this request according to the specification | origin of this DOM: essentially the fully qualified domain name in the | |||
for 3rd parties in [TRACKING-COMPLIANCE]. | address bar. | |||
* A target site is a domain name which is the target of an HTTP request, | ||||
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). | ||||
Tk: f (first-party) indicates that: | For instance, if the document at | |||
http://web.exnews.com/news/story/2098373.html references the resources | ||||
http://exnews.analytico.net/1x1.gif and | ||||
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 | ||||
targets. | ||||
* this party complies with [TRACKING-COMPLIANCE], | Issue 112: How are sub-domains handled for site-specific exceptions? | |||
* this resource is intended to be served as a first party, and | ||||
* this party will process this request according to the specifications | ||||
for 1st parties in [TRACKING-COMPLIANCE]. | ||||
Tk: s (service-provider) indicates that: | [PENDING REVIEW] 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 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. | ||||
* this party complies with [TRACKING-COMPLIANCE], | The domains that enter into the behavior of the APIs include: | |||
* this resource is intended to be used in the context of third party | ||||
acting as an outsourced service provider for a first party, and | ||||
* 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 | * As described above, the document origin active at the time of the | |||
affirmatively consented to allow this party additional permission to track | call, and; | |||
them. Unless the opt-in-flag is included, the server asserts that will act | * Domain names passed to the API. | |||
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). | Domains that enter into the decision over what DNT header to be sent in a | |||
given HTTP request include: | ||||
5.2.4 More Information | * The top-level domain of the current context; | |||
* The target of the HTTP request. | ||||
Note | ||||
If a reason code is specified in the response, the well-known resource | Note that these strict, machine-discoverable, concepts may not match the | |||
defined here MUST exist; if an opt-in-flag is included, the wel--known | definitions of first and third party; in particular, sites themselves need | |||
resource defined here SHOULD exist; otherwise it MAY exist. | 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 user can understand and manage their opt-in by visiting the well-known | The calls cause the following steps to occur: | |||
URI | ||||
/.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code} | * 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 | ||||
relative to the request-target. | 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. | ||||
The information at this URI provides additional information about this | 6.3.2 Exception use by browsers | |||
party's privacy practices and practices, particularly concerning the | ||||
opt-in-flag. | ||||
The above well-known URI has not yet been reconciled with the similar but | If a user agrees to allow tracking by a target on the top-level domain, | |||
distinct definition for the tracking status resource. We anticipate that | this should result in two user-agent behaviors: | |||
one or the other will be adopted, or the two proposals will be merged. | ||||
5.2.5 Implementation and Usage Considerations | 1. If requests to the target for resources that are part of the DOM for | |||
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 | ||||
this user preference (see below). | ||||
Issue 158: What is the effect of re-directs for content on the operation | ||||
of exceptions? | ||||
Implementers should use caution when allowing caching of resources on | What is the effect of re-directs, when the source of the re-direct would | |||
which an opt-in flag is included. If caching is not carefully managed, | get a different DNT header than the target, using these matching rules? | |||
there is a risk of sending a response intended for opted-in users to users | Proposal: The re-direct is not relevant; each site gets the DNT header | |||
who haven't opted in. | controlled by the list of grants. | |||
Implementers should carefully choose the cache properties of the items at | Issue 159: How do we allow sites that mash-in add-supported content to | |||
the well-known URI. The content at these locations must be correct for the | maintain their own trusted third parties? | |||
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 | This model does not support mashed-up content which is in turn supported | |||
a behavior. If a first party complies with the third-party definition, | by ads; it's not clear how to distinguish between embedded content which | |||
they are free to send this response. However, the first-party and service | is embedding ads (and hence the top-level domain stays the same) and | |||
provider responses indicate both a behavior and an intention about that | embedded content that should start a new context. | |||
party's status. It would be deceptive to send the first-party header on a | Proposal: For this version of the specification, we don't address this | |||
resource which is only ever embedded as a third party. | corner case. | |||
The no-dnt response should not be used on requests which are processed in | User-agents MUST handle each API request as a 'unit', granting and | |||
accordance with [TRACKING-COMPLIANCE]. An entity which implements DNT | maintaining it in its entirety, or not at all. That means that a | |||
should not use this response. | 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 embedding content from other sites, consider how that site expects | When a user-agent receives an API request for an exception that already | |||
their content to be used. If you embed/link to an object on another site, | exists (i.e. the grant is recorded in its database), it SHOULD bypass | |||
it's possible that the resource will send a first-party response even | asking the user to confirm, and simply re-confirm the grant to the caller. | |||
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 | It is left up to individual user-agent implementations how to determine | |||
and how and whether to store users' tracking preferences. | ||||
The site is a third or first party, in compliance with the definitions of | When an explicit list of domains is provided through the API, their names | |||
a 3rd party that is not tracking. | 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. | ||||
Tk: 1 1 agreed | 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. | ||||
The site is a third party, that believes it has an explicit opt-in from | Issue 111: Different DNT values to signify existence of user-granted | |||
the user; more information can be found at: | exception | |||
/.well-known/dnt?status=1&opt-in=1&r=agreed | [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. | ||||
5.3 Status Code for Tracking Required | 6.4 JavaScript API for Site-specific Exceptions | |||
An HTTP error response status code might be useful for indicating that the | 6.4.1 API to request site-specific exceptions | |||
site refuses service unless the user either logs into a subscription | ||||
account or agrees to an exception to DNT for this site and its contracted | ||||
third-party sites. | ||||
6. Site-specific Exceptions | [NoInterfaceObject] | |||
interface NavigatorDoNotTrack { | ||||
void requestSiteSpecificTrackingException (TrackingResponseCallback callb | ||||
ack, optional sequence<DOMString> arrayOfDomainStrings, optional optional site | ||||
Name, optional optional explanationString, optional optional detailURI); | ||||
}; | ||||
ISSUE-118: Should requesting a user-agent-managed site-specific exception | requestSiteSpecificTrackingException | |||
be asynchronous? | Called by a page to request or confirm a user-granted tracking | |||
[PENDING REVIEW] As proposed below. | exception. | |||
ISSUE-115: Should sites be able to manage site-specific tracking | Parameter Type Nullable Optional Descripti | |||
exceptions outside of the user-agent-managed system? | on | |||
callback TrackingResponseCallback * * | ||||
arrayOfDomainStrings sequence<DOMString> * * | ||||
siteName optional * * | ||||
explanationString optional * * | ||||
detailURI optional * * | ||||
ISSUE-111: Different DNT values to signify existence of site-specific | Return type: void | |||
exception | ||||
6.1 Overview | [Callback, NoInterfaceObject] | |||
interface TrackingResponseCallback { | ||||
void handleEvent (integer granted); | ||||
}; | ||||
This section is non-normative. | handleEvent | |||
The callback is called by the user agent to indicate the user's | ||||
response. | ||||
Exceptions to Do Not Track, including site-specific exceptions, are | Parameter Type Nullable Optional Description | |||
managed by the user agent. A resource should rely on the DNT header it | granted integer * * | |||
receives to determine the user's preference for tracking with respect to | ||||
that particular request. An API is provided so that sites may request and | ||||
check the status of exceptions for tracking. | ||||
We anticipate that many user-agents might provide a prompt to users when | Return type: void | |||
this API is used, or to store exceptions. Questions of user interface | ||||
specifics - for granting, configuring, storing, syncing and revoking | ||||
exceptions - are explicitly left open to implementers. | ||||
6.2 Motivating principles and use cases | The requestSiteSpecificTrackingException method takes one mandatory | |||
argument: | ||||
This section is non-normative. | * callback, a method that will be called when the request is complete. | |||
The following principles guide the design of the user-agent-managed | It also takes four optional arguments: | |||
site-specific exceptions proposal. | ||||
* Content providers may wish to prompt visitors to their properties to | * arrayOfDomainStrings, a JavaScript array of strings, | |||
"opt back in" to tracking for behavioral advertising or similar | * siteName, a user-readable string for the name of the top-level domain, | |||
purposes when they arrive with the Do Not Track setting enabled. | * explanationString, a short explanation of the request, and | |||
* Privacy-conscious users may wish to view or edit all the site-specific | * detailURI, a location at which further information about this request | |||
exceptions they've granted in a single, consistent user interface, | can be found. | |||
rather than managing preferences in a different way on every content | ||||
provider or tracker's privacy page. | ||||
* Granting an exception in one context (while browsing a news site) | ||||
should not apply that exception to other contexts (browsing a medical | ||||
site) that may not be expected. | ||||
* Tracking providers should not ever have to second-guess a user's | ||||
expressed Do Not Track preference. | ||||
* The solution should not require cross-domain communication between a | ||||
first party publisher and its third party trackers. | ||||
6.3 Exception model | If the request does not include the arrayOfDomainStrings, then this | |||
request is for a site-wide exception. Otherwise each string in | ||||
arrayOfDomainStrings specifies a target. When called, | ||||
requestSiteSpecificTrackingException MUST return immediately, then | ||||
asynchronously determine whether the user grants the requested | ||||
exception(s). | ||||
6.3.1 Site pairs | If the list arrayOfDomainStrings is supplied, the user-agent MAY choose to | |||
ask the user to grant a site-wide exception. If it does so, and the user | ||||
agrees, it MUST indicate this in the response callback. | ||||
This API considers exceptions which are double-keyed to two domains: the | The execution of this API and the use of the resulting permission (if | |||
site, and the tracker. A user might - for instance - want AnalytiCo to | granted) use the 'implicit' parameter, when the API is called, the | |||
track them on Example News, but not on Example Medical. To simplify | document origin. This forms the first part of the duplet in the logical | |||
language used in this API specification, we define two terms: | model, and hence in operation will be compared with the top-level domain. | |||
* This site is the domain name of the top-level document origin of this | The granted parameter passed to the callback is the user's response; The | |||
DOM: essentially the fully qualified domain name in the address bar. | response | |||
* A tracker is a domain name which is not operated by the same party | ||||
which operates this site, and which may be an origin for embedded | ||||
resources on this site. | ||||
For instance, if the document at | * 0 indicates that user does not grant the exception on top-level domain | |||
http://web.exnews.com/news/story/2098373.html references the resources | for the indicated targets. | |||
http://exnews.analytico.net/1x1.gif and | * 1 indicates that the request was for specific targets and the the user | |||
http://widgets.exsocial.org/good-job-button.js, this site is | grants an exception on top-level domain for those specific targets. | |||
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both | * 2 indicates the user grants a site-wide exception on top-level domain | |||
trackers. | for all targets; the request may have been for specific targets or for | |||
a site-wide exception. | ||||
ISSUE-112: How are sub-domains handled for site-specific exceptions? | If permission is granted for an explicit list, then the set of duplets | |||
Should a request for a tracking exception apply to all subdomains of the | (one per target): | |||
first party making the request? Or should a first party 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. | ||||
6.3.2 Exception use by browsers | [document-origin, target] | |||
If a user wishes to be tracked by a tracker on this site, this should | is added to the database of remembered grants. | |||
result in two user-agent behaviors: | ||||
1. If requests to the tracker for resources that are part of the DOM for | If permission is granted for a site-wide exception, then the duplets: | |||
pages on this site include a DNT header, that header MUST be DNT:OFF. | ||||
2. Responses to the JavaScript API indicated should be consistent with | ||||
this user preference (see below). | ||||
It is left up to individual user-agent implementations how to determine | [document-origin, * ] | |||
and how and whether to store users' tracking preferences. | ||||
ISSUE-111: Different DNT values to signify existence of site-specific | is added to the database of remembered grants. | |||
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 | A particular response to the API - like a DNT response header - is only | |||
valid immediately, and users' preferences may change. | ||||
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 | ||||
called immediately. | ||||
6.4.2 API to Cancel a Site-specific Exception | ||||
[NoInterfaceObject] | [NoInterfaceObject] | |||
interface NavigatorDoNotTrack { | interface NavigatorDoNotTrack { | |||
void requestSiteSpecificTrackingException (sequence<DOMString> arrayOfDom | boolean removeSiteSpecificTrackingException (); | |||
ainStrings, TrackingResponseCallback callback, optional siteName, optional e | ||||
xplanationString, optional detailURI); | ||||
}; | }; | |||
6.4.1 Methods | 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 | ||||
requestSiteSpecificTrackingException | This returns a boolean indicating, when true, that the call has succeeded, | |||
Called by a page to request or confirm a site-specific tracking | and that the database of grants no longer contains, or very soon will no | |||
exception. | longer contain, the indicated grant(s); when false, some kind of | |||
processing error occurred. | ||||
Parameter Type Nullable Optional Descripti | 6.5 JavaScript API for Web-wide Exceptions | |||
on | ||||
arrayOfDomainStrings sequence<DOMString> * * | 6.5.1 API to Request a Web-wide Exception | |||
callback TrackingResponseCallback * * | ||||
siteName * * | [NoInterfaceObject] | |||
explanationString * * | interface NavigatorDoNotTrack { | |||
detailURI * * | void requestWebWideTrackingException (TrackingResponseCallback callback, | |||
optional siteName, optional optional explanationString, optional optional det | ||||
ailURI); | ||||
}; | ||||
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 | Return type: void | |||
[Callback, NoInterfaceObject] | Users may wish to configure exceptions for a certain trusted tracker | |||
interface TrackingResponseCallback { | across all sites. This API requests the addition of a web-wide grant for a | |||
void handleEvent (boolean granted); | specific site, to the database. | |||
6.5.2 API to cancel a web-wide exception | ||||
[NoInterfaceObject] | ||||
interface NavigatorDoNotTrack { | ||||
boolean removeWebWideTrackingException (); | ||||
}; | }; | |||
6.4.2 Methods | 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 | ||||
handleEvent | This returns a boolean indicating, when true, that the call has succeeded, | |||
The callback is called by the user agent to indicate the user's | and that the database of grants no longer contains, or very soon will no | |||
response. | longer contain, the indicated grant; when false, some kind of processing | |||
error occurred. | ||||
Parameter Type Nullable Optional Description | 6.6 Querying a host's exception status | |||
granted boolean * * | ||||
Return type: void | Issue 160: Do we need an exception-query API? | |||
The requestSiteSpecificTrackingException method takes two mandatory | It might be useful, and 'complete the model', if we had a JS API that told | |||
arguments: | a host what its current exception status is in a given context. | |||
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. | ||||
* arrayOfDomainStrings, a JavaScript array of strings, and | [NoInterfaceObject] | |||
* callback, a method that will be called when the request is complete. | interface NavigatorDoNotTrack { | |||
DOMString requestDNTStatus (); | ||||
}; | ||||
It also takes three optional arguments: | 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 | ||||
* siteName, a string for the name of this site, | 6.7 Transfer of an exception to another third party | |||
* explanationString, a short explanation of the request, and | ||||
* detailURI, a location at which further information about this request | ||||
can be found. | ||||
Each string in arrayOfDomainStrings specifies a tracker. The special | A site may request an exception for one or more third party services used | |||
string "*" signifies all trackers. When called, | in conjunction with its own offer. Those third party services may wish to | |||
requestSiteSpecificTrackingException MUST return immediately, then | use other third parties to complete the request in a chain of | |||
asynchronously determine whether the user wants the requested exceptions. | interactions. The first party will not necessarily know in advance whether | |||
a known third party will use some other third parties. | ||||
The granted parameter passed to the callback is the user's response; true | If a user-agent sends a tracking exception to a given combination of | |||
indicates the user wants an exception on this site for all of the trackers | origin server and a named third party, the user agent will send DNT:0 to | |||
specified in arrayOfDomainStrings. The response false indicates that the | that named third party. By receiving the DNT:0 header, the named third | |||
user does not want an exception on this site for at least one of the | party acquires the permission to track the user agent and collect the data | |||
trackers specified in arrayOfDomainStrings. | and process it in any way allowed by the legal system it is operating in. | |||
A particular response to the API - like a DNT response header - is only | Furthermore, the named third party receiving the DNT:0 header acquires at | |||
valid immediately, and users' preferences may change. | 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. | ||||
A user agent MAY use an interactive method to ask the user about their | The named third party is also allowed to transmit the collected data for | |||
preferences, so sites SHOULD NOT assume that the callback function will be | uses related to this interaction to its own sub-services and | |||
called immediately. | 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. | ||||
ISSUE-109: siteSpecificTrackingExceptions property has fingerprinting | For advertisement networks this typically would mean that the collection | |||
risks: is it necessary? | and auction system chain can use the data for that interaction and combine | |||
[PENDING REVIEW] It has been removed from the proposal. | 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. | ||||
6.5 User interface guidelines | 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 | ||||
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), | |||
(Yahoo!), and Andy Zeigler (Microsoft). | John Simpson (Consumer Watchdog), David Singer (Apple), Rigo Wenning | |||
(W3C/ERCIM), Shane Wiley (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 | |||
skipping to change at line 1348 | skipping to change at line 1707 | |||
[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 | ||||
feedly mini | ||||
End of changes. 220 change blocks. | ||||
709 lines changed or deleted | 1065 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/ |