Hi Daniel, > I assume here that you can poll "handle" to see when it changes from a document you can access to one you cannot access?
Yeah that's my understanding, or polling for changes in the properties that are still accessible via handle after the popup has loaded. There are other ways to carry out these attacks as well, for instance involving techniques like attempting to navigate yourself to a given page and cancelling the navigation attempt after certain amounts of time. > Could that information leakage have been fixed instead of making a.com load slower? There was a similar question in the Mozilla standards-position for this <https://github.com/mozilla/standards-positions/issues/1177#issuecomment-2665352648> so I'll post my response from there below: Addressing the timing side channels that allow for carrying out these XS leak attacks is indeed another way to go about mitigating them, but from talking with security folks within Google the thinking is that it can be difficult to mitigate them all (especially if the mitigations might involve behavior changes that could result in breakage) and it's also challenging to prevent new ones from being introduced as the web platform evolves. As a result, our focus has been on addressing the caching behavior that makes specific attacks possible. -Andrew On Wed, Mar 5, 2025 at 10:34 AM Daniel Bratell <bratel...@gmail.com> wrote: > In your slides you write: > > const handle = window.open(“a.com/”) > ... > <Use timing to infer prior visit> > > I assume here that you can poll "handle" to see when it changes from a > document you can access to one you cannot access? Could that information > leakage have been fixed instead of making a.com load slower? > > /Daniel > On 2025-02-24 19:58, Andrew Williams wrote: > > Hey everyone, > > We ran this experiment and found no significant changes for the core web > vital metrics or for the Chrome Guardrail metrics. We also conducted an > in-depth analysis of multiple internal performance metrics and the results > from that support moving forward with adding the > "is-cross-site-main-frame-navigation" boolean to the HTTP cache. We will > follow-up with an Intent-to-Ship for this soon. :) > > If anyone has any questions about this experiment please let me know. > Thanks! > > -Andrew > > On Fri, Sep 13, 2024 at 10:51 AM Andrew Williams <awil...@chromium.org> > wrote: > >> > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkWHa_GyD6%3Du7emyXTOxWwrRvM%2B_xXSUCiVUHod9ihsEnQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkWHa_GyD6%3Du7emyXTOxWwrRvM%2B_xXSUCiVUHod9ihsEnQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUz-o4B0-WaabjP9pA0OcsJW%2BgRr9SkUbkwx4g5GfvqFg%40mail.gmail.com.
