Intent to Experiment: Incorporating navigation initiator into the HTTP cache partition key

402 views
Skip to first unread message

Andrew Williams

unread,
Sep 5, 2024, 11:40:55 PMSep 5
to blink-dev, Mike Taylor

Contact emails

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


Explainer

None yet.


Specification

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


Summary


We aim to experiment with utilizing the initiator site when caching the responses of cross-site navigations in the HTTP cache. This experiment is intended to test a potential mitigation for cross-site leak 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. The tested mitigation is also intended as a privacy improvement since it will make it more difficult for a malicious site to use navigations to infer whether a user has visited a given site previously.


Blink component

Internals>Network>Cache


TAG review

Not requested yet.


Risks


Interoperability and Compatibility

We do not expect compatibility impacts here, but there may be some performance implications. Safari and Firefox currently ship some notion of partitioned HTTP caches. We will seek their input once we have a better idea of the tradeoffs between security/privacy and performance.


Gecko: No signal requested yet.


WebKit: No signal requested yet.


Web developers: No 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


Goals for experimentation


We would like to run a 1% stable experiment to understand the performance implications of several approaches to implementing this HTTP cache security improvement. We expect 6 weeks to be sufficient for analysis, beginning in M129, but are requesting permission to run from M129 to M131 inclusive in case we run into any delays.


The approaches we’d like to experiment with are:

  • Adding a boolean value to the HTTP cache key that is set to true for top-level navigations to a URL that is cross-site from the initiator site of the navigation


  • Adding the initiator site into the HTTP cache key for top-level navigations to a URL that is cross-site from the initiator site of the navigation. If the initiator has an opaque origin (for instance, if the initiating page was loaded from a data: URL or is a sandboxed iframe) then no caching of the navigation response will occur.

  • Adding the initiator site into the HTTP cache key for all navigations (including subframe navigations) in the same way as the previous approach. With this scheme we’d also replace use of an existing HTTP cache key component (called the “is-subframe-document-resource” boolean, set to true for all subframe navigations) designed to mitigate related attacks from malicious subframes. This scheme is expected to have similar performance characteristics to the previous approach but would make Chromium’s handling of main frame and subframe navigations consistent.


Incorporating the initiator into the HTTP cache key will mean that the responses from renderer-initiated navigations will not be re-used across contexts with different frame sites or top-frame sites. This could affect the page load times for previously visited sites in cases where loading a page over the network is slower than loading the page from the local disk cache. Renderer-initiated navigations corresponding to, for example, clicking links on a site, site redirects, and link prefetches that use “as=’document’”. Incorporating the ‘is-cross-site-top-level-navigation’ boolean is expected to have the least impact on performance since it allows the most amount of response re-use. Incorporating the full initiator site is expected to have the most impact since there is less re-use with these cache partitioning schemes, but this approach may enable future HTTP cache performance optimizations that are not possible today due to cross-site leak risks.


Debuggability

No special needs.


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

No

All except WebView, which does not currently partition its HTTP cache.


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

No


Flag name on chrome://flags

None


Finch feature name

There are several feature flags, one per experiment partition key format:

  • SplitCacheByCrossSiteMainFrameNavigationBoolean - Enables use of the is-cross-site-navigation boolean in the HTTP cache key for main frame navigations with cross-site initiators

  • SplitCacheByMainFrameNavigationInitiator - Enables use of the initiator site in the HTTP cache key for main frame navigations with cross-site initiators

  • SplitCacheByNavigationInitiator - Enables use of the initiator site in the HTTP cache key for all navigations with cross-site initiators and disables use of the existing “is-subframe-document-resource” boolean.


Requires code in //chrome?

To facilitate conducting the experiment we have code to clear chrome’s HTTP cache when the experiment is conducted, but otherwise no code in //chrome is needed.


Estimated milestones

M129 to M131 inclusive.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5190577638080512


Yoav Weiss (@Shopify)

unread,
Sep 11, 2024, 9:17:26 AMSep 11
to blink-dev, Andrew Williams, Mike Taylor
I'd love to better understand the attack scenario.

On Friday, September 6, 2024 at 5:40:55 AM UTC+2 Andrew Williams wrote:
Contact emails

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


Explainer

None yet.


Specification

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


Summary

We aim to experiment with utilizing the initiator site when caching the responses of cross-site navigations in the HTTP cache. This experiment is intended to test a potential mitigation for cross-site leak 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.


bad.com navigates the user to victim.com (at the top-level??). What happens then? 

The tested mitigation is also intended as a privacy improvement since it will make it more difficult for a malicious site to use navigations to infer whether a user has visited a given site previously.


But if one site navigated to another, it doesn't get any timing info about the "navigated to" site, right?

Alex Russell

unread,
Sep 11, 2024, 11:53:36 AMSep 11
to blink-dev, Yoav Weiss, Andrew Williams, Mike Taylor
Per today's API OWNERS conversation, I understand that this experiment is going to collect data for presenting potential changes to the behaviour. Assuming that's right, LGTM1.

Best,

Alex

Andrew Williams

unread,
Sep 13, 2024, 10:51:42 AMSep 13
to Alex Russell, blink-dev, Yoav Weiss, Mike Taylor
> I'd love to better understand the attack scenario.

I recently put together the following presentation that illustrates the attack scenarios this aims to mitigate: https://docs.google.com/presentation/d/1xnGpRCyLQnLjvGLMqKZUUDCKZANFhedJyF063S7ifLE/edit?usp=sharing

TL;DR: the attacks involve a malicious site triggering a navigation to a cross-site document and/or resource and using timing to leak state.

> I understand that this experiment is going to collect data for presenting potential changes to the behaviour.

That is correct, the goal of the experiment is to collect data so that we can decide whether/how to proceed w.r.t. addressing cross-site leaks from navigations. We would continue to use the blink-dev process for actually shipping changes related to this.

Thank you!

-Andrew
Reply all
Reply to author
Forward
0 new messages