b.txt | c.txt | |||
---|---|---|---|---|
***** | ***** | |||
W3C | W3C | |||
Tracking Preference Expression (DNT) | Tracking Preference Expression (DNT) | |||
W3C Working Draft 13 March 2012 | W3C Editor's Draft 18 July 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: | Previous version: | |||
http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/ | http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ | |||
Editors: | Editors: | |||
Roy T. Fielding, Adobe | Roy T. Fielding, Adobe | |||
David Singer, Apple | David Singer, Apple | |||
Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. | Copyright (c) 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. | |||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
skipping to change at line 57 | skipping to change at line 57 | |||
can be found in the W3C technical reports index at http://www.w3.org/TR/. | can be found in the W3C technical reports index at http://www.w3.org/TR/. | |||
This document is a snapshot of live discussions within the Tracking | This document is a snapshot of live discussions within the Tracking | |||
Protection Working Group. It does not yet capture all of our work. For | Protection Working Group. It does not yet capture all of our work. For | |||
example, we have issues that are [PENDING REVIEW] with complete text | example, we have issues that are [PENDING REVIEW] with complete text | |||
proposals that did not make it into this draft. Text in white is typically | proposals that did not make it into this draft. Text in white is typically | |||
[CLOSED]: we have reached a consensus decision. Text in blue boxes | [CLOSED]: we have reached a consensus decision. Text in blue boxes | |||
presents multiple options the group is considering. In some cases we are | presents multiple options the group is considering. In some cases we are | |||
close to agreement, and in others we have more to discuss. An issue | close to agreement, and in others we have more to discuss. An issue | |||
tracking system is available for recording raised, open, pending review, | tracking system is available for recording raised, open, pending review, | |||
closed, and postponed issues regarding this document. This draft, | closed, and postponed issues regarding this document. | |||
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 101 | skipping to change at line 95 | |||
* 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.1 Interface | |||
* 4.3.2 Attributes | * 4.3.2 Attributes | |||
* 4.3.3 Implements | * 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 Resource | |||
* 5.1.3 Using the Tracking Status | * 5.3.1 Definition | |||
* 5.1.4 Tracking Status Caching | * 5.3.2 Representation | |||
* 5.1.5 Tracking Status ABNF | * 5.3.3 Qualifier Value | |||
* 5.2 Tk Header Field for HTTP Responses | * 5.3.4 Using the Tracking Status | |||
* 5.2.1 Motivation | * 5.3.5 Caching | |||
* 5.2.2 Tk ABNF | * 5.3.6 Status-object ABNF | |||
* 5.2.3 Tk Semantics | * 5.4 Tk Header Field for HTTP Responses | |||
* 5.2.4 More Information | * 5.4.1 Definition | |||
* 5.2.5 Implementation and Usage Considerations | * 5.4.2 Indicating Tracking Design | |||
* 5.2.6 Examples | * 5.4.3 Indicating an Interactive Status Change | |||
* 5.3 Status Code for Tracking Required | * 5.4.4 Indicating a Specific Tracking Status Resource | |||
* 6. Site-specific Exceptions | * 5.5 Status Code for Tracking Required | |||
* 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.1.1 Methods | |||
* 6.5 User interface guidelines | * 6.4.1.2 Methods | |||
* 6.6 Exceptions without a DNT header | * 6.4.2 API to cancel a site-specific exception | |||
* 6.7 Web-wide exceptions | * 6.4.2.1 Methods | |||
* 6.5 JavaScript API for web-wide exceptions | ||||
* 6.5.1 API to request a web-wide exception | ||||
* 6.5.1.1 Methods | ||||
* 6.5.2 API to cancel a web-wide exception | ||||
* 6.5.2.1 Methods | ||||
* 6.6 User interface guidelines | ||||
* 6.7 Exceptions without a DNT header | ||||
* 6.8 Fingerprinting | * 6.8 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, | |||
skipping to change at line 190 | skipping to change at line 192 | |||
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 225 | skipping to change at line 229 | |||
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, | ||||
usually in the form of a site-specific exception, for a given third-party. | ||||
In general: permitted uses are additional permissions granted by the | ||||
standard; user-granted exceptions are additional permissions granted by | ||||
the user. These words are often confused when drafting new text. | ||||
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-59: Should the first party be informed about whether the user has | ||||
sent a DNT header to third parties on their site? | ||||
ISSUE-111: Different DNT value to signify existence of site-specific | ISSUE-111: Different DNT value to signify existence of site-specific | |||
exception (also linked to 4.1 and 6 below) | 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. | |||
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.3.2 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. | |||
This document does not have any implied or specified behavior for the | ||||
user-agent treatment of cookies when DNT is enabled. | ||||
ISSUE-111: Different DNT value to signify existence of site-specific | ISSUE-111: Different DNT value to signify existence of site-specific | |||
exceptions | exceptions | |||
Should the user agent send a different DNT value to a first party site if | 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 | 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 | implies I have Do Not Track enabled but grant permissions to some third | |||
parties while browsing this domain) [OPEN] | parties while browsing this domain) [OPEN] | |||
4.3 JavaScript API to Detect Preference | 4.3 JavaScript API to Detect Preference | |||
skipping to change at line 399 | skipping to change at line 439 | |||
binding-specific casting methods on an instance of Navigator. | binding-specific casting methods on an instance of Navigator. | |||
ISSUE-84: Make DNT status available to JavaScript | ISSUE-84: Make DNT status available to JavaScript | |||
[OPEN] The API above has been deemed inadequate due to origin restrictions | [OPEN] The API above has been deemed inadequate due to origin restrictions | |||
on embedded javascript by reference. We are awaiting new text to resolve | on embedded javascript by reference. We are awaiting new text to resolve | |||
this issue. | 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 | ||||
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. | |||
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 | |||
skipping to change at line 428 | skipping to change at line 466 | |||
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, re-directing 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 | The last paragraph may be more appropriate in the compliance document, as | |||
other protocols beyond HTTP? | it discusses compliance. | |||
[PENDING REVIEW] Text in this section; but the last paragraph may be more | ||||
appropriate in the compliance document, as it discusses compliance. | ||||
5. Communicating a Tracking Status | 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 for | ||||
a user agent, and may direct the user to a request-specific tracking | ||||
status resource applicable to the current request. | ||||
5.1.1 Resource Definition | 5.2 Tracking Status Value | |||
A tracking status value is a short notation for communicating how a | ||||
designated resource conforms to this protocol. For a site-wide tracking | ||||
status resource, the designated resource is any resource on the same | ||||
origin server. For a Tk response header field, the resource that sent the | ||||
Tk header field in response is the designated resource, and remains the | ||||
designated resource for any subsequent request-specific tracking status | ||||
resource referred to by the Tk field's status-id. | ||||
Each of the response mechanisms use a common format to indicate the | ||||
tracking status for a designated resource. This tracking status value is a | ||||
string of characters from a limited set, where the meaning of each allowed | ||||
character is defined in the following table. | ||||
status meaning | ||||
None: The designated resource does not perform | ||||
N tracking or make use of any data collected from | ||||
tracking, not even for permitted uses. | ||||
First party: The designated resource is designed | ||||
1 for use within a first-party context and conforms | ||||
to the requirements on a first party. | ||||
Third party: The designated resource is designed | ||||
3 for use within a first-party context and conforms | ||||
to the requirements on a third party. | ||||
Dynamic: The designated resource is designed for | ||||
use in both first and third party contexts and | ||||
dynamically adjusts tracking status accordingly. If | ||||
this value is present in the site-wide tracking | ||||
status, more information will be provided via the | ||||
X Tk response header field. If this value is present | ||||
in the Tk response header field, more information | ||||
will be provided in the request-specific tracking | ||||
status resource referred to by the status-id. "X" | ||||
must not be present in the tracking status value of | ||||
a request-specific tracking status resource. | ||||
Service provider: The designated resource is | ||||
operated by a service provider acting on behalf of | ||||
S the first party and conforms to the requirements | ||||
for both a first party and a service provider | ||||
acting as a first party. | ||||
Consent: The designated resource believes it has | ||||
received prior explicit and informed consent for | ||||
tracking this user, user agent, or device, perhaps | ||||
via some mechanism not defined by this | ||||
C specification, and that prior consent overrides the | ||||
tracking preference expressed by this protocol. | ||||
When prior consent is indicated, the tracking | ||||
status object should include a control member that | ||||
references a resource for modifying the consent. | ||||
ISSUE-137: Does hybrid tracking status need to distinguish between first | ||||
party (1) and outsourcing service provider acting as a first party (s) | ||||
[OPEN] There is significant disagreement over whether a service provider | ||||
acting on behalf of a first party needs to indicate such in the tracking | ||||
status. It is particularly nonsensical given that there may be dozens of | ||||
service providers acting on any request and the service provider | ||||
definition is already limited to cases where any data collected is siloed | ||||
and under control of the first party. | ||||
5.3 Tracking Status Resource | ||||
5.3.1 Definition | ||||
An origin server must provide a tracking status resource at the well-known | An origin server must provide a tracking status resource at the well-known | |||
identifier [RFC5785] | 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.3.4 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.3.5 Caching. | |||
If an origin server contains multiple services that are controlled by | If an origin server has multiple, resource-specific tracking policies, | |||
distinct parties or that might have differing behavior or policies | such that the tracking status might differ depending on some aspect of the | |||
regarding tracking, then it may also provide a space of well-known | request (e.g., method, target URI, header fields, data, etc.), the origin | |||
resources for obtaining information about the potential tracking behavior | server may provide an additional subtree of well-known resources | |||
of each specific service. This parallel tree of resources is called the | corresponding to each of those distinct tracking statuses. The Tk response | |||
tracking status resource space. | 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. This subtree of resources is called the tracking | ||||
status resource space. | ||||
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 | Tk: 1;fRx42 | |||
may have a corresponding tracking status resource identified by | refers to the specific tracking status resource | |||
http://example.com/.well-known/dnt/over/here | /.well-known/dnt/fRx42 | |||
Resources within the tracking status resource space are represented using | Resources within the tracking status resource space are represented using | |||
the same format as a site-wide tracking status resource. | the same format as a site-wide tracking status resource. | |||
All requests for well-known URIs defined here must not be tracked, | When sending a request for the tracking status, a user agent should | |||
irrespective of the presence, value, or absence of a DNT header, cookies, | include any cookie data [COOKIES] (set prior to the request) that would be | |||
or any other information in the request. In addition, all responses to | sent in a normal request to that origin server, since that data might be | |||
requests on a tracking status resource, including redirected requests, | needed by the server to determine the current tracking status. For | |||
must not include Set-Cookie or Set-Cookie2 header fields [COOKIES] and | example, the cookie data might indicate a prior out-of-band decision by | |||
must not include content that would have the effect of initiating tracking | the user to opt-out or consent to tracking by that origin server. | |||
beyond what is already present for the request. A user agent should ignore | ||||
or treat as an error any Set-Cookie or Set-Cookie2 header field received | ||||
in such a response. | ||||
5.1.2 Tracking Status Representation | All requests on the tracking status resource space, including the | |||
site-wide tracking status resource, must not be tracked, irrespective of | ||||
the presence, value, or absence of a DNT header field, cookies, or any | ||||
other information in the request. In addition, all responses to those | ||||
requests, including the responses to redirected tracking status requests, | ||||
must not have Set-Cookie or Set-Cookie2 header fields and must not have | ||||
content that initiates tracking beyond what was already present in the | ||||
request. A user agent should ignore, or treat as an error, any Set-Cookie | ||||
or Set-Cookie2 header field received in such a response. | ||||
5.3.2 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 in | |||
section 5.1.5 Tracking Status ABNF. The following is an example tracking | section 5.3.6 Status-object ABNF. The following is an example tracking | |||
status representation that illustrates all of the fields defined by this | status representation that illustrates all of the fields defined by this | |||
specification, most of which are optional. | specification, most of which are optional. | |||
{ | { | |||
"path": "/", | ||||
"tracking": true, | "tracking": true, | |||
"received": "1", | ||||
"response": "t1", | "response": "t1", | |||
"same-site": [ | "same-party": [ | |||
"example.com", | "example.com", | |||
"example_vids.net", | "example_vids.net", | |||
"example_stats.com" | "example_stats.com" | |||
], | ], | |||
"partners": [ | "partners": [ | |||
"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 this | |||
user agent's request. | user agent's request. | |||
If the status-object has an optional path member, then this 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 | ||||
with a value of "/" indicates that this status-object applies for the | ||||
entire origin server of the originally referenced resource. If the | ||||
originally referenced resource's path component does not share the same | ||||
prefix as the value of path, or if the path member is absent, then the | ||||
tracking status for the referenced resource may be obtained via a request | ||||
on the corresponding tracking status resource space. | ||||
A status-object must have a member named tracking with a boolean value. A | A status-object must have a member named tracking with a boolean value. A | |||
value of false indicates that the corresponding resources do not perform | value of false indicates that the corresponding resources do not perform | |||
tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true | tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true | |||
indicates that the corresponding resource performs tracking and claims to | indicates that the corresponding resource performs tracking and claims to | |||
conform to all tracking compliance requirements applicable to this site. | conform to all tracking compliance requirements applicable to this site. | |||
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} | {"tracking": false} | |||
The following status-object would indicate that the entire site does not | If tracking is true, the status-object must include an additional member | |||
perform tracking. | named response and may include other members as described below. | |||
{"path": "/", "tracking": false} | ||||
If tracking is true, the status-object must include two additional | ||||
members, named received and response, and may include other members as | ||||
described below. | ||||
The received member must have either a string value equal to the | ||||
DNT-field-value received in that request or the value null if no | ||||
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 | The response member must have a string value that indicates the status of | |||
tracking applicable specifically to this user in light of the received | tracking applicable specifically to this user in light of the received | |||
DNT-field-value. The string value begins with "t" (tracking) or "n" (not | DNT-field-value. The string value begins with t (tracking), n (not | |||
tracking) and may be followed by alphanumeric characters that indicate | tracking), or s (see the more specific tracking status resource), and may | |||
reasons for that status, as described in the following table. | be followed by alphanumeric characters that indicate qualifiers for that | |||
status. The defined qualifier characters and their meanings are described | ||||
reasons meaning | in section 5.3.3 Qualifier Value. | |||
1 Designed for use as a first-party only | ||||
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 same-party may be provided with an array value | |||
containing a list of domain names that the origin server claims are the | containing a list of domain names that the origin server claims are the | |||
same site, to the extent they are referenced on this site, since all data | same party, to the extent they are referenced on this site, since all data | |||
collected via those references share the same data controller. | collected via those references share the same data controller. | |||
An optional member named partners may be provided with an array value | An optional member named partners may be provided with an array value | |||
containing a list of domain names for third-party services that might | containing a list of domain names for third-party services that might be | |||
track the user as a result of using this site and which do not have the | invoked while using this site but do not share the same data controller as | |||
same data controller as this site. | this site. | |||
An optional member named audit may be provided with an array value | ||||
containing a list of URI references to external audits of the site's | ||||
tracking policy and tracking behavior in compliance with this protocol. | ||||
Preferably, the audit references are to resources that describe the | ||||
auditor and the results of that audit; however, if such a resource is not | ||||
available, a reference to the auditor is sufficient. | ||||
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 this site. The content of such a policy document is | |||
beyond the scope of this protocol and only supplemental to what is | beyond the scope of this protocol and only supplemental to what is | |||
described by this machine-readable tracking status representation. | described by this machine-readable tracking status representation. | |||
An optional member named edit may be provided with a string value | An optional member named control may be provided with a string value | |||
containing a URI-reference to a resource intended to allow a tracked user | containing a URI-reference to a resource for giving the user control over | |||
agent to review or delete data collected by this site, if any such data | personal data collected by this site. Such control might include the | |||
remains associated with this user agent. The design of such a resource and | ability to review past data collected, delete some or all of the data, | |||
the extent to which it can provide access to that data is beyond the scope | provide additional data (if desired), or opt-in, opt-out, or otherwise | |||
of this protocol. | modify an out-of-band consent status regarding data collection by this | |||
site. The design of such a resource, the extent to which it can provide | ||||
An optional member named options may be provided with a string value | access to that data, and how one might implement an out-of-band consent | |||
containing a URI-reference to a resource intended to allow a user agent to | mechanism is beyond the scope of this protocol. | |||
opt-in, opt-out, or otherwise modify their consent status regarding data | ||||
collection by this site. The design of such a resource and how it might | ||||
implement an out-of-band consent mechanism is beyond the scope of this | ||||
protocol. | ||||
Additional extension members may be provided in the status-object to | 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. | |||
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 | |||
{ | { | |||
"tracking": true, | "tracking": true, | |||
"received": "1", | ||||
"response": "n", | "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 | [PENDING REVIEW] The same-party and partners members provide a means to | |||
list first-party and third-party domains, respectively. | list first-party and third-party domains, respectively. | |||
ISSUE-124: Alternative DNT implementations that replace HTTP headers with | ISSUE-124: Alternative DNT implementations that replace HTTP headers with | |||
something else | something else | |||
[PENDING REVIEW] The tracking status resource minimizes bandwidth usage | [PENDING REVIEW] The tracking status resource minimizes bandwidth usage | |||
because only a small proportion of user agents are expected to perform | because only a small proportion of user agents are expected to perform | |||
active verification, status would only be requested once per site per day, | active verification, status would only be requested once per site per day, | |||
and the response can be extensively cached. | and the response can be extensively cached. | |||
5.1.3 Using the Tracking Status | 5.3.3 Qualifier Value | |||
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. | ||||
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 that begins with 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. | ||||
ISSUE-136: Resolve dependencies of the TPE on the compliance | ||||
specification. | ||||
The list of qualifiers is intended to correspond to constraints and | ||||
permitted uses identified by [TRACKING-COMPLIANCE], and at some point | ||||
might perhaps even move to that document in the sections defining the | ||||
permitted uses. The above list will be updated accordingly. | ||||
5.3.4 Using the Tracking Status | ||||
A key advantage of providing the tracking status at a resource separate | A key advantage of providing the tracking status at a resource separate | |||
from the site's normal services is that the status can be accessed and | from the site's normal services is that the status can be accessed and | |||
reviewed prior to making use of those services and prior to making | reviewed prior to making use of those services and prior to making | |||
requests on third-party resources referenced by those services. In | requests on third-party resources referenced by those services. In | |||
addition, the presence (or absence) of a site-wide tracking status | addition, the presence (or absence) of a site-wide tracking status | |||
representation is a means for testing deployment of this standard and | representation is a means for testing deployment of this standard and | |||
verifying that a site's claims regarding tracking are consistent with the | verifying that a site's claims regarding tracking are consistent with the | |||
site's observed behavior over time. | site's observed behavior over time. | |||
skipping to change at line 686 | skipping to change at line 813 | |||
obtain the tracking status (up to some reasonable maximum of redirects to | obtain the tracking status (up to some reasonable maximum of redirects to | |||
avoid misconfigured infinite request loops). If the response is | avoid misconfigured infinite request loops). If the response is | |||
successful, obtain the tracking status representation from the message | successful, obtain the tracking status representation from the message | |||
payload, if possible, or consider it an error. | payload, if possible, or consider it an error. | |||
Once the tracking status representation is obtained, parse the | Once the tracking status representation is obtained, parse the | |||
representation as JSON to extract the Javascript status-object. If parsing | 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 | results in a syntax error, the user agent should consider the site to be | |||
non-conformant with this protocol. | 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 | 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 | 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 | the URI being checked. | |||
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 | Otherwise, examine the member named response to see what the origin server | |||
to see what the origin server has claimed regarding the tracking status | has claimed regarding the tracking status for this user agent in light of | |||
for this user agent in light of the received DNT-field-value. | the received DNT-field-value. | |||
If the first character of the response value is "n", then the origin | 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 | 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 | URI being checked for at least the next 24 hours or until the | |||
member's value, for at least the next 24 hours or until the Cache-Control | Cache-Control information indicates that this response expires, as | |||
information indicates that this response expires, as described below. | described below. | |||
If the first character of the response value is "t", then the origin | If the first character of the response value is "t", then the origin | |||
server claims that it might track the user agent for requests on the URI | 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 | being checked for at least the next 24 hours or until the Cache-Control | |||
member's value, for at least the next 24 hours or until the Cache-Control | ||||
information indicates that this response expires. | information indicates that this response expires. | |||
The remaining characters of the response value might indicate reasons for | If the first character of the response value is "s", then the origin | |||
the above choices or limitations that the origin server will place on its | server has multiple tracking status representations and the specific one | |||
tracking. | applicable to each request is indicated by a status-id within the Tk | |||
field-value of the corresponding response. | ||||
The remaining characters of the response value might indicate qualifiers | ||||
for the above choices or limitations that the origin server will place on | ||||
its tracking. | ||||
The others members of the status-object may be used to help the user agent | The others members of the status-object may be used to help the user agent | |||
differentiate between a site's first-party and third-party services, to | differentiate between a site's first-party and third-party services, to | |||
provide links to additional human-readable information related to the | provide links to additional human-readable information related to the | |||
tracking policy, and to provide links for control over past data collected | tracking policy, and to provide links for control over past data collected | |||
or over some consent mechanism outside the scope of this protocol. | or over some consent mechanism outside the scope of this protocol. | |||
5.1.4 Tracking Status Caching | 5.3.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 | |||
skipping to change at line 761 | skipping to change at line 880 | |||
with one of the directives "no-cache", "no-store", "must-revalidate", or | with one of the directives "no-cache", "no-store", "must-revalidate", or | |||
"max-age=0". | "max-age=0". | |||
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 update-needed field-value, as | ||||
described in section 5.4.3 Indicating an Interactive Status Change. | ||||
5.3.6 Status-object ABNF | ||||
The representation of a site's machine-readable tracking status must | The representation of a site's machine-readable tracking status must | |||
conform to the following ABNF for status-object, except that the members | conform to the following ABNF for status-object, except that the members | |||
within each member-list may be provided in any order. | within each member-list may be provided in any order. | |||
status-object = begin-object member-list end-object | status-object = begin-object member-list end-object | |||
member-list = [ path ns path-v vs ] | member-list = tracking ns tracking-v | |||
tracking ns tracking-v | [ vs response ns response-v ] | |||
[ vs received ns received-v ] | [ vs same-party ns same-party-v ] | |||
[ vs response ns response-v ] | [ vs partners ns partners-v ] | |||
[ vs same-site ns same-site-v ] | [ vs audit ns audit-v ] | |||
[ vs partners ns partners-v ] | [ vs policy ns policy-v ] | |||
[ vs policy ns policy-v ] | [ vs control ns control-v ] | |||
[ vs edit ns edit-v ] | ||||
[ vs options ns options-v ] | ||||
*( vs extension ) | *( vs extension ) | |||
path = %x22 "path" %x22 | ||||
path-v = string ; URI absolute-path | ||||
tracking = %x22 "tracking" %x22 | tracking = %x22 "tracking" %x22 | |||
tracking-v = true / false | tracking-v = true / false | |||
received = %x22 "received" %x22 | ||||
received-v = null / string | ||||
response = %x22 "response" %x22 | response = %x22 "response" %x22 | |||
response-v = %x22 r-codes %x22 | response-v = %x22 r-codes %x22 | |||
r-codes = ("t" / "n") *reasons | r-codes = (%x74 / %x6E / %x73) *qualifier | |||
qualifier = "1" ; "1" - first-party | ||||
/ "3" ; "3" - third-party | ||||
/ %x61 ; "a" - audit | ||||
/ %x63 ; "c" - ad frequency capping | ||||
/ %x66 ; "f" - fraud prevention | ||||
/ %x6C ; "l" - local law, rule, or regulation | ||||
/ %x70 ; "p" - prior consent | ||||
/ %x72 ; "r" - referrals | ||||
/ ext-qualifier | ||||
reasons = "1" ; first-party | ext-qualifier = %x2D-2E / "0" / "2" / %x34-39 / %x5F | |||
/ "3" ; third-party | / %x62 / %x64-65 / %x67-6B / %x6D / %x6F | |||
/ "a" ; advertising audits | / %x71 / %x75-7A | |||
/ "c" ; prior consent | ||||
/ "f" ; fraud prevention | ||||
/ "g" ; geographic/regional compliance | ||||
/ "q" ; frequency capping | ||||
/ "r" ; referrals | ||||
/ ALPHA / DIGIT ; TBD | ||||
same-site = %x22 "same-site" %x22 | same-party = %x22 "same-party" %x22 | |||
same-site-v = array-of-strings | same-party-v = array-of-strings | |||
partners = %x22 "partners" %x22 | partners = %x22 "partners" %x22 | |||
partners-v = array-of-strings | partners-v = array-of-strings | |||
policy = %x22 "policy" %x22 | audit = %x22 "audit" %x22 | |||
audit-v = array-of-strings | ||||
policy = %x22 "policy" %x22 | ||||
policy-v = string ; URI-reference | policy-v = string ; URI-reference | |||
edit = %x22 "edit" %x22 | control = %x22 "control" %x22 | |||
edit-v = string ; URI-reference | control-v = string ; URI-reference | |||
options = %x22 "options" %x22 | ||||
options-v = string ; URI-reference | ||||
extension = object | extension = object | |||
array-of-strings = begin-array | array-of-strings = begin-array | |||
[ string *( vs string ) ] | [ string *( vs string ) ] | |||
end-array | end-array | |||
ns = <name-separator (:), as defined in [RFC4627]> | ns = <name-separator (:), as defined in [RFC4627]> | |||
vs = <value-separator (,), as defined in [RFC4627]> | vs = <value-separator (,), as defined in [RFC4627]> | |||
begin-array = <begin-array ([), as defined in [RFC4627]> | begin-array = <begin-array ([), as defined in [RFC4627]> | |||
end-array = <end-array (]), as defined in [RFC4627]> | end-array = <end-array (]), as defined in [RFC4627]> | |||
begin-object = <begin-object ({), as defined in [RFC4627]> | begin-object = <begin-object ({), as defined in [RFC4627]> | |||
skipping to change at line 834 | skipping to change at line 951 | |||
array-of-strings = begin-array | array-of-strings = begin-array | |||
[ string *( vs string ) ] | [ string *( vs string ) ] | |||
end-array | end-array | |||
ns = <name-separator (:), as defined in [RFC4627]> | ns = <name-separator (:), as defined in [RFC4627]> | |||
vs = <value-separator (,), as defined in [RFC4627]> | vs = <value-separator (,), as defined in [RFC4627]> | |||
begin-array = <begin-array ([), as defined in [RFC4627]> | begin-array = <begin-array ([), as defined in [RFC4627]> | |||
end-array = <end-array (]), as defined in [RFC4627]> | end-array = <end-array (]), as defined in [RFC4627]> | |||
begin-object = <begin-object ({), as defined in [RFC4627]> | begin-object = <begin-object ({), as defined in [RFC4627]> | |||
end-object = <end-object (}), as defined in [RFC4627]> | end-object = <end-object (}), as defined in [RFC4627]> | |||
object = <object, as defined in [RFC4627]> | object = <object, as defined in [RFC4627]> | |||
string = <string, as defined in [RFC4627]> | string = <string, as defined in [RFC4627]> | |||
true = <true, as defined in [RFC4627]> | true = <true, as defined in [RFC4627]> | |||
false = <false, as defined in [RFC4627]> | false = <false, as defined in [RFC4627]> | |||
null = <null, as defined in [RFC4627]> | null = <null, as defined in [RFC4627]> | |||
5.4 Tk Header Field for HTTP Responses | ||||
5.2 Tk Header Field for HTTP Responses | ||||
5.2.1 Motivation | ||||
This specification defines an HTTP response header, in order to meet the | ||||
following needs: | ||||
* User-agents can confirm that the server with which they are | 5.4.1 Definition | |||
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 | As a supplement to the tracking status resource, the Tk response header | |||
by including a Tk header field in the corresponding response. If a request | field is defined as an optional means for indicating DNT conformance and | |||
contains a DNT-field-value starting with "1", an origin server should send | as a required means for indicating that a state-changing request has | |||
a Tk header field in the corresponding response. | resulted in an interactive change to the tracking status for this user | |||
agent. | ||||
If an origin server chooses not to send a Tk header field, then the user | Tk-field-name = "Tk" ; case-insensitive | |||
agent will not know if the tracking preference has been received or if it | Tk-field-value = tracking-design [ ";" status-id ] | |||
will be honored. This may have negative consequences for the site, such as | tracking-design = tracking-never | |||
triggering preventive measures on the user agent or being flagged as | / tracking-first | |||
non-compliant by tools that look for response header fields. | / tracking-third | |||
/ update-needed | ||||
tracking-never = "0" | ||||
tracking-first = "1" | ||||
tracking-third = "3" | ||||
update-needed = %x75 ; lowercase "u" | ||||
ISSUE-107: Exact format of the response header? | ISSUE-107: Exact format of the response header? | |||
[PENDING REVIEW] See the proposal in this section. | [PENDING REVIEW] See the proposal in this section. | |||
ISSUE-120: Should the response header be mandatory (must) or recommended | 5.4.2 Indicating Tracking Design | |||
(should) | ||||
[PENDING REVIEW] Text in above paragraphs. | ||||
5.2.2 Tk ABNF | ||||
The Tk header field is defined as follows: | ||||
Tk-Response = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [CFW | ||||
S] [ 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 | ||||
Tk: 0 (no-dnt) indicates that this party does not comply with | ||||
[TRACKING-COMPLIANCE]. | ||||
Tk: 1 (not-tracking) indicates that: | ||||
* this party complies with [TRACKING-COMPLIANCE], and | ||||
* this party will process this request according to the specification | ||||
for 3rd parties in [TRACKING-COMPLIANCE]. | ||||
Tk: f (first-party) indicates that: | ||||
* this party complies with [TRACKING-COMPLIANCE], | ||||
* 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: | ||||
* this party complies with [TRACKING-COMPLIANCE], | ||||
* 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 | ||||
affirmatively consented to allow this party additional permission to track | ||||
them. Unless the opt-in-flag is included, the server asserts that will act | ||||
in responding to this request as if the user has not affirmatively | ||||
consented to allow this party additional permission to track them. | ||||
The reason-code can be used when requesting more information (see below). | ||||
5.2.4 More Information | ||||
If a reason code is specified in the response, the well-known resource | The Tk field-value begins with a single character tracking-design that | |||
defined here must exist; if an opt-in-flag is included, the wel--known | indicates how the target resource conforms to [TRACKING-COMPLIANCE]. We | |||
resource defined here should exist; otherwise it may exist. | refer to this as the tracking design because it reflects only how the | |||
resource is designed to work, rather than the current status of tracking | ||||
for this requesting user agent or received DNT field-value. Separating the | ||||
design and status allows conformance to this protocol to be indicated | ||||
without having a negative impact on caching of responses. | ||||
The user can understand and manage their opt-in by visiting the well-known | An origin server may send a Tk header field in a response with a | |||
URI | tracking-design of "0" to indicate that the resource never performs | |||
tracking as it is defined by [TRACKING-COMPLIANCE]. This has the same | ||||
meaning as {"tracking": "false"} in the tracking status resource. | ||||
/.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code} | Tk: 0 | |||
relative to the request-target. | An origin server may send a Tk header field in a response with a | |||
tracking-design of "1" to indicate that the resource does perform tracking | ||||
(though not necessarily for every request), conforms to | ||||
[TRACKING-COMPLIANCE], and considers itself to be the first-party for this | ||||
request. | ||||
The information at this URI provides additional information about this | Tk: 1 | |||
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 | An origin server may send a Tk header field in a response with a | |||
distinct definition for the tracking status resource. We anticipate that | tracking-design of "3" to indicate that the resource does perform tracking | |||
one or the other will be adopted, or the two proposals will be merged. | (though not necessarily for every request), conforms to | |||
[TRACKING-COMPLIANCE], and considers itself to be a third-party for this | ||||
request. | ||||
5.2.5 Implementation and Usage Considerations | Tk: 3 | |||
Implementers should use caution when allowing caching of resources on | ISSUE-120: Should the response header be mandatory (must) or recommended | |||
which an opt-in flag is included. If caching is not carefully managed, | (should) | |||
there is a risk of sending a response intended for opted-in users to users | [PENDING REVIEW] The site-wide resource is mandatory; the header field is | |||
who haven't opted in. | optional, except for the single must case below. | |||
Implementers should carefully choose the cache properties of the items at | 5.4.3 Indicating an Interactive Status Change | |||
the well-known URI. The content at these locations must be correct for the | ||||
entire cache duration, otherwise users who load stale cached copies of | ||||
these resources may be misled. | ||||
Any party can use the not-tracking response: this response just indicates | We anticipate that interactive mechanisms might be used, beyond the scope | |||
a behavior. If a first party complies with the third-party definition, | of this specification, that have the effect of asking for and obtaining | |||
they are free to send this response. However, the first-party and service | prior consent for tracking, or for modifying prior indications of consent. | |||
provider responses indicate both a behavior and an intention about that | For example, the tracking status resource's status-object defines a | |||
party's status. It would be deceptive to send the first-party header on a | control member that can refer to such a mechanism. Although such | |||
resource which is only ever embedded as a third party. | out-of-band mechanisms are not defined by this specification, their | |||
presence might influence the tracking status object's response value. | ||||
The no-dnt response should not be used on requests which are processed in | When an origin server provides a mechanism via HTTP for establishing or | |||
accordance with [TRACKING-COMPLIANCE]. An entity which implements DNT | modifying out-of-band tracking preferences, the origin server must | |||
should not use this response. | 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-design of lowercase "u" | ||||
(update-needed). | ||||
When embedding content from other sites, consider how that site expects | Tk: u | |||
their content to be used. If you embed/link to an object on another site, | ||||
it's possible that the resource will send a first-party response even | ||||
though it is now in a third-party context because the designer of that | ||||
site never intended that object to be embedded. If a resource always sends | ||||
a third-party response, there is no risk of this inconsistent response. | ||||
Only the first-party outsourcer of service-provider objects should ever | ||||
embed them. | ||||
5.2.6 Examples | 5.4.4 Indicating a Specific Tracking Status Resource | |||
Tk: 1 | If an origin server has multiple, resource-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. | ||||
The site is a third or first party, in compliance with the definitions of | For example, a response containing | |||
a 3rd party that is not tracking. | ||||
Tk: 1 1 agreed | Tk: 1;fRx42 | |||
The site is a third party, that believes it has an explicit opt-in from | indicates that the target resource conforms to this protocol as a | |||
the user; more information can be found at: | first-party and the current tracking status can be obtained by performing | |||
a retrieval request on | ||||
/.well-known/dnt?status=1&opt-in=1&r=agreed | /.well-known/dnt/fRx42 | |||
5.3 Status Code for Tracking Required | 5.5 Status Code for Tracking Required | |||
An HTTP error response status code might be useful for indicating that the | An HTTP error response status code might be useful for indicating that the | |||
site refuses service unless the user either logs into a subscription | 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 | account or agrees to an exception to DNT for this site and its contracted | |||
third-party sites. | third-party sites. | |||
6. Site-specific Exceptions | ISSUE-128: HTTP error status code to signal that tracking is required? | |||
ISSUE-118: Should requesting a user-agent-managed site-specific exception | ||||
be asynchronous? | ||||
[PENDING REVIEW] As proposed below. | ||||
ISSUE-115: Should sites be able to manage site-specific tracking | 6. User-Granted Exceptions | |||
exceptions outside of the user-agent-managed system? | ||||
ISSUE-111: Different DNT values to signify existence of site-specific | ISSUE-111: Different DNT values to signify existence of site-specific | |||
exception | exceptions | |||
6.1 Overview | 6.1 Overview | |||
This section is non-normative. | This section is non-normative. | |||
Exceptions to Do Not Track, including site-specific exceptions, are | User-granted exceptions to Do Not Track, including site-specific | |||
managed by the user agent. A resource should rely on the DNT header it | exceptions, are managed by the user agent. A resource should rely on the | |||
receives to determine the user's preference for tracking with respect to | DNT header it receives to determine the user's preference for tracking | |||
that particular request. An API is provided so that sites may request and | with respect to that particular request. An API is provided so that sites | |||
check the status of exceptions for tracking. | may request and check the status of exceptions for tracking. | |||
We anticipate that many user-agents might provide a prompt to users when | We anticipate that many user-agents might provide a prompt to users when | |||
this API is used, or to store exceptions. Questions of user interface | this API is used, or to store exceptions. Questions of user interface | |||
specifics - for granting, configuring, storing, syncing and revoking | specifics - for granting, configuring, storing, syncing and revoking | |||
exceptions - are explicitly left open to implementers. | exceptions - are explicitly left open to implementers. | |||
6.2 Motivating principles and use cases | 6.2 Motivating principles and use cases | |||
This section is non-normative. | This section is non-normative. | |||
The following principles guide the design of the user-agent-managed | The following principles guide the design of user-agent-managed | |||
site-specific exceptions proposal. | exceptions. | |||
* Content providers may wish to prompt visitors to their properties to | * Content providers may wish to prompt visitors to their properties to | |||
"opt back in" to tracking for behavioral advertising or similar | "opt back in" to tracking for behavioral advertising or similar | |||
purposes when they arrive with the Do Not Track setting enabled. | purposes when they arrive with the Do Not Track setting enabled. | |||
* Privacy-conscious users may wish to view or edit all the site-specific | * Privacy-conscious users may wish to view or edit all the exceptions | |||
exceptions they've granted in a single, consistent user interface, | they've granted in a single, consistent user interface, rather than | |||
rather than managing preferences in a different way on every content | managing preferences in a different way on every content provider or | |||
provider or tracker's privacy page. | tracker's privacy page. | |||
* Granting an exception in one context (while browsing a news site) | * Granting an exception in one context (while browsing a news site) | |||
should not apply that exception to other contexts (browsing a medical | should not apply that exception to other contexts (browsing a medical | |||
site) that may not be expected. | site) that may not be expected. | |||
* Tracking providers should not ever have to second-guess a user's | * Tracking providers should not ever have to second-guess a user's | |||
expressed Do Not Track preference. | expressed Do Not Track preference. | |||
* The solution should not require cross-domain communication between a | * The solution should not require cross-domain communication between a | |||
first party publisher and its third party trackers. | first party publisher and its third parties. | |||
When asking for a site-specific exception, the top-level domain making the | ||||
request may be making some implicit or explicit claims as to the actions | ||||
and behavior of its third parties; for this reason, it might want to | ||||
establish exceptions for only those for which it is sure that those claims | ||||
are true. (Consider a site that has some trusted advertisers and analytics | ||||
providers, and some mashed-up content from less-trusted sites). For this | ||||
reason, there is support both for explicitly named sites, as well as | ||||
support for granting an exception to all third-parties on a given site | ||||
(site-wide exception, using the wild-card "*"). | ||||
There are some cases in which a user may desire a site to be allowed to | ||||
track them on any top-level domain. An API is provided so that the site | ||||
and the user may establish such a web-wide exception. | ||||
6.3 Exception model | 6.3 Exception model | |||
6.3.1 Site pairs | 6.3.1 Introduction | |||
This section describes the effect of the APIs in terms of a logical | ||||
processing model; this model describes the behavior, but should not be | ||||
read as mandating any specific implementation. | ||||
This API considers exceptions which are double-keyed to two domains: the | This API considers exceptions which are double-keyed to two domains: the | |||
site, and the tracker. A user might - for instance - want AnalytiCo to | site, and the target. A user might - for instance - want AnalytiCo to | |||
track them on Example News, but not on Example Medical. To simplify | track them on Example News, but not on Example Medical. To simplify | |||
language used in this API specification, we define two terms: | language used in this API specification, we define two terms: | |||
* This site is the domain name of the top-level document origin of this | * Top-Level Domain (TLD) is the domain name of the top-level document | |||
DOM: essentially the fully qualified domain name in the address bar. | origin of this DOM: essentially the fully qualified domain name in the | |||
* A tracker is a domain name which is not operated by the same party | address bar. For all these APIs, this must match the script origin. | |||
which operates this site, and which may be an origin for embedded | * A target site is a domain name which is the target of an HTTP request, | |||
resources on this site. | and which may be an origin for embedded resources on the indicated | |||
top-level domain. | ||||
For instance, if the document at | For instance, if the document at | |||
http://web.exnews.com/news/story/2098373.html references the resources | http://web.exnews.com/news/story/2098373.html references the resources | |||
http://exnews.analytico.net/1x1.gif and | http://exnews.analytico.net/1x1.gif and | |||
http://widgets.exsocial.org/good-job-button.js, this site is | http://widgets.exsocial.org/good-job-button.js, the top-level domain is | |||
web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both | web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both | |||
trackers. | targets. | |||
ISSUE-112: How are sub-domains handled for site-specific exceptions? | ISSUE-112: How are sub-domains handled for site-specific exceptions? | |||
Should a request for a tracking exception apply to all subdomains of the | 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 | first party making the request? Or should a first party explicitly list | |||
the subdomains that it's asking for? Similarly, should third party | the subdomains that it's asking for? Similarly, should third party | |||
subdomains be allowed (e.g. *.tracker.com)? | subdomains be allowed (e.g. *.tracker.com)? | |||
Proposal: Exceptions are requested for fully-qualified domain names. | Proposal: Exceptions are requested for fully-qualified domain names. | |||
The domains that enter into the behavior of the APIs include: | ||||
* As described above, the Top-Level Domain (TLD); | ||||
* The domain of the origin of the script; | ||||
* Domain names passed to the API; | ||||
* Domains declared in the well-known resource as 'partners'. | ||||
Note that these strict, machine-discoverable, concepts may not match the | ||||
definitions of first and third party; in particular, sites themselves need | ||||
to determine (and signal) when they get 'promoted' to first party by | ||||
virtue of user interaction; the UA will not change the DNT header it sends | ||||
them. | ||||
During the execution of these APIs, the top-level browsing domain and the | ||||
domain origin of the script must match, otherwise no action is taken, and | ||||
an error value returned. | ||||
The calls causes the following steps to occur: | ||||
* First, the UA somehow confirms with the user that they agree to the | ||||
grant of exception; | ||||
* If they agree, then the UA adds to its local database one or more | ||||
site-pair duplets [top-level-domain, other-domain]; 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. | ||||
6.3.2 Exception use by browsers | 6.3.2 Exception use by browsers | |||
If a user wishes to be tracked by a tracker on this site, this should | If a user wishes to allow tracking by a target on the top-level domain, | |||
result in two user-agent behaviors: | this should result in two user-agent behaviors: | |||
1. If requests to the tracker for resources that are part of the DOM for | 1. If requests to the target for resources that are part of the DOM for | |||
pages on this site include a DNT header, that header must be DNT:OFF. | pages on top-level domain include a DNT header, that header must be | |||
DNT:0. | ||||
2. Responses to the JavaScript API indicated should be consistent with | 2. Responses to the JavaScript API indicated should be consistent with | |||
this user preference (see below). | this user preference (see below). | |||
What is the effect of re-directs, when the source of the re-direct would | ||||
get a different DNT header than the target, using these matching rules? | ||||
It is left up to individual user-agent implementations how to determine | It is left up to individual user-agent implementations how to determine | |||
and how and whether to store users' tracking preferences. | and how and whether to store users' tracking preferences. | |||
ISSUE-111: Different DNT values to signify existence of site-specific | When an explicit list of domains is provided, their names might mean | |||
little to the user. The user might, for example, be told that | ||||
such-and-such top-level domain is asking for an exception for a specific | ||||
set of sites, rather than listing them by name. | ||||
Conversely, if a wild-card is or will be used, the user may be told that | ||||
the top-level domain is asking for an exception for all third-parties that | ||||
are, or will be, embedded in it. | ||||
ISSUE-111: Different DNT values to signify existence of user-granted | ||||
exception | exception | |||
Should the user agent send a different DNT value to a first party site if | 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 | 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 | implies "I have Do Not Track enabled but grant permissions to some third | |||
parties while browsing this domain") | parties while browsing this domain") | |||
Proposal: No, this API provides client-side means for sites to request | 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 | that information. Sites may also employ cookies to recall a user's past | |||
response. | response. Finally, a site may add [self, self] to the database as part of | |||
its request, and it will then get DNT:0. | ||||
6.4 JavaScript API for site-specific exceptions | 6.4 JavaScript API for site-specific exceptions | |||
6.4.1 API to request site-specific exceptions | ||||
[NoInterfaceObject] | [NoInterfaceObject] | |||
interface NavigatorDoNotTrack { | interface NavigatorDoNotTrack { | |||
void requestSiteSpecificTrackingException (sequence<DOMString> arrayOfDomai | void requestSiteSpecificTrackingException (TrackingResponseCallback callbac | |||
nStrings, TrackingResponseCallback callback, optional siteName, optional expla | k, optional siteName, optional explanationString, optional detailURI); | |||
nationString, optional detailURI); | ||||
}; | }; | |||
6.4.1 Methods | 6.4.1.1 Methods | |||
requestSiteSpecificTrackingException | requestSiteSpecificTrackingException | |||
Called by a page to request or confirm a site-specific tracking | Called by a page to request or confirm a user-granted tracking | |||
exception. | exception. | |||
Parameter Type Nullable Optional Description | Parameter Type Nullable Optional Description | |||
arrayOfDomainStrings sequence<DOMString> * * | callback TrackingResponseCallback * * | |||
callback TrackingResponseCallback * * | siteName * * | |||
siteName * * | explanationString * * | |||
explanationString * * | detailURI * * | |||
detailURI * * | ||||
Return type: void | Return type: void | |||
[Callback, NoInterfaceObject] | [Callback, NoInterfaceObject] | |||
interface TrackingResponseCallback { | interface TrackingResponseCallback { | |||
void handleEvent (boolean granted); | void handleEvent (boolean granted); | |||
}; | }; | |||
6.4.2 Methods | 6.4.1.2 Methods | |||
handleEvent | handleEvent | |||
The callback is called by the user agent to indicate the user's | The callback is called by the user agent to indicate the user's | |||
response. | response. | |||
Parameter Type Nullable Optional Description | Parameter Type Nullable Optional Description | |||
granted boolean * * | granted boolean * * | |||
Return type: void | Return type: void | |||
The requestSiteSpecificTrackingException method takes two mandatory | The requestSiteSpecificTrackingException method takes the mandatory | |||
arguments: | argument: | |||
* arrayOfDomainStrings, a JavaScript array of strings, and | ||||
* callback, a method that will be called when the request is complete. | * callback, a method that will be called when the request is complete. | |||
It also takes three optional arguments: | It also takes three optional arguments: | |||
* siteName, a string for the name of this site, | * siteName, a string for the name of the top-level domain (script | |||
origin), | ||||
* explanationString, a short explanation of the request, and | * explanationString, a short explanation of the request, and | |||
* detailURI, a location at which further information about this request | * detailURI, a location at which further information about this request | |||
can be found. | can be found. | |||
Each string in arrayOfDomainStrings specifies a tracker. The special | When called, requestSiteSpecificTrackingException must return immediately, | |||
string "*" signifies all trackers. When called, | then asynchronously determine whether the user grants the requested | |||
requestSiteSpecificTrackingException must return immediately, then | exception(s). | |||
asynchronously determine whether the user wants the requested exceptions. | ||||
The execution of this API and the use of the resulting permission (if | ||||
granted) use two 'implicit' parameters, when the API is called: | ||||
* the domain of the origin of the script (script-origin); | ||||
* the 'partners' list at the well-known URL location. | ||||
The user-agent should use the partners as the list of targets, if it | ||||
exists, or a list containing the single special string "*", indicating all | ||||
targets, as the target if it does not; it may use a list of the special | ||||
string "*" even if the partners list exists. | ||||
The granted parameter passed to the callback is the user's response; true | The granted parameter passed to the callback is the user's response; true | |||
indicates the user wants an exception on this site for all of the trackers | indicates the user grants an exception on top-level domain for all of the | |||
specified in arrayOfDomainStrings. The response false indicates that the | targets. The response false indicates that the user does not want an | |||
user does not want an exception on this site for at least one of the | exception on top-level domain for at least one of the targets. | |||
trackers specified in arrayOfDomainStrings. | ||||
If permission is granted, then the set of duplets (one per target): | ||||
[top-level-domain, target] | ||||
is added to the database of remembered grants. | ||||
A particular response to the API - like a DNT response header - is only | A particular response to the API - like a DNT response header - is only | |||
valid immediately, and users' preferences may change. | valid immediately, and users' preferences may change. | |||
A user agent may use an interactive method to ask the user about their | A user agent may use an interactive method to ask the user about their | |||
preferences, so sites should not assume that the callback function will be | preferences, so sites should not assume that the callback function will be | |||
called immediately. | called immediately. | |||
ISSUE-109: siteSpecificTrackingExceptions property has fingerprinting | 6.4.2 API to cancel a site-specific exception | |||
risks: is it necessary? | ||||
[PENDING REVIEW] It has been removed from the proposal. | ||||
6.5 User interface guidelines | [NoInterfaceObject] | |||
interface NavigatorDoNotTrack { | ||||
void removeSiteSpecificTrackingException (); | ||||
}; | ||||
6.4.2.1 Methods | ||||
removeSiteSpecificTrackingException | ||||
Ensures that the database of remembered grants no longer contains | ||||
any duplets | ||||
[top-level-domain, target] | ||||
for any target. This method never fails and there is no callback. | ||||
After the call has been made, it is assured that there are no | ||||
site-specific exceptions for the given top-level-domain. | ||||
No parameters. | ||||
Return type: void | ||||
6.5 JavaScript API for web-wide exceptions | ||||
ISSUE-113: Should there be a JavaScript API to prompt for a Web-wide | ||||
exception? | ||||
PROPOSAL: In this section | ||||
6.5.1 API to request a web-wide exception | ||||
[NoInterfaceObject] | ||||
interface NavigatorDoNotTrack { | ||||
void requestWebWideTrackingException (TrackingResponseCallback callback, op | ||||
tional siteName, optional explanationString, optional detailURI); | ||||
}; | ||||
6.5.1.1 Methods | ||||
requestWebWideTrackingException | ||||
If permission is granted, then the single duplet | ||||
[ * , top-level-domain] | ||||
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 Description | ||||
callback TrackingResponseCallback * * | ||||
siteName * * | ||||
explanationString * * | ||||
detailURI * * | ||||
Return type: void | ||||
Users may wish to configure exceptions for a certain trusted tracker | ||||
across all sites. This API requests the addition of a web-wide grant for a | ||||
specific site, to the database. | ||||
6.5.2 API to cancel a web-wide exception | ||||
[NoInterfaceObject] | ||||
interface NavigatorDoNotTrack { | ||||
void removeWebWideTrackingException (); | ||||
}; | ||||
6.5.2.1 Methods | ||||
removeWebWideTrackingException | ||||
Ensures that the database of remembered grants no longer contains | ||||
[ * , top-level-domain] | ||||
This method never fails and 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: void | ||||
6.6 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. | |||
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 News (web.exnews.com) would like to know | |||
whether you permit tracking by the following parties: | whether you permit tracking by a specific set of sites (click | |||
* exnews.analytico.net | here for their names). | |||
* widgets.exsocial.org | ||||
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 to detailURI. | pointing 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-83: How do you opt out if already opted in? | |||
revocation mechanism? (raised by npdoty) | PROPOSAL: In this section | |||
6.6 Exceptions without a DNT header | ISSUE-129: Should a blanket exception of the type ["firstparty", "*"] be | |||
possible? | ||||
PROPOSAL: In this section | ||||
ISSUE-130: Should a global exception for a given third party on all sites | ||||
be supported? | ||||
PROPOSAL: In this section | ||||
ISSUE-140: Do we need site-specific exceptions, i.e., concrete list of | ||||
permitted third parties for a site? | ||||
PROPOSAL: 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. | ||||
6.7 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 | |||
skipping to change at line 1266 | skipping to change at line 1484 | |||
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. | |||
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 | ||||
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 | 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), Roy T. Fielding (Adobe), | |||
Lowenthal (Mozilla), Aleecia M. McDonald (Mozilla), Matthias Schunter | Tom Lowenthal (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald | |||
(IBM), John Simpson (Consumer Watchdog), David Singer (Apple), Shane Wiley | (Mozilla), Matthias Schunter (IBM), John Simpson (Consumer Watchdog), | |||
(Yahoo!), and Andy Zeigler (Microsoft). | 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. | |||
feedly mini | ||||
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 1338 | skipping to change at line 1544 | |||
[RFC4627] | [RFC4627] | |||
D. Crockford. The application/json Media Type for JavaScript | D. Crockford. The application/json Media Type for JavaScript | |||
Object Notation (JSON) July 2006. Internet RFC 4627. URL: | Object Notation (JSON) July 2006. Internet RFC 4627. URL: | |||
http://www.ietf.org/rfc/rfc4627.txt | http://www.ietf.org/rfc/rfc4627.txt | |||
[TRACKING-COMPLIANCE] | [TRACKING-COMPLIANCE] | |||
Justin Brookman; Sean Harvey; Erica Newland; Heather West. | Justin Brookman; Sean Harvey; Erica Newland; Heather West. | |||
Tracking Compliance and Scope. 13 March 2012. W3C Working Draft. | Tracking Compliance and Scope. 13 March 2012. W3C Working Draft. | |||
(Work in progress.) URL: | (Work in progress.) URL: | |||
http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ | http://www.w3.org/TR/2011/WD-tracking-compliance-20120313/ | |||
[WEBIDL] | [WEBIDL] | |||
Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. | Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. | |||
(Work in progress.) URL: | (Work in progress.) URL: | |||
http://www.w3.org/TR/2011/WD-WebIDL-20110927/ | http://www.w3.org/TR/2011/WD-WebIDL-20110927/ | |||
B.2 Informative references | B.2 Informative references | |||
[COOKIES] | [COOKIES] | |||
Adam Barth. HTTP State Management Mechanism. April 2011. Internet | Adam Barth. HTTP State Management Mechanism. April 2011. Internet | |||
Proposed Standard RFC 6265. URL: | Proposed Standard RFC 6265. URL: | |||
http://www.rfc-editor.org/rfc/rfc6265.txt | http://www.rfc-editor.org/rfc/rfc6265.txt | |||
[KnowPrivacy] | [KnowPrivacy] | |||
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | |||
2009. URL: | 2009. URL: | |||
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | |||
[RFC3986] | ||||
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource | ||||
Identifier (URI): Generic Syntax. January 2005. Internet RFC 3986. | ||||
URL: http://www.ietf.org/rfc/rfc3986.txt | ||||
[RFC5785] | [RFC5785] | |||
Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform | Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform | |||
Resource Identifiers (URIs). April 2010. Internet Proposed | Resource Identifiers (URIs). April 2010. Internet Proposed | |||
Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt | Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt | |||
[URI-TEMPLATE] | [URI-TEMPLATE] | |||
Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David | Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David | |||
Orchard. URI Template. 26 January 2012. Internet Draft (work in | Orchard. URI Template. March 2012. Internet RFC 6570. URL: | |||
progress). URL: | http://www.rfc-editor.org/rfc/rfc6570.txt | |||
http://tools.ietf.org/html/draft-gregorio-uritemplate-08 | ||||
feedly mini | ||||
End of changes. 152 change blocks. | ||||
505 lines changed or deleted | 707 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/ |