Intent to Ship: Partitioning cross-site top-level navigations in the HTTP cache

[Andrew Williams]

Contact emails

mike...@chromium.org, awi...@chromium.org

Explainer

HTTP cache partitioning in general is covered by https://github.com/shivanigithub/http-cache-partitioning, and this proposal extends partitioning to navigations. This I2S and the linked resources discuss the partitioning scheme changes and the specific attack scenarios that are mitigated.

Specification

https://fetch.spec.whatwg.org/#http-cache-partitions

Summary

Chrome’s HTTP cache keying scheme will be updated to include an “is-cross-site-main-frame-navigation” boolean to mitigate cross-site leak attacks involving top-level navigation. 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.

For an overview of the attacks mitigated by the “is-cross-site-main-frame-navigation” boolean, see:

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

 - https://docs.google.com/presentation/d/1StMrI1hNSw_QSmR7bg0w3WcIoYnYIt5K8G2fG01O0IA/edit?usp=sharing 

Blink component

Internals>Network>Cache

TAG review

HTTP cache partitioning was originally reviewed in https://github.com/w3ctag/design-reviews/issues/424. We did not submit for a new TAG review since cache partitioning standardization hasn’t changed much since then, and since it’s unclear whether there’s support for updating standards to partitioning by more than just top-level site.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interop risk: We do not expect compatibility impacts here since the behavior is not web-visible (other than affecting navigation completion times), and our earlier 1% experiment didn’t indicate any significant changes to performance as a result of this. Regarding interop, Safari and Firefox currently ship partitioned HTTP caches but with different partitioning schemes that don’t partition navigations differently from other network requests.

Gecko: https://github.com/mozilla/standards-positions/issues/1177

WebKit: https://github.com/WebKit/standards-positions/issues/462

Web developers: No signals

Other signals:

WebView application risks:
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No - cache partitioning is not enabled for WebView

Debuggability

Partition keys are visible in net logs, and whether something was served from the HTTP cache is visible in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No, it will be supported on all platforms except WebView, which does not currently partition its HTTP cache.

Is this feature fully tested by web-platform-tests?

No, this isn’t web visible.

Flag name on chrome://flags

None

Finch feature name

SplitCacheByCrossSiteMainFrameNavigationBoolean

Requires code in //chrome?

False

Launch bug

https://launch.corp.google.com/launch/4345002

Estimated milestones

Shipping on desktop	135
Shipping on Android	135

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

The spec already leaves the HTTP cache key as implementation-defined apart from partitioning by top-level site. It's unclear whether other browsers support standardizing any portion of what we are shipping.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5190577638080512

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkV1oQg2cc_MWW_RtG9de%3DVk2i1rUv8MrQ49GV0yWZwy_w%40mail.gmail.com

[Yoav Weiss (@Shopify)]

Thanks for pushing this!

On Monday, February 24, 2025 at 8:04:31 PM UTC+1 Andrew Williams wrote:

Contact emailsmike...@chromium.org, awi...@chromium.org

Explainer

HTTP cache partitioning in general is covered by https://github.com/shivanigithub/http-cache-partitioning, and this proposal extends partitioning to navigations. This I2S and the linked resources discuss the partitioning scheme changes and the specific attack scenarios that are mitigated.

Specificationhttps://fetch.spec.whatwg.org/#http-cache-partitions

The spec doesn't seem to indicate any of this logic (nor does it include triple keying AFAIU).

I don't think it's a blocker, but it'd be nice to get cross-implementer alignment on the strategy here, or barring that, add UA-defined conditions.

 

SummaryChrome’s HTTP cache keying scheme will be updated to include an “is-cross-site-main-frame-navigation” boolean to mitigate cross-site leak attacks involving top-level navigation. 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.

For an overview of the attacks mitigated by the “is-cross-site-main-frame-navigation” boolean, see:

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

 - https://docs.google.com/presentation/d/1StMrI1hNSw_QSmR7bg0w3WcIoYnYIt5K8G2fG01O0IA/edit?usp=sharing 

Do I understand correctly that this will prevent "Attack 1" and "Attack 2", but "Attack 3" is already mitigated by triple keying?

While attack 1 is clear, I'm not sure how come attack 2 isn't mitigated by the fact that a.com/img is already partitioned. 

Blink componentInternals>Network>Cache
TAG reviewHTTP cache partitioning was originally reviewed in https://github.com/w3ctag/design-reviews/issues/424. We did not submit for a new TAG review since cache partitioning standardization hasn’t changed much since then, and since it’s unclear whether there’s support for updating standards to partitioning by more than just top-level site.

TAG review statusNot applicable
Risks

Interoperability and CompatibilityInterop risk: We do not expect compatibility impacts here since the behavior is not web-visible (other than affecting navigation completion times), and our earlier 1% experiment didn’t indicate any significant changes to performance as a result of this. Regarding interop, Safari and Firefox currently ship partitioned HTTP caches but with different partitioning schemes that don’t partition navigations differently from other network requests.

Gecko: https://github.com/mozilla/standards-positions/issues/1177
WebKit: https://github.com/WebKit/standards-positions/issues/462
Web developers: No signals
Other signals:

WebView application risks:
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?No - cache partitioning is not enabled for WebView

DebuggabilityPartition keys are visible in net logs, and whether something was served from the HTTP cache is visible in DevTools.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No, it will be supported on all platforms except WebView, which does not currently partition its HTTP cache.
Is this feature fully tested by web-platform-tests?No, this isn’t web visible.

Flag name on chrome://flagsNone
Finch feature nameSplitCacheByCrossSiteMainFrameNavigationBoolean
Requires code in //chrome?False

Launch bughttps://launch.corp.google.com/launch/4345002

Estimated milestones

Shipping on desktop

135

Shipping on Android

135

Anticipated spec changesOpen questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).The spec already leaves the HTTP cache key as implementation-defined apart from partitioning by top-level site. It's unclear whether other browsers support standardizing any portion of what we are shipping.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5190577638080512

[Andrew Williams]

Thanks for taking a look Yoav, replying inline below

On Tue, Feb 25, 2025 at 2:55 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Thanks for pushing this!

On Monday, February 24, 2025 at 8:04:31 PM UTC+1 Andrew Williams wrote:

Contact emailsmike...@chromium.org, awi...@chromium.org
Explainer

HTTP cache partitioning in general is covered by https://github.com/shivanigithub/http-cache-partitioning, and this proposal extends partitioning to navigations. This I2S and the linked resources discuss the partitioning scheme changes and the specific attack scenarios that are mitigated.

Specificationhttps://fetch.spec.whatwg.org/#http-cache-partitions

The spec doesn't seem to indicate any of this logic (nor does it include triple keying AFAIU).

I don't think it's a blocker, but it'd be nice to get cross-implementer alignment on the strategy here, or barring that, add UA-defined conditions.

"Determine the HTTP cache partition" uses the "Determine the network partition key" algorithm, which is where double-keying is defined and triple-keying is supported but left as "implementation-defined": https://fetch.spec.whatwg.org/#determine-the-network-partition-key. There is a corresponding issue containing discussions on moving this forward, and I left a comment there recently to try and rekindle those conversations but haven't heard anything back from other implementers yet: https://github.com/whatwg/fetch/issues/1035#issuecomment-2658239821

 

 

SummaryChrome’s HTTP cache keying scheme will be updated to include an “is-cross-site-main-frame-navigation” boolean to mitigate cross-site leak attacks involving top-level navigation. 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.

For an overview of the attacks mitigated by the “is-cross-site-main-frame-navigation” boolean, see:

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

 - https://docs.google.com/presentation/d/1StMrI1hNSw_QSmR7bg0w3WcIoYnYIt5K8G2fG01O0IA/edit?usp=sharing 

Do I understand correctly that this will prevent "Attack 1" and "Attack 2", but "Attack 3" is already mitigated by triple keying?

While attack 1 is clear, I'm not sure how come attack 2 isn't mitigated by the fact that a.com/img is already partitioned. 

Neither "Attack 2" nor "Attack 3" are prevented by triple-keying because for navigations the top-level site and frame site are computed solely based on the URL being navigated to. As an example, a navigation to 'a.com/url' will have top-level site and frame site of 'a.com', and these three keys will be the same as for 'a.com/url' being loaded as a resource from an 'a.com' top-level document. Attack 3 is prevented today by a separate boolean used in the cache key that is set to true for all subframe navigations. There isn't a similar mitigation for Attack 2 today, but this is what the "is-cross-site-main-frame-navigation" boolean addresses.

[Mike Taylor]

On 2/25/25 2:55 AM, Yoav Weiss (@Shopify) wrote:

Thanks for pushing this!

On Monday, February 24, 2025 at 8:04:31 PM UTC+1 Andrew Williams wrote:

Contact emailsmike...@chromium.org, awi...@chromium.org
Explainer

HTTP cache partitioning in general is covered by https://github.com/shivanigithub/http-cache-partitioning, and this proposal extends partitioning to navigations. This I2S and the linked resources discuss the partitioning scheme changes and the specific attack scenarios that are mitigated.

Specificationhttps://fetch.spec.whatwg.org/#http-cache-partitions

The spec doesn't seem to indicate any of this logic (nor does it include triple keying AFAIU).

I don't think it's a blocker, but it'd be nice to get cross-implementer alignment on the strategy here, or barring that, add UA-defined conditions.

Triple-keying should be covered by https://fetch.spec.whatwg.org/#determine-the-network-partition-key (see "an implementation-defined value). There's ongoing discussion in https://github.com/whatwg/fetch/issues/1035 as well.

A TPAC or three ago we had some conversations in on this topic, and IMO there is interest in perhaps converging on the perfect design one day, but I don't see cross-implementer alignment on a single keying scheme coming any time soon. I think gsnedders also makes a good point in the fetch issue that experimentation on keying schemes by UAs for different modes is also useful to consider.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e9fd7e0-87ba-4a07-ba77-2d4178ca881b%40chromium.org.

[Domenic Denicola]

LGTM2.

I'm saddened by the way the implementer community has not been able to converge upon and specify a unified keying scheme, but I agree we shouldn't block further improvements on that, since none of the browsers seem to be making movements toward such alignment. I appreciate that you pinged the relevant thread to see if there's any movement.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Taylor]

FYI, it looks like WebKit is trending supportive on this change: https://github.com/WebKit/standards-positions/issues/462#issuecomment-2693662676

[Alex Russell]

LGTM3

[Andrew Williams]

Thanks everyone! We've flipped the feature flag for this to be enabled by default, and the functionality will roll out in M136. 🎉

-Andrew 

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.