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://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.
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.
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.
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.
LGTM3On Sun, Oct 4, 2020 at 1:07 PM Yoav Weiss <yo...@yoav.ws> wrote:LGTM2On 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.