Thanks for taking a look Yoav, replying inline below On Tue, Feb 25, 2025 at 2:55 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> Thanks for pushing this! > > On Monday, February 24, 2025 at 8:04:31 PM UTC+1 Andrew Williams wrote: > > Contact emailsmiketa...@chromium.org, awil...@chromium.org > Explainer > > HTTP cache partitioning in general is covered by https://github.com/ > shivanigithub/http-cache-partitioning, and this proposal extends > partitioning to navigations. This I2S and the linked resources discuss the > partitioning scheme changes and the specific attack scenarios that are > mitigated. > > Specificationhttps://fetch.spec.whatwg.org/#http-cache-partitions > > > The spec doesn't seem to indicate any of this logic (nor does it include > triple keying AFAIU). > I don't think it's a blocker, but it'd be nice to get cross-implementer > alignment on the strategy here, or barring that, add UA-defined conditions. > "Determine the HTTP cache partition" uses the "Determine the network partition key" algorithm, which is where double-keying is defined and triple-keying is supported but left as "implementation-defined": https://fetch.spec.whatwg.org/#determine-the-network-partition-key. There is a corresponding issue containing discussions on moving this forward, and I left a comment there recently to try and rekindle those conversations but haven't heard anything back from other implementers yet: https://github.com/whatwg/fetch/issues/1035#issuecomment-2658239821 > > > > SummaryChrome’s HTTP cache keying scheme will be updated to include an > “is-cross-site-main-frame-navigation” boolean to mitigate cross-site leak > attacks involving top-level navigation. Specifically, this will prevent > cross-site 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. This change > also improves privacy by preventing a malicious site from using navigations > to infer whether a user has visited a given site previously. > > For an overview of the attacks mitigated by the > “is-cross-site-main-frame-navigation” > boolean, see: > > - https://xsleaks.dev/docs/attacks/navigations/# > partitioned-http-cache-bypass > > - https://docs.google.com/presentation/d/1StMrI1hNSw_ > QSmR7bg0w3WcIoYnYIt5K8G2fG01O0IA/edit?usp=sharing > > > Do I understand correctly that this will prevent "Attack 1" and "Attack > 2", but "Attack 3" is already mitigated by triple keying? > > While attack 1 is clear, I'm not sure how come attack 2 isn't mitigated by > the fact that a.com/img is already partitioned. > Neither "Attack 2" nor "Attack 3" are prevented by triple-keying because for navigations the top-level site and frame site are computed solely based on the URL being navigated to. As an example, a navigation to 'a.com/url' will have top-level site and frame site of 'a.com', and these three keys will be the same as for 'a.com/url' being loaded as a resource from an ' a.com' top-level document. Attack 3 is prevented today by a separate boolean used in the cache key that is set to true for all subframe navigations. There isn't a similar mitigation for Attack 2 today, but this is what the "is-cross-site-main-frame-navigation" boolean addresses. > > > > Blink componentInternals>Network>Cache > <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECache%22> > TAG reviewHTTP cache partitioning was originally reviewed in > https://github.com/w3ctag/design-reviews/issues/424. We did not submit > for a new TAG review since cache partitioning standardization hasn’t > changed much since then, and since it’s unclear whether there’s support for > updating standards to partitioning by more than just top-level site. > TAG review statusNot applicable > Risks > > Interoperability and CompatibilityInterop risk: We do not expect > compatibility impacts here since the behavior is not web-visible (other > than affecting navigation completion times), and our earlier 1% experiment > didn’t indicate any significant changes to performance as a result of this. > Regarding interop, Safari and Firefox currently ship partitioned HTTP > caches but with different partitioning schemes that don’t partition > navigations differently from other network requests. > Gecko: https://github.com/mozilla/standards-positions/issues/1177 > WebKit: https://github.com/WebKit/standards-positions/issues/462 > Web developers: No signals > Other 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 - > cache partitioning is not enabled for WebView > > DebuggabilityPartition keys are visible in net logs, and whether > something was served from the HTTP cache is visible in DevTools. > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?No, it will be supported > on all platforms 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, this isn’t web visible. > Flag name on chrome://flagsNone > Finch feature nameSplitCacheByCrossSiteMainFrameNavigationBoolean > Requires code in //chrome?False > Launch bughttps://launch.corp.google.com/launch/4345002 > Estimated milestones > > Shipping on desktop > > 135 > > Shipping on Android > > 135 > > > Anticipated spec changesOpen questions about a feature may be a source of > future web compat or interop issues. Please list open issues (e.g. links to > known github issues in the project for the feature specification) whose > resolution may introduce web compat/interop risk (e.g., changing to naming > or structure of the API in a non-backward-compatible way).The spec > already leaves the HTTP cache key as implementation-defined apart from > partitioning by top-level site. It's unclear whether other browsers support > standardizing any portion of what we are shipping. > Link to entry on the Chrome Platform Statushttps://chromestatus.com/ > feature/5190577638080512 > <https://chromestatus.com/feature/5190577638080512?gate=5181053938171904> > Links to previous Intent discussions > > Intent to Experiment: https://groups.google.com/a/ > chromium.org/d/msgid/blink-dev/CAEa0%2BkV1oQg2cc_MWW_RtG9de% > 3DVk2i1rUv8MrQ49GV0yWZwy_w%40mail.gmail.com > > -- 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%2BkUOCwicsRYNuwVrTZYjMVQKduciHZo2mdjw58_FuP3Pdg%40mail.gmail.com.
