Intent to Implement: Prefetch Request Changes for Double-Keyed Cache

413 views
Skip to first unread message

Dominic Farolino

unread,
Jul 30, 2019, 4:12:50 AM7/30/19
to blink-dev, Kinuko Yasuda, Yutaka Hirano, Shivani Sharma, Josh Karlin, Yoav Weiss

Contact emails

d...@chromium.org


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:

  1. Cross-origin prefetched resources in the HTTP cache cannot be re-used for top-level navigations

  2. 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):


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

unread,
Jul 30, 2019, 3:38:04 PM7/30/19
to blink-dev
So import-maps is FINALLY somewhere near shipping, and thus javascript modules are FINALLY about to become modular again (reusable across sites).

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.

Dominic Farolino

unread,
Jul 30, 2019, 8:50:31 PM7/30/19
to blink-dev
I think you're misunderstanding this intent. The work described here is making more things (cross-origin prefetch) work in light of a double-keyed cache. It is not about the implementation or motivation of the cache itself, that you're against. There will be an intent/PSA regarding the double-keyed cache implementation soon, where you can voice your concerns.

domfa...@google.com

unread,
Aug 7, 2019, 11:11:30 AM8/7/19
to blink-dev, kin...@chromium.org, yhi...@chromium.org, shiva...@chromium.org, jka...@chromium.org, yoav...@chromium.org
Firefox: Public support (Mozilla standards editor reviewing the PR)

While talking with annevk on IRC, an important correction is that there is actually no public support from Mozilla on this at the moment. We'll have to file an issue on their standards-positions to get official feedback. The review of the PR is not direct endorsement.

huan...@google.com

unread,
Sep 8, 2019, 3:05:45 PM9/8/19
to blink-dev, kin...@chromium.org, yhi...@chromium.org, shiva...@chromium.org, jka...@chromium.org, yoav...@chromium.org
Please consider having a tracking bug so we can have a privacy review:)

Dominic Farolino

unread,
Sep 16, 2019, 2:10:31 AM9/16/19
to blink-dev, kin...@chromium.org, yhi...@chromium.org, shiva...@chromium.org, jka...@chromium.org, yoav...@chromium.org
Yep sorry, the bug is here: http://crbug.com/988956. Must've forgotten to include it in this email. Understanding the exact changes we'll need to make to prefetch requests is still early-stage. See https://github.com/kinu/speculative-loading for some thoughts on the speculative loading threat model in general, and some mitigations.
Reply all
Reply to author
Forward
0 new messages