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.
