The TPWG introduced the idea of consent for site-specific or web-wide tracking, with user agents signalling to sites or browser context through the DNT:0 header.
It is doubtful that many informed users would agree to web-wide tracking so it is very important that consent for site-specific tracking can be registered and communicated. This is impossible to achieve in a secure way with simple HTTP cookies because the Cookie header is always transmitted in sub-resource requests.
This has also been recognised by the AdTech community who have come up with the elaborate encoding of data controller identifiers in an HTTP cookie (the IABEU Consent Framework "daisybit" cookie which contains a bit map where the ordinal position indicates if consent has been given to a particular Vendor Id). This method has to rely on contracted parties agreeing to operational and administrative procedures to not do any tracking, even though the encoded "daisybit" cookie would make a very effective unique identifier in its own right and is available to all parties in the AdTech ecosystem, intrinsically creating a security and privacy risk because there is no way to prove that the identifier is not being used for tracking.
At the end of last year we (TPWG) discussed extending the DNT:0 header to carry an arbitrarily encoded field to carry e.g. purpose information. This would naturally enforce the secure signalling of site-specific consent because the DNT:0 header would only be sent to sub-resources for which the user had given their consent (only in the context of a particular site in the case of site-specific consent). The arbitrary field value could be used to carry a unique id or audience information which could be guaranteed to
only be received by the consented-to set, and HTTP cookies would not need to be used by the parties.
Another way to achieve limiting tracking to a site-specific context would for user agents to support double-keyed cookies (Aleecia talked about this many moons ago).
This has effectively been introduced somewhat in Safari's Intelligent Tracking Prevention (ITP) mechanism. After a cookie has been placed by a third-party sub-resource for longer than 24 hours it becomes "partitioned" i.e. will only be sent in the context of the top-level site where it was
placed. This has recently been extended https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/ with a Storage Access API https://webkit.org/blog/8124/introducing-storage-access-api/ and other
associated changes.
It might be useful if we established a bridge with the WebKit ITP work and jointly produced a document that standardised these "partitioned" aka "double-keyed" cookies.
My thoughts so far is for a response header from a top-level site that could either allow the status quo (no partitioning), immediately force partitioning of all cookies placed by sub-resources, or to force
partitioning but specify a subset whose members are allowed to create non-partitioned cookies.
For example this could be a new Policy "web-wide-state" for the Feature-Policy header.
Feature-Policy: web-wide-state 'none';
This would stop all nested browsing contexts or embedded sub-resources placing non-partitioned cookies, i.e. any third-party cookies placed would be immediately partitioned.
Feature-Policy: web-wide-state https://example.com;
This could allow a particular third-party to create non-partitioned i.e. normal cookies, while all others are partitioned.
Feature-Policy: web-wide-state *;
This would allow all sub-resources to create non-partitioned cookies, which could also be the default if a "web-wide-state" Policy was not present. Particular browsers, e.g. Safari, could set the default to their own privacy oriented mechanism such as ITP.
First-party determined partitioned cookies would complement DNT by giving sites a simple way to
enforce site-specific consent. The site can generate the appropriate Feature-Policy header after examining either the DNT:0 field-value or a first-party cookie. In either case the set of consented-to parties could be conveyed using the "daisybit" encoding, or any other encoding.
Other user-agent storage i.e. localStorage, IndexedDB etc. could also be similarly partitioned (they are already partitioned by default in Safari & Edge), and controlled via the same FP header.
The TPWG introduced the idea of consent for site-specific or web-wide tracking, with user agents signalling to sites or browser context through the DNT:0 header. It is doubtful that many informed users would agree to web-wide tracking so it is very important that consent for site-specific tracking can be registered and communicated. This is impossible to achieve in a secure way with simple HTTP cookies because the Cookie header is always transmitted in sub-resource requests.
This has also been recognised by the AdTech community who have come up with the elaborate encoding of data controller identifiers in an HTTP cookie (the IABEU Consent Framework "daisybit" cookie which contains a bit map where the ordinal position indicates if consent has been given to a particular Vendor Id). This method has to rely on contracted parties agreeing to operational and administrative procedures to not do any tracking, even though the encoded "daisybit" cookie would make a very effective unique identifier in its own right and is available to all parties in the AdTech ecosystem, intrinsically creating a security and privacy risk because there is no way to prove that the identifier is not being used for tracking.
At the end of last year we (TPWG) discussed extending the DNT:0 header to carry an arbitrarily encoded field to carry e.g. purpose information. This would naturally enforce the secure signalling of site-specific consent because the DNT:0 header would only be sent to sub-resources for which the user had given their consent (only in the context of a particular site in the case of site-specific consent). The arbitrary field value could be used to carry a unique id or audience information which could be guaranteed to only be received by the consented-to set, and HTTP cookies would not need to be used by the parties.
Another way to achieve limiting tracking to a site-specific context would for user agents to support double-keyed cookies (Aleecia talked about this many moons ago).
This has effectively been introduced somewhat in Safari's Intelligent Tracking Prevention (ITP) mechanism. After a cookie has been placed by a third-party sub-resource for longer than 24 hours it becomes "partitioned" i.e. will only be sent in the context of the top-level site where it was placed. This has recently been extended https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/ with a Storage Access API https://webkit.org/blog/8124/introducing-storage-access-api/ and other associated changes.
It might be useful if we established a bridge with the WebKit ITP work and jointly produced a document that standardised these "partitioned" aka "double-keyed" cookies.
My thoughts so far is for a response header from a top-level site that could either allow the status quo (no partitioning), immediately force partitioning of all cookies placed by sub-resources, or to force partitioning but specify a subset whose members are allowed to create non-partitioned cookies.
For example this could be a new Policy "web-wide-state" for the Feature-Policy header.
Feature-Policy: web-wide-state 'none'; This would stop all nested browsing contexts or embedded sub-resources placing non-partitioned cookies, i.e. any third-party cookies placed would be immediately partitioned.
Feature-Policy: web-wide-state https://example.com; This could allow a particular third-party to create non-partitioned i.e. normal cookies, while all others are partitioned.
Feature-Policy: web-wide-state *; This would allow all sub-resources to create non-partitioned cookies, which could also be the default if a "web-wide-state" Policy was not present. Particular browsers, e.g. Safari, could set the default to their own privacy oriented mechanism such as ITP.
First-party determined partitioned cookies would complement DNT by giving sites a simple way to enforce site-specific consent. The site can generate the appropriate Feature-Policy header after examining either the DNT:0 field-value or a first-party cookie. In either case the set of consented-to parties could be conveyed using the "daisybit" encoding, or any other encoding.
Other user-agent storage i.e. localStorage, IndexedDB etc. could also be similarly partitioned (they are already partitioned by default in Safari & Edge), and controlled via the same FP header.