Thanks for working on this important partitioning! On Tue, Feb 1, 2022 at 7:01 PM 'Matt Menke' via blink-dev < blink-dev@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 > <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. > 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 > <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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrYvoXcc%2B28rFrHbb1tEJN6HPf1y%3DHdE%2BcGe3tuJwsAnA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAL5BFfV45SMHdDWYE3FzX5kKOR%2Bnz%2BM5CEqioSEE8RfW7%2BGJpw%40mail.gmail.com.
