Hey folks, Are there any public updates regarding 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>? (I couldn't find anything regarding the trial's status/results). @Brianna, any insight on current data or what it looks like things are shaping to would be much appreciated.
Thank you! On Monday, February 28, 2022 at 6:14:08 PM UTC+2 Matt Menke wrote: > The cache will use the same key as everyone else, so this will change the > cache to use a single-value key as well. > > On Sun, Feb 20, 2022 at 3:43 PM Johnny Fang <johnny...@gmail.com> wrote: > >> 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/2c63c961-bdd9-4a37-a6af-f8849ece9500n%40chromium.org.
