W3C

Tracking Preference Expression (DNT)

W3C Working Draft 02 October 2012

This version:
http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/
Latest published version:
http://www.w3.org/TR/tracking-dnt/
Latest editor's draft:
http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
Previous version:
http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/
Editors:
Roy T. Fielding , Adobe
David Singer , Apple

Abstract

This specification defines the technical mechanisms for expressing a tracking preference via the DNT request header field in HTTP, via an HTML DOM property readable by embedded scripts, and via properties accessible to various user agent plug-in or extension APIs. It also defines 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 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 desired.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of 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/.

This document is a snapshot of live discussions within the Tracking Protection Working Group . It does not yet capture all of our work. For example, we have issues that are [PENDING REVIEW] with complete text proposals that did have not make yet made it into this draft. Text in white is typically [CLOSED]: we have reached a consensus decision. Text in blue boxes presents multiple options the group is considering. In some cases we are close to agreement, and Options included in others we have more to discuss. this draft should not be read as limitations on the potential outcome, but rather simply as possible options that are currently under consideration by the working group. 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 draft, published 13 March 2012, is substantially different from and more complete than the First Public Working Draft. We have not yet reviewed comments from the Community Group associated with this work. We thank them for their time and detailed feedback, and will address their comments in the near future.

This document was published by the Tracking Protection Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-tracking@w3.org ( subscribe , archives ). All feedback is welcome.

Publication as a Working Draft does not imply endorsement by the W3C 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 document as other than work in progress.

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 made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .

Table of Contents

1. Introduction

The World Wide Web (WWW, or Web) consists of millions of sites interconnected through the use of hypertext. Hypertext provides a simple, page-oriented view of a wide variety of information that can be traversed by selecting links, manipulating controls, and supplying data via forms and search dialogs. A Web page is usually composed of many different information sources beyond the initial resource request, including embedded references to stylesheets, inline images, javascript, and other elements that might be automatically requested as part of the rendering or behavioral processing defined for that page.

Each of the hypertext actions and each of the embedded resource references might refer to any site on the Web, leading to a seamless interaction with the user even though the pages might be composed of information requested from many different and possibly independent Web sites. From the user's perspective, they are simply visiting and interacting with a single brand — the first-party Web property — and all of the technical details and protocol mechanisms that are used to compose a page representing that brand are hidden behind the scenes.

It has become common for Web site owners to collect data regarding the usage of their sites for a variety of purposes, including what led the user to visit their site (referrals), how effective the user experience is within the site (web analytics), and the nature of who is using their site (audience segmentation). In some cases, the data collected is used to dynamically adapt the content (personalization) or the advertising presented to the user (targeted advertising). Data collection can occur both at the first-party site and via third-party providers through the insertion of tracking elements on each page. A survey of these techniques and their privacy implications can be found in [ KnowPrivacy ].

People have the right to know how data about them will be collected and how it will be used. Empowered with that knowledge, individuals can decide whether to allow their online activities to be tracked and data about them to be collected. Many Internet companies use data gathered about people's online activities to personalize content and target advertising based on their perceived interests. While some people appreciate this personalization of content and ads in certain contexts, others are troubled by what they perceive as an invasion of their privacy. For them, the benefit of personalization is not worth their concerns about allowing entities with whom they have no direct relationship to amass detailed profiles about their activities.

Therefore, users need a mechanism to express their own preference regarding tracking that is both simple to configure and efficient when implemented. In turn, Web sites that are unwilling or unable to offer content without such targeted advertising or data collection need a mechanism to indicate those requirements to the user and allow them (or their user agent) to make an individual choice regarding exceptions.

This specification defines the HTTP request header field DNT for expressing a tracking preference on the Web, a well-known location (URI) for providing a machine-readable tracking status resource that describes a service's DNT compliance, the HTTP response header field Tk for resources to communicate their compliance or non-compliance with the user's expressed preference, and JavaScript APIs for determining DNT status and requesting a site-specific user-granted exception.

A companion document, [ TRACKING-COMPLIANCE ], more precisely defines the terminology of tracking preferences, the scope of its applicability, and the requirements on compliant first-party and third-party participants when an indication of tracking preference is received.

Issue 136 ISSUE-117 : Terms: tracking v. cross-site tracking Resolve dependencies of the TPE on the compliance specification

The WG has not come to consensus regarding the definition of tracking and whether the scope of DNT includes all forms of user-identifying data collection DNT. As such, a site cannot actually say with any confidence whether or just cross-site data collection/use. not it is tracking, let alone describe the finer details in a tracking status resource. This issue will be resolved in by progress on the TCS document, though its resolution is a necessary prerequisite to understanding and correctly implementing the protocol defined by this document.

2. Notational Conventions

2.1 Requirements

The key words must MUST , must not MUST NOT , required REQUIRED , should SHOULD , should not SHOULD NOT , recommended RECOMMENDED , may MAY , and optional OPTIONAL in this specification are to be interpreted as described in [ RFC2119 ].

2.2 Formal Syntax

This specification uses Augmented Backus-Naur Form [ ABNF ] to define network protocol syntax and WebIDL [ WEBIDL ] for defining scripting APIs.

2.3 Terminology

This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including, but not limited to, browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [ HTTP11 ].

The term permitted use is used to indicate a restricted set of conditions under which tracking is allowed in spite of the user's DNT preference.

The term user-granted exception is used when the user has permitted tracking by a given third party, usually in the form of a site-specific exception.

A companion document, [ TRACKING-COMPLIANCE ], defines many of the terms used here, notably 'party', 'first party', and 'third party'.

3. Determining User Preference

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 communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties.

Key to that notion of expression is that it must MUST reflect the user's preference, not the preference choice of some institutional vendor, institution, or network-imposed mechanism outside the user's control. The basic principle is that a tracking preference expression is only transmitted when it 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 Do Not Track preference: unset or DNT:1 . A user agent MAY offer a third alternative choice: DNT:0 .

If the user's choice is DNT:1 or DNT:0 , the tracking preference is enabled ; otherwise, the tracking preference is not enabled .

A user agent MUST have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred , but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred . Likewise, a user agent extension or add-on MUST NOT alter the tracking preference unless the act of installing and enabling that extension or add-on is an explicit choice by the user for that tracking preference.

We do not specify how tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled . For example, a user might select a check-box in their user agent's configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high ). The user-agent might ask the user for their preference during startup, perhaps on first use or after an update adds the tracking protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.

Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what sites resources can or cannot be accessed through that network. The remainder of this specification defines the protocol in terms Implementations of whether a tracking preference is enabled or not enabled . We do not specify how HTTP that preference is enabled: each implementation is responsible for determining are not under control of the user experience by which this preference is enabled. For example, a user might select a check-box in their user agent's configuration, install a plug-in or extension that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high ). Likewise, a user might install MUST NOT generate or configure a proxy to add the expression to their own outgoing requests. For each of these cases, we say that modify a tracking preference is enabled . preference.

4. Expressing a Tracking Preference

4.1 Expression Format

When a user has enabled a tracking preference, that preference needs to be expressed to all mechanisms that might perform or initiate tracking by third parties, including sites that the user agent communicates with via HTTP, scripts that can extend behavior on pages, and plug-ins or extensions that might be installed and activated for various media types.

When enabled , a tracking preference is expressed as either:
DNT meaning
1 This user prefers not to be tracked on the target site.
0 This user prefers to allow tracking on the target site.

If A user agent MUST NOT send a tracking preference expression if a tracking preference is not enabled , then no preference is expressed by this protocol. . This means that no expression is sent for each of the following cases:

In the absence of regulatory, legal, or other requirements, servers may MAY interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol. ISSUE-111 : Different DNT value to signify existence of site-specific exception (also linked to 4.1 and 6 below)

4.2 DNT Header Field for HTTP Requests

The DNT header field is hereby defined as the means for expressing a user's tracking preference via HTTP [ HTTP11 ].

DNT-field-name  = "DNT"                          ; case-insensitive
DNT-field-value = ( "0" / "1" ) *DNT-extension   ; case-sensitive
DNT-extension   = %x21 / %x23-2B / %x2D-5B / %x5D-7E
                ; excludes CTL, SP, DQUOTE, comma, backslash

A user agent must MUST send the DNT header field on all HTTP requests if (and only if) a tracking preference is enabled . A user agent must not MUST NOT send the DNT header field if a tracking preference is not enabled .

The DNT field-value sent by a user agent must MUST begin with the numeric 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 origin server targeted by this request.

The DNT field-value sent by a user agent must MUST begin with the numeric character "0" (%x30) if a tracking preference is enabled and the preference is to allow tracking in general or by specific exception for the origin server targeted by this request. GET /something/here HTTP/1.1

Example 1
GET /something/here HTTP/1.1
Host: example.com
DNT:
1

An HTTP intermediary must not MUST NOT add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests. For example, an Internet Service Provider must not MUST NOT inject DNT: 1 on behalf of all of their users who have not selected expressed a choice. preference.

The remainder of the DNT field-value after the initial character is reserved for future extensions. User agents that do not implement such extensions must not MUST NOT send DNT-extension characters in the DNT field-value. Servers that do not implement such extensions should SHOULD ignore anything beyond the first character.

DNT extensions are to be interpreted as modifiers to the main preference expressed by the first digit, such that the main preference will be obeyed if the recipient does not understand the extension. Hence, a DNT-field-value of "1xyz" can be thought of as do not track, but if you understand the refinements defined by x, y, or z, then adjust my preferences according to those refinements. DNT extensions can only be transmitted when a tracking preference is enabled .

The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding ( section 5.1.2 Tracking Status 5.5.3 Representation ). Since the DNT header field is intended to be sent on every request, when enabled, designers of future extensions ought to use as few extension characters as possible.

ISSUE-111 : Different DNT value to signify existence of site-specific exceptions Should
Note

This document does not have any implied or specified behavior for the user agent send a different user-agent treatment of cookies when DNT value to a first party site if there exist site-specific exceptions for that first party? (e.g. DNT:2 implies I have Do Not Track enabled but grant permissions to some third parties while browsing this domain ) [OPEN] is enabled.

4.3 JavaScript API to Detect Preference

4.3.1 Interface

The A doNotTrack attribute on the NavigatorDoNotTrack Navigator interface [ NAVIGATOR interface provides a ] (e.g., the window.navigator object) is hereby defined as the means for expressing the user's general tracking preference to be expressed to web applications scripts running within a page rendered by the top-level page. A user agent. agent MUST provide a doNotTrack attribute on the Navigator interface for each top-level page.

] interface {
partial interface Navigator {
    readonly attribute DOMString doNotTrack;
};

};

4.3.2 Attributes
doNotTrack of type DOMString , readonly
When a tracking preference is enabled , the doNotTrack attribute must for each top-level page MUST have a the same string value that is the same as the would be sent in a DNT-field-value defined in ( section 4.2 DNT Header Field for HTTP Requests . If ) 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 is of null .
4.3.3 Implements Navigator implements

The NavigatorDoNotTrack doNotTrack ; Objects implementing attribute only provides the Navigator interface [ NAVIGATOR ] (e.g., user's general tracking preference, independent of any user-granted exceptions or out-of-band consent. A script wishing to determine the window.navigator object) must also implement 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 NavigatorDoNotTrack interface. An instance of NavigatorDoNotTrack doNotTrack attribute value that is obtained by using binding-specific casting methods on an instance of Navigator . ISSUE-84 : Make consistent with the user's current tracking preference that would be expressed via the DNT status available to JavaScript [OPEN] The API above has been deemed inadequate due header field. However, changes to origin restrictions on embedded javascript by reference. We the user's preference might occur between the time when the APIs are awaiting new text to resolve this issue. checked and an actual request is made. A server MUST treat the user's most recently received preference as authoritative.

ISSUE-116 Issue 116 : How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals?
ISSUE-125 : Way to test if a given user agent supports DNT

[PENDING REVIEW] Updated text in this section.

4.4 Plug-In APIs

User agents often include user-installable component parts, commonly known as plug-ins or browser extensions , that are capable of making their own network requests. From the user's perspective, these components are considered part of the user agent and thus ought to respect the user's configuration of a tracking preference. However, plug-ins do not normally have read access to the browser configuration.

Note

It is unclear whether we need to standardize the plug-in APIs or if we should rely on it being defined per user agent based on general advice here. No plug-in APIs have been proposed yet.

4.5 Tracking Preference Expressed in Other Protocols

A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. The protocol expressed here is specific to HTTP communication; however, the semantics are not restricted to use in HTTP; the same semantics may be carried by other protocols, either in future revisions of this specification, or in other specifications.

When it is known that the user's preference is for no tracking, compliant services are still required to honor that preference, even if other protocols are used. For example, re-directing redirecting to another protocol in order to avoid receipt of the header is not compliant.

ISSUE-108 : Should/could the tracking preference expression be extended to other protocols beyond HTTP? [PENDING REVIEW] Text in this section; but the
Note

The last paragraph may be more appropriate in the compliance document, as it discusses compliance.

5. Communicating a Tracking Status

5.1 Overview

The next two sections detail two proposals how primary goals of this protocol—expressing the user's preference and adhering to communicate that preference—can be accomplished without any response from the server. However, the protocol also seeks to improve the transparency of tracking status: behavior by providing a machine-readable means for discovering claims of compliance and determining the current tracking status.

Well-known URI to

Unfortunately, providing a dynamic indication of tracking compliance on every HTTP response is not feasible, since it would have the effect of disabling caching for the entire Web. Instead, this protocol defines a combination of response mechanisms that allow the information to be communicated without making every response dynamic.

This section explains how a user agent to retrieve MAY discover an origin server's tracking status for a site HTTP Response given resource. It defines a REQUIRED site-wide tracking status resource at a specific well-known location and an OPTIONAL space of request-specific tracking status resources for sites where the tracking status might vary based on data within the request. It also defines a Tk response header field that MAY be sent in any HTTP response, MUST be sent in responses to communicate requests that modify the tracking status, and MAY direct the user to a request-specific tracking status resource applicable to the current request.

5.2 Tracking Status Value

A tracking status value is a short notation for communicating how a designated resource conforms to the tracking protection protocol, as defined by this document and [ TRACKING-COMPLIANCE ]. There is no form of negative response; i.e., an origin server that does not wish to claim conformance to this protocol would not supply a tracking status resource and would not send a Tk header field in responses.

For a site-wide tracking status resource, the designated resource to which the tracking status applies is any resource on the same origin server. For a Tk response header field, the corresponding request target is the designated resource and remains so for any subsequent request-specific tracking status resource referred to by that field.

This All of the tracking status mechanisms use a common format for the tracking status value: a single character from a limited set. The meaning of each allowed character is work defined in progress. the following table.

status meaning
N None : The WG has designated resource does not yet decided which perform tracking of these options (or both) to choose. any kind, not even for a permitted use , and does not make use of any data collected from tracking.
1 First party : The WG designated resource is currently working designed for use within a first-party context and conforms to the requirements on a resolution but nevertheless appreciates input first party. If the designated resource is operated by an outsourced service provider, the service provider claims that it conforms to the requirements on a third party acting as a first party.
3 Third party : The designated resource is designed for use within a third-party context and conforms to the requirements on a third party.
X Dynamic : The designated resource is designed for use in both first and third-party contexts and dynamically adjusts tracking status accordingly. If X is present in the site-wide tracking status, more information MUST be provided via the Tk response header field when accessing a designated resource. If X is present in the Tk header field, more information will be provided in a request-specific tracking status resource referred to by the status-id . An origin server MUST NOT send X as the tracking status value in the representation of a request-specific tracking status resource.
C Consent : The designated resource believes it has received prior consent for tracking this open issue. We are currently working user, user agent, or device, perhaps via some mechanism not defined by this specification, and that prior consent overrides the tracking preference expressed by this protocol.
U Updated : The request resulted in a potential change to the tracking status applicable to this user, user agent, or device. A user agent that relies on a proposal which combines cached tracking status SHOULD update the cache entry with the current status by making a new request on the applicable tracking status resource. An origin server MUST NOT send U as a tracking status value anywhere other than a Tk header field that is in response to a state-changing request.

For the site-wide tracking status and Tk header field, the tracking status values 1 and 3 indicate how the designated resource is designed to conform, not the nature of the request. Hence, if a user agent is making a request in what appears to be a third-party context and the tracking status value indicates that the designated resource is designed only for first-party conformance, then either the context has been misunderstood (both are actually the same party) or the resource has been referenced incorrectly. For the request-specific tracking status resource, an indication of first or third party as the status value describes how the resource conformed to that specific request, and thus indicates both the nature of the request (as viewed by the origin server) and the applicable set of requirements to which the origin server claims to conform.

The tracking status value is case sensitive, as defined formally by the following ABNF.

tracking-v    = "1"   ; "1" — first-party
              / "3"   ; "3" — third-party
              / %x43  ; "C" - consent
              / %x4E  ; "N" - none
              / %x55  ; "U" - updated
              / %x58  ; "X" - dynamic
Issue 137 : Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)

[PENDING REVIEW] No, in practice there may be dozens of service providers on any given request. If the designated resource is operated by a service provider acting as a first party, then the responsible first party is identified by the policy link or the owner of the origin server domain. This satisfies the use case of distinguishing between a service provider acting for some other site and the same service provider acting on one of its own sites.

5.3 Tracking Status Resource. It would make Qualifier Values

When present, the TSR compulsory and tracking status qualifier member's value consists of a string of characters indicating what permitted uses for tracking are being used. Multiple qualifiers can be provided.

Issue 136 : Resolve dependencies of the Tk header optional. However, it would TPE on the compliance specification

The list of qualifiers is intended to match one to one to the permitted uses identified by [ TRACKING-COMPLIANCE ], using references to the definitions there. The list will then be updated accordingly.

qualifier meaning
a Audit: Tracking is limited to that necessary for an external 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.
f Fraud prevention: Tracking is limited to that necessary for preventing or investigating fraudulent behavior and security violations; the data collected is minimized accordingly.
l Local constraints: Tracking is limited to what is required by 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 specific permitted uses in [ TRACKING-COMPLIANCE ]. An origin server indicating one or more of those permitted uses also indicates that it conforms to the requirements associated with those permitted uses. Multiple limitation qualifiers mean that multiple permitted uses of tracking might be present and that each such use conforms to the associated requirements. All limitation qualifiers imply some form of tracking might be used and thus MUST NOT be provided with a tracking status value of N (not tracking).

Future extensions to this protocol might define additional characters as qualifiers from the ext-qualifier set (consisting of the remaining unused lowercase letters, dot, dash, and underscore). Recipients SHOULD ignore extension qualifiers that they do not understand.

The tracking qualifier value is case sensitive, as defined formally by the following ABNF.

	tracking-q    = tracking-q-v*	tracking-q-v  = %x61   ; "a" - audit
			  / %x63  ; "c" — capping
			  / %x66  ; "f" - fraud
			  / %x6C  ; "l" - local
			  / %x72  ; "r" - referral

5.4 Tk Header Field for HTTP Responses

5.4.1 Definition

The Tk response header field is hereby defined as an OPTIONAL means for indicating the tracking status that applied to notify the user when something corresponding request and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the TSR tracking status.

Tk-field-name   =  "Tk"       ; case-insensitiveTk-field-value  =  tracking-v [tracking-q] [ ";" status-id ]

The Tk field-value begins with a tracking status value ( section 5.2 Tracking Status Value ), optionally followed by one or more tracking qualifiers ( section 5.3 Tracking Status Qualifier Values ), and then optionally a semicolon and a status-id that refers to a request-specific tracking status resource ( section 5.4.2 Referring to a Request-specific Tracking Status Resource ).

For example, a Tk header field for a resource that claims not to be tracking would look like:

Example 2

Tk:
N

whereas a Tk header field for a resource that might perform tracking (though not necessarily for every request) and conforms to the third-party requirements of [ TRACKING-COMPLIANCE ], while claiming the audit exception, would look like:

Example 3

Tk:
3a

5.4.2 Referring to a Request-specific Tracking Status Resource

If an origin server has changed multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The OPTIONAL status-id portion of the Tk field-value indicates which specific tracking status resource applies to the current request.

status-id       =  1*id-char  ; case-sensitiveid-char         =  ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"

For example, a response containing

Example 4

Tk:
1;fRx42

indicates that the target resource claims to conform to the first-party requirements of [ TRACKING-COMPLIANCE ] and that an applicable tracking status representation can be obtained by performing a retrieval request on


/.well-known/dnt/fRx42

If a Tk field-value has a tracking status value of X (dynamic), then a status-id MUST be included in real time. the field-value.

5.4.3 Indicating an Interactive Status Change

We anticipate that interactive mechanisms might be used, beyond the scope of this specification, that have the effect of asking for and obtaining prior consent for tracking, or for modifying prior indications of consent. For example, the tracking status resource's status-object defines a control member that can refer to such a mechanism. Although such out-of-band mechanisms are not defined by this specification, their presence might influence the tracking status object's response value.

When an origin server provides a mechanism via HTTP for establishing or modifying out-of-band tracking preferences, the origin server MUST indicate within the mechanism's response when a state-changing request has resulted in a change to the tracking status for that server. This indication of an interactive status change is accomplished by sending a Tk header field in the response with a tracking status value of U (updated).

Example 5
Tk:
U

5.1 5.5 Tracking Status Resource

5.1.1 5.5.1 Resource Definition Site-wide Tracking Status

An origin server must MUST provide a site-wide tracking status resource at the well-known identifier [ RFC5785 ]

/.well-known/dnt

(relative to the URI of that origin server) for obtaining information about the potential tracking behavior of services resources provided by that origin server. A tracking status resource may MAY be used for verification of DNT support, as described in section 5.1.3 5.7 Using the Tracking Status .

A valid retrieval request (e.g., a GET in [ HTTP11 ]) HTTP) on the well-known URI must MUST result in either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation. A user agent may MAY consider failure to provide access to such a representation equivalent to the origin server not implementing this protocol. The representation might MAY be cached, as described in section 5.1.4 Tracking Status 5.5.5 Caching .

5.5.2 Request-specific Tracking Status

If an origin server contains multiple services that are controlled by distinct parties or has multiple, request-specific tracking policies, such that the tracking status might have differing behavior or policies regarding tracking, then it may differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY also provide a space an additional subtree of well-known resources for obtaining information about the potential tracking behavior of corresponding to each specific service. This parallel tree of resources is called the those distinct tracking statuses. The Tk response header field ( section 5.4 Tk Header Field for HTTP Responses ) can include a status-id to indicate which specific tracking status resource space . applies to the current request.

The tracking status resource space is defined by the following URI Template [ URI-TEMPLATE ]:

/.well-known/dnt{+pathinfo}

/.well-known/dnt{/status-id}

where the value of pathinfo status-id is equal to the path component [ RFC3986 ] a string of URI-safe characters provided by a given reference Tk field-value in response to that origin server, excluding those references already within the above resource space. a prior request. For example, a reference to prior response containing

http://example.com/over/here?q=hello#top
Example 6

Tk:
1;ahoy

may have a corresponding refers to the specific tracking status resource identified by

http://example.com/.well-known/dnt/over/here

/.well-known/dnt/ahoy

Resources within the request-specific tracking status resource space are represented using the same format as a site-wide tracking status resource.

All requests for well-known URIs defined here must not be tracked, irrespective of the presence, value, or absence of a DNT header, cookies, or any other information in the request. In addition, all responses to requests on a tracking status resource, including redirected requests, must not include Set-Cookie or Set-Cookie2 header fields [ COOKIES ] and must not include content that would have the effect of initiating tracking beyond what is already present for the request. A user agent should ignore or treat as an error any Set-Cookie or Set-Cookie2 header field received in such a response.

5.1.2 5.5.3 Tracking Status Representation

The representation of a tracking status resource shall be provided in the "application/json" format [ RFC4627 ] and must MUST conform to the ABNF for status-object (except that the members within each member-list MAY be provided in section 5.1.5 Tracking Status ABNF . any order).

The following is an example tracking status representation that illustrates all of the fields defined by this specification, most of which are optional.

{ "path": "/", "tracking": true, "received": "1", "response": "t1", "same-site": [
Example 7
{
  "tracking": "1",
  "same-party": [

    "example.com",
    "example_vids.net",
    "example_stats.com"
  ],
  "partners": [
    "api.example-third-party.com"

  "third-party": [
    "api.example.net"
  ],
  "audit": [
    "http://auditor.example.org/727073"

  ],
  "policy": "/tracking.html",
  "edit": "http://example-third-party.com/your/data",
  "options": "http://example-third-party.com/your/consent"

  "control": "http://example.com/your/data"

}

A tracking status representation consists of a single status-object containing members that describe the tracking status applicable to this user agent's request. If the status-object has an optional path member, then this object describes the tracking status for the entire space of resources that share the same path prefix as the value of path . The user agent must interpret the path value relative to the originally referenced resource, not the resource where it obtained the tracking status representation. For the site-wide tracking status resource, the presence of a path member with a value of "/" indicates that this status-object applies for the entire origin server of the originally referenced designated resource. If the originally referenced resource's path component does not share the same prefix as the value of path , or if the path member is absent, then the tracking status for the referenced resource may be obtained via a request on the corresponding tracking status resource space.

status-object = begin-object member-list end-object
member-list   = tracking         ns tracking-v [tracking-q]
                [ vs same-party  ns same-party-v  ]
                [ vs third-party ns third-party-v ]
                [ vs audit       ns audit-v       ]
                [ vs policy      ns policy-v      ]
                [ vs control     ns control-v     ]
                *( vs extension )

A status-object must MUST have a member named tracking with a boolean value. A value of false indicates that the corresponding resources do not perform contains a single character tracking as it is defined by [ TRACKING-COMPLIANCE ]. A status value of true ( section 5.2 Tracking Status Value indicates that the corresponding resource performs tracking and claims to conform to all ), optionally followed by one or more tracking compliance requirements applicable to this site. qualifiers ( section 5.3 Tracking Status Qualifier Values ) .

tracking      = %x22 "tracking" %x22

For example, the following demonstrates a minimal tracking status representation that is applicable to any resource that does not perform tracking.

{"tracking": false} The following status-object would indicate that the entire site does not perform tracking. {"path": "/", "tracking": false} If tracking is true , the status-object must include two additional members, named received and response , and may include other members as described below. The received member must have either a string value equal to the DNT-field-value received in that request or the value null if no DNT-field-value was received. Any invalid characters received in the DNT-field-value must be elided from the string value to ensure that invalid data is not injected into the JSON result. The response member must have a string value that indicates the status of tracking applicable specifically to this user in light of the received DNT-field-value . The string value begins with "t" (tracking) or "n" (not tracking) and may be followed by alphanumeric characters that indicate reasons for that status, as described in the following table. reasons meaning 1 Designed for use as a first-party only 3 Designed for use as a third-party a Limited to advertising audits
c Prior consent received from this user agent
f Limited to fraud prevention Example 8 g For compliance with regional/geographic constraints
q Limited to advertising frequency capping
{"tracking":
"N"}
r Limited to referral information

An optional OPTIONAL member named same-site same-party may MAY be provided with an array value containing a list of domain names that the origin server claims are the same site, party, to the extent they are referenced on this site, by the designated resource, since all data collected via those references share the same data controller.

same-party    = %x22 "same-party" %x22
same-party-v  = array-of-strings

An optional OPTIONAL member named partners third-party may MAY be provided with an array value containing a list of domain names for third-party services that might track the user as a result of be invoked while using this site and which the designated resource but do not have share the same data controller as the designated resource.

third-party   = %x22 "third-party" %x22third-party-v = array-of-strings

An OPTIONAL member named audit MAY be provided with an array value containing a list of URI references to external audits of the designated resource's tracking policy and tracking behavior in compliance with this site. protocol. Preferably, the audit references are to resources that describe the auditor and the results of that audit; however, if such a resource is not available, a reference to the auditor is sufficient.

audit         = %x22 "audit" %x22
audit-v       = array-of-strings

An optional OPTIONAL member named policy may MAY be provided with a string value containing a URI-reference to a human-readable document that describes the tracking policy for this site. the designated resource. The content of such a policy document is beyond the scope of this protocol and only supplemental to what is described by this machine-readable tracking status representation.

policy        = %x22 "policy" %x22
policy-v      = string       ; URI-reference

If the tracking status value is 1 and the designated resource is being 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 OPTIONAL member named edit control may MAY be provided with a string value containing a URI-reference to a resource intended to allow a tracked for giving the user agent to review or delete control over personal data collected by this site, if any such data remains associated with this user agent. The design of such a resource and the extent to which it can provide access to that data is beyond the scope of this protocol. An optional member named designated resource (and possibly other resources); a options control may member SHOULD be provided with a string if the tracking status value containing a URI-reference to indicates prior consent ( C ). Such a control resource intended to allow a user agent might include the ability to review past data collected, delete some or all of the data, provide additional data (if desired), or opt-in , opt-out , or otherwise modify their an out-of-band consent status regarding data collection by this site. collection. The design of such a resource resource, the extent to which it can provide access to that data, and how it one might implement an out-of-band consent mechanism is beyond the scope of this protocol.

control       = %x22 "control" %x22
control-v     = string       ; URI-reference

Additional extension members may MAY be provided in the status-object to support future enhancements to this protocol. A user agent should SHOULD ignore extension members that it does not recognize.

extension     = object
array-of-strings = begin-array
                   [ string *( vs string ) ]
                   end-array
ns            = <name-separator  (:), as defined in [[!RFC4627]]>vs            = <value-separator (,), as defined in [[!RFC4627]]>begin-array   = <begin-array     ([), as defined in [[!RFC4627]]>end-array     = <end-array       (]), as defined in [[!RFC4627]]>begin-object  = <begin-object    ({), as defined in [[!RFC4627]]>end-object    = <end-object      (}), as defined in [[!RFC4627]]>object        = <object, as defined in [[!RFC4627]]>string        = <string, as defined in [[!RFC4627]]>true          = <true,   as defined in [[!RFC4627]]>false         = <false,  as defined in [[!RFC4627]]>null          = <null,   as defined in [[!RFC4627]]>

Note that the tracking status resource space applies equally to both first-party and third-party services. An example of a third-party tracking status is { "tracking": true, "received": "1", "response": "n",

Example 9
{
  "tracking": "3",

  "policy": "/privacy.html",
  "edit": "/your/data",
  "options": "/your/consent"

  "control": "/your/data",

}
ISSUE-47 : Should the response from the server indicate a policy that describes the DNT practices of the server? [PENDING REVIEW] The tracking status resource is a machine-readable policy and provides a mechanism for supplying a link to a human-readable policy. ISSUE-61 : A site could publish a list of the other domains that are associated with them [PENDING REVIEW] The same-site and partners members provide a means to list first-party and third-party domains, respectively. ISSUE-124 : Alternative DNT implementations that replace HTTP headers with something else [PENDING REVIEW] The tracking status resource minimizes bandwidth usage because only a small proportion of user agents are expected to perform active verification, status would only be requested once per site per day, and the response can be extensively cached.

5.1.3 5.5.4 Using the Tracking Status Checks are Not Tracked

A key advantage of providing the tracking status at When sending a resource separate from the site's normal services is that the status can be accessed and reviewed prior to making use of those services and prior to making requests on third-party resources referenced by those services. In addition, request for the presence (or absence) of a site-wide tracking status representation is a means for testing deployment of this standard and verifying that status, a site's claims regarding tracking are consistent with the site's observed behavior over time. A user agent may SHOULD check include any cookie data [ COOKIES ] (set prior to the tracking status for a given resource URI by making request) that would be sent in a retrieval normal request for the well-known address /.well-known/dnt relative to that URI. If the response is an error, then the service does not implement this standard. If the response is a redirect, then follow the redirect to obtain origin server, since that data might be needed by the tracking status (up to some reasonable maximum of redirects server to avoid misconfigured infinite request loops). If the response is successful, obtain the tracking status representation from the message payload, if possible, or consider it an error. Once determine the current tracking status representation is obtained, parse the representation as JSON to extract status. For example, the Javascript status-object . If parsing results in cookie data might indicate a syntax error, prior out-of-band decision by the user agent should consider the site to be non-conformant with this protocol. If the status-object does not have a member named path opt-out or if the value of path is not "/" and not a prefix of the path component for the URI being checked, then find the service-specific consent to tracking status resource by taking the template /.well-known/dnt{+pathinfo} and replacing {+pathinfo} with the path component of the URI being checked. Perform a retrieval request that origin server.

All requests on the service-specific tracking status resource and process the result as described above to obtain the specific tracking status. The status-object is supposed to have a member named tracking with a boolean value. If space, including the value is false , then no site-wide tracking is performed for the URI being checked. If the value is true , then examine the member named received to verify that the DNT header field sent by the user agent has been correctly received by the server. If the received value is incorrect, there may status resource, MUST NOT be an intermediary interfering with transmission tracked, irrespective of the presence, value, or absence of a DNT request header field. If the received value is correct, then examine field, cookies, or any other information in the member named response request. In addition, all responses to see what the origin server has claimed regarding those requests, including the responses to redirected tracking status for this user agent in light of the received DNT-field-value . If the first character of the response value is "n", then the origin server claims requests, MUST NOT have Set-Cookie or Set-Cookie2 header fields and MUST NOT have content that it will not track initiates tracking beyond what was already present in the request. A user agent for requests on the URI being checked, and for any URIs with a path prefix matching the path member's value, for at least the next 24 hours SHOULD ignore, or until the Cache-Control information indicates that this response expires, treat as described below. If the first character of the response value is "t", then the origin server claims that it might track the user agent for requests on the URI being checked, and for an error, any URIs with a path prefix matching the path member's value, for at least the next 24 hours or until the Cache-Control information indicates that this response expires. The remaining characters of the response value might indicate reasons for the above choices Set-Cookie or limitations that the origin server will place on its tracking. The others members of the status-object may be used to help the user agent differentiate between Set-Cookie2 header field received in such a site's first-party and third-party services, to provide links to additional human-readable information related to the tracking policy, and to provide links for control over past data collected or over some consent mechanism outside the scope of this protocol. response.

5.1.4 5.5.5 Tracking Status Caching

If the tracking status is applicable to all users, regardless of the received DNT-field-value or other data received via the request, then the response should SHOULD be marked as cacheable and assigned a time-to-live (expiration or max-use) that is sufficient to enable shared caching but not greater than the earliest point at which the service's tracking behavior might increase. For example, if the tracking status response is set to expire in seven days, then the earliest point in time that the service's tracking behavior can be increased is seven days after the policy has been updated to reflect the new behavior, since old copies might persist in caches until the expiration is triggered. A service's tracking behavior can be reduced at any time, with or without a corresponding change to the tracking status resource.

If the tracking status is only applicable to all users that have the same DNT-field-value , then either the response must MUST include a Cache-Control header field either be marked with one of the directives "no-cache", "no-store", "must-revalidate", or "max-age=0", or the response must include a Vary header field that includes "DNT" in its field-value. field-value or marked as not reusable by a shared cache without revalidation with a Cache-Control header field containing one of the following directives: "private", "no-cache", "no-store", or "max-age=0".

If the tracking status is only applicable to the specific user that requested it, then the response must MUST include a Cache-Control header field with containing one of the directives following directives: "private", "no-cache", "no-store", "must-revalidate", or "max-age=0". "no-store".

Regardless of the cache-control settings, it is expected that user agents will check the tracking status of a service only once per session (at most). A public Internet site that intends to change its tracking status to increase tracking behavior must MUST update the tracking status resource in accordance with that planned behavior at least twenty-four hours prior to activating that new behavior on the service.

5.1.5 Tracking Status ABNF

The representation A user agent that adjusts behavior based on active verification of a site's machine-readable tracking status, relying on cached tracking status must responses to do so, SHOULD conform check responses to the following ABNF its state-changing requests (e.g., POST, PUT, DELETE, etc.) for status-object , except that a Tk header field with the members within each member-list may be provided U tracking status value, as described in any order. section 5.4.3 Indicating an Interactive Status Change .

= begin-object member-list end-object = [ path ns path-v vs ] tracking ns tracking-v [ vs received ns received-v ] [ vs response ns response-v ] [ vs same-site ns same-site-v ] [ vs partners ns partners-v ] [ vs policy ns policy-v ] [ vs edit ns edit-v ] [ vs options ns options-v ] *( vs extension ) = %x22 "path" %x22 = string ; URI absolute-path = %x22 "tracking" %x22 = true / false = %x22 "received" %x22 = null / string = %x22 "response" %x22 %x22 = ("t" / "n") *reasons = "1" ; first-party / "3" ; third-party / "a" ; advertising audits / "c" ; prior consent / "f" ; fraud prevention / "g" ; geographic/regional compliance / "q" ; frequency capping / "r" ; referrals / ALPHA / DIGIT ; TBD = %x22 "same-site" %x22 = array-of-strings = %x22 "partners" %x22 = array-of-strings = %x22 "policy" %x22 = string ; URI-reference = %x22 "edit" %x22 = string ; URI-reference = %x22 "options" %x22 = string ; URI-reference = object = begin-array [ string *( vs string ) ] end-array ]> ]> ]> ]> ]> ]> ]> ]> ]> ]> ]>

5.2 5.6 Tk Header Field Status Code for HTTP Responses Tracking Required

5.2.1 Motivation

This specification defines If an HTTP response header, in order to meet the following needs: User-agents can confirm that the server with which they are communicating has received their DNT request. User-agents can determine which class of practices the origin server intends to follow when processing this particular request. User-agents can determine if receives a server believes that the user has request with DNT:1 , does not have out-of-band consented to let them do additional tracking, and may be able to review or modify that consent. Servers make a clear promise about how they will process data gathered from consent for tracking this particular request. Servers have a well-known place to point user, and wishes to more information about their tracking/privacy practice. Servers can provide customized information deny access to clients if desired. An origin server may indicate the tracking status requested resource until the user provides some form of user-granted exception or consent for a particular request by including a Tk header field in tracking, then the corresponding response. If a request contains a DNT-field-value starting with "1", an origin server should SHOULD send a Tk header field in the corresponding response. If an origin server chooses not to send HTTP error response with a Tk header field, then the user agent will not know if status code of 409 (Conflict) and a message body that describes why the tracking preference request has been received or if it will be honored. This may have negative consequences for the site, such as triggering preventive measures on the user agent or being flagged as non-compliant by tools that look for response header fields. ISSUE-107 : Exact format of the response header? [PENDING REVIEW] See the proposal in this section. ISSUE-120 : Should refused and how one might supply the response header be mandatory ( must ) required consent or recommended ( should ) [PENDING REVIEW] Text in above paragraphs. 5.2.2 Tk ABNF The Tk header field is defined as follows: = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [CFWS] [ reason-code ] = no-dnt / not-tracking / first-party / service-provider = "0" = "1" = %x66 ; lowercase f = %x73 ; lowercase s = "1" = ALPHA 5.2.3 Tk Semantics Tk: 0 ( no-dnt ) indicates that exception to avoid this party does not comply with conflict [ TRACKING-COMPLIANCE HTTP11 ].

Tk: 1 ( not-tracking ) indicates that: 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 which access is granted.

this party complies with [ TRACKING-COMPLIANCE

], and this party will process this request according to 5.7 Using the specification for 3rd parties in [ Tracking Status

TRACKING-COMPLIANCE
]. Tk: f ( first-party ) indicates that: this party complies with [ Note TRACKING-COMPLIANCE
], this resource

This section is intended to be served as for collecting use cases that describe questions a first party, user agent might have about tracking status and this party will process this request according to how the specifications for 1st parties in [ TRACKING-COMPLIANCE protocol can be used to answer such questions. More cases are needed.

]. 5.7.1 Discovering Deployment

Tk: s ( service-provider ) indicates that: this party complies with [ TRACKING-COMPLIANCE ], this resource The presence of a site-wide tracking status representation is intended to be used in a claim that the context of third party acting as an outsourced service provider conforms to this protocol for a first party, and this party will process given user agent. Hence, deployment of this request according to the exemption protocol for a third party acting as an outsourced given service provider for can be discovered by making a first party, as described in [ retrieval request on the site-wide tracking resource TRACKING-COMPLIANCE /.well-known/dnt ]. relative to the service URI.

The opt-in-flag indicates that If the server believes that response is an error, then the user has affirmatively consented to allow service does not implement this party additional permission to track them. Unless standard. If the opt-in-flag response is included, a redirect, then follow the server asserts that will act in responding redirect to this request as if obtain the user has not affirmatively consented tracking status (up to allow this party additional permission some reasonable maximum of redirects to track them. The reason-code can be used when requesting more information (see below). 5.2.4 More Information avoid misconfigured infinite request loops). If a reason code is specified in the response, the well-known resource defined here must exist; if an opt-in-flag response is included, the wel--known resource defined here should exist; otherwise it may exist. The user can understand and manage their opt-in by visiting the well-known URI /.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code} relative to the request-target. The information at this URI provides additional information about this party's privacy practices and practices, particularly concerning the opt-in-flag . The above well-known URI has not yet been reconciled with the similar but distinct definition for successful, obtain the tracking status resource. We anticipate that one or representation from the other will be adopted, message payload, if possible, or the two proposals will be merged. consider it an error.

5.2.5 5.7.2 Implementation and Usage Considerations Preflight Checks

Implementers should use caution when allowing caching of resources on which an opt-in flag is included. If caching is not carefully managed, there is a risk of sending a response intended for opted-in users to users who haven't opted in. Implementers should carefully choose the cache properties A key advantage of providing the items tracking status at a resource separate from the well-known URI. The content at these locations must be correct for site's normal services is that the entire cache duration, otherwise users who load stale cached copies status can be accessed and reviewed prior to making use of these those services and prior to making requests on third-party resources may be misled. referenced by those services.

Any party can use A user agent MAY check the not-tracking response: this response just indicates a behavior. If tracking status for a designated resource by first party complies with the third-party definition, they are free to send this response. However, the first-party and service provider responses indicate both making a behavior retrieval request for the site-wide tracking status representation, as described above, and an intention about that party's status. It would be deceptive to send then parsing the first-party header on a resource which is only ever embedded representation as a third party. The no-dnt response should not be used on requests which are processed in accordance with [ TRACKING-COMPLIANCE ]. An entity which implements DNT should not use this response. When embedding content from other sites, consider how that site expects their content to be used. If you embed/link JSON to an object on another site, it's possible that extract the resource will send a first-party response even though it Javascript status-object . If retrieval is now unsuccessful or parsing results in a third-party context because syntax error, the user agent SHOULD consider the designer of that site never intended that object to be embedded. If a resource always sends a third-party response, there is no risk of non-conformant with this inconsistent response. Only the first-party outsourcer of service-provider objects should ever embed them. protocol.

5.2.6 Examples Tk: 1

The site status-object is supposed to have a third or first party, in compliance with member named tracking containing the definitions tracking status value. The meaning of a 3rd party that each tracking status value is not tracking. defined in section 5.2 Tracking Status Value .

Tk: 1 1 agreed

The site If the tracking status value is a third party, N , then the origin server claims that believes it has an explicit opt-in from no tracking is performed for the user; more information can be found at: /.well-known/dnt?status=1&opt-in=1&r=agreed 5.3 Status Code designated resource for Tracking Required An HTTP error at least the next 24 hours or until the Cache-Control information indicates that this response expires.

If the tracking status code value is not N , then the origin server claims that it might be useful track the user agent for indicating that requests on the site refuses service unless URI being checked for at least the user either logs into a subscription account next 24 hours or agrees to an exception to DNT for until the Cache-Control information indicates that this site and its contracted third-party sites. response expires.

6. Site-specific User-Granted Exceptions

ISSUE-118 : Should requesting a user-agent-managed site-specific exception be asynchronous? [PENDING REVIEW] As proposed below. ISSUE-115 : Should sites be able to manage site-specific tracking exceptions outside of the user-agent-managed system? ISSUE-111 : Different DNT values to signify existence of site-specific exception

6.1 Overview

This section is non-normative.

Exceptions User-granted exceptions to Do Not Track, including site-specific exceptions, are managed by the user agent. A resource should rely on the DNT header it receives to determine the user's preference for tracking with respect to that particular request. An API is provided so that sites may request and check the status of exceptions for tracking.

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 user/granted exceptions

[OPEN] but mostly addressed in the proposal here.

6.2 Motivating principles Principles and use cases Use Cases

This section is non-normative.

The following principles guide the design of the user-agent-managed site-specific exceptions proposal. exceptions.

When asking for a site-specific exception, the top-level domain making the request may be making some implicit or explicit claims as to the actions and behavior of its third parties; for this reason, it might want to establish exceptions for only those for which it is sure that those claims are true. (Consider a site that has some trusted advertisers and analytics providers, and some mashed-up content from less-trusted sites). For this reason, there is support both for explicitly named sites, as well as support for granting an exception to all third-parties on a given site (site-wide exception, using the conceptual wild-card "*").

There are some cases in which a user may desire a site to be allowed to track them on any top-level domain. An API is provided so that the site and the user may establish such a web-wide exception.

6.3 Exception model

6.3.1 Site pairs Introduction

This section describes the effect of the APIs in terms of a logical processing model; this model describes the behavior, but should not be read as mandating any specific implementation.

This API considers exceptions which are double-keyed to two domains: the site , and the tracker target . A user might — for instance — want AnalytiCo to be allowed to track them on Example News, but not on Example Medical. To simplify language used in this API specification, we define two three terms:

  • This site Top-Level Domain (TLD) is the domain name of the top-level document origin of this DOM: essentially the fully qualified domain name in the address bar.
  • A tracker target site is a domain name which is not operated by the same party which operates this site , target of an HTTP request, and which may be an origin for embedded resources on this site the indicated top-level domain .
  • The document origin of a script is the domain of origin of the document that caused that script to be loaded (not necessarily the same as the origin of the script itself).

For instance, if the document at http://web.exnews.com/news/story/2098373.html references the resources http://exnews.analytico.net/1x1.gif and http://widgets.exsocial.org/good-job-button.js , this site the top-level domain is web.exnews.com ; exnews.analytico.net and widgets.exsocial.org are both trackers targets .

ISSUE-112 Issue 112 : How are sub-domains handled for site-specific exceptions?

[PENDING REVIEW] Should a request for a tracking exception apply to all subdomains of the first party making the request? Or should a first party explicitly list the subdomains that it's asking for? Similarly, should third party 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:

  • As described above, the document origin active at the time of the call, and;
  • Domain names passed to the API.

Domains that enter into the decision over what DNT header to be sent in a given HTTP request include:

  • The top-level domain of the current context;
  • The target of the HTTP request.
Note

Note that these strict, machine-discoverable, concepts may not match the definitions of first and third party; in particular, sites themselves need to determine (and signal) when they get 'promoted' to first party by virtue of user interaction; the UA will not change the DNT header it sends them.

The calls cause the following steps to occur:

  • First, the UA somehow confirms with the user that they agree to the grant of exception, if not already granted;
  • If they agree, then the UA adds to its local database one or more site-pair duplets [document-origin, target]; one or other of these may be a wild-card ("*");
  • While the user is browsing a given site (top-level domain), and a DNT header is to be sent to a target domain, if the duplet [top-level domain, target domain] matches any duplet in the database, then a DNT:0 header is sent, otherwise DNT:1 is sent.
Note

Note that a site may record no that it has previously asked for, and been denied, an exception, if it wishes to avoid repeatedly asking the user for an exception.

6.3.2 Exception use by browsers

If a user wishes agrees to be tracked allow tracking by a tracker target on the this site top-level domain , this should result in two user-agent behaviors:

  1. If requests to the tracker target for resources that are part of the DOM for pages on this site top-level domain include a DNT header, that header must MUST be DNT:OFF. 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 maintain their own trusted third parties?

This model does not support mashed-up content which is in turn supported by ads; it's not clear how to distinguish between embedded content which is embedding ads (and hence the top-level domain stays the same) and embedded content that should start a new context.
Proposal : For this version of the specification, we don't address this corner case.

User-agents MUST handle each API request as a 'unit', granting and maintaining it in its entirety, or not at all. That means that a user-agent MUST NOT indicate to a site that a request for targets {a, b, c} has been granted, and later remove only one or two of {a, b, c} from its logical database of remembered grants. This assures sites that the set of sites they need for operational integrity is treated as a unit. Each separate call to an API is a separate unit.

When a user-agent receives an API request for an exception that already exists (i.e. the grant is recorded in its database), it SHOULD bypass asking the user to confirm, and simply re-confirm the grant to the caller.

Note

It is left up to individual user-agent implementations how to determine and how and whether to store users' tracking preferences.

When an explicit list of domains is provided through the API, their names might mean little to the user. The user might, for example, be told that such-and-such top-level domain is asking for an exception for a specific set of sites, rather than listing them by name; or the user-agent may decide to ask the user for a site-wide exception, effectively ignoring the list of domain names, if supplied.

Conversely, if a wild-card is used, the user may be told that the top-level domain is asking for an exception for all third-parties that are, or will be, embedded in it.

ISSUE-111 Issue 111 : Different DNT values to signify existence of site-specific user-granted exception

[POSTPONED] Should the user agent send a different DNT value to a first party site if there exist site-specific user-granted exceptions for that first party? (e.g. DNT:2 implies "I have Do Not Track enabled but grant permissions to some third parties while browsing this domain")
Proposal : No, this API provides client-side means A previous proposal was that it can add itself to the list (i.e. an exception for sites [site, site]) and then it will get DNT:0, but DNT:0 to request that information. Sites may also employ cookies a first party means something different (that it can pass data to recall third parties, and tracking is permitted). It would be better to have an indication in the DNT header that one or more site-specific exceptions exist for the given target (i.e. that there is at least one duplet in the database with target as its first host name), for example "DNT:1E" where E means you are a user's past response. first party with one or more active exceptions.

6.4 JavaScript API for site-specific exceptions Site-specific Exceptions

] interface { ); };

6.4.1 Methods API to request site-specific exceptions

[NoInterfaceObject]
interface NavigatorDoNotTrack {
    void requestSiteSpecificTrackingException (           TrackingResponseCallback callback,           optional sequence<DOMString> arrayOfDomainStrings,           optional optional siteName,           optional optional explanationString,           optional optional detailURI
         );
};

requestSiteSpecificTrackingException
Called by a page to request or confirm a site-specific user-granted tracking exception.
Parameter Type Nullable Optional Description
arrayOfDomainStrings callback sequence< DOMString TrackingResponseCallback >
callback arrayOfDomainStrings TrackingResponseCallback sequence< DOMString >
siteName optional
explanationString optional
detailURI optional
Return type: void
]
[Callback, NoInterfaceObject]
interface TrackingResponseCallback {
    void handleEvent (integer granted);
};

};

6.4.2 Methods
handleEvent
The callback is called by the user agent to indicate the user's response.
Parameter Type Nullable Optional Description
granted boolean integer
Return type: void

The requestSiteSpecificTrackingException method takes two one mandatory arguments: argument:

  • arrayOfDomainStrings , a JavaScript array of strings, and callback , a method that will be called when the request is complete.

It also takes three four optional arguments:

  • arrayOfDomainStrings , a JavaScript array of strings,
  • siteName , a user-readable string for the name of this site, the top-level domain,
  • explanationString , a short explanation of the request, and
  • detailURI , a location at which further information about this request can be found.

Each If the request does not include the arrayOfDomainStrings , then this request is for a site-wide exception. Otherwise each string in arrayOfDomainStrings specifies a tracker . The special string “*” signifies all trackers target . When called, requestSiteSpecificTrackingException must MUST return immediately, then asynchronously determine whether the user wants grants the requested exceptions. exception(s).

If the list arrayOfDomainStrings is supplied, the user-agent MAY choose to ask the user to grant a site-wide exception. If it does so, and the user agrees, it MUST indicate this in the response callback.

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 user's response; The response

  • true 0 indicates the that user wants an does not grant the exception on this site top-level domain for all of the indicated tracker target s specified in arrayOfDomainStrings . The response s.
  • false 1 indicates that the request was for specific target s and the the user does not want grants an exception on this site top-level domain for at least one of those specific target s.
  • 2 indicates the user grants a site-wide exception on tracker top-level domain for all target s; the request may have been for specific target s specified in arrayOfDomainStrings . or for a site-wide exception.

If permission is granted for an explicit list, then the set of duplets (one per target):


[document-origin,
target]

is added to the database of remembered grants.

If permission is granted for a site-wide exception, then the duplets:


[document-origin,
*
]

is added to the database of remembered grants.

A particular response to the API — like a DNT response header — is only valid immediately, and users' preferences may change.

A user agent may MAY use an interactive method to ask the user about their preferences, so sites should not SHOULD NOT assume that the callback function will be called immediately.

ISSUE-109 : siteSpecificTrackingExceptions property has fingerprinting risks: 6.4.2 API to Cancel a Site-specific Exception

[NoInterfaceObject]
interface NavigatorDoNotTrack {
    boolean removeSiteSpecificTrackingException ();
};
removeSiteSpecificTrackingException
Ensures that the database of remembered grants no longer contains any duplets for which the first part is the current document origin; i.e., no duplets [document-origin, target] for any target. There is no callback. After the call has been made, it necessary? is assured that there are no site-specific or site-wide exceptions for the given top-level-domain.
No parameters.
Return type: boolean

This returns a boolean indicating, when true, that the call has succeeded, and that the database of grants no longer contains, or very soon will no longer contain, the indicated grant(s); when false, some kind of processing error occurred.

6.5 JavaScript API for Web-wide Exceptions

6.5.1 API to Request a Web-wide Exception

[NoInterfaceObject]
interface NavigatorDoNotTrack {
    void requestWebWideTrackingException (           TrackingResponseCallback callback,           optional  siteName,           optional optional explanationString,           optional optional detailURI
         );
};
requestWebWideTrackingException
If permission is granted, then the single duplet [ * , document-origin] is added to the database of remembered grants. The parameters are as described above in the request for site-specific exceptions.
Parameter Type Nullable Optional Description
callback TrackingResponseCallback
siteName
explanationString optional
detailURI optional
Return type: void

Users may wish to configure exceptions for a certain trusted tracker across all sites. This API requests the addition of a web-wide grant for a specific site, to the database.

6.5.2 API to cancel a web-wide exception

[NoInterfaceObject]
interface NavigatorDoNotTrack {
    boolean removeWebWideTrackingException ();
};
removeWebWideTrackingException
Ensures that the database of remembered grants no longer contains the duplet [ * , document-origin] . There is no callback. After the call has been made, the indicated pair is assured not to be in the database. The same matching as is used for determining which header to send is used to detect which entry (if any) to remove from the database.
No parameters.
Return type: boolean

This returns a boolean indicating, when true, that the call has succeeded, and that the database of grants no longer contains, or very soon will no longer contain, the indicated grant; when false, some kind of processing error occurred.

6.6 Querying a host's exception status

Issue 160 : Do we need an exception-query API?

[PENDING REVIEW] It has been removed might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context. See proposal here.
Proposal : Specifically, an API QueryExceptionStatus() which examines the document origin of the script, the current top-level domain and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.

[NoInterfaceObject]
interface NavigatorDoNotTrack {
    DOMString requestDNTStatus ();
};
requestDNTStatus
Returns the same string value that would be sent in a DNT-field-value ( section 4.2 DNT Header Field for HTTP Requests ) to a target that is the document-origin of the request, in the context of the current top-level domain . If no DNT header would be sent (e.g. because a tracking preference is not enabled ) the return value is null .
No parameters.
Return type: DOMString

6.7 Transfer of an exception to another third party

A site may request an exception for one or more third party services used in conjunction with its own offer. Those third party services may wish to use other third parties to complete the request in a chain of interactions. The first party will not necessarily know in advance whether a known third party will use some other third parties.

If a user-agent sends a tracking exception to a given combination of origin server and a named third party, the user agent will send DNT:0 to that named third party. By receiving the DNT:0 header, the named third party acquires the permission to track the user agent and collect the data and process it in any way allowed by the legal system it is operating in.

Furthermore, the named third party receiving the DNT:0 header acquires at least the right to collect data and process it for the given interaction and any secondary use unless it receives a DNT:1 header from that particular identified user agent.

The named third party is also allowed to transmit the proposal. collected data for uses related to this interaction to its own sub-services and sub-sub-services (transitive permission). The tracking permission request triggered by the origin server is thus granted to the named third party and its sub-services. This is even true for sub-services that would normally receive a DNT:1 web-wide preference from the user-agent if the user agent interacted with this service directly.

For advertisement networks this typically would mean that the collection and auction system chain can use the data for that interaction and combine it with existing profiles and data. The sub-services to the named third party do not acquire an independent right to process the data for independent secondary uses unless they, themselves, receive a DNT:0 header from the user agent (as a result of their own request or the request of a first-party). In our example of advertisement networks that means the sub-services can use existing profiles in combination with the data received, but they can not store the received information into a profile until they have received a DNT:0 of their own.

A named third party acquiring an exception with this mechanism MUST make sure that sub-services it uses acknowledge this constraint by requiring the use of the appropriate tracking status value and qualifier , which is "XX" (such as "tl"), from its sub-sub-services.

The permission acquired by the DNT mechanism does not override retention limitations found in the legal system the content provider or the named third party are operating in.

Issue 168 : What is the correct way for sub-services to signal that they are taking advantage of a transferred exception?

When the status values and qualifiers are fixed, the penultimate paragraph will probably need adjusting to match. The use of "tl" (which meant "tracking but only in accordance with local laws" when this text was written) doesn't seem right, as the text talks, essentially, of the sub-sub-service acting on behalf of the site that received the DNT:0 header, which might suggest something more like "CS" (service provision to a third-party that received consent).

6.5 6.8 User interface guidelines

This section is non-normative.

User agents are free to implement exception management user interfaces as they see fit. Some agents might provide a prompt to the user at the time of the request. Some agents might allow users to configure this preference in advance. In either case, the user agent responds with the user’s 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:

) would like to know whether you permit tracking by the following parties: * *
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

  These sites allow Example News to see how we're
  doing, and provide useful features of the Example News
  experience.”     [More info]

  experience.     [More info]

[Allow
Tracking]
[Deny
Tracking
Request]

In this example, the domains listed are those specified in arrayOfDomainStrings , the phrase “Example News” Example News is from siteName , and the explanationString is displayed for the user with a “More info” More info link pointing to detailURI .

The user agent might then store that decision, and answer future requests based on this stored preference. User agents might provide users with granular choice over which tracking origins are granted site-specific exceptions and which are not (using checkboxes, for example). User agents might automatically clear site-specific exceptions after a period of time or in response to user activity, like leaving a private browsing mode or using a preference manager to edit their chosen exceptions. If a A user agent retains user preferences, it might provide the user with an interface to explicitly add or remove site-specific (or add) user-granted exceptions.

Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on 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.

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 users of the device. Thus, exceptions may not always represent the current 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 control these preferences. Users may desire options to edit exceptions 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 without visiting that site.

ISSUE: Should there be a normative requirement for the existence
Issue 140 : Do we need site-specific exceptions, i.e., concrete list of permitted third parties for a revocation mechanism? (raised by npdoty) site?

[PENDING REVIEW] In this section; yes, as some sites may have a mix of trusted/needed third parties, and others that either don't need to track, or aren't as trusted, or both. But all sites are (a) told what they got granted (list, or *) and (b) are assured that requests will be treated 'atomically'.

6.6 6.9 Exceptions without a DNT header

Sites might wish to request exceptions even when a user arrives without a DNT header. Users might wish to grant affirmative permission to tracking on or by certain sites even without expressing general tracking preferences.

User agents may MAY instantiate NavigatorDoNotTrack.requestSiteSpecificTrackingException even when navigator.doNotTrack is null. Sites should SHOULD test for the existence of requestSiteSpecificTrackingException before calling the method. If an 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 isn't expressed for other requests. Persisted preferences may MAY also affect which header is transmitted if a user later chooses to express a tracking preference.

Note

Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on 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. 6.7 Web-wide exceptions Users may wish to configure exceptions for a certain trusted tracker across several or all sites . User agent configuration of these preferences is outside the scope of this specification. ISSUE-113 : Should there be a JavaScript API to prompt for a Web-wide exception? PROPOSAL : User agents can provide configuration options outside the scope of this specification.

6.8 6.10 Fingerprinting

By storing a client-side configurable state and providing functionality to learn about it later, this API might facilitate user fingerprinting and tracking. User agent developers ought to consider the possibility of fingerprinting during implementation and might consider rate-limiting requests or using other heuristics to mitigate fingerprinting risk. User agents should SHOULD clear stored site-specific user-granted exceptions when the user chooses to clear cookies or other client-side state.

ISSUE-114 : Guidance or mitigation of fingerprinting risk for user-agent-managed site-specific tracking exceptions PENDING REVIEW Above text provides guidance for user agent developers.

A. Acknowledgements

This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Nick Doty Nick Doty ( W3C / MIT ), Roy T. Fielding Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Tom Lowenthal Tom Lowenthal (Mozilla), Aleecia M. McDonald Jonathan Mayer (Stanford), Aleecia M. McDonald (Mozilla), Matthias Schunter Matthias Schunter (IBM), John Simpson John Simpson (Consumer Watchdog), David Singer David Singer (Apple), Shane Wiley David Wainberg (Network Advertising Initiative), Rigo Wenning ( W3C / ERCIM ), Shane Wiley (Yahoo!), and Andy Zeigler Andy Zeigler (Microsoft).

The DNT header field is based on the original Do Not Track submission by Jonathan Mayer Jonathan Mayer (Stanford), Arvind Narayanan Arvind Narayanan (Stanford), and Sid Stamm Sid Stamm (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web Tracking Protection submission by Andy Zeigler, Adrian Bateman, Andy Zeigler, Adrian Bateman, and Eliot Graff Eliot Graff (Microsoft). Many thanks to Robin Berjon Robin Berjon for ReSpec.js.

B. References

B.1 Normative references

[ABNF]
D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet RFC 5234. URL: http://www.ietf.org/rfc/rfc5234.txt
[HTTP11]
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
[NAVIGATOR]
Robin Berjon; Travis Leithead; Silvia Pfeiffer; Erika Doyle Navara; Edward O'Connor; Ian Hickson, David Hyatt. Hickson. The Navigator interface in object - System state and capabilities - HTML5. 15 April 2011. 28 September 2012. Editors' draft. (Work in progress.) URL: http://dev.w3.org/html5/spec/timers.html#navigator http://dev.w3.org/html5/spec/system-state-and-capabilities.html#the-navigator-object
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[RFC4627]
D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) July 2006. Internet RFC 4627. URL: http://www.ietf.org/rfc/rfc4627.txt
[TRACKING-COMPLIANCE]
Justin Brookman; Sean Harvey; Erica Newland; Heather West. Tracking Compliance and Scope. 13 March 2 October 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/
[WEBIDL]
Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-WebIDL-20110927/

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]
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June 2009. URL: http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf [RFC3986] T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt
[RFC5785]
Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform Resource Identifiers (URIs). April 2010. Internet Proposed Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt
[URI-TEMPLATE]
Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David Orchard. URI Template. 26 January March 2012. Internet Draft (work in progress). RFC 6570. URL: http://tools.ietf.org/html/draft-gregorio-uritemplate-08 http://www.rfc-editor.org/rfc/rfc6570.txt