LGTM to experiment based on the suggested timelines Thanks for trying to win back some of the performance losses that came with cache partitioning!
On Tue, May 2, 2023 at 4:41 PM Andrew Williams <[email protected]> wrote: > Contact emails > > [email protected] > > Explainer > > This change is not covered by an explainer, but the following are related: > > https://github.com/shivanigithub/http-cache-partitioning > > > https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md > > Spec > > https://fetch.spec.whatwg.org/#http-cache-partitions > > https://fetch.spec.whatwg.org/#network-partition-keys > > Summary > > To protect users from multiple types of cross-site data leak attacks, the > HTTP cache was partitioned > <https://chromestatus.com/feature/5730772021411840> based on the > top-level site and the frame site. In other words, cache entries for a > given URL created from third-party contexts (e.g., a ‘b.com’ iframe > embedded on ‘a.com’) are stored separately from those from first-party > contexts (‘a.com’, or an ‘a.com’ iframe embedded on ‘a.com’) and other > third-party contexts (a ‘c.com’ iframe embedded on ‘a.com’). > > Other shared network state was recently partitioned > <https://chromestatus.com/feature/6713488334389248> as well, but using a > different partitioning scheme - instead of using the top-level site and the > frame site, network state in third-party contexts is partitioned by the > top-level site and whether the frame site is cross-site from the top-level > site. Using this "is-cross-site" bit instead of the frame site was chosen > as a balance between security and performance after running experiments and > measuring the results. > > The change proposed here is to replace the frame site in the HTTP cache > partitioning scheme with an "is-cross-site" bit to perform similar > experimentation. Using the examples above, this change means that a ‘b.com’ > iframe embedded on ‘a.com’ would now share an HTTP cache partition with a > ‘c.com’ iframe embedded on ‘a.com’, since the “is-cross-site” bit for > both would be set to true (and since the top-level site for both is ‘a.com > ’). > > Blink component > > Internals>Network>Cache > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECache&can=2> > > TAG review > > Not requested at this time > > TAG review status > > N/A > > RisksInteroperability and Compatibility > > No interoperability / compatibility risks are expected, since the caching > behavior generally only affects site performance , and in this case the > change should result in performance improvements > > Gecko: N/A, but their implementation doesn’t partition by frame site or > “is-cross-site”; > > WebKit: N/A, but their implementation doesn’t partition by frame site or > “is-cross-site”; > > Web developers: No signals > > Other signals: N/A > > WebView application risks > > None, since HTTP cache partitioning is not enabled for WebView > > Security > > One side effect of this change is that a malicious cross-site iframe will > now share an HTTP cache partition with other cross-site iframes under the > same top-level site. This allows the malicious cross-site iframe to perform > data leak attacks against the other cross-site iframes via HTTP cache > probing. It’s unclear how useful this attack primitive would be in > practice, since the data available to the attacker would still be > partitioned by the top-level site, and since construction of a page to take > advantage of this weakness (for instance, a phishing page where a victim > site is in one cross-site iframe) could be thwarted by X-Frame-Options / > CSP’s frame-ancestors option. > > Goals for experimentation > > This experiment aims to identify what effect the new partitioning scheme > has on the Chrome guiding metrics/vital metrics, and on other metrics that > are influenced by the performance of the HTTP cache. > > Also, one specific side-effect of this change is that iframes with opaque > origins (for instance, those created using data: URLs) may now be eligible > to have their resources added to the HTTP cache. We aim to measure what > changes in performance result from this. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? > > This feature will be supported on all six Blink platforms, but note that > HTTP cache partitioning is only enabled-by-default for Chrome desktop and > mobile platforms (but not WebView). > > Flag name > > --enable-features=EnableCrossSiteFlagNetworkIsolationKey > > Proposed experiment timeline > > We plan to roll out the experiment as follows: > > - > > April 27th - 50% of Canary and Dev users (M114) > - > > May 4th - 50% of Canary, Dev, and Beta users (M114) > - > > May 11th - 1% of Stable users and 50% of Canary, Dev, and Beta users > - > > June 15th - End the experiment > > > Is this feature fully tested by web-platform-tests? > > No - for this experiment, testing is only implemented via unit tests and > Chrome browser tests > > Link to entry on the feature dashboard <https://www.chromestatus.com/> > > https://chromestatus.com/feature/6169233265786880 > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVFqn2BxfXhtGjYbb6%3DVA8MpTnD%2BNx4bcQqt3a3a0s%3DCw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVFqn2BxfXhtGjYbb6%3DVA8MpTnD%2BNx4bcQqt3a3a0s%3DCw%40mail.gmail.com?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV0aLX_5TCJ%2BnX60iTT684C6Ao2AYUMh68KL7fNtqFbAg%40mail.gmail.com.
