Intent to Experiment: Incorporating navigation initiator into the HTTP cache partition key
Andrew Williams
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
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
Yoav Weiss (@Shopify)
Contact emailsmike...@chromium.org, awi...@chromium.org
ExplainerNone yet.
Specificationhttps://fetch.spec.whatwg.org/#http-cache-partitions
SummaryWe 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.
