LGTM3 On Wednesday, March 5, 2025 at 6:21:35 AM UTC-8 Mike Taylor wrote:
> FYI, it looks like WebKit is trending supportive on this change: > https://github.com/WebKit/standards-positions/issues/462#issuecomment-2693662676 > > On 3/2/25 9:32 PM, Domenic Denicola wrote: > > 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/735965f2-9db3-4aee-8118-0991718a1b78n%40chromium.org.
