Partition network state by the network partition key (which consists of top frame site and possibly frame site), to protect against cross-site tracking through the use of side channels. "Network State" here includes connections (H1, H2, H3, websocket), the DNS cache, ALPN/H2 support data, TLS/H3 resumption information, Reporting/NEL configuration and uploads, and Expect-CT information.
This partitions the DNS cache and connections, which could result in longer load times when previously reusable resources can no longer be reused. It also potentially increases the number of connections made to sites, both because connections can't be reused as often, and because Chromium is less likely to know in advance if H2 or H3 can be used with a site. When that isn't known, up to 6 connections are created to a site, instead of 1 or 2.
NEL, Reporting, and Expect-CT: Report-To headers tell Chromium how and when to inform a site of certain errors. Partitioning this information means that Chromium potentially won't know where to report errors, particularly the first time it issues a request to a site in a particular context.
None of these changes are expected to visibly break sites.
Gecko: In development (https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A)
WebKit: Shipped/Shipping (https://webkit.org/status/#?search=client-side%20storage%20partitioning)
Web developers: No signals
The only risk here is decreased performance, particularly in cross-site iframes.
We want to roll this out to a subset of stable to get less noisy performance numbers.
The page load performance numbers we have on beta are generally within the margin error, except for cross-site iframes (PageLoad.Clients.ThirdParty.Frames.NavigationToFirstContentfulPaint3), where, in the 25th to 75th percentiles, we’ve seen regressions of anywhere from within the margin of error to 7%. Outside of that percentile range, the numbers have always been within the margin of error. The numbers have been very noisy, however, so we want more accurate numbers to better understand potential performance impact before sending out an intent-to-ship.
Devtools won't display the network partition key, but will continue to display the results of network requests accurately.
This will not initially be supported on WebView, since all requests will need a network partition key, and WebView exposes APIs for requests to be made directly by the embedding app, so we won't know what key to use. We intend to investigate enabling this feature for WebView down the line.
No. Some features (like the DNS cache) are not possible to test with web platform tests, and Reporting/NEL are still draft standards.
I think this is cache partitioning is a good idea, but I'm guessing you are not really requesting an origin trial but a mini-shipping? I guess so because an origin trial would most likely not help you get more accurate performance numbers. Origin Trials are enabled by sites requesting it, and I think it will be hard to get a representative partition of the web to request this.
On the other hand, enabling this for X% of users on stable through finch should give you some useful numbers. Do you know how large X would have to be?
Since the effect for users will hopefully be small or negligible and it will have a small impact on web developers I see no significant risks with having it enabled for a small X.
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/CAEK7mvpb_m-4w5E%2BGFzPRQ37baKzYdh%3Dn3yabDyHKeUeYzbJGQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrd9_9_vwNKCDBG7ti2-DVd3jpv2VuR6Zsg9MybOScC1w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DePRK3FHsuzRQ4Yb8BAdZZDkGJKCXq5%3DSNb_YV52Ycn7w%40mail.gmail.com.
On Thu, Apr 22, 2021 at 5:05 PM 'Matt Menke' via blink-dev
I don't see the CORS-preflight cache mentioned here.
There's also some open specification issues here. In particular
whether we should say more about the things that Fetch's connection
concept covers (https://github.com/whatwg/fetch/issues/917) and
WebSocket not being covered by that connection concept
(https://github.com/whatwg/fetch/issues/1122). The latter is somewhat
tricky to tackle due to the WebSocket protocol not being maintained,
but I suppose we could continue to awkwardly patch it. If you are Adam
Rice have further thoughts on these that would be helpful.