Intent to Ship: Network State Partitioning

[Brianna Goldstein]

Contact emails

brgol...@chromium.org, mme...@chromium.org, a...@google.com, mike...@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 to protect against cross-site tracking through the use of side channels. The network partition key consists of the schemeful site of the top level frame and a boolean indicating if the request is coming from a cross-site iframe. "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.

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 a connected socket exists. 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).

Our initial attempt to partition the network state re-used the triple key partition scheme that was shipped for the HTTP cache. This included the schemeful sites of the top-level frame and the iframe. However, in an attempt to land a favorable balance between (1) the performance benefits of shared resources, and (2) the privacy promises of ensuring sites are safely prevented from gaining information about a user’s browsing habits, this new partition key consists of the top level site and a boolean indicating if the request is coming from a cross-site iframe.

Partitioning may reduce Chromium’s ability to reuse network resources.  We’ve enabled network state partitioning in a 1% experiment on Stable. From our experiments, Android navigation times to first contentful paint are increased by around 0.35% at the 50th percentile and 0.17% at the 99th percentile. Cross-site iframe navigation time to first contentful paints is increased by 2.85% at the 50th percentile and 1.35% at the 99th percentile. This represents about a 40 ms increase at the 50th percentile. On desktop, navigation times to first contentful paint are increased by around 1.00% at the 50th percentile (approximately a 10 ms increase) and have no impact on the 99th percentile. For cross-site iframes, the navigation times to first contentful paint are increased by 1.84% at the 50th percentile and 2.05% at the 99th percentile.

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

Review of partitioning design options: https://docs.google.com/document/d/1UPjO44CMekDDXIKlih570Z6SOvKQnWzKoDe7APN_GHg/edit

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 and a boolean flag indicating if the frame site is cross-site to the top-level site. This is unlike the implementation shipped by other browser vendors, which just uses the top-level site.

This will also increase the number of connections made per page load, 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 for a site.

NEL and Reporting `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

Web developers: No signals

Other signals:

Ergonomics

The only risk here is slightly 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

Flag name

EnableCrossSiteFlagNetworkAnonymizationKey, SplitHostCacheByNetworkIsolationKey, PartitionConnectionsByNetworkIsolationKey, PartitionHttpServerPropertiesByNetworkIsolationKey, PartitionSSLSessionsByNetworkIsolationKey, PartitionExpectCTStateByNetworkIsolationKey, PartitionNelAndReportingByNetworkIsolationKey

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1343856

Launch bug

https://crbug.com/1166303

Estimated milestones

Ship at 1% on December 13th - M108

Ship at 10% on January 9th - M109

Ship at 100% on January 23rd - M109

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6713488334389248

Links to previous Intent discussions

Intent to ship (triple key): https://groups.google.com/a/chromium.org/g/blink-dev/c/tJa6uzXu_IA/m/IN6UhwKtAwAJ

Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/-5lo8I9QT0c/

[Yoav Weiss]

LGTM1

Thanks for working on this compromise between our security/privacy needs and our performance goals!!

On Thu, Dec 1, 2022 at 9:38 PM 'Brianna Goldstein' via blink-dev <blin...@chromium.org> wrote:

Contact emails

brgol...@chromium.org, mme...@chromium.org, a...@google.com, mike...@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 to protect against cross-site tracking through the use of side channels. The network partition key consists of the schemeful site of the top level frame and a boolean indicating if the request is coming from a cross-site iframe. "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.

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 a connected socket exists. 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).

Our initial attempt to partition the network state re-used the triple key partition scheme that was shipped for the HTTP cache. This included the schemeful sites of the top-level frame and the iframe. However, in an attempt to land a favorable balance between (1) the performance benefits of shared resources, and (2) the privacy promises of ensuring sites are safely prevented from gaining information about a user’s browsing habits, this new partition key consists of the top level site and a boolean indicating if the request is coming from a cross-site iframe.

Partitioning may reduce Chromium’s ability to reuse network resources.  We’ve enabled network state partitioning in a 1% experiment on Stable. From our experiments, Android navigation times to first contentful paint are increased by around 0.35% at the 50th percentile and 0.17% at the 99th percentile. Cross-site iframe navigation time to first contentful paints is increased by 2.85% at the 50th percentile and 1.35% at the 99th percentile. This represents about a 40 ms increase at the 50th percentile. On desktop, navigation times to first contentful paint are increased by around 1.00% at the 50th percentile (approximately a 10 ms increase) and have no impact on the 99th percentile. For cross-site iframes, the navigation times to first contentful paint are increased by 1.84% at the 50th percentile and 2.05% at the 99th percentile.

The numbers still don't make me leap of joy, but they are significantly more reasonable than the previous iteration.

I'm curious about the p75 numbers, but assuming they are somewhere in between, that probably won't change the outcome.

I wonder if speculative preconnection using the right key could have bought back some of this. I similarly wonder if it could've been safe to somehow publish speculative congestion windows to get rid of slow start in those cases.

But obviously, none of this is a blocker to shipping this. Just ideas for winning back some of the losses (that may enable stricter partitioning if they actually work)

+Kenji Baheux - FYI

 

--
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/CALO2AEcVQz68P41h%3D%2Bb-zp%3DEdFFQ1nSn9OTPqaTQBjgAeXQiXw%40mail.gmail.com.

[Chris Harrelson]

LGTM2

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

[Mike West]

LGTM3.

Thanks for your close collaboration with the security team here; I think the compromise you landed on is both reasonable and good.

-mike

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

[Brianna Goldstein]

Updating this thread to track that this was ramped up to 10% stable this week. Estimated milestones remain:

[Brianna Goldstein]

This is now enabled on 100% of clients.

On Wed, Jan 25, 2023 at 1:57 PM Brianna Goldstein <brgol...@google.com> wrote:

This is now enabled on 100% of clients.