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

SRI cannot help this use case as SRI just uses hashes, not asymmetric signatures. SRI is only useful for cross-origin security.

---

I would like to implement signature verification in a service worker in my current project, where unlike in a typical web app, the client code is *user-controlled*; the user would upload a signed app update to the server, and the service worker would check the signature on the files coming from the server – allowing a trust-on-first-use model with regards to the server… if there was a "paranoia mode" for service workers that would disable all the escape hatches, making sure that the service worker could strip `Clear-Site-Data` and that update requests for the service worker would always go through it and never bypass it (and shift+reload would, I guess, ideally display a prompt about breaking the security? or just, like, get turned into a special message for the worker?).

Please, please, please give us **the choice**.

For the vast majority of web apps the current way of working, which would indeed "prevent an attacker from intentionally bricking the app forever", is the appropriate one.

For our paranoid E2EE apps with unconventional update models, we would like to **opt in** to full control of the update process with no escape hatches.

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

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