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

>I can't quite get my dead around the use cases.

Imagine we have created a PGP app to encrypt messages, and we serve it at https://mypgpapp.com. It generates private keys and stores them in IndexedDB, then lets the user encrypt messages with those keys so they can copy their encrypted messages to send via email.

So far, our security is pretty good. Since we used HTTPS, we can be reasonably sure the user won't load a backdoored script from some attacker. However, what happens if *our server* gets compromised? If an attacker had access to it, they could deploy an update to the registered SW script which fetches code that will upload the private key somewhere. Now it's game over for any user who visits the app and has their SW script caching expire.

>How does the current update model prevent this?

By this example I meant that when the app is being hosted on servers owned by some other party, the host who actually runs the machines could deploy backdoored code. But if a SW prevented forced updating, it could be built to check that the updated version is cryptographically signed by the author before accepting updates. Then, the author can sign the resources offline, and never has to give the private key to the host to have the users verify authenticity.

CSP doesn't solve this since the malicious scripts are coming from a whitelisted domain.

(I suppose I didn't need to mention integrity, authenticity was the important part).

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/822#issuecomment-174782878