Thanks everyone! We've flipped the feature flag for this to be enabled by default, and the functionality will roll out in M136. 🎉
-Andrew On Wed, Mar 12, 2025 at 11:26 AM Alex Russell <slightly...@chromium.org> wrote: > 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/CAEa0%2BkUFoa_LCGg26m%2BJ%3DuMcbgQtgGxL3YDW7hKoniAyKLsCCg%40mail.gmail.com.
