Left comment about potential harm to end users re power and bandwidth consumption, but overall OK with this. Suggested mitigation for timing attacks aside from partitioning.

Tess: i want to investigate : to what extent does ths proposed spec match the partitioning that other ... already do. And whow can we find interop? There's a storage partitioning discussion in privacyCG group... That may include networking state stuff.

Yves: knowing if the partitioning of network state.. different process, thread for each tab then it's likely that they will be partitioned by default...

Tess: different browsers have different process architectures. Webkit has a network process that is distinct - so you could theoretically share network state between different browser parts.

Yves: ... many things that require buy-in from vebdors.

Tess: lots of moving parts.

Yves: goal is to avoid timing attacks - it's a good thing - but the question is : is there a consensus amongst browsers that it's a good way to do it?

Tess: will do more reading...

Yves: we can leave feedback asking for evidence of interop and vendor buy-in...

Peter: foundation key... everything else is based on - should be talking to the people working on storage partition keys.

Tess: some browsers double-key and some browsers triple-key...

Yves: having current partioning policies depending on caches, network state, etc...

Peter: confusing in their explainer: they propose using the 2-value key as a triple key.

Tess: THERE ARE 4 LIGHTS!!!

Dan: 😂

Hadley: additional network partition key?

Peter: top level site plus the iframe site. Network partition key is where you're using the key. Http cache partitioning ... [in some parts] double keying seems like single-keying...

Tess: I'll do it.

Propose close.

Draft closing comment from @hober:

Hi @MattMenke2!

@ylafon and I took a look at this during a breakout this week. Overall we're really happy that you're tackling this work; it's really important to the future of the Web.

I think whatever we do, SW (and all storage) should ideally be partitioned by network partition key. If you have B->C->B and use the full path as the key, the inner B would have its own SW, which would certainly a bit funky.

We have a separate design review request that came in recently, Partitioning Storage, Service Workers, and Communication APIs, and that for them, cookies and network stack related state is out of scope. We hope that you're working with them to make sure that the SW/storage partitioning key is the same as the one you're proposing.

We note that the multi-vendor effort to coordinate on all these types of partitioning questions is happening in the Privacy CG's storage-partitioning repo, which you're hopefully already aware of and pitching in on, which will help ensure that all implementations converge on the same partitioning keys for each kind of partitioned data or state.

Mostly our concern is that there are so many related-but-distinct efforts going on here, we want to make sure that we don't end up with subtly-different and incompatible solutions in each case of partitioning.

Thanks for bringing this to us, and please don't hesitate to come back to us if there are substantive changes that you'd like us to take a look at.