Intent to Ship: Partition the HTTP cache

[Shivani Sharma]

Contact emails

shiva...@chromium.org, jka...@chromium.org  

Explainer

https://github.com/shivanigithub/http-cache-partitioning (includes impact on metrics)

Spec

Fetch Spec:

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

https://fetch.spec.whatwg.org/#network-partition-keys

HTML Spec:

https://github.com/whatwg/html/pull/4966 and https://github.com/whatwg/html/pull/5491

TAG review:

https://github.com/w3ctag/design-reviews/issues/424

(Resolution: satisfied)

Summary

The HTTP cache is currently one-per-profile, with a single namespace for all resources regardless of origin or renderer process. This opens the browser to a side-channel attack where one site can detect if another site has loaded a resource by checking if it’s in the cache.

This feature will partition the HTTP cache using top frame and the subframe sites (scheme://eTLD+1) to prevent documents from one site from knowing if a resource from a cross-site document load was cached or not. 

Motivation

Cache attacks have been exploited for the following:

Detect if a user has visited a specific site: If the cached resource is specific to a particular site or to a particular cohort of sites, an adversary can detect the user's browsing history by checking if the cache has that resource.

Cross-site search attack: There exist cross site search attack proofs-of-concept which exploit the fact that some popular sites load a specific image when a search result is empty. By opening a tab and performing a search and then checking for that image in the cache, an adversary can detect if an arbitrary string is in the user’s search results.

Tracking: In addition to the above cache attacks, the cache can also be used to store cross-site super-cookies as a cross-site tracking mechanism. To clear them the user has to delete their entire cache (not just a particular site). Since fingerprinting is neither transparent nor under the user’s control, it results in tracking that doesn’t respect user choice.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/6KKXv1PqPZ0/m/3_1nYzrBBAAJ?pli=1

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Risks

Mozilla has started the implementation and Safari has long since implemented a variant of it by using top-frame eTLD+1 to partition the cache. This is the github issue with inputs from various browsers.

Firefox: Public support

Edge: No public signals

Safari: Public support

Web developers: This is not a breaking change, but it will have performance considerations for some organizations. For instance those that serve large volumes of highly cacheable resources across many sites (e.g., fonts and popular scripts). This needs to be balanced with the privacy and security concerns and the fact that sites often use different versions of popular libraries, reducing the benefits of such caching. It’s also worth reiterating that Safari partitioned its cache eight years ago and that Firefox is working on it as well.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/external/wpt/fetch/http-cache/split-cache.html

https://wpt.fyi/results/fetch/http-cache/split-cache.html?label=experimental&label=master&aligned

Entry on the feature dashboard

https://chromestatus.com/feature/5730772021411840

Rollout Info

As this is a significant change, we intend to roll it out gradually starting in Chrome M85. We will monitor for performance regressions as we ramp up.

[Domenic Denicola]

It's extremely exciting to see that this has reached ready-to-ship stage. It's a big step forward for protecting our users.

I want to chime in here with support for the excellent spec work Shivani has done, including collaboration with the HTML and Fetch spec editors. Instead of treating this as a non-breaking, mostly-unobservable change, she seriously engaged with the standards communities here to provide a rigorous spec update that outlines exactly how this works. This has in turn contributed to larger efforts to better define third-party and first-party content across the web specification ecosystem, which will pay many dividends going forward.

There remains room for improved interop on the exact nature of the partitioning key. (We use top-frame + subframe sites; Safari's uses only top-frame eTLD+1; Mozilla has proposed top-frame + second-level-frame sites.) But there is an explicit carveout for some of this variance in the spec, with the intention of tightening it up over time through discussion and as implementations experiment and ship, tracked at https://github.com/whatwg/fetch/issues/1035. Moving forward to ship our current proposal seems like the right move.

[Daniel Bratell]

LGTM1

I am happy to see this change coming. The main concern was performance but the investigations seems to show that for the average user and site, the change will not be noticed. For a few users and sites, there might be a performance[1] or data usage impact, but weighing that against the security and privacy benefits results in a net positive.

I'm also not concerned about "only-if-cached" requests since this follows Safari's partitioning (though slightly more strict) and they will not have worked for cross-site cache populating already.. I looked through github for scripts using it, and they exist but it's mostly testcases and comments. Little code that seems associated with real web sites/embedded apps. You might want to take an extra look since you know more about the area to be even more certain.

/Daniel

[1]: For some it may be a win since not all resources load faster from cache than from the network.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0_u-9o0-bavj4frCyzgaq2aVLyG6Lb_EbWOpynwKDwXWw%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cfe0762-8fd9-9c57-f1fa-8747c66e80e5%40gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjVG-sGKQtbZB%2B0f337nRi0wREecujCALP48BhfeoKt0g%40mail.gmail.com.

[Shivani Sharma]

Thanks all!

On Sun, Oct 4, 2020 at 7:23 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

On Sun, Oct 4, 2020 at 1:07 PM Yoav Weiss <yo...@yoav.ws> wrote:

LGTM2

On Sat, Oct 3, 2020 at 11:57 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM1

I am happy to see this change coming. The main concern was performance but the investigations seems to show that for the average user and site, the change will not be noticed. For a few users and sites, there might be a performance[1] or data usage impact, but weighing that against the security and privacy benefits results in a net positive.

I'm also not concerned about "only-if-cached" requests since this follows Safari's partitioning (though slightly more strict) and they will not have worked for cross-site cache populating already.. I looked through github for scripts using it, and they exist but it's mostly testcases and comments. Little code that seems associated with real web sites/embedded apps. You might want to take an extra look since you know more about the area to be even more certain.

That’s a good point, I have added the analysis of error code ERR_CACHE_MISS (which is returned for "only-if-cached" cases if there's a cache miss) in the explainer and will continue to look at it as the feature expands to more users.