Re: [w3c/ServiceWorker] Preventing server-forced updates (#822)

MicahZoltu left a comment (w3c/ServiceWorker#822)

> I think if this is to be done, browser controlled version freezing is best choice. Meaning, a "lock this page?" browser prompt that website code doesn't specifically trigger apart from by having a SW. This avoids malicious service workers from locking automatically. Thoughts? I actually dont think this belongs in the SW API at all: else it would be abused.

That is an interesting idea.  I worry a bit about how to expose this to users in a way that is useful to them.  99% of users will just use defaults, so if it is off-by-default then most users are exposed to supply chain attacks for all of their service workers, and if it is on-by-default then most users are exposed to discovered security vulnerabilities.  The app developer likely knows the risk profile better (e.g., "I'm not maintaining this" or "I did 32 security audits of the code and none of the deployment key management process").  Of course, not all developers will make wise decisions either.

The whole situation seems to be full of tradeoffs, and while I'm pretty confident the current selected set of tradeoffs (not allowing any protection against supply chain attacks) is not ideal, it is not obvious to me which tradeoff set is "best" (it probably changes over time).

If we look to the future, supply chain attacks are on the rise and AI is making it easier to write software with fewer security vulnerabilities (when people actually put in the effort to do so), so the right tradeoff today may not be the right trade off in the future.  This makes me lean towards letting individual app/service worker developers set the policy so it can adapt over time, and making it easy for users to excise malicious service workers when they are notified of a problem.

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

Message ID: <w3c/ServiceWorker/issues/822/5693546465@github.com>

Received on Wednesday, 16 September 2026 07:17:15 UTC