consider allowing a non-scope identifier for registrations

[wanderview]

Currently registrations are identified and keyed based on their scope string. This works well for most cases, but can create difficulties for folks that want to modify the structure of their site.

For example, consider a site that has a product hosted at a location like:

foo.com/product/bar

But they want to re-organize their site to remove the "/product" sub-path since its needlessly verbose. They want to move to:

foo.com/bar

In this case they must unregister their old scope and register their new scope. Both the removal of the old registration and the installation of the new registration are async operations that can take time to complete. In addition, both of these service workers may wish to manage the same underlying resources. Trying to coordinate between the service workers to avoid accidentally breaking something can be difficult.

As an alternative, we could allow the service worker to specify a separate origin-unique identifier. For example:

await navigation.serviceWorker.register('sw.js', {
  scope: '/product/bar',
  id: 'product-bar',
});

Then when the site registers a service worker on a different scope with the same id, it would be treated as an update of the service worker that modifies the scope.

While there are uses for this today, this sort of thing may be a lot more useful in a world where the scopes pattern matching has been implemented. With the scopes pattern matching sites may want to mutate their scope pattern over time to cover more sites or to fix mistakes in the pattern, etc.

Note, there is also an effort to add a unique identifier to manifests for webapps in w3c/manifest#586. I asked if they wanted to try to unify with service workers, but the feedback was that they should be separate.

The manifest issue also suggests the identifier should be a URL instead of an opaque string. I don't have a strong feeling about, although I feel it might confuse people into thinking it somehow operates as a scope.

Edit:

Final proposal is summarized in #1526.

Security/Privacy Considerations:

This proposal does not change the security or privacy characteristics of service workers:

• The id value does not expose any additional information about the device or user to the site.
• The id value has no cross-origin communication or interaction at all.
• All existing restrictions like https://w3c.github.io/ServiceWorker/#path-restriction are maintained.
• Modifying a registration's scope will fail if it conflicts with a scope currently owned by another registration. This prevents accidental scope confusion. (But this is more of footgun issue and not a security issue.)

[asutherland]

This seems reasonable. Presumably this would be spec'ed so that this couldn't be used as an end-run around the https://w3c.github.io/ServiceWorker/#path-restriction mechanism by stealing a registration with actively controlled clients that could not otherwise be controlled by a given script?

[wanderview]

I'm not sure I understand, can you expand on the risk you are thinking of?

Perhaps the question is around what happens in the scenario:

1. Old version is active and controlling clients.
2. New version is installing and the new scope would not match the controlled clients from (1).
3. New version calls skipWaiting().

What happens? It seems skipWaiting() should either (a) cause the clients that no longer match the scope to stop being controlled or (b) fail to promote new version to active if there are non-matching controlled clients in play.

[asutherland]

Yes, that. Thanks!

[jakearchibald]

I guess it would reject if a service worker changed scope to a scope that already existed on the origin?

await navigation.serviceWorker.register('/sw.js', {
  scope: '/product/bar',
  id: 'product-bar',
});

await navigation.serviceWorker.register('/sw2.js', {
  scope: '/bar',
});

await navigation.serviceWorker.register('/sw.js', {
  scope: '/bar',
  id: 'product-bar',
});

[jakearchibald]

As a compatibility path, what if id defaults to the scope?

// Past me did this:
await navigation.serviceWorker.register('/sw.js', {
  scope: '/product/bar',
});

// But it's ok, I can move it:
await navigation.serviceWorker.register('/sw.js', {
  scope: '/bar',
  id: '/product/bar',
});

[wanderview]

I guess it would reject if a service worker changed scope to a scope that already existed on the origin?

It could, but I think it would be consistent with current behavior to unregister the sw2.js registration in your example.

Tangentially related to this is something I've been thinking about for the scopes pattern matching effort. If we add multiple scope strings for a registration (as recommended from the TPAC meeting), then the overlapping scope scenario here could have just a partial overlap. I think we would probably want to treat them the same as what we do here, though; error or replace.

As a compatibility path, what if id defaults to the scope?

This makes sense to me, but I haven't thought it fully through.

[wanderview]

I would like to move forward on this with the following:

1. id value permits any kind of string. It does not have to be a URL like scope.
2. id defaults to scope value.
3. Spec will be updated to operate on id value everywhere we currently use scope for the identifier.
4. Moving a registration to a scope that exactly matches another existing registration will replace that registration. From an API perspective this is similar to calling register() again on the same scope with a different script URL, etc. I think throwing would be unexpected.

@jakearchibald @youennf @asutherland @jungkees please let me know if you have any comments or concerns with this. Thanks!

[asutherland]

@wanderview Elaborating on my original concern in #1512 (comment) I'm not sure from your description in #1512 (comment) how this prevents an end-run around https://w3c.github.io/ServiceWorker/#path-restriction by stealing existing controlled clients. Can you expand on how your prior comments interact with your current proposal given the following scenario:

• A SW was installed on a site with scope "/send-money/" and defaulted id is "/send-money/". It hosts a UI for sending money that's protected by some type of 2nd factor code.
• A partial site compromise allows an attacker control over static content hosted at "/about/" including the ability to host a ServiceWorker script there, but no higher.
• A user goes to /send-money/ to send money. They click on the "/about/" link to open in a new tab or a pop-up because they want to check something out or there's some ill conceived iframe stuff going on.
• The "/about/" page does register('/about/evil-mitm-sw.js', {id: '/send-money/', scope: '/about/' }) and "evil-mitm-sw.js" does skipWaiting() and is thereby able to take control of the existing controlled clients and intercept their network requests. It re-writes the target bank account numbers in the intercepted fetch requests for the transfer or something, which is a plausible nefarious thing that CSP can't stop, why not.

Note that I'm not suggesting that https://w3c.github.io/ServiceWorker/#path-restriction is going to moot the massive badness of such a hypothetical compromise given that same-origin is where the actual security boundary is, but https://w3c.github.io/ServiceWorker/#path-restriction is an existing protection that is stricter than same-origin and we should be intentional about weakening or removing it.

[wanderview]

Sorry, I did not address it in my previous comment. I propose:

5. Changing the scope of a registration would still need to pass the path-restriction/ServiceWorkerAllowed check just like if registered from scratch. (I assume we do this when changing the script URL on a registration today?)
6. By default the new service worker will not activate if there are existing controlled clients.
7. skipWaiting() will cause the new service worker to activate and any existing controlled clients not covered by the new scope become uncontrolled via a controlchange event.
8. The registration.scope attribute reflects the scope associated with the oldest worker, so the scope attribute does not change until the new service worker activates.

The main ugliness here is that the scope is now associated with a version of the service worker and not the registration as a whole. Its a worse form of the updateViaCache change on the registration previously.

Should I expose a ServiceWorker.scope to reflect the scope of each version? I'm not sure it would be used in the algorithm, but it might help folks understand that it can change. Not sure on that one.

[wanderview]

Actually, I kind of like being explicit about the ServiceWorker having a scope and I think I would make some of the algorithms use that.

[asutherland]

That sounds reasonable to me, thank you. I recall the path-restriction check to be self-consistent and having the scope be per-ServiceWorker should make things work nicely. Pedantnit: I am assuming s/controlchange/controllerchange/ was intended for the event.

[jakearchibald]

Moving scope to a service worker level thing sounds fine, and I agree it should be exposed to script.

skipWaiting() will cause the new service worker to activate and any existing controlled clients not covered by the new scope become uncontrolled via a controlchange event.

I agree this as the only sensible thing to do. However, I don't think skipWaiting should cause clients to switch to another service worker registration, or switch from no registration to a registration. We have clients.claim for that.

Moving a registration to a scope that exactly matches another existing registration will replace that registration. From an API perspective this is similar to calling register() again on the same scope with a different script URL, etc. I think throwing would be unexpected.

I don't think this is the right model. Calling register with a different script URL is altering one registration, whereas the scenario above is moving one registration and unregistering another.

const reg1 = await navigator.serviceWorker.register('/sw1.js');
const reg2 = await navigator.serviceWorker.register('/sw2.js', { id: 'foo' });

I'm assuming that:

• reg1 has an id of / and a scope of /
• reg2 has an id of foo and a scope of /

Either:

• The second register fails because there's already a registration at that scope.
• The first registration implicitly unregisters.

In the second case, reg1 would continue to control clients until they go away, or reg2 claims those clients.

My only worry about this behaviour is it involves data loss. Things like push registrations, bg fetch, associated with reg1 would be removed. Could that be a gotcha?

[wanderview]

I don't think this is the right model. Calling register with a different script URL is altering one registration, whereas the scenario above is moving one registration and unregistering another.

I can make it reject for now and we can consider loosening it in the future.

I do worry a bit about some sharp edges for sites in the future with my pattern matching scopes work. We want to support registrations with multiple scopes. If a site is migrating from having two registrations to a single registration that covers both of the old scopes how do they reasonably do that migration? It may be hard to ensure the timing of the registration/move of the final registration vs the removal of the old registration. They certainly can't do it atomically.

Maybe we could consider adding a further unregisterConflicts:true option to register() that would opt-in to removing conflicting registrations automatically.

[wanderview]

Work-in-progress draft PR here: #1526