> 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 On Wed, Sep 11, 2024 at 5:53 PM Alex Russell <slightly...@chromium.org> wrote: > 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 > > On Wednesday, September 11, 2024 at 6:17:26 AM UTC-7 Yoav Weiss wrote: > >> 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/CAEa0%2BkWoNN1q%2BLfVijuPqT8b%2BhZxNc%3DeYn%3Dw5ie9wRG6EYNP8w%40mail.gmail.com.
