Intent to Implement: Prefetch Request Changes for Double-Keyed Cache
Dominic Farolino
Contact emails
Explainer
The closest thing we have to an explainer right now are changes proposed on the Resource Hints standard, which outline developer-facing changes that will need to be made to the prefetch requests and the processing mode.
Design doc/Spec
TAG review request: https://github.com/w3ctag/design-reviews/issues/398
Summary
Chromium is implementing, and will ship, a double-keyed HTTP cache which essentially partitions the HTTP cache roughly by the top-frame-origin that a request is made from. Naturally this breaks cross-origin prefetch, whose goal is to prefetch a cross-origin resource and store it into the HTTP cache for later re-use (e.g., navigations).
SplitCache breaks cross-origin prefetch in two ways:
Cross-origin prefetched resources in the HTTP cache cannot be re-used for top-level navigations
Cross-origin prefetched resources in the HTTP cache cannot be re-used as subresources
Due to privacy concerns around cache timing attacks, we’re only interested in preserving the current prefetch behavior for case (1) above. That is, we’ll allow cross-origin prefetched resources in the HTTP cache to be re-used for top-level navigations. Doing so for subresources can leak arbitrary amounts of information across domains, as this proof-of-concept suggests. We believe reusing cross-origin entries for top-level navigations is safe because by navigating, the user is explicitly sharing their interest with the destination site, and timing attacks on cache-reuse would not leak any more information than that. In order to preserve privacy when prefetching, changes must be made to the prefetch processing model.
The developer-facing changes include updating the following properties of prefetch requests (as per the latest proposal):
Redirect mode: “manual” (this is under discussion)
Credentials mode: “same-origin” (currently defaults to “include”)
Referrer policy: “no-referrer” (currently defaults to full referrer)
Service-workers mode: “none” (currently defaults to “all”)
Motivation
This change is positive because SplitCache will force all cross-origin prefetches to cause a double-download (once for the prefetch, and once for the navigation intending to reuse the prefetch), so preserving this behavior is good from a performance perspective. From a privacy perspective, reusing cross-origin prefetches for top-level navigations is deemed safe, and maintaining this behavior is currently blocking Chrome’s plans to roll out a double-keyed cache. As previously mentioned, preserving this behavior for cross-origin subresources has been deemed dangerous.
Risks
Interoperability and Compatibility
We think the interoperability risk is low, because Apple has contributed to the spec discussion and started working on their implementation. Mozilla has also expressed interest. The final spec details are not resolved yet, but multiparty interest in this makes us confident that all vendors will work together to ship these changes.
The compatibility risk is mostly low, but not completely clear. Changing the credentials mode for prefetch requests may cause more cache-misses and therefore double-downloads, however could also introduce a correctness problem if prefetch responses do not have the `Vary: Cookie` header attached when their content actually relies on credentials. In this case, it is possible that a user can navigate (with credentials) to a resource, and the user will be served the uncredentialed response from the HTTP cache. We don’t expect the changes to service-workers mode, referrer policy, and redirect mode to break existing content. It is likely they will cause more cache-misses and double-downloads though.
Edge: No signals
Firefox: Public support (Mozilla standards editor reviewing the PR)
Safari: Public support/In development (GitHub proposal, tracking bug)
Web / Framework developers: Unknown - but the fact that prefetch is used at all indicates developers expect it to keep working
Ergonomics
These changes will work in tandem with the double-keyed cache that will be shipped in Chromium.
Activation
It will not be challenging for developers to start using; we’re interested in preserving existing behavior after changes land that would normally break this behavior.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5280299309072384
Requesting approval to ship?
No.
rek...@gmail.com
And a quarter or so before that happens, some lame PoC attack that leaks information that I still don't grok as at all interesting or of value comes along, and destroys the possibility of running a JS CDN? On the eve of JS modules finally becoming good & performant & cached again?
This feels like a drastic overreaction to an "attack" that doesn't seem like an attack at all. It seems basic & straightforward sensible & expected behavior that we've all known about, handled, & dealt with semi-responsibly for a long time.
If we need more securitization for some resources, cook up a new Content-Security-Policy directive for this niche, irrelevant, tiny little use case that affects almost no one. Don't rewrite the rules of the web. Don't break JS CDNs the quarter before they're about to be viable, now that JS modules are FINALLY modular again.
I'm opposed to this work. This is bad for the web, protecting some very tiny long tail of resources at HUGE opportunity cost to make the web fast efficient & fast. Please do not sabotage JavaScript like this on the very EVE of it becoming good again.
