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

[arthuredelstein]

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]

Thanks!

[martinthomson]

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.)

[michael-oneill]

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....

[michael-oneill]

Woops

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

[mnot]

Isn't that effectively what SameSite is?

http://httpwg.org/http-extensions/draft-ietf-httpbis-cookie-same-site.html

[michael-oneill]

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

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

[mikewest]

I'll add in the editorial note discussed above in an upcoming -02 draft.

@michael-oneill: I don't intend to define a DoubleKeyed attribute in this round of edits, as it's not clear to me what value it would actually provide for developers. If you think it's something we ought to implement, I'd suggest sketching out an explainer document in a little more detail so we have a concrete problem we can discuss. :)

[arthuredelstein]

Looks great. Thanks!