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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>

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
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
?

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 discussionsIntent 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+unsubscr...@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.

Reply via email to