A problem with isolating service workers is that they are somewhat intrinsically linked to globalThis.caches aka the Cache API, a typical origin-scoped storage API. And that in turn is expected to be the same as localStorage or Indexed DB as sites might have interdependencies between the data they put in each.

Possible solutions:

1. Using the "storage access" principal is what dFPI does and creates a strange transition scenario in that you have the old and new service worker that can each talk to a different group. At that point all the third parties the old service worker is in touch with can be given the first party data from the new service worker. Also, once B embedded in A is granted storage access, A might be able to tell some additional things about B, but I'm not sure how avoidable that is anyway.
2. We could attempt to disable service workers (as well as BroadcastChannel and shared workers) when a document does not have storage access to avoid the weirdness of being able to communicate with documents in a third party and first party state at the same time. (An assumption here is that sites do not assume that if they have storage they also have service workers (as well as BroadcastChannel and shared workers).)
3. We could scope service workers (as well as BroadcastChannel and shared workers) to the agent cluster (or perhaps browsing context group).
   1. If we did this unconditionally it would largely defeat the point of BroadcastChannel and shared workers, which is to be able to share work across many instances of an application (e.g., consider having multiple editable documents open in separate tabs). And it might also defeat the clients API in service workers.
   2. If we only did this for third parties we would again hit the problematic transition scenario when there's a popup. Though perhaps it's reasonable to consider an opener popup (as opposed to a noopener popup) in a special way to encourage sites to adopt Cross-Origin-Opener-Policy and get their own browsing context group? I.e., while you get first-party storage, you still get don't get top shelf communication channels.

Based on this I still favor 2, but 3.2 is also interesting.

Filed https://github.com/privacycg/storage-partitioning/issues/9 to discuss this with a wider group of people.

To be clear, 2 is roughly the status quo in Firefox right now:

• BroadcastChannel runs a storage check and throws if storage is denied, modulo carve outs for:
  • opaque origins (null principals)
  • partitioned storage (when partitioning is enabled for the cookie jar, falling back to denial)
• SharedWorker runs a storage check and throws if storage is denied and also throws if partitioning is decided upon but not enabled for the cookie jar (but no carve-outs for opaque origins).
• ServiceWorkers:
  • Refuse to control clients for which storage isn't explicitly allowed when intercepting for fetch and fast pathing for no-fetch and just for general API usage.

Can this be closed, Tim? Or is it still relevant for FPI specifically?

FYI: tor-15563 is their ticket. Since SWers aren't currently used in PB mode (Bug 1320796) then TB is not affected (although TB users do flip starting in PB mode) and the issue is like P5 - so there isn't really a specific FPI + SWers bugzilla (if there is I cannot find it)

We have a service worker test for dFPI, which kinda covers what we want to test here. So, I think we can close this bug for now.