Revision of existing double key cookie logic to meet requirements
Complete implementation of what is termed double keying as both 1st party hostname and 3rd party hostname are stored and conditionally used when constructing the Cookie HTTP header.
Adaption to common use cases
Common browsing use cases involving cookies must be supported while protecting against crossdomain tracking violations. This includes travel reservations, shopping carts, surveys, comment providers, approval and rating systems, journalist drop boxes, and (one-time|two-factor) authentication systems.
Allow granular cookie inspection
Fine grained cookie inspection must be enabled through new design of a user interface indexing either 1st or 3rd party URI contexts. This requirement does not specify the UI itself.
3rd party cookie storage
3rd party cookies are stored under the usual conditions, according to the Set-Cookie HTTP header (RFC 6265.) Their storage structure enables 1st party association as a new measure.
3rd party cookie retrieval
3rd party cookies are revealed according to host domain matching (RFC 6265) of 1st party URI contexts. This change mitigates the problem of identification across independent domains.
Legacy cookie behaviour
New 3rd party isolation must not depend on legacy cookie behaviour configuraion network.cookie.cookieBehavior.
The configuration value privacy.thirdparty.isolate influences control of 3rd party cookie transmission. The private browsing channel attribute plays a binary role in enabling transmission but depends on privacy.thirdparty.isolate.
New logic must approximate the logging behaviour of legacy cookie logic.