The DNT Tracking Preference Expression document (TPE) 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 cn be 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 DNT Consent (aka 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.