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. 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. 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/f05f274a-799b-4063-89a0-530e6186d3e7n%40chromium.org.
