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 <johnnyfan...@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/CAEK7mvqoZ7kK-njMW_P1JmkYY80zEF5YS2w_Mp2AuvLWz%3DeWug%40mail.gmail.com.
