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

Open
arthuredelstein opened this Issue Oct 12, 2016 · 6 comments

Projects

None yet

5 participants

@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 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
@mikewest
Member

Thanks!

@martinthomson
Contributor

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
Contributor
mnot commented Nov 23, 2016
@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.

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