Feature Policy: Service Worker fetch handling

kinu commented 5 years ago

Proposing a feature policy that controls Service Worker fetch interception, e.g. bypassing service worker if set to 'none' even if the document were within the scope of some SW. The feature name could be something like service-workers or service-workers-fetch.

Example scenarios:

A site wants to temporarily disable Service Worker interception after its cached assets become stale or for some other reasons, enabling a semi-kill switch for SWs (in a perf-efficient way).
A site wants to disable Service Worker for any third-party iframes.
A site wants to disable Service Worker only when the page is rendered from a Signed Exchanges (SXG).

A caveat is that this doesn't work when the site's Service Worker swallows the main resource request/response, but given that this is primarily an opt-in feature the site should be able to make its SW behave appropriately if it wants this to work.

(I'm having slightly mixed feeling about this idea, but it seems this could still be useful in certain cases so let me propose.) /cc @yoavweiss @jakearchibald @RByers @jyasskin

clelland commented 5 years ago

Service worker interaction is hard, given that the worker may already have been instantiated by a different client, which wasn't under the same policy restrictions.

That said, it might be possible to restrict a worker's interaction on a client-by-client basis, or even prevent a page from being controlled by a service worker at all. (We won't just be able to block the registration call, we'd actually have to ensure that a worker wasn't selected to load the page in the first place, I think.)

I'm also not sure that this is a good idea; just commenting on the technical feasibility. I'd be interested in hearing what the actual use cases are.

mfalken commented 5 years ago

I think @clelland already alludes to this, but the interaction with the rest of the service worker API may get weird, some design choices this would raise:

Does the skipped client show up in ServiceWorkerGlobalScope.clients?
Is the client's navigator.serviceWorker.controller null?
Can the client use navigator.serviceWorker.getRegistration() to find the service worker whose scope it's inside of?
Does the client affect the update lifecycle?
Can the client use navigator.serviceWorker.register() to make a new service worker?
Can the service worker use clients.claim() to control the client?

Probably would depend on use cases.

My inclination is probably to make it all or nothing, if the client is skipped for the fetch event it should not have a ServiceWorkerContainer at all and should not be exposed to any service worker APIs as a client.

kinu commented 5 years ago

Thanks, very good questions. To the fundamental question by @clelland yes I supposed this API would be client-by-client basis one.

For @mattto's questions: my initial thinking is that this could be all yes, but just service-workers mode of all the fetch requests from the context would be set to none. I feel restricting registration can be done with a separate policy or maybe with a different parameters.

mfalken commented 5 years ago

I see. I guess the risk is small but that creates a new situation could surprise some sites, e.g., suddenly getting an in-scope client without a corresponding fetch event for it; expecting to talk with the in-scope client via both message and fetch events but not getting fetch events. Same from the client side, it could be weird to have a controller but have fetches skip it.

Feature policy looks like it applies to nested iframes so it could happen even if the site didn't opt-in to the policy.

For insecure contexts a similar thing happens with nested frames, but in that case the service worker API is totally unexposed.

But yea, not sure if this matters.

ithinkihaveacat commented 5 years ago

I don't quite follow what's being proposed here. So we're talking about a request/response pair something like:

GET https://example.com/

HTTP/2 200
content-security-policy: service-workers 'none'
content-type: text/html
...

<html>
...
</html>

Is the proposal that this would disble fetch interception for all subsequent requests to example.com? Across all tabs/clients? For sub-resources only?

If it's for all subsequent requests, if feels like it behaves a bit more like Clear-Site-Data (applies to all subsequent requests) than the typical CSP restrictions (applies to current page only?).

w3c / webappsec-permissions-policy

Feature Policy: Service Worker fetch handling #280