NetworkIsolationKey partition features rollout experience

[Aleksey Khoroshilov]

Hi all!

We see an amazing work you're doing on the storage partitioning and network isolation, and we're eager to enable some of Partition/Split*ByNetworkIsolationKey features for our users. To be safe we'd like to ping you and maybe hear some info about compatibility or other issues we can expect or should be wary of when we will enable these features.

Can you share some insights?

[Matt Menke]

We're experimenting with 5% on stable with everything but cache partitioning enabled (which is at 100%, I believe), and have had no reports of any breakages.

The only issue we've seen from our metrics is performance loss, particularly with cross-site iframes, since we key on top frame site and frame site.  shivanisha@ and jkarlin@ would be more familiar with the effects of enabling cache partitioning, but with enabling everything else on top of cache partitioning, frame load times in general are within the margin of error (say, a percent or so), while cross-site iframes are typically within ~5% of where they are without partitioning, with more of the regression seen, proportionally, below the 75th percentile of load times.

Wanting to get a better handle on the performance regressions is the sole reason we're not at 100%.

One thing to be aware of is that while enabling kSplitCacheByNetworkIsolationKey independently of the others works totally fine, a lot of the other features are interdependent in unexpected and confusing ways, and don't really work quite right alone, though keeping them separate was useful while implementing them.  For example, kPartitionExpectCTStateByNetworkIsolationKey affects an Expect-CT cache used both above and below the socket pool layer, so enabling it without also partitioning the socket pools doesn't quite work right, despite things apparently working fine with that combination of flags, unless you dig into the specific cases where it matters.  I'd recommend enabling them all together, if you plan to do so.

There are still a couple areas in the network service that still aren't partitioned (cert verifier, auth cache, HSTS, off the top of my head) that we need to figure out, but they should all work fine with the partitioning features enabled.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/3ca79077-b922-45bb-a1af-440d4614a274n%40chromium.org.

[Aleksey Khoroshilov]

Matt, thank you for the detailed dive into the process! That's very valuable.

> We're experimenting with 5% on stable with everything but cache partitioning enabled (which is at 100%, I believe)

I was curious why SplitCacheByNetworkIsolationKey is not enabled by default in code or any study, but then found [1] and it makes sense now.

On a side note, looking at other browser vendors I wonder if you compared the current Chromium partitioning state to the Firefox or other browsers implementation? Maybe there is something particularly exciting we can all benefit from.

1. https://chromium-review.googlesource.com/c/chromium/src/+/2503343

[Matt Menke]

Chrome uses (top frame site, frame site, iframe document bool) as the key, to better protect against cross-site frames within a page spying on each other.  FireFox just uses top frame site (I believe Safari does, too).  There's a perf/protection tradeoff there.  We experimented with both, but decided to go with the more secure approach.

[Aleksey Khoroshilov]

> Chrome uses (top frame site, frame site, iframe document bool) as the key, to better protect against cross-site frames within a page spying on each other.  FireFox just uses top frame site (I believe Safari does, too).  There's a perf/protection tradeoff there.  We experimented with both, but decided to go with the more secure approach.

Gotcha! One more thing. We would like to call out teams or individuals who worked on these features and made this partitioning possible. Can you maybe list everyone involved so we can thank you all for this work when we launch it?

[Matt Menke]

On Mon, Sep 27, 2021 at 4:32 AM Aleksey Khoroshilov <akhoro...@brave.com> wrote:

> Chrome uses (top frame site, frame site, iframe document bool) as the key, to better protect against cross-site frames within a page spying on each other.  FireFox just uses top frame site (I believe Safari does, too).  There's a perf/protection tradeoff there.  We experimented with both, but decided to go with the more secure approach.

Gotcha! One more thing. We would like to call out teams or individuals who worked on these features and made this partitioning possible. Can you maybe list everyone involved so we can thank you all for this work when we launch it?

Shivani Sharma (sivanisha@), Josh Karlin (jkarlin@), David Benjamin (davidben@), Yao Xiao (yaoxia@), and I all contributed.  The NetworkIsolationKey is plumbed through a large number of consumers of the network stack, so a lot of feature owners have also contributed by updating their code to correctly use NetworkIsolationKeys and helping with reviews, so it would be difficult to assemble a list of all contributors.