Intent to Experiment: "is-cross-site" bit in the HTTP Cache Partitioning Key
Andrew Williams
Contact emails
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 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 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
TAG review
Not requested at this time
TAG review status
N/A
Risks
Interoperability 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
Yoav Weiss
--
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+...@chromium.org.
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.
Mike West
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
Andrew Williams
- decreases in the 25th and 50th percentile time by 28.19% and 18.56% respectively for desktop platforms, with very strong confidence (4-diamonds in our internal dashboard)
- decreases in the 75th percentile time by 7.39% for desktop platform, with strong confidence (3-diamonds in our internal dashboard)
- decreases in the 25th percentile time by 6.14% for Android, with moderate confidence (2-diamonds in our internal dashboard)
- decreases in the 99th percentile time by 3.09% for Android, with weak confidence (1-diamond in our internal dashboard)
Page loads from opaque origin iframes appear to make up only 1% of all third-party context page loads, though, and the metrics tracking the time until FCP for all third-party contexts showed no statistically significant changes.
We also tracked metrics related to cache utilization over the course of the experiment, but we weren’t able to draw any conclusions from the data we collected. Our plan was to take the experiment group, who would effectively be starting from an empty cache due to the cache partitioning scheme change, and compare them to a control group of users with a primed cache. We thought that the experiment group would have low cache utilization at first but reach a steady state after a few weeks and allow us to make a fair comparison at the end of the experiment. This turned out to not be the case, though, due to the experiment itself taking a month to fully roll out and the cache likely taking longer on average to fully repopulate. Also, we thought it'd be interesting to measure the effect having a shared cache partition for all opaque origin contexts under a given top-level site (but otherwise using triple-keying for everything) would have on performance. As a result, we’d like to repeat the experiment with different groups:
- New control group that clears the HTTP cache upon starting and begins alongside the others
- 2.5-keyed with shared cache for opaque origin contexts (same as in Round 1)
- Triple-keyed with a shared partition for all opaque origin iframes under a given top-level site
- September 27th - Enable experiment for Canary, Dev, and Beta users, pending I2E LGTM
- October 4th - Enable experiment for 3% of Stable users (1% in each experiment group mentioned above)
- November 8th - End the experiment
Yoav Weiss
Hey everyone,TL;DR: We'd like to extend the experiment with some modifications, and are requesting an LGTM for this.As part of the experiment we found that enabling the HTTP cache for opaque origin contexts (and having those cache partitions be shared among third-party contexts) resulted in the following changes to the FCP (first contentful paint) times for those contexts:
- decreases in the 25th and 50th percentile time by 28.19% and 18.56% respectively for desktop platforms, with very strong confidence (4-diamonds in our internal dashboard)
- decreases in the 75th percentile time by 7.39% for desktop platform, with strong confidence (3-diamonds in our internal dashboard)
- decreases in the 25th percentile time by 6.14% for Android, with moderate confidence (2-diamonds in our internal dashboard)
- decreases in the 99th percentile time by 3.09% for Android, with weak confidence (1-diamond in our internal dashboard)
Page loads from opaque origin iframes appear to make up only 1% of all third-party context page loads, though, and the metrics tracking the time until FCP for all third-party contexts showed no statistically significant changes.
We also tracked metrics related to cache utilization over the course of the experiment, but we weren’t able to draw any conclusions from the data we collected. Our plan was to take the experiment group, who would effectively be starting from an empty cache due to the cache partitioning scheme change, and compare them to a control group of users with a primed cache. We thought that the experiment group would have low cache utilization at first but reach a steady state after a few weeks and allow us to make a fair comparison at the end of the experiment. This turned out to not be the case, though, due to the experiment itself taking a month to fully roll out and the cache likely taking longer on average to fully repopulate. Also, we thought it'd be interesting to measure the effect having a shared cache partition for all opaque origin contexts under a given top-level site (but otherwise using triple-keying for everything) would have on performance. As a result, we’d like to repeat the experiment with different groups:
- New control group that clears the HTTP cache upon starting and begins alongside the others
- 2.5-keyed with shared cache for opaque origin contexts (same as in Round 1)
- Triple-keyed with a shared partition for all opaque origin iframes under a given top-level siteOur proposed timeline for this is:- September 20th - Enable experiment for Canary and Dev users
- September 27th - Enable experiment for Canary, Dev, and Beta users, pending I2E LGTM
- October 4th - Enable experiment for 3% of Stable users (1% in each experiment group mentioned above)
- November 8th - End the experimentAlso, Mike, thanks for the feedback regarding risk analysis. We will ensure there is a more comprehensive assessment that is made publicly available if we decide to move forward with implementing a change here.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUs7VkJ6kZQvprS591mXa-CzDO_jTGrmqf7ZLhcVcgvfw%40mail.gmail.com.