Intent to Experiment: Network State Partitioning

[Matt Menke]

Contact emails

mme...@chromium.org

Explainer

https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md

Specification

https://fetch.spec.whatwg.org/#connections

Summary

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.

Explainer: https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md

Blink component

Internals>Network

TAG review

https://github.com/w3ctag/design-reviews/issues/596

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

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

Ergonomics

The only risk here is decreased performance, particularly in cross-site iframes.

Goals for experimentation

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.

Debuggability

Devtools won't display the network partition key, but will continue to display the results of network requests accurately.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

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.

Is this feature fully tested by web-platform-tests?

No.  Some features (like the DNS cache) are not possible to test with web platform tests, and Reporting/NEL are still draft standards.

Tracking bug

https://crbug.com/993801

Launch bug

https://crbug.com/1166303

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/6713488334389248

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/6KKXv1PqPZ0/m/nm2z5I_MBAAJ

[Daniel Bratell]

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.

/Daniel

--
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.

[Matt Menke]

HTTP cache partitioning is already shipping, apologies for not making that clear in the explainer.  This actually covers most everything in net/ *other* than the cache (socket pools, reporting, Expect-CT state, DNS cache, etc).

As you say, we want to "mini-ship" the feature, rather than have an origin trial.  We're currently thinking 1% initially, and then ramping up to 5%, before asking for ship permissions, and gradually rolling it out from there.

[Mike West]

LGTM1 to experiment with up to 5%.

As this experiment isn't running as an OT, but a percent-rollout, it'll require 3 LGTMs. That deviation sounds completely reasonable to me for this, as it's not the kind of thing that any particular origin can reasonably opt-into, nor is it the kind of thing that an origin-by-origin opt-in would provide data upon which we could reasonably make a decision about the performance impacts at scale. The rollout strategy you've described here sounds good, and I wish you luck. :)

-mike

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.

[Chris Harrelson]

LGTM2 to experiment at 5%.

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.

[Daniel Bratell]

LGTM3

/Daniel

[Anne van Kesteren]

On Thu, Apr 22, 2021 at 5:05 PM 'Matt Menke' via blink-dev
<blin...@chromium.org> wrote:
> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md

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.

[Matt Menke]

On Tue, Apr 27, 2021 at 4:12 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Apr 22, 2021 at 5:05 PM 'Matt Menke' via blink-dev
<blin...@chromium.org> wrote:
> https://github.com/MattMenke2/Explainer---Partition-Network-State/blob/main/README.md

I don't see the CORS-preflight cache mentioned here.

My mistake, that is included.

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.

WebSocket connections aren't reusable across frames, are they?  So this only affects WebSockets over H2/QUIC proxies (proxies are not covered by the spec), and other caches (DNS cache, ALPN cache, TLS session resumption cache), none of which are covered by the spec, either, for either the WebSocket case or just HTTP.