This is a proposal for new [[tracking-dnt]] building-blocks to improve the usability and verifiability of consent based tracking.


The [[tracking-dnt]] allows for the registration and communication of site-specific consent, but there is no verifiable or transparent way to implement this using HTTP cookies. Although servers can stop using UID cookies when the DNT:1 header exists (or in Europe if the DNT:0 header does not exist), any server receiving DNT:0 could theoretically store a UID which then would be capable of tracking the use across the entire web.

This is because the current specification for HTTP cookies does not differentiate between first-party and third-party accesses. Irrespective of context, once a cookie is associated with a particular origin then it will be communicated in all requests to that origin. The same third-party sub-resources are often embedded on very many separate websites so once such a “third-party” cookie is stored it can be used to report on subsequent visits to any of these websites.

This bug in the specification of HTTP cookies was the "original sin" that led to the explosion of invisible user cross-origin tracking.

To mitigate the risk of this, some browsers allow the user to set the browser to restrict the storage of, or block, some “third-party” cookies, but this is both inadequate as a privacy measure and can seriously diminish the capabilities of the web platform. Not only can third-party cookie blocking break applications such as federated login or the use of localStorage for non-identifying audience categorization, it is easily circumvented through the inclusion of third-party script on first-party sites. This script can use standard APIs to arrange for values encoded in first-party cookies to be embedded in URIs and communicated to third-party servers by dynamic element creation. These values can then be correlated with those on other first-party sites by linking them with third-party cookies (“cookie syncing”). Also, it is very easy to bypass partial third-party cookie blocking, such as the Safari "only visited" option, via first-party link redirection, so that the browser is fooled into seeing the request as a first-party one, unable to detect that the cookie use is in fact by a third-party.

What is needed is for an efficient way to communicate a tracking identifier amongst a group of origins but only within the context of a first-party site.

There has been talk of "double keyed" cookies, the ability to segregate sub-resource cookies into first-party scoped cookie stores, but while there is some activity in Mozilla on this, e.g. the recent work on containers , it has not yet become a W3C issue. There is some discussion about referring to them in the upgrade to the IETF cookie standard (RFC 6265bis).

The proposed e-Privacy Regulation requires that user consent be obtained before the "use of processing and storage capabilities of terminal equipment and the collection of information from end-users’ terminal equipment, including about its software and hardware". There are exception to usage solely necessary for fulfilling a service requested by the user, for carrying out the basic transmission, or for "web audience measuring, provided that such measurement is carried out by the provider of the information society service requested by the end-user". In addition there is now explicit obligations on software (e.g. browser) providers to "offer the option to prevent third parties from storing information on the terminal equipment of an end-user or processing information already stored on that equipment".

The new obligations on browsers to obtain, register and communicate consent, together with taking an active role in safeguarding users’ data, creates an opportunity to introduce a form of double-keyed identifier, tied to browser managed user consent. This identifier can be carried in an extension to the DNT header, but it would exist only when the user has given consent, i.e. when the DNT value’s first character is “0”. The browser would be responsible for creating the value so it could not be used for arbitrary cross-origin tracking on its own. There would be no need for “cookie syncing”, or in fact any use of HTTP cookies, because the same browser managed value would be sent in the DNT header only to the named third-party resources the user has agreed to, and only in the context of the controlling first-party site. Third-parties can prove they are respecting users' site-specific consent by only relying on this method, and avoiding the use of HTTP cookies which may in any case be blocked.

Publisher (or Advertiser) ID

This is a unique user identifier which is associated with a first-party site when a site-specific DNT exception is granted, following the invocation of a particular variant of the Exception API.

The Publisher ID is only communicated to its associated first-party site and the specifically named third-party sub-resources accessed in the context of the associated first-party site. This gives explicitly trusted advertisers a cross-origin on-line identifier to single-out the user without the need for "cookie syncing", while giving more control to the user.

It is transmitted only as an extension to a DNT:0 header (readable by script via navigator.doNotTrack), and the identifier is erased when the DNT Exception expires or is revoked.

When a request is sent to an embedded sub-resource target (i.e. it's domain is included in the relevant arrayOfDomainStrings property ), this is indicated to the receiving server by including a DNT-target DNT extension. This tells the server that it has been given site-specific consent and should not, for example, store a UUID in a persistent HTTP cookie which can be read in the context of other first-party sites.

To discourage the potentially opaque use of other communications channels between a first-party and its embedded third-parties a DNT-information DNT Extension is defined, which can be used for example to communicate the publisher determined audience category of the user. This is restricted to 5 or less visible characters to minimise its potential use as a cross-origin unique identifier.

Because it is tied to explicit user consent (it only exists when DNT is "0"), user-agents would not ordinarily block its use, so it could be available even when full third-party cookie blocking is configured as a general preference.

Extensions to the DNT Header field

The following extensions to the DNT header are proposed. There can be 0 or more extensions each separated by "&" following the DNT header field value. Extensions are determined by the user agent as a result of calls to the extended API described below. If the Do Not Track general preference has not been set and an extension has been specified a DNT header will be inserted without a DNT field value, see the example below.

The extensions are defined formally by the following ABNF

            DNT-field-name  = "DNT"
            DNT-field-value = ( "0" / "1" ) *( LWSP DNT-qualifier "&")
            DNT-qualifier = DNT-identifier / DNT-target / DNT-information / DNT-revoked / DNT-extension
            DNT-identifier   = "i=" 1*(%x30-39 / %x41-46 / %x62-66)
            DNT-revoked   = "r"
            DNT-target   = "t"
            DNT-information   = "a=" 1*5(VCHAR)
            DNT-extension   = ALPHA "=" *(%x21 %x23-25 / %x27-2B / %x2D-3A / %x3C-5B / %x5D-7E) ; first character is lower-case alphanumeric qualifier then rest excludes "&", ";", CTL, SP, DQUOTE, comma, backslash

DNT header extensions via a cookie

If a user agent does not support the ability to encode DNT extensions such as the DNT-identifier or the DNT-permission i.e. navigator.confirmTrackingException is undefined, then the extensions can be delivered in an HTTP cookie. It is envisioned that a JavaScript library emulating the DNT-identifier functionality could be installed on a page to be activated if the required functionality is not implemented by a particular user agent.

To retain transparency and verifiability the cookie should have a standard name $DNT, with the value encoding the DNT-extensions as they would appear in the DNT header. The cookie should only exist when the DNT field value is "0", and MUST be ignored when it is "1". If the user agent does not support the [[tracking-dnt]]] exceptions API then the value of the DNT field value in the $DNT cookie overrides the field value in any DNT header. In this case the $DNT cookie should be stored with an expiry equivalent to that in the exceptions API, and the server MUST respond with a Tk: C header.

Extensions should look like cookie subkeys using the ASP.NET convention.



The [[tracking-dnt]]] JavaScript API is enhanced in the following ways:

            partial interface Navigator {
                    storeSiteSpecificTrackingException (TrackingPermission properties);
            dictionary TrackingStatusObject {
                DomString DNTval; // string value indicating the full DNT header which will  be sent to the first-party and the named targets. 
                                  // This includes the encoded Publisher ID calculated by the user-agent.
            dictionary StoreExceptionPropertyBag {
            DOMString? domain;
            DOMString? siteName;
            DOMString? explanationString;
            DOMString? detailURI;
            DOMString? expires;
            long? maxAge;
            dictionary TrackingPermission : StoreExceptionPropertyBag {
                boolean? trackingId; // true to request a trackingId (i extension will be inserted)
                DOMString information; // a string of no more than 5 characters which the first-party can use to convey information to user-consented embedded sub-resources.
                                       // This can be used for example to communicate a publisher determined audience category for the current user.