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.
On Mon, Feb 7, 2022 at 10:06 AM Mike Taylor <miketa...@chromium.org> wrote: > 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. > > On 2/2/22 1:05 PM, 'Matt Menke' via blink-dev wrote: > > Thanks for the feedback! Responses inline. > > On Wed, Feb 2, 2022 at 12:03 PM Alex Russell <slightly...@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 < >>> 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) >>> >> > 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 >>>> <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? >>> >> > 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 >>>> <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 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+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/CAEK7mvrCJFYRoP7FW5JcwK5DjeCy2iW7j4%2BfN6WUy_zfjuZJDw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrCJFYRoP7FW5JcwK5DjeCy2iW7j4%2BfN6WUy_zfjuZJDw%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/CAEK7mvrjvJKWV6iYTsXE0Df_i2jri3jUvOj3YeenBEWi2kaNKQ%40mail.gmail.com.
