Intent to Ship: 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 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.

Unpartitioned network state allows for side-channel timing attacks, where one site can figure out if another has been visited recently. For example, if the connection is made quickly, it may be assumed that the socket was warm. It also allows for third parties to track users across first party contexts they are loaded in using a variety of techniques (tracking socket reuse, using per-user alternative service advertisements, etc).

Partitioning storage may reduce Chromium’s ability to reuse network resources.  We’ve enabled network state partitioning in a 5% experiment on Stable.  It slows time to first contentful paint by about 0.5%, and slows cross-site iframe time to first contentful paint by about 5%.  These are very rough averages that vary across platforms and users.

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 proposal partitions the DNS cache and connections, which could result in longer load times when previously reusable resources can no longer be reused.  The performance impact will likely be most visible in cross-site iframes.

Chromium's implementation partitions state by (top-level site, innermost frame site), unlike the implementation shipped by other browser vendors, which just uses top-level site.

This will also potentially increase 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 six connections are created to a site, instead of one or two.

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.  The latest version of the Reporting API (Reporting V1, to replace Reporting V0) is scoped to frames, anyways, so is already subject to a more restrictive limitation.

None of these changes is expected to visibly break sites.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1590107)

WebKit: Shipped/Shipping (https://webkit.org/status/#?search=client-side%20storage%20partitioning)

Web developers: No signals

Other signals:

Ergonomics

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

Debuggability

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

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

No, though it does have partial coverage. web-platform-tests can't test some features like, e.g., DNS cache partitioning.

Flag name

SplitHostCacheByNetworkIsolationKey, PartitionConnectionsByNetworkIsolationKey, PartitionHttpServerPropertiesByNetworkIsolationKey, PartitionSSLSessionsByNetworkIsolationKey, PartitionExpectCTStateByNetworkIsolationKey, PartitionNelAndReportingByNetworkIsolationKey

Requires code in //chrome?

False

Tracking bug

https://crbug.com/993801

Launch bug

https://crbug.com/1166303

Estimated milestones

Plan to roll out in M97/M98 over the course of February

Link to entry on the Chrome Platform Status

https://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

Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/sLC_W6B8big/m/5sk787RQBAAJ

[Yoav Weiss]

Thanks for working on this important partitioning!

On Tue, Feb 1, 2022 at 7:01 PM 'Matt Menke' via blink-dev <blin...@chromium.org> wrote:

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

Unpartitioned network state allows for side-channel timing attacks, where one site can figure out if another has been visited recently. For example, if the connection is made quickly, it may be assumed that the socket was warm. It also allows for third parties to track users across first party contexts they are loaded in using a variety of techniques (tracking socket reuse, using per-user alternative service advertisements, etc).

Partitioning storage may reduce Chromium’s ability to reuse network resources.  We’ve enabled network state partitioning in a 5% experiment on Stable.  It slows time to first contentful paint by about 0.5%, and slows cross-site iframe time to first contentful paint by about 5%.  These are very rough averages that vary across platforms and users.

Can't say that I'm excited about a 5% slowdown here..

Have y'all worked with the webperf community to try and find mitigations to that? (e.g. adding preconnects for resources that typically already had warm connections)

Any research on the implications in other browsers that we could use as developer advice? Have y'all looked at the implications on overall LCP?

Any developer facing documentation on this change and what they should do about it?

 

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 proposal partitions the DNS cache and connections, which could result in longer load times when previously reusable resources can no longer be reused.  The performance impact will likely be most visible in cross-site iframes.

Chromium's implementation partitions state by (top-level site, innermost frame site), unlike the implementation shipped by other browser vendors, which just uses top-level site.

This will also potentially increase 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 six connections are created to a site, instead of one or two.

This has DDoS potential. Any reports on heavier server load from the 5% experiment? How are you planning to roll this out?

Is there a way for us to "remember" the H2/H3 state without it being a vector for re-leaking the information we're trying to hide from content?

 

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.  The latest version of the Reporting API (Reporting V1, to replace Reporting V0) is scoped to frames, anyways, so is already subject to a more restrictive limitation.

None of these changes is expected to visibly break sites.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1590107)

WebKit: Shipped/Shipping (https://webkit.org/status/#?search=client-side%20storage%20partitioning)

Web developers: No signals

Have we asked?

 

Other signals:

Ergonomics

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

Debuggability

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

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

No, though it does have partial coverage. web-platform-tests can't test some features like, e.g., DNS cache partitioning.

Flag name

SplitHostCacheByNetworkIsolationKey, PartitionConnectionsByNetworkIsolationKey, PartitionHttpServerPropertiesByNetworkIsolationKey, PartitionSSLSessionsByNetworkIsolationKey, PartitionExpectCTStateByNetworkIsolationKey, PartitionNelAndReportingByNetworkIsolationKey

Requires code in //chrome?

False

Tracking bug

https://crbug.com/993801

Launch bug

https://crbug.com/1166303

Estimated milestones

Plan to roll out in M97/M98 over the course of February

Link to entry on the Chrome Platform Status

https://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

Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/sLC_W6B8big/m/5sk787RQBAAJ

--
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/CAEK7mvrYvoXcc%2B28rFrHbb1tEJN6HPf1y%3DHdE%2BcGe3tuJwsAnA%40mail.gmail.com.

[Alex Russell]

A 0.5%-5% regression on FCP is massive, particularly if this is at the median. Are y'all able to publish more data about the histograms these numbers came from?

Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Matt Menke]

Thanks for the feedback!  Responses inline.

On Wed, Feb 2, 2022 at 12:03 PM Alex Russell <sligh...@chromium.org> wrote:

A 0.5%-5% regression on FCP is massive, particularly if this is at the median. Are y'all able to publish more data about the histograms these numbers came from?

A 0.5% for main frames is similar to what we saw on HTTP cache partitioning, not sure about cross-site iframes.  Look at the latest metrics, 0.7% for main frames is probably a more accurate summary.

The metrics in question specifically are PageLoad.PaintTiming.NavigationToFirstContentfulPaint and PageLoad.Clients.ThirdParty.Frames.NavigationToFirstContentfulPaint3.

We have details about percentiles and platforms, though I'm not quite sure how useful those are.  For general frame loads, the greatest regressions are on slower page loads. For iframes, the largest regression is at the 50th percentile and below of page loads, with the regression dropping to around 1% at the 99th percentile of load times.  Regressions are similar across platforms, though Android seems to see the greatest regression for general frame loads.

I'm unaware of any histograms that would let us better delve into what sorts of cases the regressions affect most.

 

Thanks.

On Wednesday, February 2, 2022 at 1:25:41 AM UTC-8 Yoav Weiss wrote:

Thanks for working on this important partitioning!

On Tue, Feb 1, 2022 at 7:01 PM 'Matt Menke' via blink-dev <blin...@chromium.org> wrote:

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

Unpartitioned network state allows for side-channel timing attacks, where one site can figure out if another has been visited recently. For example, if the connection is made quickly, it may be assumed that the socket was warm. It also allows for third parties to track users across first party contexts they are loaded in using a variety of techniques (tracking socket reuse, using per-user alternative service advertisements, etc).

Partitioning storage may reduce Chromium’s ability to reuse network resources.  We’ve enabled network state partitioning in a 5% experiment on Stable.  It slows time to first contentful paint by about 0.5%, and slows cross-site iframe time to first contentful paint by about 5%.  These are very rough averages that vary across platforms and users.

Can't say that I'm excited about a 5% slowdown here..

Have y'all worked with the webperf community to try and find mitigations to that? (e.g. adding preconnects for resources that typically already had warm connections)

I'm unaware of any process for this.  We can't allow arbitrary preconnects for cross-site navs, since they potentially leak information, though I believe another team is looking / has looked into fancier cross-site prefetch (which may allow only the root document to be prefetched, though doesn't allow connection reuse).  Also worth noting that Chrome throws away never used sockets after 10 seconds, since sites tend to close unused sockets quickly, which would also make cross-site preconnects potentially less useful, unless they happen exactly at the time navigation starts.

Preconnects for cross-site iframes seems potentially more viable, since the concerns there are largely around cross-site attacks, so leaking data due to preconnects are less a use privacy concern, and, to the extent of my knowledge, are less useful for spying on cross-site iframes as well.

 

Any research on the implications in other browsers that we could use as developer advice? Have y'all looked at the implications on overall LCP?

I'm unaware of any research here.  We have not looked into the implications of lower LCP here, though I imagine they're similar to those of cache partitioning.

 

Any developer facing documentation on this change and what they should do about it?

The fetch spec covers keying on main frame site (and also allows for additional keys).  We're also talking to devrel, though I'm unfamiliar with any developer-targeted documentation that we maintain, apart from web standards documentation.

  

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 proposal partitions the DNS cache and connections, which could result in longer load times when previously reusable resources can no longer be reused.  The performance impact will likely be most visible in cross-site iframes.

Chromium's implementation partitions state by (top-level site, innermost frame site), unlike the implementation shipped by other browser vendors, which just uses top-level site.

This will also potentially increase 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 six connections are created to a site, instead of one or two.

This has DDoS potential. Any reports on heavier server load from the 5% experiment? How are you planning to roll this out?

We have received no reports of heavier server load, but it's not entirely clear we'd learn of it if it were an issue.  Note that this does not increase number of HTTP requests, but rather number of established connections (with SSL negotiated), though of course, those aren't free from either the perspective of the server or the client (it can also increase number of DNS requests, though those should typically cached by upstream resolvers).

The plan is to slowly ramp this up to 100% over the course of a month.  Ramp it up to 10%, monitor for two weeks.  If all goes well ramp, it up to 50%, monitor for two more weeks, and then ramp it up to 100%.

 

Is there a way for us to "remember" the H2/H3 state without it being a vector for re-leaking the information we're trying to hide from content?

We do still remember H2/H3 information, but it's sharded by site (e.g., in the contexts of https://*a.com, we know that HTTPS requests to https://*b.com can be sent to unique-user-id.tracker.com via H3).  Since H3 remembers much more than just a boolean, even remembering a single H3 server across sites is basically equivalent to a 3P cookie, unless we rework how H3 advertisements works, or have some central repository where we can validate that H3 information is not user identifying, which would be a rather major undertaking.

That having been said, DNS HTTPS records do, in fact, rework how H3 (and H2) advertisements works, with browsers learning that information directly from DNS results, and that should hopefully help here, at least.  Other members of the Chromium team are actively working on wiring this up.  This does add a new DNS request type, which is a pretty major change, so I'm not sure how long it will take from implementation to deployment.

 

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.  The latest version of the Reporting API (Reporting V1, to replace Reporting V0) is scoped to frames, anyways, so is already subject to a more restrictive limitation.

None of these changes is expected to visibly break sites.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1590107)

WebKit: Shipped/Shipping (https://webkit.org/status/#?search=client-side%20storage%20partitioning)

Web developers: No signals

Have we asked?

I hadn't realized there was a process here.  I'll look into starting that.

 

Other signals:

Ergonomics

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

Debuggability

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

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

No, though it does have partial coverage. web-platform-tests can't test some features like, e.g., DNS cache partitioning.

Flag name

SplitHostCacheByNetworkIsolationKey, PartitionConnectionsByNetworkIsolationKey, PartitionHttpServerPropertiesByNetworkIsolationKey, PartitionSSLSessionsByNetworkIsolationKey, PartitionExpectCTStateByNetworkIsolationKey, PartitionNelAndReportingByNetworkIsolationKey

Requires code in //chrome?

False

Tracking bug

https://crbug.com/993801

Launch bug

https://crbug.com/1166303

Estimated milestones

Plan to roll out in M97/M98 over the course of February

Link to entry on the Chrome Platform Status

https://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

Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/sLC_W6B8big/m/5sk787RQBAAJ

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

[Mike Taylor]

FYI, we're going to run some other experiments to see how to improve performance here.

(And we'll send a new I2S after that, rather than revive this thread.)

Thanks everyone.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrCJFYRoP7FW5JcwK5DjeCy2iW7j4%2BfN6WUy_zfjuZJDw%40mail.gmail.com.

[Matt Menke]

I think it's worth stating here that the experiments will be to switch to one-value keys (which is what other browsers do), which involves some tradeoffs.

[Johnny Fang]

Matt and Mike, could you please clarify whether the intent is to experiment only with Network Partitioning - as in, no effect on HTTP Cache partitioning?

Are there any thoughts of revisiting HTTP Cache partitioning being triple-key'd (given it had similar performance regression), or is the security/privacy concern more serious there?

It seems the CRBug for this work is at  1294930 - Run an experiment to see if double-keyed IsolationInfo improves perf over triple-key - chromium

Is there a public method to track the experiment/feature's exposure, or is that internal to Google?

Thanks,

Johnny

[Matt Menke]

The cache will use the same key as everyone else, so this will change the cache to use a single-value key as well.

[Johnny Fang]

Hey folks,

Are there any public updates regarding  1294930 - Run an experiment to see if double-keyed IsolationInfo improves perf over triple-key - chromium? (I couldn't find anything regarding the trial's status/results).
@Brianna, any insight on current data or what it looks like things are shaping to would be much appreciated.

Thank you!