Clarification about ServiceWorker partitioning

[scottpledger]

The ServiceWorker API section of the explainer makes it seem like registering a ServiceWorker from some partition A+B would effectively prevent that ServiceWorker from being able to handle direct navigations to site B, since that would violate the "ExtendableEvents that are fired at the ServiceWorker and may cause it to "wake up" must have a partition key associated with them and match the key in the registration." statement.

Is this understanding correct?

If so, wouldn't this break the Offline Support in 3rd Party Contexts Key Scenario? If that is intentional, it should be called out in that section.

[wanderview]

No. When a navigation occurs the request has an associated environment. That environment represents the "window that has not loaded yet" essentially. We compute the storage key (partition key) from that environment. We can get all the information used in the storage key in order to properly consult the service worker with the same key. For example, the environment will know about any nesting going on when an iframe is loaded. So things like top-level site can be properly checked.

[scottpledger]

Right, but if a ServiceWorker is registered through an iframe from site B embedded in site A, then the storage of assets during the install and/or activate events would happen on the A+B partition. When a direct navigation to site B then happens, resource access will happen from the B partition, not the A+B partition, correct?

[wanderview]

When a direct navigation to site B then happens, resource access will happen from the B partition, not the A+B partition, correct?

Depends on the context of the "direction navigation". Is this a navigation at the top level of a tab? If yes, then its just the B partition. Is this a navigation in a B iframe embedded under A? In this case its the A+B partition.

[scottpledger]

Yes, I was thinking of the former where a user navigates a tab to B.

So, in the case where a user navigates a tab to B directly (after having the ServiceWorker installed from an A+B partition), there would be no assets for the registered ServiceWorker to use to respond to requests, despite a successful install/activate sequence for that very same ServiceWorker.

[wanderview]

Correct. Because if there would be assets for that scenario its identical in behavior to 3rd party cookies and could be used for tracking.

[wanderview]

But that does not break the "offline support in 3rd party scenarios". You are mixing 1st party and 3rd party scenarios, which is different. We require the user to visit the site in a 1st party context if they want it to work offline later in a 1st party context. The same for a 3rd party context.

Also note, partitioning does not occur if A and B are same-site (etld+1). Just FYI in case that impacts your use case.

[scottpledger]

Aah, I was interpreting "3rd party" as being able to enable offline support for a site other than your own (ie, embed an iframe and ask the other site to set up their offline assets).

This doesn't affect any scenarios I currently have, but it does impact a proposal I've been thinking about.