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.
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.
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.
DNT-identifier. This is a user agent generated on-line identifier ("publisher ID") initiated by a call to the API
and denoted by i= followed by a hexadecimal encoded bit string.
The value of the bit string should be calculated by obtaining a cryptographic quality random number as described in section 4.5 of [[RFC4122]] for the 47 bit UUID node. It is important that no information about the client is leaked i.e. the identifier should not be derived from an IEEE MAC address.
An identical identifier will be inserted into requests to consented-to embedded third-parties i.e. origin servers "targets" referenced by the descendant browsing contexts of this origin server where the DNT field value is "0".
For example, the origin servers for the first-party site would receive
DNT:0&i=1f54acef29indicating the on-line identifier (Publisher ID).
While the origin servers for the consented-to embedded third-parties would receive
DNT:0&i=1f54acef29&tindicating the same value for on-line identifier, and indicating this request is being sent to a target.
DNT-target.
When included in a DNT:0 header this indicates that the request is to an embedded third-party sub-resource,
and that a DNT site-specific Exception for this target has been granted.
This extension should not be present within a DNT:1 header and MUST be ignored if it is.
DNT-information.
When included in a DNT:0 header this indicates information given to third-party sub-resources by the first-party site.
For example, this could indicate the advertiser relevant audience category of the current user.
The value is a length restricted string of no more tan 5 visible characters.
This is to reduce the bit length (entropy) to minimise its use as a unique user identifier.
This extension should not be present within a DNT:1 header and MUST be ignored if it is.
DNT-revoked. When included in a DNT:1 header this indicates that a previous DNT:0 consent indication has been revoked by the user agent.
Invoking either the storeWebWideTrackingException or storeWebWideTrackingException JavaScript functions in the origin server's browsing context
will result in the removal of this qualifier. The qualifier will also be removed after the original Tracking Consent has expired.
This qualifier can be used by an origin server to adjust its behaviour on receipt of DNT:1. For example it could decide not initiate another request for consent when the user has already revoked it.
This qualifier has no meaning if it is in a DNT:0 header and in that case MUST be ignored.
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
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.
Cookie:$DNT=0&i=1f54acef29&r
The [[tracking-dnt]]] JavaScript API is enhanced in the following ways:
navigator.storeSiteSpecificTrackingException function will return a Promise resolving to an object TrackingStatusObject.
partial interface Navigator {
Promise<TrackingStatusObject>
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.
};