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 miketa...@chromium.org, awil...@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? Blink component Internals>Network>Cache <https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECache&can=2> 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://chromestatus.com/feature/5190577638080512?gate=5181053938171904> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e0ba632c-bef4-4da9-80af-cf2d798fc418n%40chromium.org.
