dnt-wd3.txt   dnt-wd4.txt 
W3C W3C
Tracking Preference Expression (DNT) Tracking Preference Expression (DNT)
W3C Working Draft 02 October 2012 W3C Working Draft 30 April 2013
This version: This version:
http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/ http://www.w3.org/TR/2013/WD-tracking-dnt-20130430/
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/2012/WD-tracking-dnt-20120313/ http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/
Editors: Editors:
Roy T. Fielding, Adobe Roy T. Fielding, Adobe
David Singer, Apple David Singer, Apple
Copyright (c) 2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. W3C Copyright (c) 2013 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights
liability, trademark and document use rules apply. Reserved. W3C liability, trademark and document use rules apply.
---------------------------------------------------------------------- ----------------------------------------------------------------------
Abstract Abstract
This specification defines the technical mechanisms for expressing a This specification defines the technical mechanisms for expressing a
tracking preference via the DNT request header field in HTTP, via an HTML tracking preference via the DNT request header field in HTTP, via an HTML
DOM property readable by embedded scripts, and via properties accessible DOM property readable by embedded scripts, and via properties accessible
to various user agent plug-in or extension APIs. It also defines to various user agent plug-in or extension APIs. It also defines
mechanisms for sites to signal whether and how they honor this preference, mechanisms for sites to signal whether and how they honor this preference,
both in the form of a machine-readable tracking status resource at a both in the form of a machine-readable tracking status resource at a
well-known location and via a Tk response header field, and a mechanism well-known location and via a Tk response header field, and a mechanism
for allowing the user to approve site-specific exceptions to DNT as for allowing the user to approve exceptions to DNT as desired.
desired.
Status of This Document Status of This Document
This section describes the status of this document at the time of its This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports index at http://www.w3.org/TR/. can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a snapshot of live discussions within the Tracking This document is a snapshot of ongoing discussions within the Tracking
Protection Working Group. It does not yet capture all of our work. For Protection Working Group. Text present or not present in this document
example, we have issues that are [PENDING REVIEW] with complete text does not determine consensus within the Working Group; discussions and
proposals that have not yet made it into this draft. Text in blue boxes debates are ongoing. Text in option boxes (highlighted with light blue
presents multiple options the group is considering. Options included in background color) present options that the group is currently considering,
this draft should not be read as limitations on the potential outcome, but particularly where consensus is known to be lacking, and should be read as
rather simply as possible options that are currently under consideration a set of proposals rather than as limitations on the potential outcome.
by the working group. Readers may review changes from the previous Working Members of the Working Group wish to emphasize that this draft is a work
Draft. An issue tracking system is available for recording raised, open, in progress and not a decided outcome or guaranteed direction for future
pending review, closed, and postponed issues regarding this document. versions of this document.
Readers may review changes from the previous Working Draft. An issue
tracking system is available for recording raised, open, pending review,
closed, and postponed issues regarding this document.
This document was published by the Tracking Protection Working Group as a This document was published by the Tracking Protection Working Group as a
Working Draft. This document is intended to become a W3C Recommendation. Working Draft. This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to If you wish to make comments regarding this document, please send them to
public-tracking@w3.org (subscribe, archives). All feedback is welcome. public-tracking-comments@w3.org (subscribe, archives). All comments are
welcome.
Publication as a Working Draft does not imply endorsement by the W3C Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress. document as other than work in progress.
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
skipping to change at line 87 skipping to change at line 91
* 1. Introduction * 1. Introduction
* 2. Notational Conventions * 2. Notational Conventions
* 2.1 Requirements * 2.1 Requirements
* 2.2 Formal Syntax * 2.2 Formal Syntax
* 2.3 Terminology * 2.3 Terminology
* 3. Determining User Preference * 3. Determining User Preference
* 4. Expressing a Tracking Preference * 4. Expressing a Tracking Preference
* 4.1 Expression Format * 4.1 Expression Format
* 4.2 DNT Header Field for HTTP Requests * 4.2 DNT Header Field for HTTP Requests
* 4.3 JavaScript API to Detect Preference * 4.3 JavaScript Property to Detect Preference
* 4.4 Plug-In APIs * 4.4 Plug-In APIs
* 4.5 Tracking Preference Expressed in Other Protocols * 4.5 Tracking Preference Expressed in Other Protocols
* 5. Communicating a Tracking Status * 5. Communicating a Tracking Status
* 5.1 Overview * 5.1 Overview
* 5.2 Tracking Status Value * 5.2 Tracking Status Value
* 5.3 Tracking Status Qualifier Values * 5.2.1 Definition
* 5.4 Tk Header Field for HTTP Responses * 5.2.2 None (N)
* 5.4.1 Definition * 5.2.3 First Party (1)
* 5.4.2 Referring to a Request-specific Tracking Status * 5.2.4 Third Party (3)
* 5.2.5 Dynamic (X)
* 5.2.6 Consent (C)
* 5.2.7 Potential Consent (P)
* 5.2.8 Disregarding (D)
* 5.2.9 Updated (U)
* 5.2.10 Non-compliant (!)
* 5.3 Tk Header Field for HTTP Responses
* 5.3.1 Definition
* 5.3.2 Referring to a Request-specific Tracking Status
Resource Resource
* 5.4.3 Indicating an Interactive Status Change * 5.3.3 Indicating an Interactive Status Change
* 5.5 Tracking Status Resource * 5.4 Tracking Status Resource
* 5.5.1 Site-wide Tracking Status * 5.4.1 Site-wide Tracking Status
* 5.5.2 Request-specific Tracking Status * 5.4.2 Request-specific Tracking Status
* 5.5.3 Representation * 5.4.3 Representation
* 5.5.4 Status Checks are Not Tracked * 5.4.4 Status Checks are Not Tracked
* 5.5.5 Caching * 5.4.5 Caching
* 5.6 Status Code for Tracking Required * 5.5 Status Code for Tracking Required
* 5.7 Using the Tracking Status * 5.6 Using the Tracking Status
* 5.7.1 Discovering Deployment * 5.6.1 Discovering Deployment
* 5.7.2 Preflight Checks * 5.6.2 Preflight Checks
* 6. User-Granted Exceptions * 6. User-Granted Exceptions
* 6.1 Overview * 6.1 Overview
* 6.2 Motivating Principles and Use Cases * 6.2 Motivating Principles and Use Cases
* 6.3 Exception model * 6.3 Exception model
* 6.3.1 Introduction * 6.3.1 User Interaction
* 6.3.2 Exception use by browsers * 6.3.2 Processing Model
* 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 * 6.4.1 API to Request a Site-specific Exception
* 6.4.2 API to Cancel a Site-specific Exception * 6.4.2 API to Cancel a Site-specific Exception
* 6.4.3 API to Confirm a Site-specific Exception
* 6.5 JavaScript API for Web-wide Exceptions * 6.5 JavaScript API for Web-wide Exceptions
* 6.5.1 API to Request a Web-wide Exception * 6.5.1 API to Request a Web-wide Exception
* 6.5.2 API to cancel a web-wide exception * 6.5.2 API to Cancel a Web-wide Exception
* 6.6 Querying a host's exception status * 6.5.3 API to Confirm a Web-wide Exception
* 6.7 Transfer of an exception to another third party * 6.6 Transfer of an exception to another third party
* 6.8 User interface guidelines * 6.7 User interface guidelines
* 6.8 Exceptions without interactive JavaScript
* 6.9 Exceptions without a DNT header * 6.9 Exceptions without a DNT header
* 6.10 Fingerprinting * 6.10 Exception use by sites
* 6.11 Fingerprinting
* A. Acknowledgements * A. Acknowledgements
* B. References * B. References
* B.1 Normative references * B.1 Normative references
* B.2 Informative references * B.2 Informative references
1. Introduction 1. Introduction
The World Wide Web (WWW, or Web) consists of millions of sites The World Wide Web (WWW, or Web) consists of millions of sites
interconnected through the use of hypertext. Hypertext provides a simple, interconnected through the use of hypertext. Hypertext provides a simple,
page-oriented view of a wide variety of information that can be traversed page-oriented view of a wide variety of information that can be traversed
skipping to change at line 197 skipping to change at line 213
expressed preference, and JavaScript APIs for determining DNT status and expressed preference, and JavaScript APIs for determining DNT status and
requesting a user-granted 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 136: Resolve dependencies of the TPE on the compliance specification Issue 136: Resolve dependencies of the TPE on the compliance specification
The WG has not come to consensus regarding the definition of tracking and [OPEN] The WG has not come to consensus regarding the definition of
the scope of DNT. As such, a site cannot actually say with any confidence tracking and the scope of DNT. As such, a site cannot actually say with
whether or not it is tracking, let alone describe the finer details in a any confidence whether or not it is tracking, let alone describe the finer
tracking status resource. This issue will be resolved by progress on the details in a tracking status resource. This issue will be resolved by
TCS document, though its resolution is a necessary prerequisite to progress on the TCS document, though its resolution is a necessary
understanding and correctly implementing the protocol defined by this prerequisite to understanding and correctly implementing the protocol
document. defined by this document.
2. Notational Conventions 2. Notational Conventions
2.1 Requirements 2.1 Requirements
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, The key words must, must not, required, should, should not, recommended,
MAY, and OPTIONAL in this specification are to be interpreted as described may, and optional in this specification are to be interpreted as described
in [RFC2119]. in [RFC2119].
2.2 Formal Syntax 2.2 Formal Syntax
This specification uses Augmented Backus-Naur Form [ABNF] to define This specification uses Augmented Backus-Naur Form [ABNF] to define
network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs.
2.3 Terminology 2.3 Terminology
This specification uses the term user agent to refer to any of the various This specification uses the term user agent to refer to any of the various
client programs capable of initiating HTTP requests, including, but not client programs capable of initiating HTTP requests, including, but not
limited to, browsers, spiders (web-based robots), command-line tools, limited to, browsers, spiders (web-based robots), command-line tools,
native applications, and mobile apps [HTTP11]. native applications, and mobile apps [HTTP11].
The term permitted use is used to indicate a restricted set of conditions 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. under which tracking is allowed in spite of the user's DNT preference.
The term user-granted exception is used when the user has permitted The term user-granted exception is used when the user has permitted
tracking by a given third party, usually in the form of a site-specific tracking by a given third party.
exception.
A companion document, [TRACKING-COMPLIANCE], defines many of the terms A companion document, [TRACKING-COMPLIANCE], defines many of the terms
used here, notably 'party', 'first party', and 'third party'. used here, notably 'party', 'first party', and 'third party'.
3. Determining User Preference 3. Determining User Preference
The goal of this protocol is to allow a user to express their personal The goal of this protocol is to allow a user to express their personal
preference regarding tracking to each server and web application that they preference regarding tracking to each server and web application that they
communicate with via HTTP, thereby allowing each service to either adjust communicate with via HTTP, thereby allowing each service to either adjust
their behavior to meet the user's expectations or reach a separate their behavior to meet the user's expectations or reach a separate
agreement with the user to satisfy all parties. agreement with the user to satisfy all parties.
Key to that notion of expression is that it MUST reflect the user's Key to that notion of expression is that the signal sent MUST reflect the
preference, not the choice of some vendor, institution, or network-imposed user's preference, not the choice of some vendor, institution, site, or
mechanism outside the user's control. The basic principle is that a any network-imposed mechanism outside the user's control; this applies
tracking preference expression is only transmitted when it reflects a equally to both the general preference and exceptions. The basic principle
deliberate choice by the user. In the absence of user choice, there is no is that a tracking preference expression is only transmitted when it
tracking preference expressed. reflects a deliberate choice by the user. In the absence of user choice,
there is no tracking preference expressed.
A user agent MUST offer users a minimum of two alternative choices for a A user agent MUST offer users a minimum of two alternative choices for a
Do Not Track preference: unset or DNT:1. A user agent MAY offer a third Do Not Track preference: unset or DNT:1. A user agent MAY offer a third
alternative choice: DNT:0. alternative choice: DNT:0.
If the user's choice is DNT:1 or DNT:0, the tracking preference is If the user's choice is DNT:1 or DNT:0, the tracking preference is
enabled; otherwise, the tracking preference is not enabled. enabled; otherwise, the tracking preference is not enabled.
A user agent MUST have a default tracking preference of unset (not A user agent MUST have a default tracking preference of unset (not
enabled) unless a specific tracking preference is implied by the decision enabled) unless a specific tracking preference is implied by the decision
skipping to change at line 291 skipping to change at line 307
have access to user agents with a predetermined preference enabled, the have access to user agents with a predetermined preference enabled, the
user is at least able to choose whether to make use of those user agents. user is at least able to choose whether to make use of those user agents.
In contrast, if a user brings their own Web-enabled device to a library or In contrast, if a user brings their own Web-enabled device to a library or
cafe with wireless Internet access, the expectation will be that their cafe with wireless Internet access, the expectation will be that their
chosen user agent and personal preferences regarding Web site behavior chosen user agent and personal preferences regarding Web site behavior
will not be altered by the network environment, aside from blanket will not be altered by the network environment, aside from blanket
limitations on what resources can or cannot be accessed through that limitations on what resources can or cannot be accessed through that
network. Implementations of HTTP that are not under control of the user network. Implementations of HTTP that are not under control of the user
MUST NOT generate or modify a tracking preference. MUST NOT generate or modify a tracking preference.
Issue 136: Resolve dependencies of the TPE on the compliance specification
Some participants have noted that enabled/not-enabled status may depend on
the Compliance document or may have varying implications in different
jurisdictions.
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.
skipping to change at line 329 skipping to change at line 351
servers might make use of other preference information outside the scope servers might make use of other preference information outside the scope
of this protocol, such as site-specific user preferences or third-party of this protocol, such as site-specific user preferences or third-party
registration services, to inform or adjust their behavior when no explicit registration services, to inform or adjust their behavior when no explicit
preference is expressed via this protocol. preference is expressed via this protocol.
4.2 DNT Header Field for HTTP Requests 4.2 DNT Header Field for HTTP Requests
The DNT header field is hereby defined as the means for expressing a The DNT header field is hereby defined as the means for expressing a
user's tracking preference via HTTP [HTTP11]. user's tracking preference via HTTP [HTTP11].
DNT-field-name = "DNT" ; case-insensitive DNT-field-name = "DNT"
DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive DNT-field-value = ( "0" / "1" ) *DNT-extension
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash ; excludes CTL, SP, DQUOTE, comma, backslash
A user agent MUST send the DNT header field on all HTTP requests if (and A user agent MUST send the DNT header field on all HTTP requests if (and
only if) a tracking preference is enabled. A user agent MUST NOT send the only if) a tracking preference is enabled. A user agent MUST NOT send the
DNT header field if a tracking preference is not enabled. DNT header field if a tracking preference is not enabled.
The DNT field-value sent by a user agent MUST begin with the numeric The DNT field-value sent by a user agent MUST begin with the numeric
character "1" (%x31) if a tracking preference is enabled, the preference character "1" (%x31) if a tracking preference is enabled, the preference
is for no tracking, and there is not a site-specific exception for the is for no tracking, and there is not an exception for the origin server
origin server targeted by this request. targeted by this request.
The DNT field-value sent by a user agent MUST begin with the numeric The DNT field-value sent by a user agent MUST begin with the numeric
character "0" (%x30) if a tracking preference is enabled and the character "0" (%x30) if a tracking preference is enabled and the
preference is to allow tracking in general or by specific exception for preference is to allow tracking in general or by specific exception for
the origin server targeted by this request. the origin server targeted by this request.
Example 1 Example 1
GET /something/here HTTP/1.1 GET /something/here HTTP/1.1
Host: example.com Host: example.com
skipping to change at line 378 skipping to change at line 400
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.5.3 Representation). Since the DNT without further encoding (section 5.4.3 Representation). Since the DNT
header field is intended to be sent on every request, when enabled, header field is intended to be sent on every request, when enabled,
designers of future extensions ought to use as few extension characters as designers of future extensions ought to use as few extension characters as
possible. possible.
Note Note
This document does not have any implied or specified behavior for the This document does not have any implied or specified behavior for the
user-agent treatment of cookies when DNT is enabled. user-agent treatment of cookies when DNT is enabled.
4.3 JavaScript API to Detect Preference Note
A doNotTrack attribute on the Navigator interface [NAVIGATOR] (e.g., the The HTTP specification [HTTP11] permits multiple headers with the same
window.navigator object) is hereby defined as the means for expressing the field-name only under restricted circumstances which do not apply here;
user's general tracking preference to scripts running within a top-level hence, at most one DNT header may be present in a valid HTTP request.
page. A user agent MUST provide a doNotTrack attribute on the Navigator
interface for each top-level page.
partial interface Navigator { Issue 176: Requirements on intermediaries/isps and header insertion that
readonly attribute DOMString doNotTrack; might affect tracking
};
doNotTrack of type DOMString, readonly [OPEN]
When a tracking preference is enabled, the doNotTrack attribute
for each top-level page MUST have the same string value that would
be sent in a DNT-field-value (section 4.2 DNT Header Field for
HTTP Requests) to an origin server that does not have any
corresponding user-granted exceptions. When a tracking preference
is not enabled, the doNotTrack attribute for each top-level page
MUST have a value of null.
The doNotTrack attribute only provides the user's general tracking Issue 153: What are the implications on software that changes requests but
preference, independent of any user-granted exceptions or out-of-band does not necessarily initiate them?
consent. A script wishing to determine the specific tracking preference
for a given document origin is expected to use the API in section 6.6
Querying a host's exception status.
A user agent MUST provide a doNotTrack attribute value that is consistent [PENDING REVIEW]
with the user's current tracking preference that would be expressed via
the DNT header field. However, changes to the user's preference might
occur between the time when the APIs are checked and an actual request is
made. A server MUST treat the user's most recently received preference as
authoritative.
Issue 116: How can we build a JS DOM property which doesn't allow inline 4.3 JavaScript Property to Detect Preference
JS to receive mixed signals?
[PENDING REVIEW] Updated text in this section. This property enables a site executing code in its own origin to determine
what DNT header would be sent to it in the current context, taking into
account the user's general preference (if any) and any user-granted
exceptions.
[NoInterfaceObject]
interface WindowDoNotTrack {
attribute DOMString doNotTrack;
};
doNotTrack of type DOMString,
Returns the same string value that would be sent in a
DNT-field-value (section 4.2 DNT Header Field for HTTP Requests)
to a target that is the document-origin of the window, in the
context of the current top-level origin. If no DNT header would be
sent (e.g. because a tracking preference is not enabled) the value
is null.
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.
skipping to change at line 489 skipping to change at line 508
tracking status resource at a specific well-known location and an OPTIONAL tracking status resource at a specific well-known location and an OPTIONAL
space of request-specific tracking status resources for sites where the space of request-specific tracking status resources for sites where the
tracking status might vary based on data within the request. It also tracking status might vary based on data within the request. It also
defines a Tk response header field that MAY be sent in any HTTP response, defines a Tk response header field that MAY be sent in any HTTP response,
MUST be sent in responses to requests that modify the tracking status, and MUST be sent in responses to requests that modify the tracking status, and
MAY direct the user to a request-specific tracking status resource MAY direct the user to a request-specific tracking status resource
applicable to the current request. applicable to the current request.
5.2 Tracking Status Value 5.2 Tracking Status Value
A tracking status value is a short notation for communicating how a 5.2.1 Definition
A tracking status value (TSV) is a short notation for communicating how a
designated resource conforms to the tracking protection protocol, as designated resource conforms to the tracking protection protocol, as
defined by this document and [TRACKING-COMPLIANCE]. There is no form of defined by this document and [TRACKING-COMPLIANCE]. For a site-wide
negative response; i.e., an origin server that does not wish to claim tracking status resource, the designated resource to which the tracking
conformance to this protocol would not supply a tracking status resource status applies is any resource on the same origin server. For a Tk
and would not send a Tk header field in responses. response header field, the corresponding request target is the designated
resource and remains so for any subsequent request-specific tracking
status resource referred to by that field.
For a site-wide tracking status resource, the designated resource to which The tracking status value is case sensitive, as defined formally by the
the tracking status applies is any resource on the same origin server. For following ABNF.
a Tk response header field, the corresponding request target is the
designated resource and remains so for any subsequent request-specific
tracking status resource referred to by that field.
All of the tracking status mechanisms use a common format for the tracking TSV = "1" ; "1" - first-party
status value: a single character from a limited set. The meaning of each / "3" ; "3" - third-party
allowed character is defined in the following table. / %x43 ; "C" - consent
/ %x44 ; "D" - disregarding
/ %x4E ; "N" - none
/ %x50 ; "P" - potential consent
/ %x55 ; "U" - updated
/ %x58 ; "X" - dynamic
/ ( "!" [testv] ) ; "!" - non-compliant
status meaning testv = id-char
None: The designated resource does not perform tracking of any
N kind, not even for a permitted use, and does not make use of any
data collected from tracking. Issue 137: Does hybrid tracking status need to distinguish between first
First party: The designated resource is designed for use within a party (1) and outsourcing service provider acting as a first party (s)
first-party context and conforms to the requirements on a first
1 party. If the designated resource is operated by an outsourced [PENDING REVIEW] No, in practice there may be dozens of service providers
service provider, the service provider claims that it conforms to on any given request. If the designated resource is operated by a service
the requirements on a third party acting as a first party. provider acting as a first party, then the responsible first party is
Third party: The designated resource is designed for use within a identified by the controller member or the owner of the origin server
3 third-party context and conforms to the requirements on a third domain. This satisfies the use case of distinguishing between a service
party. provider acting for some other site and the same service provider acting
Dynamic: The designated resource is designed for use in both first on one of its own sites.
and third-party contexts and dynamically adjusts tracking status
accordingly. If X is present in the site-wide tracking status, more 5.2.2 None (N)
information MUST be provided via the Tk response header field when
X accessing a designated resource. If X is present in the Tk header A tracking status value of N means the origin server claims that the
field, more information will be provided in a request-specific designated resource does not perform tracking of any kind, not even for a
tracking status resource referred to by the status-id. An origin permitted use, and does not make use of any data collected from tracking.
server MUST NOT send X as the tracking status value in the
representation of a request-specific tracking status resource. Issue 119: Specify "absolutely not tracking"
Consent: The designated resource believes it has received prior
consent for tracking this user, user agent, or device, perhaps via [OPEN] The N tracking status value corresponds to this notion of
C some mechanism not defined by this specification, and that prior absolutely not tracking.
consent overrides the tracking preference expressed by this
protocol. 5.2.3 First Party (1)
Updated: The request resulted in a potential change to the tracking
status applicable to this user, user agent, or device. A user agent A tracking status value of 1 means that the origin server claims that the
that relies on a cached tracking status SHOULD update the cache designated resource is designed for use only within a first-party context
U entry with the current status by making a new request on the and conforms to the requirements on a first party. If the designated
applicable tracking status resource. An origin server MUST NOT send resource is operated by an outsourced service provider, the service
U as a tracking status value anywhere other than a Tk header field provider claims that it conforms to the requirements on a third party
that is in response to a state-changing request. acting as a first party.
For the site-wide tracking status and Tk header field, the tracking status For the site-wide tracking status and Tk header field, the tracking status
values 1 and 3 indicate how the designated resource is designed to values 1 and 3 indicate how the designated resource is designed to
conform, not the nature of the request. Hence, if a user agent is making a conform, not the nature of the request. Hence, if a user agent is making a
request in what appears to be a third-party context and the tracking request in what appears to be a third-party context and the tracking
status value indicates that the designated resource is designed only for status value indicates that the designated resource is designed only for
first-party conformance, then either the context has been misunderstood first-party conformance, then either the context has been misunderstood
(both are actually the same party) or the resource has been referenced (both are actually the same party) or the resource has been referenced
incorrectly. For the request-specific tracking status resource, an incorrectly.
indication of first or third party as the status value describes how the
resource conformed to that specific request, and thus indicates both the
nature of the request (as viewed by the origin server) and the applicable
set of requirements to which the origin server claims to conform.
The tracking status value is case sensitive, as defined formally by the For the request-specific tracking status resource, an indication of first
following ABNF. or third party as the status value describes how the resource conformed to
that specific request, and thus indicates both the nature of the request
(as viewed by the origin server) and the applicable set of requirements to
which the origin server claims to conform.
tracking-v = "1" ; "1" - first-party 5.2.4 Third Party (3)
/ "3" ; "3" - third-party
/ %x43 ; "C" - consent
/ %x4E ; "N" - none
/ %x55 ; "U" - updated
/ %x58 ; "X" - dynamic
Issue 137: Does hybrid tracking status need to distinguish between first A tracking status value of 3 means that the origin server claims that the
party (1) and outsourcing service provider acting as a first party (s) designated resource is designed for use within a third-party context and
conforms to the requirements on a third party.
[PENDING REVIEW] No, in practice there may be dozens of service providers 5.2.5 Dynamic (X)
on any given request. If the designated resource is operated by a service
provider acting as a first party, then the responsible first party is
identified by the policy link or the owner of the origin server domain.
This satisfies the use case of distinguishing between a service provider
acting for some other site and the same service provider acting on one of
its own sites.
5.3 Tracking Status Qualifier Values A tracking status value of X means that the origin server claims that the
designated resource is designed for use in both first and third-party
contexts and dynamically adjusts tracking status accordingly.
When present, the tracking status qualifier member's value consists of a If X is present in the site-wide tracking status, more information MUST be
string of characters indicating what permitted uses for tracking are being provided via the Tk response header field when accessing a designated
used. Multiple qualifiers can be provided. resource. If X is present in the Tk header field, more information will be
provided in a request-specific tracking status resource referred to by the
status-id. An origin server MUST NOT send X as the tracking status value
in the representation of a request-specific tracking status resource.
Issue 136: Resolve dependencies of the TPE on the compliance specification 5.2.6 Consent (C)
The list of qualifiers is intended to match one to one to the permitted A tracking status value of C means that the origin server believes it has
uses identified by [TRACKING-COMPLIANCE], using references to the received prior consent for tracking this user, user agent, or device,
definitions there. The list will then be updated accordingly. perhaps via some mechanism not defined by this specification, and that
prior consent overrides the tracking preference expressed by this
protocol.
qualifier meaning Issue 195: Flows and signals for handling out of band consent
Audit: Tracking is limited to that necessary for an external
a audit of the service context and the data collected is minimized
accordingly.
c Ad frequency capping: Tracking is limited to frequency capping
and the data collected is minimized accordingly.
Fraud prevention: Tracking is limited to that necessary for
f preventing or investigating fraudulent behavior and security
violations; the data collected is minimized accordingly.
Local constraints: Tracking is limited to what is required by
l local law, rule, or regulation and the data collected is
minimized accordingly.
r Referrals: Tracking is limited to collecting referral
information and the data collected is minimized accordingly.
Qualifiers that indicate limitations on tracking correspond to the [OPEN] The C tracking status value indicates out of band consent.
specific permitted uses in [TRACKING-COMPLIANCE]. An origin server
indicating one or more of those permitted uses also indicates that it
conforms to the requirements associated with those permitted uses.
Multiple limitation qualifiers mean that multiple permitted uses of
tracking might be present and that each such use conforms to the
associated requirements. All limitation qualifiers imply some form of
tracking might be used and thus MUST NOT be provided with a tracking
status value of N (not tracking).
Future extensions to this protocol might define additional characters as Issue 152: User Agent Compliance: feedback for out-of-band consent
qualifiers from the ext-qualifier set (consisting of the remaining unused
lowercase letters, dot, dash, and underscore). Recipients SHOULD ignore
extension qualifiers that they do not understand.
The tracking qualifier value is case sensitive, as defined formally by the [PENDING REVIEW] Proposal is to not add UA requirements.
following ABNF.
tracking-q = tracking-q-v* 5.2.7 Potential Consent (P)
tracking-q-v = %x61 ; "a" - audit
/ %x63 ; "c" - capping
/ %x66 ; "f" - fraud
/ %x6C ; "l" - local
/ %x72 ; "r" - referral
5.4 Tk Header Field for HTTP Responses A tracking status value of P means that the origin server does not know,
in real-time, whether it has received prior consent for tracking this
user, user agent, or device, but promises not to use or share any DNT:1
data until such consent has been determined, and further promises to
delete or de-identify within forty-eight hours any DNT:1 data received for
which such consent has not been received.
5.4.1 Definition Since this status value does not itself indicate whether a specific
request is tracked, an origin server that sends a P tracking status value
MUST provide an edit member in the corresponding tracking status
representation that links to a resource for obtaining consent status.
The P tracking status value is specifically meant to address audience
survey systems for which determining consent at the time of a request is
either impractical, due to legacy systems not being able to keep up with
Web traffic, or potentially "gamed" by first party sites if they can
determine which of their users have consented. The data cannot be used for
the sake of personalization. If consent can be determined at the time of a
request, the C tracking status is preferred.
Issue 195: Flows and signals for handling out of band consent
[OPEN] The P tracking status value indicates a special case of general
data collection which is then trimmed to exclude those without out of band
consent.
5.2.8 Disregarding (D)
A tracking status value of D means that the origin server is unable or
unwilling to respect a tracking preference received from the requesting
user agent. An origin server that sends this tracking status value MUST
detail within the server's corresponding privacy policy the conditions
under which a tracking preference might be disregarded.
For example, an origin server might disregard the DNT field received from
specific user agents (or via specific network intermediaries) that are
deemed to be non-conforming, might be collecting additional data from
specific source network locations due to prior security incidents, or
might be compelled to disregard certain DNT requests to comply with a
local law, regulation, or order.
Issue 161: Do we need a tracking status value for partial compliance or
rejecting DNT?
[PENDING REVIEW] The D tracking status value indicates rejection.
5.2.9 Updated (U)
A tracking status value of U means that the request resulted in a
potential change to the tracking status applicable to this user, user
agent, or device. A user agent that relies on a cached tracking status
SHOULD update the cache entry with the current status by making a new
request on the applicable tracking status resource.
An origin server MUST NOT send U as a tracking status value anywhere other
than a Tk header field that is in response to a state-changing request.
5.2.10 Non-compliant (!)
A tracking status value of ! means that the origin server is unable or
unwilling to claim that the designated resource conforms to the tracking
protection protocol, but is providing a tracking response for the sake of
testing and transparency.
The ! value has been provided to ease testing and deployment on production
systems during the initial periods of testing compliance and during
adjustment periods due to future protocol changes or shifting regulatory
constraints. Note that this value does not indicate that the DNT signal
will be ignored, nor that tracking will occur as a result of accessing the
designated resource, but rather that the site makes no claim to
conformance at this time.
This ! value MAY be followed by an optional testv character in order to
communicate further information for testing, such as what tracking status
the server intends to deploy for the designated resource at some point in
the future, but that cannot be relied upon as an indication of
conformance.
Issue 161: Do we need a tracking status value for partial compliance or
rejecting DNT?
[PENDING REVIEW] The ! tracking status value indicates non-compliance in a
format that conforms to the response syntax.
5.3 Tk Header Field for HTTP Responses
5.3.1 Definition
The Tk response header field is hereby defined as an OPTIONAL means for The Tk response header field is hereby defined as an OPTIONAL means for
indicating the tracking status that applied to the corresponding request indicating the tracking status that applied to the corresponding request
and as a REQUIRED means for indicating that a state-changing request has and as a REQUIRED means for indicating that a state-changing request has
resulted in an interactive change to the tracking status. resulted in an interactive change to the tracking status.
Tk-field-name = "Tk" ; case-insensitive Tk-field-name = "Tk"
Tk-field-value = tracking-v [tracking-q] [ ";" status-id ] Tk-field-value = TSV [ ";" status-id ]
The Tk field-value begins with a tracking status value (section 5.2 The Tk field-value begins with a tracking status value (section 5.2
Tracking Status Value), optionally followed by one or more tracking Tracking Status Value), optionally followed by a semicolon and a status-id
qualifiers (section 5.3 Tracking Status Qualifier Values), and then that refers to a request-specific tracking status resource (section 5.3.2
optionally a semicolon and a status-id that refers to a request-specific Referring to a Request-specific Tracking Status Resource).
tracking status resource (section 5.4.2 Referring to a Request-specific
Tracking Status Resource).
For example, a Tk header field for a resource that claims not to be For example, a Tk header field for a resource that claims not to be
tracking would look like: tracking would look like:
Example 2 Example 2
Tk: N Tk: N
whereas a Tk header field for a resource that might perform tracking 5.3.2 Referring to a Request-specific Tracking Status Resource
(though not necessarily for every request) and conforms to the third-party
requirements of [TRACKING-COMPLIANCE], while claiming the audit exception,
would look like:
Example 3
Tk: 3a
5.4.2 Referring to a Request-specific Tracking Status Resource
If an origin server has multiple, request-specific tracking policies, such If an origin server has multiple, request-specific tracking policies, such
that the tracking status might differ depending on some aspect of the that the tracking status might differ depending on some aspect of the
request (e.g., method, target URI, header fields, data, etc.), the origin request (e.g., method, target URI, header fields, data, etc.), the origin
server MAY provide an additional subtree of well-known resources server MAY provide an additional subtree of well-known resources
corresponding to each of those distinct tracking statuses. The OPTIONAL corresponding to each of those distinct tracking statuses. The OPTIONAL
status-id portion of the Tk field-value indicates which specific tracking status-id portion of the Tk field-value indicates which specific tracking
status resource applies to the current request. status resource applies to the current request.
status-id = 1*id-char ; case-sensitive status-id = 1*id-char
id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/" id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
For example, a response containing For example, a response containing
Example 4 Example 3
Tk: 1;fRx42 Tk: 1;fRx42
indicates that the target resource claims to conform to the first-party indicates that the target resource claims to conform to the first-party
requirements of [TRACKING-COMPLIANCE] and that an applicable tracking requirements of [TRACKING-COMPLIANCE] and that an applicable tracking
status representation can be obtained by performing a retrieval request on status representation can be obtained by performing a retrieval request on
/.well-known/dnt/fRx42 /.well-known/dnt/fRx42
If a Tk field-value has a tracking status value of X (dynamic), then a If a Tk field-value has a tracking status value of X (dynamic), then a
status-id MUST be included in the field-value. status-id MUST be included in the field-value. The status-id is
case-sensitive.
5.4.3 Indicating an Interactive Status Change 5.3.3 Indicating an Interactive Status Change
We anticipate that interactive mechanisms might be used, beyond the scope We anticipate that interactive mechanisms might be used, beyond the scope
of this specification, that have the effect of asking for and obtaining of this specification, that have the effect of asking for and obtaining
prior consent for tracking, or for modifying prior indications of consent. prior consent for tracking, or for modifying prior indications of consent.
For example, the tracking status resource's status-object defines a For example, the tracking status resource's status-object defines an edit
control member that can refer to such a mechanism. Although such member that can refer to such a mechanism. Although such out-of-band
out-of-band mechanisms are not defined by this specification, their mechanisms are not defined by this specification, their presence might
presence might influence the tracking status object's response value. influence the tracking status object's response value.
When an origin server provides a mechanism via HTTP for establishing or When an origin server provides a mechanism via HTTP for establishing or
modifying out-of-band tracking preferences, the origin server MUST modifying out-of-band tracking preferences, the origin server MUST
indicate within the mechanism's response when a state-changing request has indicate within the mechanism's response when a state-changing request has
resulted in a change to the tracking status for that server. This resulted in a change to the tracking status for that server. This
indication of an interactive status change is accomplished by sending a Tk indication of an interactive status change is accomplished by sending a Tk
header field in the response with a tracking status value of U (updated). header field in the response with a tracking status value of U (updated).
Example 5 Example 4
Tk: U Tk: U
5.5 Tracking Status Resource 5.4 Tracking Status Resource
5.5.1 Site-wide Tracking Status 5.4.1 Site-wide Tracking Status
An origin server MUST provide a site-wide tracking status resource at the An origin server MUST provide a site-wide tracking status resource at the
well-known identifier [RFC5785] well-known identifier [RFC5785]
/.well-known/dnt /.well-known/dnt/
(relative to the URI of that origin server) for obtaining information (relative to the URI of that origin server) for obtaining information
about the potential tracking behavior of resources 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 can be used for verification of DNT
support, as described in section 5.7 Using the Tracking Status. support, as described in section 5.6 Using the Tracking Status.
A valid retrieval request (e.g., a GET in HTTP) on the well-known URI MUST A valid retrieval request (e.g., a GET in HTTP) on the well-known URI 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
MAY be cached, as described in section 5.5.5 Caching. can be cached, as described in section 5.4.5 Caching.
5.5.2 Request-specific Tracking Status 5.4.2 Request-specific Tracking Status
If an origin server has multiple, request-specific tracking policies, such If an origin server has multiple, request-specific tracking policies, such
that the tracking status might differ depending on some aspect of the that the tracking status might differ depending on some aspect of the
request (e.g., method, target URI, header fields, data, etc.), the origin request (e.g., method, target URI, header fields, data, etc.), the origin
server MAY provide an additional subtree of well-known resources server MAY provide an additional subtree of well-known resources
corresponding to each of those distinct tracking statuses. The Tk response corresponding to each of those distinct tracking statuses. The Tk response
header field (section 5.4 Tk Header Field for HTTP Responses) can include header field (section 5.3 Tk Header Field for HTTP Responses) can include
a status-id to indicate which specific tracking status resource applies to a status-id to indicate which specific tracking status resource applies to
the current request. the current request.
The tracking status resource space is defined by the following URI The tracking status resource space is defined by the following URI
Template [URI-TEMPLATE]: Template [URI-TEMPLATE]:
/.well-known/dnt{/status-id} /.well-known/dnt/{+status-id}
where the value of status-id is a string of URI-safe characters provided where the value of status-id is a string of URI-safe characters provided
by a Tk field-value in response to a prior request. For example, a prior by a Tk field-value in response to a prior request. For example, a prior
response containing response containing
Example 6 Example 5
Tk: 1;ahoy Tk: 1;ahoy
refers to the specific tracking status resource refers to the specific tracking status resource
/.well-known/dnt/ahoy /.well-known/dnt/ahoy
Resources within the request-specific tracking status resource space are Resources within the request-specific tracking status resource space are
represented using the same format as a site-wide tracking status resource. represented using the same format as a site-wide tracking status resource.
5.5.3 Representation 5.4.3 Representation
The representation of a tracking status resource shall be provided in the An origin server MUST provide a representation of each tracking status
"application/json" format [RFC4627] and MUST conform to the ABNF for resource in the JSON format [RFC4627] that conforms to the ABNF for
status-object (except that the members within each member-list MAY be status-object (except that the members within each member-list MAY be
provided in any order). provided in any order).
The following example tracking status representation illustrates all of The following example tracking status representation illustrates all of
the fields defined by this specification, most of which are optional. the fields defined by this specification, most of which are optional.
Example 7 Example 6
{ {
"tracking": "1", "tracking": "1",
"qualifiers": "afc",
"controller": ["https://www.example.com/privacy"],
"same-party": [ "same-party": [
"example.com", "example.com",
"example_vids.net", "example_vids.net",
"example_stats.com" "example_stats.com"
], ],
"third-party": [ "third-party": [
"api.example.net" "api.example.net"
], ],
"audit": [ "audit": [
"http://auditor.example.org/727073" "http://auditor.example.org/727073"
], ],
"policy": "/tracking.html", "policy": "/privacy.html#tracking",
"control": "http://example.com/your/data" "edit": "http://example.com/your/data"
} }
A tracking status representation consists of a single status-object A tracking status representation consists of a single status-object
containing members that describe the tracking status applicable to the containing members that describe the tracking status applicable to the
designated resource. designated resource.
status-object = begin-object member-list end-object status-object = begin-object member-list end-object
member-list = tracking ns tracking-v [tracking-q] member-list = tracking ns tracking-v
[ vs qualifiers ns qualifiers-v ]
[ vs controller ns controller-v ]
[ vs same-party ns same-party-v ] [ vs same-party ns same-party-v ]
[ vs third-party ns third-party-v ] [ vs third-party ns third-party-v ]
[ vs audit ns audit-v ] [ vs audit ns audit-v ]
[ vs policy ns policy-v ] [ vs policy ns policy-v ]
[ vs control ns control-v ] [ vs edit ns edit-v ]
*( vs extension ) *( vs extension )
A status-object MUST have a member named tracking that contains a single A status-object always has a member named tracking with a string value
character tracking status value (section 5.2 Tracking Status Value), that consists of the tracking status value applicable to the designated
optionally followed by one or more tracking qualifiers (section 5.3 resource (section 5.2 Tracking Status Value).
Tracking Status Qualifier Values) .
tracking = %x22 "tracking" %x22 tracking = %x22 "tracking" %x22
tracking-v = %x22 TSV %x22
For example, the following demonstrates a minimal tracking status For example, the following demonstrates a minimal tracking status
representation that is applicable to any resource that does not perform representation that is applicable to any resource that does not perform
tracking. tracking.
Example 8 Example 7
{"tracking": "N"} {"tracking": "N"}
An origin server MAY send a status-object member named qualifiers with a
string value containing a sequence of case sensitive characters
corresponding to each of the permitted uses (as defined in
[TRACKING-COMPLIANCE]) that might be in use for the designated resource.
The purpose of this field is to provide additional transparency where
desired.
qualifier meaning
Audit: Tracking is limited to that necessary for an external
a audit of the service context and the data collected is minimized
accordingly.
c Ad frequency capping: Tracking is limited to frequency capping
and the data collected is minimized accordingly.
Fraud prevention: Tracking is limited to that necessary for
f preventing or investigating fraudulent behavior and security
violations; the data collected is minimized accordingly.
Local constraints: Tracking is limited to what is required by
l local law, rule, or regulation and the data collected is
minimized accordingly.
r Referrals: Tracking is limited to collecting referral
information and the data collected is minimized accordingly.
Multiple qualifiers mean that multiple permitted uses of tracking might be
present and that each such use conforms to the associated requirements.
All qualifiers imply some form of tracking might be used and thus MUST NOT
be provided with a tracking status value of N (not tracking).
qualifiers = %x22 "qualifiers" %x22
qualifiers-v = %x22 0*5qualifier %x22
qualifier = %x61 ; "a" - audit
/ %x63 ; "c" - capping
/ %x66 ; "f" - fraud
/ %x6C ; "l" - local
/ %x72 ; "r" - referral
Issue 136: Resolve dependencies of the TPE on the compliance specification
[OPEN] The list of qualifiers is intended to match one to one to the
permitted uses identified by [TRACKING-COMPLIANCE], using references to
the definitions there. The list will then be updated accordingly.
An origin server MAY send a member named controller with an array value
containing a list of URI references indirectly identifying the party or
set of parties that claims to be the responsible data controller for
personal data collected via the designated resource. An origin server MUST
send a controller member if the responsible data controller does not own
the designated resource's domain name.
An origin server that does not send controller is implying that its domain
owner is the sole data controller; information about the data controller
ought to be found on the designated resource's site root page, or by way
of a clearly indicated link from that page (i.e., no controller member is
considered equivalent to: "controller":["/"]).
If the designated resource has joint data controllers (i.e., multiple
parties have independent control over the collected data), the origin
server MUST send a controller member that contains a reference for each
data controller.
Each URI reference provided in controller MUST refer to a resource that,
if a retrieval action is performed on that URI, would provide the user
with information regarding (at a minimum) the identity of the
corresponding party and its data collection practices.
controller = %x22 "controller" %x22
controller-v = array-of-strings
An OPTIONAL member named same-party 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 party, to the extent they are referenced by the designated resource, same party, to the extent they are referenced by the designated resource,
since all data collected via those references share the same data since all data collected via those references share the same data
controller. controller as the designated resource.
same-party = %x22 "same-party" %x22 same-party = %x22 "same-party" %x22
same-party-v = array-of-strings same-party-v = array-of-strings
An OPTIONAL member named third-party MAY be provided with an array value An OPTIONAL member named third-party MAY be provided with an array value
containing a list of domain names for third-party services that might be containing a list of domain names for third-party services that might be
invoked while using the designated resource but do not share the same data invoked while using the designated resource but do not share the same data
controller as the designated resource. controller as the designated resource.
third-party = %x22 "third-party" %x22 third-party = %x22 "third-party" %x22
third-party-v = array-of-strings third-party-v = array-of-strings
An OPTIONAL member named audit MAY be provided with an array value An OPTIONAL member named audit MAY be provided with an array value
containing a list of URI references to external audits of the designated containing a list of URI references to external audits of the designated
resource's tracking policy and tracking behavior in compliance with this resource's privacy policy and tracking behavior in compliance with this
protocol. Preferably, the audit references are to resources that describe protocol. Preferably, the audit references are to resources that describe
the auditor and the results of that audit; however, if such a resource is the auditor and the results of that audit; however, if such a resource is
not available, a reference to the auditor is sufficient. not available, a reference to the auditor is sufficient.
audit = %x22 "audit" %x22 audit = %x22 "audit" %x22
audit-v = array-of-strings audit-v = array-of-strings
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 the designated resource. The content of such a policy relevant privacy policy for the designated resource. The content of such a
document is beyond the scope of this protocol and only supplemental to policy document is beyond the scope of this protocol and only supplemental
what is described by this machine-readable tracking status representation. to what is described in the machine-readable tracking status
representation. If no policy member is provided, this information might be
obtained via the links provided in controller.
policy = %x22 "policy" %x22 policy = %x22 "policy" %x22
policy-v = string ; URI-reference policy-v = string ; URI-reference
If the tracking status value is 1 and the designated resource is being An OPTIONAL member named edit MAY be provided with a string value
operated by an outsourced service provider on behalf of a first party, the
origin server MUST identify the responsible first party via the domain of
the policy URI, if present, or by the domain owner of the origin server.
If no policy URI is provided and the origin server domain is owned by the
service provider, then the service provider is the first party.
An OPTIONAL member named control MAY be provided with a string value
containing a URI-reference to a resource for giving the user control over containing a URI-reference to a resource for giving the user control over
personal data collected by the designated resource (and possibly other personal data collected by the designated resource (and possibly other
resources); a control member SHOULD be provided if the tracking status resources); an edit member SHOULD be provided if the tracking status value
value indicates prior consent (C). Such a control resource might include indicates prior consent (C). If no edit member is provided, this
the ability to review past data collected, delete some or all of the data, information might be obtained via the links provided in controller or
provide additional data (if desired), or opt-in, opt-out, or otherwise policy.
modify an out-of-band consent status regarding data collection. The design
of such a resource, the extent to which it can provide access to that
data, and how one might implement an out-of-band consent mechanism is
beyond the scope of this protocol.
control = %x22 "control" %x22 An edit resource might include the ability to review past data collected,
control-v = string ; URI-reference delete some or all of the data, provide additional data (if desired), or
opt-in, opt-out, or otherwise modify an out-of-band consent status
regarding data collection. The design of such a resource, the extent to
which it can provide access to that data, and how one might implement an
out-of-band consent mechanism is beyond the scope of this protocol.
edit = %x22 "edit" %x22
edit-v = string ; URI-reference
Additional extension members MAY be provided in the status-object to Additional extension members MAY be provided in the status-object to
support future enhancements to this protocol. A user agent SHOULD ignore support future enhancements to this protocol. A user agent SHOULD ignore
extension members that it does not recognize. extension members that it does not recognize.
extension = object extension = object
array-of-strings = begin-array array-of-strings = begin-array
[ string *( vs string ) ] [ string *( vs string ) ]
skipping to change at line 918 skipping to change at line 1053
string = <string, as defined in [[!RFC4627]]> string = <string, as defined in [[!RFC4627]]>
true = <true, as defined in [[!RFC4627]]> true = <true, as defined in [[!RFC4627]]>
false = <false, as defined in [[!RFC4627]]> false = <false, as defined in [[!RFC4627]]>
null = <null, as defined in [[!RFC4627]]> null = <null, as defined in [[!RFC4627]]>
Note that the tracking status resource space applies equally to both Note that the tracking status resource space applies equally to both
first-party and third-party services. An example of a third-party tracking first-party and third-party services. An example of a third-party tracking
status is status is
Example 9 Example 8
{ {
"tracking": "3", "tracking": "3",
"policy": "/privacy.html", "policy": "/privacy.html",
"control": "/your/data", "edit": "/your/data",
} }
5.5.4 Status Checks are Not Tracked Issue 164: To what extent should the same-party attribute of tracking
status resource be required?
[OPEN] 3 Alternatives - text is needed:
(A) Current draft: Resource is optional
(B) Alternative proposal 1: If multiple domains on a page belong to the
same party, then this fact SHOULD be declared using the same-party
attribute
(C) Alternative proposal 2: State that user agents MAY assume that
additional elements that are hosted under a different URL and occur on a
page and declare "intended for 1st party use" are malicious unless this
URL is listed in the "same-party" attribute
5.4.4 Status Checks are Not Tracked
When sending a request for the tracking status, a user agent SHOULD When sending a request for the tracking status, a user agent SHOULD
include any cookie data [COOKIES] (set prior to the request) that would be include any cookie data [COOKIES] (set prior to the request) that would be
sent in a normal request to that origin server, since that data might be sent in a normal request to that origin server, since that data might be
needed by the server to determine the current tracking status. For needed by the server to determine the current tracking status. For
example, the cookie data might indicate a prior out-of-band decision by example, the cookie data might indicate a prior out-of-band decision by
the user to opt-out or consent to tracking by that origin server. the user to opt-out or consent to tracking by that origin server.
All requests on the tracking status resource space, including the All requests on the tracking status resource space, including the
site-wide tracking status resource, MUST NOT be tracked, irrespective of site-wide tracking status resource, MUST NOT be tracked, irrespective of
the presence, value, or absence of a DNT header field, cookies, or any the presence, value, or absence of a DNT header field, cookies, or any
other information in the request. In addition, all responses to those other information in the request. In addition, all responses to those
requests, including the responses to redirected tracking status requests, requests, including the responses to redirected tracking status requests,
MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have
content that initiates tracking beyond what was already present in the content that initiates tracking beyond what was already present in the
request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie
or Set-Cookie2 header field received in such a response. or Set-Cookie2 header field received in such a response.
5.5.5 Caching 5.4.5 Caching
If the tracking status is applicable to all users, regardless of the If the tracking status is applicable to all users, regardless of the
received DNT-field-value or other data received via the request, then the received DNT-field-value or other data received via the request, then the
response SHOULD be marked as cacheable and assigned a time-to-live 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 tracking status representation has been updated to reflect the new
might persist in caches until the expiration is triggered. A service's behavior, since old copies might persist in caches until the expiration is
tracking behavior can be reduced at any time, with or without a triggered. A service's tracking behavior can be reduced at any time, with
corresponding change to the tracking status resource. or without a corresponding change to the tracking status resource.
If the tracking status is only applicable to all users that have the same If the tracking status is only applicable to all users that have the same
DNT-field-value, then the response MUST either be marked with a Vary DNT-field-value, then the response MUST either be marked with a Vary
header field that includes "DNT" in its field-value or marked as not header field that includes "DNT" in its field-value or marked as not
reusable by a shared cache without revalidation with a Cache-Control reusable by a shared cache without revalidation with a Cache-Control
header field containing one of the following directives: "private", header field containing one of the following directives: "private",
"no-cache", "no-store", or "max-age=0". "no-cache", "no-store", or "max-age=0".
If the tracking status is only applicable to the specific user that If the tracking status is only applicable to the specific user that
requested it, then the response MUST include a Cache-Control header field requested it, then the response MUST include a Cache-Control header field
skipping to change at line 983 skipping to change at line 1131
will check the tracking status of a service only once per session (at will check the tracking status of a service only once per session (at
most). A public Internet site that intends to change its tracking status most). A public Internet site that intends to change its tracking status
to increase tracking behavior MUST update the tracking status resource in to increase tracking behavior MUST update the tracking status resource in
accordance with that planned behavior at least twenty-four hours prior to accordance with that planned behavior at least twenty-four hours prior to
activating that new behavior on the service. activating that new behavior on the service.
A user agent that adjusts behavior based on active verification of A user agent that adjusts behavior based on active verification of
tracking status, relying on cached tracking status responses to do so, tracking status, relying on cached tracking status responses to do so,
SHOULD check responses to its state-changing requests (e.g., POST, PUT, SHOULD check responses to its state-changing requests (e.g., POST, PUT,
DELETE, etc.) for a Tk header field with the U tracking status value, as DELETE, etc.) for a Tk header field with the U tracking status value, as
described in section 5.4.3 Indicating an Interactive Status Change. described in section 5.3.3 Indicating an Interactive Status Change.
5.6 Status Code for Tracking Required 5.5 Status Code for Tracking Required
If an origin server receives a request with DNT:1, does not have If an origin server receives a request with DNT:1, does not have
out-of-band consent for tracking this user, and wishes to deny access to out-of-band consent for tracking this user, and wishes to deny access to
the requested resource until the user provides some form of user-granted the requested resource until the user provides some form of user-granted
exception or consent for tracking, then the origin server SHOULD send an exception or consent for tracking, then the origin server SHOULD send an
HTTP error response with a status code of 409 (Conflict) and a message HTTP error response with a status code of 409 (Conflict) and a message
body that describes why the request has been refused and how one might body that describes why the request has been refused and how one might
supply the required consent or exception to avoid this conflict [HTTP11]. supply the required consent or exception to avoid this conflict [HTTP11].
The 409 response SHOULD include a user authentication mechanism in the The 409 response SHOULD include a user authentication mechanism in the
header fields and/or message body if user login is one of the ways through header fields and/or message body if user login is one of the ways through
which access is granted. which access is granted.
5.7 Using the Tracking Status 5.6 Using the Tracking Status
Note Note
This section is for collecting use cases that describe questions a user This section is for collecting use cases that describe questions a user
agent might have about tracking status and how the protocol can be used to agent might have about tracking status and how the protocol can be used to
answer such questions. More cases are needed. answer such questions. More cases are needed.
5.7.1 Discovering Deployment 5.6.1 Discovering Deployment
The presence of a site-wide tracking status representation is a claim that Deployment of this protocol for a given service can be discovered by
the service conforms to this protocol for a given user agent. Hence,
deployment of this protocol for a given service can be discovered by
making a retrieval request on the site-wide tracking resource making a retrieval request on the site-wide tracking resource
/.well-known/dnt relative to the service URI. /.well-known/dnt/ relative to the service URI.
If the response is an error, then the service does not implement this If the response is an error, then the service does not implement this
standard. If the response is a redirect, then follow the redirect to standard. If the response is a redirect, then follow the redirect to
obtain the tracking status (up to some reasonable maximum of redirects to obtain the tracking status (up to some reasonable maximum of redirects to
avoid misconfigured infinite request loops). If the response is avoid misconfigured infinite request loops). If the response is
successful, obtain the tracking status representation from the message successful, obtain the tracking status representation from the message
payload, if possible, or consider it an error. payload, if possible, or consider it an error.
5.7.2 Preflight Checks 5.6.2 Preflight Checks
A key advantage of providing the tracking status at a resource separate A key advantage of providing the tracking status at a resource separate
from the site's normal services is that the status can be accessed and from the site's normal services is that the status can be accessed and
reviewed prior to making use of those services and prior to making reviewed prior to making use of those services and prior to making
requests on third-party resources referenced by those services. requests on third-party resources referenced by those services.
A user agent MAY check the tracking status for a designated resource by A user agent MAY check the tracking status for a designated resource by
first making a retrieval request for the site-wide tracking status first making a retrieval request for the site-wide tracking status
representation, as described above, and then parsing the representation as representation, as described above, and then parsing the representation as
JSON to extract the Javascript status-object. If retrieval is unsuccessful JSON to extract the status-object. If retrieval is unsuccessful or parsing
or parsing results in a syntax error, the user agent SHOULD consider the results in a syntax error, the user agent SHOULD consider the site to be
site to be non-conformant with this protocol. non-conformant with this protocol.
The status-object is supposed to have a member named tracking containing The status-object is supposed to have a member named tracking containing
the tracking status value. The meaning of each tracking status value is the tracking status value. The meaning of each tracking status value is
defined in section 5.2 Tracking Status Value. defined in section 5.2 Tracking Status Value.
If the tracking status value is N, then the origin server claims that no If the tracking status value is N, then the origin server claims that no
tracking is performed for the designated resource for at least the next 24 tracking is performed for the designated resource for at least the next 24
hours or until the Cache-Control information indicates that this response hours or until the Cache-Control information indicates that this response
expires. expires.
skipping to change at line 1057 skipping to change at line 1203
least the next 24 hours or until the Cache-Control information indicates least the next 24 hours or until the Cache-Control information indicates
that this response expires. that this response expires.
6. User-Granted Exceptions 6. User-Granted Exceptions
6.1 Overview 6.1 Overview
This section is non-normative. This section is non-normative.
User-granted exceptions to Do Not Track, including site-specific User-granted exceptions to Do Not Track, including site-specific
exceptions, are managed by the user agent. A resource should rely on the exceptions, are agreed between the site and the user, and stored by the
DNT header it receives to determine the user's preference for tracking user agent. A resource should rely on the DNT header it receives to
with respect to that particular request. An API is provided so that sites determine the user's preference for tracking with respect to that
may request and check the status of exceptions for tracking. particular request. An API is provided so that sites may request and check
the status of exceptions for tracking.
We anticipate that many user-agents might provide a prompt to users when
this API is used, or to store exceptions. Questions of user interface
specifics - for granting, configuring, storing, syncing and revoking
exceptions - are explicitly left open to implementers.
Issue 144: What constraints on user agents should be imposed for Note
user/granted exceptions
[OPEN] but mostly addressed in the proposal here. We envisage that the exceptions may also be usable as a consent mechanism.
6.2 Motivating Principles and Use Cases 6.2 Motivating Principles and Use Cases
This section is non-normative. This section is non-normative.
The following principles guide the design of user-agent-managed The following principles guide the design of user-agent-managed
exceptions. 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 purposes opt back in to tracking for behavioral advertising or similar purposes
skipping to change at line 1094 skipping to change at line 1235
managing preferences in a different way on every content provider or managing preferences in a different way on every content 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 parties. first-party publisher and its third parties.
When asking for a site-specific exception, the top-level domain making the When asking for a site-specific exception, the top-level origin making the
request may be making some implicit or explicit claims as to the actions 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 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 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 are true. (Consider a site that has some trusted advertisers and analytics
providers, and some mashed-up content from less-trusted sites). For this providers, and some mashed-up content from less-trusted sites). For this
reason, there is support both for explicitly named sites, as well as 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 support for granting an exception to all third-parties on a given site
(site-wide exception, using the conceptual wild-card "*"). (site-wide exception, using the conceptual wild-card "*").
There are some cases in which a user may desire a site to be allowed to 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 track them on any top-level origin. An API is provided so that the site
and the user may establish such a web-wide exception. and the user may establish such a web-wide exception.
6.3 Exception model 6.3 Exception model
6.3.1 Introduction 6.3.1 User Interaction
The call to store an exception MUST reflect the user's intention to grant
an exception, at the time of the call. This intention MUST be determined
by the site prior to each call to store an exception, at the time of the
call. (This allows the user to change their mind, and delete a stored
exception, which might then trigger the site to explain, and ask for, the
exception again). It is the responsibility solely of the site making the
call to determine that a call to record an exception reflects the user's
informed consent at the time of the call.
Issue 194: How should we ensure consent of users for DNT inputs?
[OPEN] We agree that exceptions should reflect user consent and that this
needs to be ensured before a site is permitted to register an exception.
There is concern that the language above is insufficient to guarantee this
desire. Potential language that is acceptable by the whole group is still
under discussion.
Sites MAY ask for an exception, and have it stored, even when the user's
general preference is not enabled. (This permits recording a permission to
allow tracking in jurisdictions where such permission cannot be assumed -
see section 6.8 Exceptions without interactive JavaScript.)
The user-agent MAY provide interfaces to the user:
* To indicate that a call to store an exception has just been made;
* To allow the user to confirm a user-granted exception prior to
storage;
* To indicate that one or more exceptions exist for the current
top-level origin;
* To indicate that one or more exceptions exist for sites incorporated
into the current page;
* To allow the user to see and possibly revoke stored exceptions;
* Other aspects of the exception mechanism, as desired.
There is no required user interface for the user agent; user agents MAY
choose to provide no user interface regarding user-granted exceptions.
Note
The requirement for the site to determine the user's intention is new;
previously the site was required to inform, but the final determination of
intention was the responsibility of the UA. This version removes that
split of user-determination, and leaves it solely with the site.
6.3.2 Processing Model
This section describes the effect of the APIs in terms of a logical This section describes the effect of the APIs in terms of a logical
processing model; this model describes the behavior, but should not be processing model; this model describes the behavior, but should not be
read as mandating any specific implementation. 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 target. A user might - for instance - want AnalytiCo to be site, and the target. A user might - for instance - want AnalytiCo to be
allowed to track them on Example News, but not on Example Medical. To allowed to track them on Example News, but not on Example Medical. To
simplify language used in this API specification, we define three terms: simplify language used in this API specification, we define three terms:
* Top-Level Domain (TLD) is the domain name of the top-level document * top-level origin is the domain name of the top-level document origin
origin of this DOM: essentially the fully qualified domain name in the of this DOM: essentially the fully qualified domain name in the
address bar. address bar.
* A target site is a domain name which is the target of an HTTP request, * A target site is a domain name which is the target of an HTTP request,
and which may be an origin for embedded resources on the indicated and which may be an origin for embedded resources on the indicated
top-level domain. top-level origin.
* The document origin of a script is the domain of origin of the * The document origin of a script is the domain of origin of the
document that caused that script to be loaded (not necessarily the document that caused that script to be loaded (not necessarily the
same as the origin of the script itself). same as the origin of the script itself).
For instance, if the document at For instance, if the document at
http://web.exnews.com/news/story/2098373.html references the resources http://web.exnews.com/news/story/2098373.html references the resources
http://exnews.analytico.net/1x1.gif and http://exnews.analytico.net/1x1.gif and
http://widgets.exsocial.org/good-job-button.js, the top-level domain is http://widgets.exsocial.org/good-job-button.js, the top-level origin 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
targets. targets.
Issue 112: How are sub-domains handled for site-specific exceptions? Issue 112: How are sub-domains handled for site-specific exceptions?
[PENDING REVIEW] Should a request for a tracking exception apply to all [PENDING REVIEW] In the current proposal a domain parameter allows
subdomains of the first party making the request? Or should a first party exceptions to apply to sub-domains in the same way as cookies.
explicitly list the subdomains that it's asking for? Similarly, should
third-party subdomains be allowed (e.g. *.tracker.com)?
Proposal: Exceptions are requested for fully-qualified domain names.
The domains that enter into the behavior of the APIs include: The domains that enter into the behavior of the APIs include:
* As described above, the document origin active at the time of the * As described above, the document origin active at the time of the
call, and; call, and;
* Domain names passed to the API. * Domain names passed to the API.
Domains that enter into the decision over what DNT header to be sent in a Domains that enter into the decision over what DNT header to be sent in a
given HTTP request include: given HTTP request include:
* The top-level domain of the current context; * The top-level origin of the current context;
* The target of the HTTP request. * The target of the HTTP request.
Note Note
Note that these strict, machine-discoverable, concepts may not match the Note that these strict, machine-discoverable, concepts may not match the
definitions of first and third party; in particular, sites themselves need definitions of first and third party; in particular, sites themselves need
to determine (and signal) when they get 'promoted' to first party by to determine (and signal) when they get 'promoted' to first party by
virtue of user interaction; the UA will not change the DNT header it sends virtue of user interaction; the UA will not change the DNT header it sends
them. them.
The calls cause the following steps to occur: The calls cause the following steps to occur (subject to user confirmation
of the exception, if the user-agent asks for it):
* First, the UA somehow confirms with the user that they agree to the * The UA adds to its local database one or more site-pair duplets
grant of exception, if not already granted; [document-origin, target]; one or other of these may be a wild-card
* If they agree, then the UA adds to its local database one or more ("*");
site-pair duplets [document-origin, target]; one or other of these may * While the user is browsing a given site (top-level origin), and a DNT
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 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 origin, target domain] matches any duplet in the database, then a
DNT:0 header is sent, otherwise DNT:1 is sent. DNT:0 header is sent, otherwise DNT:1 is sent.
Note
Note that a site may record no that it has previously asked for, and been A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A
denied, an exception, if it wishes to avoid repeatedly asking the user for pair of values A and X match if and only if one of the following is true:
an exception.
6.3.2 Exception use by browsers * either A or X is "*";
* A and X are the same string;
* A has the form '*.domain' and X is 'domain' or is of the form
'string.domain', where 'string' is any sequence of characters.
If a user agrees to allow tracking by a target on the top-level domain, In addition, responses to the JavaScript API indicated should be
this should result in two user-agent behaviors: consistent with this user preference (see below).
Note
The prior version of this required that the UA "somehow confirms with the
user that they agree to the grant of exception, if not already granted"
1. If requests to the target for resources that are part of the DOM for
pages on top-level domain include a DNT header, that header MUST be
DNT:0.
2. Responses to the JavaScript API indicated should be consistent with
this user preference (see below).
Issue 159: How do we allow sites that mash-in ad-supported content to Issue 159: How do we allow sites that mash-in ad-supported content to
maintain their own trusted third parties? maintain their own trusted third parties?
This model does not support mashed-up content which is in turn supported [POSTPONED] This model does not support mashed-up content which is in turn
by ads; it's not clear how to distinguish between embedded content which supported by ads; it's not clear how to distinguish between embedded
is embedding ads (and hence the top-level domain stays the same) and content which is embedding ads (and hence the top-level origin stays the
embedded content that should start a new context. same) and embedded content that should start a new context.
Proposal: For this version of the specification, we don't address this Proposal: For this version of the specification, we don't address this
corner case. corner case.
User-agents MUST handle each API request as a 'unit', granting and User-agents MUST handle each API request as a 'unit', granting and
maintaining it in its entirety, or not at all. That means that a maintaining it in its entirety, or not at all. That means that a
user-agent MUST NOT indicate to a site that a request for targets {a, b, user-agent MUST NOT indicate to a site that a request for targets {a, b,
c} has been granted, and later remove only one or two of {a, b, c} from c} exists in the database, and later remove only one or two of {a, b, c}
its logical database of remembered grants. This assures sites that the set from its logical database of remembered grants. This assures sites that
of sites they need for operational integrity is treated as a unit. Each the set of sites they need for operational integrity is treated as a unit.
separate call to an API is a separate unit. Each separate call to an API is a separate unit.
When a user-agent receives an API request for an exception that already
exists (i.e. the grant is recorded in its database), it SHOULD bypass
asking the user to confirm, and simply re-confirm the grant to the caller.
Note Note
It is left up to individual user-agent implementations how to determine It is left up to individual user-agent implementations how to determine
and how and whether to store users' tracking preferences. and how and whether to store users' tracking preferences.
When an explicit list of domains is provided through the API, their names When an explicit list of domains is provided through the API, their names
might mean little to the user. The user might, for example, be told that might mean little to the user. The user might, for example, be told that
such-and-such top-level domain is asking for an exception for a specific there is a stored exception for a specific set of sites on such-and-such
set of sites, rather than listing them by name; or the user-agent may top-level origin, rather than listing them by name; or the user-agent may
decide to ask the user for a site-wide exception, effectively ignoring the decide to store, and show to the user, a site-wide exception, effectively
list of domain names, if supplied. ignoring the list of domain names, if supplied.
Conversely, if a wild-card is used, the user may be told that the Conversely, if a wild-card is used, the user may be told that there is a
top-level domain is asking for an exception for all third-parties that stored exception for all third-parties that are, or will be, embedded on
are, or will be, embedded in it. the indicated the top-level origin.
Issue 111: Different DNT values to signify existence of user-granted Issue 151: User Agent Requirement: Be able to handle an exception request
exception
[POSTPONED] Should the user agent send a different DNT value to a first [OPEN] There is software that in just a few lines of code just spawn DNT;1
party site if there exist user-granted exceptions for that first party? or DNT;0 headers regardless of user's will. A requirement on the user
(e.g. DNT:2 implies "I have Do Not Track enabled but grant permissions to agent that they can handle the full exception mechanism will allow to
some third parties while browsing this domain") discard compliance statements by those agents. It will also allow also the
Proposal: A previous proposal was that it can add itself to the list (i.e. site to test for conformance by requiring an exception. In case the UA
an exception for [site, site]) and then it will get DNT:0, but DNT:0 to a does not react on an exception request, the server could ignore DNT
first party means something different (that it can pass data to third signals from that UA. It would allow thus testing from the horizon of the
parties, and tracking is permitted). It would be better to have an site without wild guessing;
indication in the DNT header that one or more site-specific exceptions However, there is no practical difference between a UA that hard-wires
exist for the given target (i.e. that there is at least one duplet in the 'no' to all exception requests, and a UA that does not implement the
database with target as its first host name), for example "DNT:1E" where E calls.
means you are a first party with one or more active exceptions.
Issue 167: Multiple site exceptions
[PENDING REVIEW] The current assumption is that the best practice is to
use frames.
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 6.4.1 API to Request a Site-specific Exception
[NoInterfaceObject] partial interface Navigator {
interface NavigatorDoNotTrack { void storeSiteSpecificTrackingException (StoreSiteSpecificExceptionProper
void requestSiteSpecificTrackingException ( tyBag properties);
TrackingResponseCallback callback,
optional sequence<DOMString> arrayOfDomainStrings,
optional optional siteName,
optional optional explanationString,
optional optional detailURI
);
}; };
requestSiteSpecificTrackingException storeSiteSpecificTrackingException
Called by a page to request or confirm a user-granted tracking Called by a page to store a site-specific tracking exception.
exception.
Parameter Type Nullable Optional Descripti Parameter Type Nullable Optional Descripti
on on
callback TrackingResponseCallback * * properties StoreSiteSpecificExceptionPropertyBag * *
arrayOfDomainStrings sequence<DOMString> * *
siteName optional * *
explanationString optional * *
detailURI optional * *
Return type: void Return type: void
[Callback, NoInterfaceObject] dictionary StoreExceptionPropertyBag {
interface TrackingResponseCallback { DOMString? domain;
void handleEvent (integer granted); DOMString? siteName;
DOMString? explanationString;
DOMString? detailURI;
}; };
handleEvent detailURI of type DOMString, nullable
The callback is called by the user agent to indicate the user's A location at which further information about this request can be
response. found.
Parameter Type Nullable Optional Description domain of type DOMString, nullable
granted integer * * Cookie-like domain string to which the exception applies.
Return type: void explanationString of type DOMString, nullable
A short explanation of the request.
The requestSiteSpecificTrackingException method takes one mandatory siteName of type DOMString, nullable
argument: A user-readable string for the name of the top-level origin.
* callback, a method that will be called when the request is complete. dictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag
{
sequence<DOMString> arrayOfDomainStrings;
};
It also takes four optional arguments: arrayOfDomainStrings of type sequence<DOMString>
A JavaScript array of strings.
* arrayOfDomainStrings, a JavaScript array of strings, The storeSiteSpecificTrackingException method takes a dictionary argument
* siteName, a user-readable string for the name of the top-level domain, of type StoreSiteSpecificExceptionPropertyBag that allows optional
* explanationString, a short explanation of the request, and information to be provided.
* detailURI, a location at which further information about this request
can be found.
If the request does not include the arrayOfDomainStrings, then this If the request does not include the arrayOfDomainStrings, then this
request is for a site-wide exception. Otherwise each string in request is for a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target. When called, arrayOfDomainStrings specifies a target. When called,
requestSiteSpecificTrackingException MUST return immediately, then storeSiteSpecificTrackingException MUST return immediately.
asynchronously determine whether the user grants the requested
exception(s).
If the list arrayOfDomainStrings is supplied, the user-agent MAY choose to If the list arrayOfDomainStrings is supplied, the user-agent MAY choose to
ask the user to grant a site-wide exception. If it does so, and the user store a site-wide exception. If it does so it MUST indicate this in the
agrees, it MUST indicate this in the response callback. return value.
The execution of this API and the use of the resulting permission (if
granted) use the 'implicit' parameter, when the API is called, the
document origin. This forms the first part of the duplet in the logical
model, and hence in operation will be compared with the top-level domain.
The granted parameter passed to the callback is the user's response; The
response
* 0 indicates that user does not grant the exception on top-level domain If domain is not specified or is null or empty then the execution of this
for the indicated targets. API and the use of the resulting permission (if granted) use the
* 1 indicates that the request was for specific targets and the the user 'implicit' parameter, when the API is called, the document origin. This
grants an exception on top-level domain for those specific targets. forms the first part of the duplet in the logical model, and hence in
* 2 indicates the user grants a site-wide exception on top-level domain operation will be compared with the top-level origin.
for all targets; the request may have been for specific targets or for
a site-wide exception.
If permission is granted for an explicit list, then the set of duplets If permission is stored for an explicit list, then the set of duplets (one
(one per target): per target):
[document-origin, target] [document-origin, target]
is added to the database of remembered grants. is added to the database of remembered grants.
If permission is granted for a site-wide exception, then the duplets: If permission is stored for a site-wide exception, then the duplet:
[document-origin, * ] [document-origin, * ]
is added to the database of remembered grants. is added to the database of remembered grants.
If domain is supplied and not empty then it is treated in the same way as
the domain parameter to cookies and allows setting for subdomains. The
domain argument can be set to fully-qualified right-hand segment of the
document host name, up to one level below TLD.
Note
For example, www.foo.bar.example.com may set the domain parameter as as
"bar.example.com" or "example.com", but not to
"something.else.example.com" or "com".
If the document-origin would not be permitted to set a cookie on the
domain following the cookie domain rules [COOKIES] (e.g. domain is not a
right-hand match or is a TLD) then the duplet MUST not be entered into the
database and a SYNTAX_ERR exception should be thrown.
If permission is stored for an explicit list, then the set of duplets (one
per target):
[*.domain, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[*.domain, * ]
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 may choose to edit the list of stored
exceptions and revoke some or all of them.
A user agent MAY use an interactive method to ask the user about their Note
preferences, so sites SHOULD NOT assume that the callback function will be
called immediately. The prior version of this call was asynchronous with a call-back; the
change to require the site to determine the user's wishes, rather than the
UA, enabled this to become synchronous. This is simpler; the user-agent
may still ask for the user's approval. Sites wishing to know whether an
exception stands, or the DNT header that they would receive, should call
the appropriate enquiry API.
6.4.2 API to Cancel a Site-specific Exception 6.4.2 API to Cancel a Site-specific Exception
[NoInterfaceObject] partial interface Navigator {
interface NavigatorDoNotTrack { void removeSiteSpecificTrackingException (RemoveExceptionPropertyBag prop
boolean removeSiteSpecificTrackingException (); erties);
}; };
removeSiteSpecificTrackingException removeSiteSpecificTrackingException
Ensures that the database of remembered grants no longer contains
any duplets for which the first part is the current document If domain is not supplied or is null or empty then this ensures
origin; i.e., no duplets [document-origin, target] for any target. that the database of remembered grants no longer contains any
duplets for which the first part is the current document origin;
i.e., no duplets [document-origin, target] for any target.
If domain is supplied and is not empty then this ensures that the
database of remembered grants no longer contains any duplets for
which the first part is the domain wildcard; i.e., no duplets
[*.domain, target] for any target.
There is no callback. After the call has been made, it is assured There is no callback. After the call has been made, it is assured
that there are no site-specific or site-wide exceptions for the that there are no site-specific or site-wide exceptions for the
given top-level-domain. given top-level origin.
No parameters.
Parameter Type Nullable Optional Description
properties RemoveExceptionPropertyBag * *
Return type: void
dictionary RemoveExceptionPropertyBag {
DOMString? domain;
};
domain of type DOMString, nullable
Cookie-like domain string to which the exception applies.
When this method returns the database of grants no longer contains the
indicated grant(s); if some kind of processing error occurred then an
appropriate exception will be thrown.
Note
If there are no matching duplets in the database of remembered grants when
the method is called then this operation does nothing (and does not throw
an exception).
6.4.3 API to Confirm a Site-specific Exception
partial interface Navigator {
boolean confirmSiteSpecificTrackingException (ConfirmSiteSpecificExceptio
nPropertyBag properties);
};
confirmSiteSpecificTrackingException
Called by a page to confirm a site-specific tracking exception.
Parameter Type Nullable Optional Descripti
on
properties ConfirmSiteSpecificExceptionPropertyBag * *
Return type: boolean Return type: boolean
This returns a boolean indicating, when true, that the call has succeeded, dictionary ConfirmExceptionPropertyBag {
and that the database of grants no longer contains, or very soon will no DOMString? domain;
longer contain, the indicated grant(s); when false, some kind of };
processing error occurred.
domain of type DOMString, nullable
Cookie-like domain string to which the exception applies.
dictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionProperty
Bag {
sequence<DOMString> arrayOfDomainStrings;
};
arrayOfDomainStrings of type sequence<DOMString>
A JavaScript array of strings.
If the call does not include the arrayOfDomainStrings, then this call is
to confirm a site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a target.
If the list arrayOfDomainStrings is supplied, and the user-agent stores
only site-wide exceptions, then the user-agent MUST match by confirming a
site-wide exception.
If the domain argument is not supplied or is null or empty then the
execution of this API uses the 'implicit' parameter, when the API is
called, the document origin. This forms the first part of the duplet in
the logical model.
If the user-agent stores explicit lists, and the call includes one, the
database is checked for the existence of all the duplets (one per target):
[document-origin, target]
If the user-agent stores only site-wide exceptions or the call did not
include an explicit list, the database is checked for the single duplet:
[document-origin, * ]
If the user-agent stores explicit lists, and the call includes one, and
the domain argument is provided and is not empty then the database is
checked for the existence of all the duplets (one per target):
[*.domain, target]
If the user-agent stores only site-wide exceptions or the call did not
include an explicit list, and the domain argument is provided and is not
empty then the database is checked for the single duplet:
[*.domain, * ]
The returned boolean has the following possible values:
* true all the duplets exist in the database;
* false one or more of the duplets does not exist in the database.
6.5 JavaScript API for Web-wide Exceptions 6.5 JavaScript API for Web-wide Exceptions
6.5.1 API to Request a Web-wide Exception 6.5.1 API to Request a Web-wide Exception
[NoInterfaceObject] partial interface Navigator {
interface NavigatorDoNotTrack { void storeWebWideTrackingException (StoreExceptionPropertyBag properties)
void requestWebWideTrackingException ( ;
TrackingResponseCallback callback,
optional siteName,
optional optional explanationString,
optional optional detailURI
);
}; };
requestWebWideTrackingException storeWebWideTrackingException
If permission is granted, then the single duplet [ * , The single duplet [ * , document-origin] or [ * , *.domain] (based
document-origin] is added to the database of remembered grants. on if domain is provided and is not null and not empty) is added
The parameters are as described above in the request for to the database of remembered grants. The members of the
site-specific exceptions. StoreExceptionPropertyBag dictionary are as described above in the
request for site-specific exceptions.
Parameter Type Nullable Optional Descripti Parameter Type Nullable Optional Description
on properties StoreExceptionPropertyBag * *
callback TrackingResponseCallback * *
siteName * *
explanationString optional * *
detailURI optional * *
Return type: void Return type: void
Users may wish to configure exceptions for a certain trusted tracker This API requests the addition of a web-wide grant for a specific site, to
across all sites. This API requests the addition of a web-wide grant for a the database.
specific site, to the database.
6.5.2 API to cancel a web-wide exception Note
[NoInterfaceObject] As above, this call used to be asynchronous, and the change to the UI
interface NavigatorDoNotTrack { enabled it to be synchronous.
boolean removeWebWideTrackingException ();
6.5.2 API to Cancel a Web-wide Exception
partial interface Navigator {
void removeWebWideTrackingException (RemoveExceptionPropertyBag propertie
s);
}; };
removeWebWideTrackingException removeWebWideTrackingException
Ensures that the database of remembered grants no longer contains Ensures that the database of remembered grants no longer contains
the duplet [ * , document-origin]. There is no callback. After the the duplet [ * , document-origin] or [ * , *.domain] (based on if
call has been made, the indicated pair is assured not to be in the domain is provided and is not null and not empty). There is no
database. The same matching as is used for determining which callback. After the call has been made, the indicated pair is
header to send is used to detect which entry (if any) to remove assured not to be in the database. The same matching as is used
from the database. for determining which header to send is used to detect which entry
No parameters. (if any) to remove from the database.
Return type: boolean
This returns a boolean indicating, when true, that the call has succeeded,
and that the database of grants no longer contains, or very soon will no
longer contain, the indicated grant; when false, some kind of processing
error occurred.
6.6 Querying a host's exception status Parameter Type Nullable Optional Description
properties RemoveExceptionPropertyBag * *
Issue 160: Do we need an exception-query API? Return type: void
[PENDING REVIEW] It might be useful, and 'complete the model', if we had a 6.5.3 API to Confirm a Web-wide Exception
JS API that told a host what its current exception status is in a given
context. See proposal here.
Proposal: Specifically, an API QueryExceptionStatus() which examines the
document origin of the script, the current top-level domain and returns an
empty string if no DNT header would be sent to that document origin, or
the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
[NoInterfaceObject] partial interface Navigator {
interface NavigatorDoNotTrack { boolean confirmWebWideTrackingException (ConfirmExceptionPropertyBag prop
DOMString requestDNTStatus (); erties);
}; };
requestDNTStatus confirmWebWideTrackingException
Returns the same string value that would be sent in a
DNT-field-value (section 4.2 DNT Header Field for HTTP Requests)
to a target that is the document-origin of the request, in the
context of the current top-level domain. If no DNT header would be
sent (e.g. because a tracking preference is not enabled) the
return value is null.
No parameters.
Return type: DOMString
6.7 Transfer of an exception to another third party Parameter Type Nullable Optional Descriptio
n
properties ConfirmExceptionPropertyBag * *
Return type: boolean
This API confirms the existence of a web-wide grant for a specific site,
in the database.
The returned boolean indicates whether the duplet [ * , document-origin]
or [ * , *.domain] (based on if domain is provided and is not null and not
empty) exists in the database.
* true indicates that the web-wide exception exists;
* false indicates that the web-wide exception does not exist.
6.6 Transfer of an exception to another third party
A site may request an exception for one or more third party services used A site may request an exception for one or more third party services used
in conjunction with its own offer. Those third party services may wish to in conjunction with its own offer. Those third party services may wish to
use other third parties to complete the request in a chain of use other third parties to complete the request in a chain of
interactions. The first party will not necessarily know in advance whether interactions. The first party will not necessarily know in advance whether
a known third party will use some other third parties. a known third party will use some other third parties.
If a user-agent sends a tracking exception to a given combination of If a user-agent sends a tracking exception to a given combination of
origin server and a named third party, the user agent will send DNT:0 to origin server and a named third party, the user agent will send DNT:0 to
that named third party. By receiving the DNT:0 header, the named third that named third party. By receiving the DNT:0 header, the named third
skipping to change at line 1501 skipping to change at line 1778
the use of the appropriate tracking status value and qualifier, which is the use of the appropriate tracking status value and qualifier, which is
"XX" (such as "tl"), from its sub-sub-services. "XX" (such as "tl"), from its sub-sub-services.
The permission acquired by the DNT mechanism does not override retention The permission acquired by the DNT mechanism does not override retention
limitations found in the legal system the content provider or the named limitations found in the legal system the content provider or the named
third party are operating in. third party are operating in.
Issue 168: What is the correct way for sub-services to signal that they Issue 168: What is the correct way for sub-services to signal that they
are taking advantage of a transferred exception? are taking advantage of a transferred exception?
When the status values and qualifiers are fixed, the penultimate paragraph [OPEN] When the status values and qualifiers are fixed, the penultimate
will probably need adjusting to match. The use of "tl" (which meant paragraph will probably need adjusting to match. The use of "tl" (which
"tracking but only in accordance with local laws" when this text was meant "tracking but only in accordance with local laws" when this text was
written) doesn't seem right, as the text talks, essentially, of the written) doesn't seem right, as the text talks, essentially, of the
sub-sub-service acting on behalf of the site that received the DNT:0 sub-sub-service acting on behalf of the site that received the DNT:0
header, which might suggest something more like "CS" (service provision to header, which might suggest something more like "CS" (service provision to
a third-party that received consent). a third-party that received consent).
6.8 User interface guidelines 6.7 User interface guidelines
This section is non-normative. This section is non-normative.
User agents are free to implement exception management user interfaces as As described above, it is the responsibility solely of the site making the
they see fit. Some agents might provide a prompt to the user at the time call to determine that an exception grant reflects the user's informed
of the request. Some agents might allow users to configure this preference consent at the time of the call.
in advance. In either case, the user agent responds with the user's
preference.
In general, it is expected that the site will explain, in its online
content, the need for an exception, and the consequences of granting or
denying an exception, to the user, and guide. The call to the API and the
resulting request for user confirmation should not be a 'surprise' to the
user, or require much explanation on the part of the user-agent.
A user agent that chooses to implement a prompt to present tracking
exception requests to the user might provide an interface like the
following:
Example 10
Example News (web.exnews.com) would like to confirm
that you permit tracking by a specific set of sites (click
here for their names).
Example News says:
These sites allow Example News to see how we're
doing, and provide useful features of the Example News
experience. [More info]
[Allow Tracking] [Deny Tracking Request] It is expected that the site will explain, in its online content, the need
for an exception, and the consequences of granting or denying an
exception, to the user.
In this example, the domains listed are those specified in User agents are free to implement exception management user interfaces as
arrayOfDomainStrings, the phrase Example News is from siteName, and the they see fit. Some agents might provide a notification to the user at the
explanationString is displayed for the user with a More info link pointing time of the request, or even not complete the storing of the exception
to detailURI. until the user approves. Some agents might provide a user-interface to see
and edit the database of recorded exception grants. The API parameters
siteName, explanationString, and detailURI are provided so that the
user-agent may use them in their user interface.
The user agent might then store that decision, and answer future requests A user agent that chooses to highlight when tracking exceptions have been
based on this stored preference. A user agent might provide the user with stored might provide an interface like the following.
an interface to explicitly remove (or add) user-granted exceptions.
Users might not configure their agents to have simple values for DNT, but * an icon in the status bar indicating that an exception has been
use different browsing modes or other contextual information to decide on stored, which, when clicked on, gives the user more information about
a DNT value. What algorithm a user agent employs to determine DNT values the exception and an option to revoke such an exception.
(or the lack thereof) is out of the scope of this specification. * an infobar stating "Example News (news.example.com) has indicated to
Browser that you have consented to granting it exceptions to your
general Do Not Track preference. If you believe this is incorrect,
click Revoke."
* no UI at all.
In some user-agent implementations, decisions to grant exceptions may have In some user-agent implementations, decisions to grant exceptions may have
been made in the past (and since forgotten) or may have been made by other been made in the past (and since forgotten) or may have been made by other
users of the device. Thus, exceptions may not always represent the current users of the device. Thus, exceptions may not always represent the current
preferences of the user. Some user agents might choose to provide ambient preferences of the user. Some user agents might choose to provide ambient
notice that user-opted tracking is ongoing, or easy access to view and notice that user-opted tracking is ongoing, or easy access to view and
control these preferences. Users may desire options to edit exceptions control these preferences. Users may desire options to edit exceptions
either at the time of tracking or in a separate user interface. This might either at the time of tracking or in a separate user interface. This might
allow the user to edit their preferences for a site they do not trust allow the user to edit their preferences for a site they do not trust
without visiting that site. without visiting that site.
Issue 140: Do we need site-specific exceptions, i.e., concrete list of 6.8 Exceptions without interactive JavaScript
permitted third parties for a site?
[PENDING REVIEW] In this section; yes, as some sites may have a mix of This section is non-normative.
trusted/needed third parties, and others that either don't need to track,
or aren't as trusted, or both. But all sites are (a) told what they got Some third party servers that comply with this standard may wish to
granted (list, or *) and (b) are assured that requests will be treated receive user-granted exceptions but when they are invoked as third parties
'atomically'. (using, for example, images, or "tracking pixels") do not have an
interactive JavaScript presence on the page. They cannot request an
exception under these circumstances, both because a script is needed, and
because they are required to explain to the user the need for and
consequences of granting an exception, and get the user's consent. In
general this process of informing, getting consent, and calling the API is
not expected to be in the page where such trackers are invoked.
To obtain an exception, a document (page, frame, etc.) that loads the
Javascript is needed. The user may visit the site that desires an
exception directly, the first party site could load a frame of the site
desiring the exception, or that frame might be part of some other page
containing a number of frames, which allows aggregation of requests for
exceptions.
In all these ways, the site is contributing to informing the user and
getting their consent, and is also able to call the Javascript API when it
is granted.
Note
Depending on the resolution of options for the User-Granted Exceptions
section, this language might need to be updated to correspond.
6.9 Exceptions without a DNT header 6.9 Exceptions without a DNT header
Sites might wish to request exceptions even when a user arrives without a Sites might wish to request exceptions even when a user arrives without a
DNT header. Users might wish to grant affirmative permission to tracking DNT header. Users might wish to grant affirmative permission to tracking
on or by certain sites even without expressing general tracking on or by certain sites even without expressing general tracking
preferences. preferences.
User agents MAY instantiate User agents MAY instantiate navigator.storeSiteSpecificTrackingException
NavigatorDoNotTrack.requestSiteSpecificTrackingException even when even when navigator.doNotTrack is null. Sites SHOULD test for the
navigator.doNotTrack is null. Sites SHOULD test for the existence of existence of storeSiteSpecificTrackingException before calling the method.
requestSiteSpecificTrackingException before calling the method. If an If an exception is granted in this context and the user-agent stores that
exception is granted in this context and the user-agent stores that
preference, a user agent may send a DNT:0 header even if a tracking preference, a user agent may send a DNT:0 header even if a tracking
preference isn't expressed for other requests. Persisted preferences MAY preference isn't expressed for other requests. Persisted preferences MAY
also affect which header is transmitted if a user later chooses to express also affect which header is transmitted if a user later chooses to express
a tracking preference. a tracking preference.
Note Note
Users might not configure their agents to have simple values for DNT, but Users might not configure their agents to have simple values for DNT, but
use different browsing modes or other contextual information to decide on use different browsing modes or other contextual information to decide on
a DNT value. What algorithm a user agent employs to determine DNT values a DNT value. What algorithm a user agent employs to determine DNT values
(or the lack thereof) is out of the scope of this specification. (or the lack thereof) is out of the scope of this specification.
6.10 Fingerprinting 6.10 Exception use by sites
This section is non-normative.
This section is to inform the authors of sites on some considerations in
using the exceptions APIs to best effect; sites of particular interest
here are those that need an exception in order to allow the user to
perform some operation or to have some access.
The 'Store' calls do not have a return value, and return immediately. If
there is a problem with the calling parameters, then a Javascript
exception will be raised. In addition, it may be that the user-agent does
not immediately store the exception, possibly because it is allowing the
user to confirm. Even though the site has acquired the user's informed
consent before calling the 'Store' API, it is possible that the user will
change their mind, and allow the store to proceed but then later ask it be
removed, or even by denying the storage in the first place.
Note
The use of the word 'exception' both to describe the user granting
something, and for a problem in Javascript, is an unfortunate clash here.
Sites can call the 'Confirm' APIs to enquire whether a specific exception
has been granted and stands in the user-agent. This is the call to make to
determine whether the exception exists, and hence to control access to the
function or operation; if it fails (the exception has been deleted, or not
yet granted), then the user is ideally again offered the information
needed to give their informed consent, and again offered the opportunity
to indicate that they grant it. As stated in the normative text, the site
needs to explain and acquire consent immediately prior to calling the
Store API, and not remember some past consent; this allows the user to
change their mind.
If they do grant it (using some positive interaction such as a button),
the site can return to checking the 'Confirm' API.
In this way the site:
* does not assume that the storage is instantaneous, and mistakenly
grant access when the exception does not (yet) stand;
* does not call the Confirm API repeatedly without a user-interaction
between each call, in a loop;
* permits the user the opportunity to delete a previously granted
exception.
6.11 Fingerprinting
By storing a client-side configurable state and providing functionality to By storing a client-side configurable state and providing functionality to
learn about it later, this API might facilitate user fingerprinting and learn about it later, this API might facilitate user fingerprinting and
tracking. User agent developers ought to consider the possibility of tracking. User agent developers ought to consider the possibility of
fingerprinting during implementation and might consider rate-limiting fingerprinting during implementation and might consider rate-limiting
requests or using other heuristics to mitigate fingerprinting risk. User requests or using other heuristics to mitigate fingerprinting risk. User
agents SHOULD clear stored user-granted 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.
A. Acknowledgements A. Acknowledgements
skipping to change at line 1631 skipping to change at line 1959
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 Tracking Protection submission by Andy Zeigler, Adrian Bateman, and
Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.
B. References B. References
B.1 Normative references B.1 Normative references
[ABNF] [ABNF]
D. Crocker and P. Overell. Augmented BNF for Syntax D. Crocker; P. Overell. Augmented BNF for Syntax Specifications:
Specifications: ABNF. January 2008. Internet RFC 5234. URL: ABNF. January 2008. Internet RFC 5234. URL:
http://www.ietf.org/rfc/rfc5234.txt http://www.ietf.org/rfc/rfc5234.txt
[HTTP11] [COOKIES]
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June Adam Barth. HTTP State Management Mechanism. April 2011. Internet
1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt Proposed Standard RFC 6265. URL:
http://www.rfc-editor.org/rfc/rfc6265.txt
[NAVIGATOR] [HTTP11]
Robin Berjon; Travis Leithead; Silvia Pfeiffer; Erika Doyle R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June
Navara; Edward O'Connor; Ian Hickson. The Navigator object - 1999. RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
System state and capabilities - HTML5. 28 September 2012. Editors'
draft. (Work in progress.) URL:
http://dev.w3.org/html5/spec/system-state-and-capabilities.html#the
-navigator-object
[RFC2119] [RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. March 1997. Internet RFC 2119. URL: Levels. March 1997. Internet RFC 2119. URL:
http://www.ietf.org/rfc/rfc2119.txt http://www.ietf.org/rfc/rfc2119.txt
[RFC4627] [RFC4627]
D. Crockford. The application/json Media Type for JavaScript D. Crockford. The application/json Media Type for JavaScript
Object Notation (JSON) July 2006. Internet RFC 4627. URL: Object Notation (JSON) (RFC 4627). July 2006. RFC. 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. 2 October 2012. W3C Working Draft. Tracking Compliance and Scope. 02 October 2012. W3C Working Draft.
(Work in progress.) URL: URL: http://www.w3.org/TR/tracking-compliance/
http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/
[WEBIDL] [WEBIDL]
Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. Cameron McCormack. Web IDL. 19 April 2012. W3C Candidate
(Work in progress.) URL: Recommendation. URL: http://www.w3.org/TR/2012/CR-WebIDL-20120419/
http://www.w3.org/TR/2011/WD-WebIDL-20110927/
B.2 Informative references B.2 Informative references
[COOKIES]
Adam Barth. HTTP State Management Mechanism. April 2011. Internet
Proposed Standard RFC 6265. URL:
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
[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) (RFC 5785). April 2010. RFC. URL:
Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt 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. March 2012. Internet RFC 6570. URL: Orchard. URI Template. March 2012. RFC 6570. URL:
http://www.rfc-editor.org/rfc/rfc6570.txt http://www.rfc-editor.org/rfc/rfc6570.txt
 End of changes. 182 change blocks. 
599 lines changed or deleted 928 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/