Partitioning cross-site top-level navigations in the HTTP cache

[recvfrom]

Specification title

Partitioning cross-site top-level navigations in the HTTP cache

Specification or proposal URL (if available)

No response

Explainer URL (if available)

No response

Proposal author(s)

@recvfrom

MDN URL

No response

Caniuse.com URL

No response

Bugzilla URL

No response

Mozillians who can provide input

No response

WebKit standards-position

No response

Other information

Chrome is planning to ship an update to its HTTP cache keying scheme that will include an “is-cross-site-top-level-navigation” boolean to mitigate cross-site leak attacks involving top-level navigations. Specifically, this will prevent cross-site attacks in which an attacker can initiate a top-level navigation to a given page and then navigate to a resource known to be loaded by the page in order to infer sensitive information via load timing. This change also improves privacy by preventing a malicious site from using navigations to infer whether a user has visited a given site previously. More information on this attack can be found at: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass

From a standards perspective, the spec calls for partitioning the HTTP cache by at least top-level site, but partitioning beyond that is implementation-defined. The relevant parts of the spec are:

• https://fetch.spec.whatwg.org/#determine-the-network-partition-key
• https://fetch.spec.whatwg.org/#http-cache-partitions

IIUC, all browsers do partition by top-level site [1][2], but there hasn't been much recent progress on standardizing beyond that. Some existing differences I'm aware of:

• Chrome also partitions by frame site and an "is-subframe-navigation" boolean
• Firefox also partitions using an "is-cross-origin-fetch" boolean [3]

I've left a comment about this in whatwg/fetch#1035 (comment), but opening this as well to get a formal standards position. Thanks!

[1] https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#network_partitioning
[2] https://webkit.org/tracking-prevention/#partitioned-third-party-http-cache
[3] https://hg.mozilla.org/mozilla-central/rev/94ed4d6361b3

[tomrittervg]

@bvandersloot-mozilla

[valenting]

https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass

For this specific attack I would have expected that the solution is to immediately change the origin of the opened window, before we actually check the HTTP cache? I assume there are "good" (this is how DOM needs to work) reasons for this, but if not, it would be good to try to change that.

Apart from the above, I think we're generally not against introducing additional flags into the HTTP cache key, especially if it's part of the Fetch standard.

[recvfrom]

Thanks for the feedback @valenting!

For this specific attack I would have expected that the solution is to immediately change the origin of the opened window

Addressing the timing side channels that allow for carrying out these XS leak attacks is indeed another way to go about mitigating them, but from talking with security folks within Google the thinking is that it can be difficult to mitigate them all (especially if the mitigations might involve behavior changes that could result in breakage) and it's also challenging to prevent new ones from being introduced as the web platform evolves. As a result, our focus has been on addressing the caching behavior that makes specific attacks possible.