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 <https://bugs.chromium.org/p/chromium/issues/detail?id=1294930> Is there a public method to track the experiment/feature's exposure, or is that internal to Google? Thanks, Johnny On Monday, February 7, 2022 at 8:47:28 PM UTC+2 Matt Menke wrote: > 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 <mike...@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 <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 >>>>> <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+...@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+...@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/0553d233-bdf1-4bda-8145-856890830d4fn%40chromium.org.
