Thoughts on site-specific consent, ITP etc.

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.

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 https://example.com;

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:
Feature-Policy: web-wide-state *;
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.

Received on Monday, 2 April 2018 14:13:58 UTC