Re: [w3c/ServiceWorker] ServiceWorker verification (Issue #1720)

I see what you're trying to accomplish, but here are my thoughts (hopefully without offending).  Your idea creates the potential of a schism where some clients are operating on the latest service worker, while others are not, which creates a potentially very complex inconsistent environment that could corrupt the shared domain's intent behind updating their service worker, upending the basic premise behind who controls the service worker and forcing domain admins to accommodate potentially many historical versions of serviceworkers if they change frequently enough.  It's doubtful the client will be smart enough to know what's the best decision, particularly if the serviceworker update addresses a critical security flaw/bug.

I believe the existing approach of scoping serviceworkers to domains where all clients update in sync represents the more encapsulated approach, and much easier to digest conceptually.  In other words, if your use case is to control the serviceworker version, then take control by owning a specific domain for the relevant clients, rather than trying to make a shared domain fit, unintuitively inverting control of the updates to the client.

I've been an advocate of disabling serviceworker updates entirely in scenarios where the serviceworker cannot change (IPFS), but you're still looking for updateability, so it's a different use case.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1720#issuecomment-2144984212
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1720/2144984212@github.com>