brgol...@chromium.org, mike...@chromium.org, mme...@chromium.org
We would like to run another experiment for the Network State Partitioning effort to better understand the performance impacts of an alternative partitioning scheme. To date we’ve run experiments with a triple-keyed HTTP cache and triple-keyed network state, and a double-keyed HTTP cache and double-keyed network state.
As a possible compromise between security and performance tradeoffs, which were discussed at a recent WebAppSec session at TPAC, we want to measure a triple-keyed HTTP cache with the following network state key configurations:
Triple-keyed network state (this is the first experiment we ran, but the data is quite old now)
Double-keyed network state
Double-key with an is_cross_site bit (whether the iframe is cross-site from the top-level parent frame).
(and a control group, with unpartitioned network state)
As a reminder, here’s a link to the (triple-key) I2E, and the (double-key) I2E. This document only contains changes to previous intents.
We want to roll this out to 1% of Stable traffic (i.e., this is not an Origin Trial) to be able to compare to the previous experiments.
We’d like to run at 1% on Stable for ~4 weeks, ideally beginning in M107 (but some chance of this slipping to M108 depending on timing).
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/2e1e2e27-514b-688b-6318-e029fa7bf08f%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXWnY4jM9DDy9X3j75xafDA%3DQ79mQSnA6A4GRiDopP1Zg%40mail.gmail.com.