LGTM2. I'm saddened by the way the implementer community has not been able to converge upon and specify a unified keying scheme, but I agree we shouldn't block further improvements on that, since none of the browsers seem to be making movements toward such alignment. I appreciate that you pinged <https://github.com/whatwg/fetch/issues/1035#issuecomment-2658239821> the relevant thread to see if there's any movement.
On Thursday, February 27, 2025 at 1:23:43 AM UTC+9 Chris Harrelson wrote: > LGTM1 > > On Tue, Feb 25, 2025 at 7:54 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 2/25/25 2:55 AM, Yoav Weiss (@Shopify) 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. >> >> Triple-keying should be covered by >> https://fetch.spec.whatwg.org/#determine-the-network-partition-key (see >> "an implementation-defined value). There's ongoing discussion in >> https://github.com/whatwg/fetch/issues/1035 as well. >> >> A TPAC or three ago we had some conversations in on this topic, and IMO >> there is interest in perhaps converging on the perfect design one day, but >> I don't see cross-implementer alignment on a single keying scheme coming >> any time soon. I think gsnedders also makes a good point in the fetch issue >> that experimentation on keying schemes by UAs for different modes is also >> useful to consider. >> >> >> >> >> 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/0e9fd7e0-87ba-4a07-ba77-2d4178ca881b%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e9fd7e0-87ba-4a07-ba77-2d4178ca881b%40chromium.org?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/b02f00ea-35c2-458b-8cda-9686f7b21f8cn%40chromium.org.
