There is a way to verify the new SW file when it updates and warn the user (but not prevent the update), but for now it's quite hacky.
- There's an "updatefound" event with which you can listen for updates to the Service Worker
- You can request the new SW file from browser cache with: fetch('/serviceworker.js', {cache: 'only-if-cached', credentials: 'same-origin', mode: 'same-origin'})
You would hope that that's all you need (just register for updatefound in the SW file, and when it updates, check the new one, if verifying fails, warn the user). Unfortunately, the new SW can kill the old SW with skipWaiting(). I opened a bug to try and fix that [1].
In the meantime, you could instead listen for the updatefound event in the web application. However, the example fetch() above would go through the new SW, which is no good, but...
- You can bypass the SW from the web app, but only by basically relying on a bug in the spec: if you send a request from an <iframe srcdoc="..."> (or data/object url) it doesn't go through the SW. That will probably be fixed, but a less hacky mechanism will probably replace it [2].
There are some other remaining issues (some of which are discussed in [1]), but given the above the probability of detection of a malicious Service Worker is very high.
- There's an "updatefound" event with which you can listen for updates to the Service Worker
- You can request the new SW file from browser cache with: fetch('/serviceworker.js', {cache: 'only-if-cached', credentials: 'same-origin', mode: 'same-origin'})
You would hope that that's all you need (just register for updatefound in the SW file, and when it updates, check the new one, if verifying fails, warn the user). Unfortunately, the new SW can kill the old SW with skipWaiting(). I opened a bug to try and fix that [1].
In the meantime, you could instead listen for the updatefound event in the web application. However, the example fetch() above would go through the new SW, which is no good, but...
- You can bypass the SW from the web app, but only by basically relying on a bug in the spec: if you send a request from an <iframe srcdoc="..."> (or data/object url) it doesn't go through the SW. That will probably be fixed, but a less hacky mechanism will probably replace it [2].
There are some other remaining issues (some of which are discussed in [1]), but given the above the probability of detection of a malicious Service Worker is very high.
[1]: https://github.com/w3c/ServiceWorker/issues/1208
[2]: https://github.com/w3c/ServiceWorker/issues/1026