Tracking Preference Expression (DNT)

2.1 HTTP

The following terms are used as defined by HTTP/1.1 syntax [RFC7230] and semantics [RFC7231]: client, server, origin server, user agent, sender, recipient, request, response, message, intermediary, proxy, cache, uri-host, authority, header field, target resource, resource, and representation.

2.2 HTML

The following terms are used as defined by HTML [HTML51]: active document, document.domain, effective script origin, responsible document, browsing context, nested browsing context, and top-level browsing context.

2.3 Activity

Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties.

A network interaction is a single HTTP request and its corresponding response(s): zero or more interim (1xx) responses and a single final (2xx-5xx) response.

A user action is a deliberate action by the user, via configuration, invocation, or selection, to initiate a network interaction. Selection of a link, submission of a form, and reloading a page are examples of user actions. User activity is any set of such user actions.

2.4 Participants

A user is a natural person who is making, or has made, use of the Web.

A party is a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user. Common branding or providing a list of affiliates that is available via a link from a resource where a party describes DNT practices are examples of ways to provide this discoverability.

With respect to a given user action, a first party is a party with which the user intends to interact, via one or more network interactions, as a result of making that action. Merely hovering over, muting, pausing, or closing a given piece of content does not constitute a user's intent to interact with another party.

In some cases, a resource on the Web will be jointly controlled by two or more distinct parties. Each of those parties is considered a first party if a user would reasonably expect to communicate with all of them when accessing that resource. For example, prominent co-branding on the resource might lead a user to expect that multiple parties are responsible for the content or functionality.

For any data collected as a result of one or more network interactions resulting from a user's action, a third party is any party other than that user, a first party for that user action, or a service provider acting on behalf of either that user or that first party.

Access to Web resources often involves multiple parties that might process the data received in a network interaction. For example, domain name services, network access points, content distribution networks, load balancing services, security filters, cloud platforms, and software-as-a-service providers might be a party to a given network interaction because they are contracted by either the user or the resource owner to provide the mechanisms for communication. Likewise, additional parties might be engaged after a network interaction, such as when services or contractors are used to perform specialized data analysis or records retention.

For the data received in a given network interaction, a service provider is considered to be the same party as its contractee if the service provider:

1. processes the data on behalf of the contractee;
2. ensures that the data is only retained, accessed, and used as directed by the contractee;
3. has no independent right to use the data other than in a permanently de-identified form (e.g., for monitoring service integrity, load balancing, capacity planning, or billing); and,
4. has a contract in place with the contractee which is consistent with the above limitations.

2.5 Data

A party collects data received in a network interaction if that data remains within the party’s control after the network interaction is complete.

A party uses data if the party processes the data for any purpose other than storage or merely forwarding it to another party.

A party shares data if it transfers or provides a copy of that data to any other party.

Data is permanently de-identified when there exists a high level of confidence that no human subject of the data can be identified, directly or indirectly (e.g., via association with an identifier, user agent, or device), by that data alone or in combination with other retained or available information.

3.1 Requirements

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

3.2 Formal Syntax

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] to define network protocol syntax and WebIDL [WebIDL-20161215] to define scripting APIs. Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

How to throw a DOMexception and the exceptions named "InvalidStateError", "SecurityError", and "SyntaxError" are defined in [WebIDL-20161215].

Promise objects are defined in [ECMASCRIPT]; the phrases promise-call, resolve promise, reject promise, upon fulfillment, and upon rejection are used in accordance with [PromiseGuide].

5.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.

When enabled, a tracking preference is expressed as either:

A user agent MUST NOT send a tracking preference expression if a tracking preference is not enabled. This means that no expression is sent for each of the following cases:

• the user agent does not implement this protocol;
• the user has not yet made a choice for a specific preference; or,
• the user has chosen not to transmit a preference.

In the absence of regulatory, legal, or other requirements, servers 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.

5.2 DNT Header Field for HTTP Requests

The DNT header field is a mechanism for expressing the user's tracking preference in an HTTP request ([RFC7230]). At most one DNT header field can be present in a valid request.

DNT-field-name  = "DNT"
DNT-field-value = ( "0" / "1" ) *DNT-extension

A user agent MUST NOT generate a DNT header field if the user's tracking preference is not enabled.

A user agent MUST generate a DNT header field with a field-value that begins with the numeric character "1" if the user's tracking preference is enabled, their preference is for DNT:1, and no exception has been granted for the target resource (see section 6. User-Granted Exceptions).

A user agent MUST generate a DNT header field with a field-value that begins with the numeric character "0" if the user's tracking preference is enabled and their preference is for DNT:0, or if an exception has been granted for the target resource.

A proxy MUST NOT generate a DNT header field unless it has been specifically installed or configured to do so by the user making the request and adheres to the above requirements as if it were a user agent.

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

DNT-extension   = %x21 / %x23-2B / %x2D-5B / %x5D-7E
                ; excludes CTL, SP, DQUOTE, comma, backslash

5.3 JavaScript Property to Detect Preference

The Navigator.doNotTrack property enables a client-side script with read access to the Navigator object [HTML51] to determine what DNT header field value would be sent to the effective script origin, taking into account the user's general preference (if any) and user-granted exceptions applicable to the target domain when referenced by the active document's top-level browsing context.

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

The value is null if no DNT header field would be sent (e.g., because a tracking preference is not enabled and no user-granted exception is applicable); otherwise, the value is a string beginning with "0" or "1", possibly followed by DNT-extension characters.

Specifically, the value of Navigator.doNotTrack for a given script is either null or the string value that would be sent in a DNT field-value (section 5.2 DNT Header Field for HTTP Requests) in a request to a target resource at the effective script origin (the current document.domain of the script's responsible document) when that request is due to an embedded reference from this site (the document.domain of the top-level browsing context's active document).

Ideally, the value of Navigator.doNotTrack ought to reflect the current set of user-granted exceptions in effect when the attribute is read. In practice, however, the value might only reflect the value that was in effect when the script was initiated.

5.4 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. However, it is beyond the scope of this specification to define how a user's tracking preference might be communicated via protocols other than HTTP.

6.1 Overview

Content providers might wish to prompt visitors to opt in to tracking for behavioral advertising or similar purposes when they arrive with the Do Not Track setting enabled. However, granting an exception in one context (e.g., while browsing a news site) does not imply that exception is applicable to other contexts (e.g., browsing an unrelated medical site). Furthermore, users might wish to view or edit all the exceptions they've granted in a single, consistent user interface, rather than managing preferences in a different way on every content provider or tracker's privacy page.

A user-granted exception is the record of a decision by the user to grant consent for tracking (DNT:0) on future requests from a given site to a set of target domains. Both site and target are scoped by domain, similar to the existing domain scope of cookies (Section 5.3.1 of [HTML51]), to avoid prompting the user for every subdomain of a site and every target resource that might be referenced.

A client-side database can be used for persistent storage of user-granted exceptions, such that permission to send DNT:0 is obtained by a site and stored via a JavaScript API. However, we only define the API (below); the choice of storage mechanism is left to each implementation. In comparison to the use of cookies to manage consent, an exception database and APIs provide more transparency and better user control, while also providing better persistence of those exceptions for sites.

6.2 Site-specific or Web-wide

There are three domain concepts involved in the processing of user-granted exceptions:

site domain

the domain associated with a site on which a given reference might be found and for which the user-granted exceptions API might be queried: specifically, the current document.domain of the top-level browsing context's active document [HTML51].

target domain

the uri-host subcomponent of the authority component of a referenced "http" or "https" URI [RFC7230].

script domain

the effective domain of a script when it uses the exception API: specifically, the current document.domain of the script's responsible document [HTML51].

A user-granted exception is site-specific if the exception is limited to requests embedded in, or referred by, a given site domain; otherwise, the exception is web-wide because it applies to the target domain regardless of the referring site. For example, a user might wish to grant a certain target domain a web-wide exception for the purpose of audience measurement across multiple sites, perhaps in exchange for some incentive.

When asking for consent to record a site-specific exception, a site might make some claims regarding limitations on the actions and behavior of the known third parties that it references. Such a site might wish to restrict its site-specific exceptions to only target domains for which those claims have been verified. (For example, consider the dilemma of a site that has trusted advertisers and analytics providers, along with some less trusted mashed-up content that might reference other sites). For this reason, site-specific exceptions can be limited to the script domain, limited to a named set of target domains, or be applicable to any target domain ("*").

6.3 Granting an Exception

It is expected that a site will explain to the user, in its online content, the need for an exception and the consequences of granting or denying that exception. Upon receipt of an informed consent from the user, a script operating on the site's page is expected to promise-call the Navigator.storeTrackingException API using parameters consistent with the consent granted by the user.

A site MUST ensure that a call to store an exception reflects the user's intention to grant an exception at the time of that call. It is the sole responsibility of the site to determine that a call to record an exception reflects the user's informed consent at the time of that call.

Third party target domains that might wish to receive a user-granted exception often do not have the ability to invoke an interactive JavaScript presence on a page (for example, those that provide only images or "tracking pixels"). They cannot request an exception under these circumstances, either because a script is needed to make the API call or it requires interaction to ensure the user is informed and to receive an indication of their consent. In general, this process of informing, getting consent, and calling the API is not expected within page elements where such trackers are invoked.

A first party site's page (the top-level browsing context) might be used to obtain consent for multiple parties; e.g., using multiple iframe elements containing scripts that can convey information about each party's policies and obtain specific consent for each party. In this case, the effective script origin might be different from the site for which consent is being granted.

Alternatively, a third party might encourage the user to visit their own site directly in order to engage in a consent dialog and make use of the API to store a web-wide exception.

A site can request an exception be stored even when the user's general preference is not enabled. This permits the sending of DNT only for target resources for which an expressed preference is desired. Stored exceptions could affect which preference is transmitted if a user later chooses to configure a general tracking preference.

A user agent might not store the exception immediately, possibly because it is allowing the user to confirm. Even though the site has acquired the user's informed consent before calling the store API, it is possible that the user will change their mind, allow the storing of an exception to proceed but later remove it, or perhaps deny the storage by prior configuration. Nonetheless, at the time of a call, the site has acquired the user's consent and can proceed on that basis whether or not the user agent has stored an exception.

6.4 Checking for an Exception

A site can promise-call the Navigator.trackingExceptionExists API to enquire whether a set of exceptions has been granted and stands in the user agent. If the promise resolves to false (indicating the exception set has expired, been deleted, or has not yet been stored), the user can be asked again for consent.

A user agent is expected to query the exceptions database at the time of a request in order to determine what value (if any) to send as the user's tracking preference.

• While the user is browsing a given site, if the duplet [site domain, target domain] matches any duplet in the database, then a DNT:0 preference is sent, otherwise the user’s general preference is sent (if any).

A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A pair of values A and X match if and only if one of the following is true:

• either A or X is "*";
• A and X are the same string;
• A has the form '*.domain' and X is 'domain' or is of the form 'string.domain', where 'string' is any sequence of characters.

For example, a user might grant an exception for metrics.example.net to track their activity on news.example.com and weather.example.com, but not on medical.example.org. If the document at http://news.example.com/news/story/2098373.html has embedded references to http://metrics.example.net/1x1.gif and http://weather.example.com/widget.js, the site domain for those references is news.example.com and the target domains are metrics.example.net and weather.example.com, respectively.

A user agent MAY choose to disregard a user-granted exception when the target resource does not have a corresponding tracking status resource with a valid tracking status representation, since that would imply the target resource does not conform to this specification.

6.5 Revoking an Exception

A site that stores exceptions is also expected to enable revocation of those exceptions. The Navigator.removeTrackingException API can be promise-called by a script to remove all exceptions applicable to that site.

A site MAY monitor for changes to its user-granted exceptions. If a user revokes consent by deleting an exception, the site MUST respect that revocation, though it MAY ask again for a new exception. In other words, a site MUST NOT resurrect a deleted exception without first interacting with and receiving new consent from the user.

6.6 Client-side Scripting API

partial interface Navigator {
    Promise<TrackingExResult> storeTrackingException (
      TrackingExData properties
    );
};
dictionary TrackingExData {
   DOMString? site;
   sequence<DOMString>? targets;
   DOMString? name;
   DOMString? explanation;
   DOMString? details;
   long?      maxAge;
};
dictionary TrackingExResult {
  boolean isSiteWide;
};