[6265bis] Add double-keying policy example to "Third-party cookies" section #248

arthuredelstein opened this Issue Oct 12, 2016 · 6 comments


None yet

5 participants


Firefox and Tor Browser are introducing an option to "double-key" cookies by (origin-domain|first-party-domain). (The first-party domain is defined as domain of the top-level document, visible to the user as the domain in the URL bar at the top of the browser.)

With double keying, it is possible for third-party cookies to be stored and retrieved, these third-party cookies cannot be used for tracking across websites.

I think this policy is notable in that it keeps third-party cookies enabled but also prevents tracking. Thus third-party cookies function properly for many use cases. I would like to suggest adding this policy to the discussion of examples in RFC6265 section 7.1, "Third-party cookies." After the sentence,

Others refuse to process the Set-Cookie header in responses to third-party requests.

it might be of helpful to add something like

Still others store third-party cookies loaded by different first-party domains into separate cookie databases, to prevent cross-site tracking.

@mikewest mikewest added the 6265bis label Oct 12, 2016
@mikewest mikewest self-assigned this Oct 12, 2016
@mikewest mikewest added the editorial label Oct 12, 2016



Better than that, in Firefox we have the ability to segment/compartmentalize based on user categorization of tabs (which uses the same underlying mechanism, which we call origin attributes; "extended origin" was already taken).

That means that there are multiple criteria that we might use to partition cookies: primary origin, top-level browsing context origin, "container", user profile, etc... Maybe this needs to be a even more generic:

Clients might refuse to process cookies or segregate cookies based on context. This might be done to prevent correlation of requests between separate contexts. For instance, cookies sent to a browser in a third-party context might be separated based on the first-party context.

(Your words are likely to be better here.)


It would be useful to have an attribute in the Set-Cookie header so origins can specify double keying if the user agent supports it.

Set-Cookie: {name}={value};doubleKeyed;hhpOnly etc....



Set-Cookie: {name}={value};doubleKeyed;httpOnly;secure etc....

mnot commented Nov 23, 2016

Actually, after thinking about it, it's not the same.

The SameSite attribute says only send this cookie in a request when it is same origin as the top-level browsing context - effectively the server is asking for a "third-party cookie block" for this cookie.

I was thinking of the doubleKeyed cookie idea where there is a separate cookie store for the parent contexts, which would allow a lot of functionality but mitigate cross-origin tracking. If this supported as a user option in the UA why not extend it as a server option also allowing sites to help protect user's privacy.

Maybe there is a halfway house where you could constrain sending back cookies to same context i.e. the chain of descendent origins is the same as when the cookie was stored

is not "same context" as
other-toplevel.com->cookiedwidgit.com etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment