3 ms·
You're assuming the old version of the service worker will be there and running. That isn't a good assumption. It will normally be there, but it doesn't have to
by jimktrains2 9y ago
You're assuming the old version of the service worker will be there and running. That isn't a good assumption. It will normally be there, but it doesn't have to be. There will always be circumstances where I'm downloading it for the first time, even in the same browser and computer.
Also, step 7 on https://w3c.github.io/ServiceWorker/#update-algorithm https://w3c.github.io/ServiceWorker/#update-algorithm says that updating the service worker bypasses the service worker. How do you then validate that new service workers haven't been meddled with?
- twiss 9y agoThat's blocked on https://github.com/w3c/ServiceWorker/issues/1208 https://github.com/w3c/ServiceWorker/issues/1208. However, there's also an alternative option to make updating the Service Worker unnecessary, by making a "stub" Service Worker which downloads, validates and executes the rest of the SW code. Then, whenever the "stub" Service Worker updates, it's likely a breach and we can warn the user accordingly.
- jimktrains2 9y agoCode you can't update is normally an expensive liability in the case that it's not perfect. Also, then the stub service worker is subject to the same problem it's attempting to solve. I'm still left in a situation where I need to trust you don't mess up. You even say it yourself: > (Of course, we can't prevent the update, but we can at least try to convince the user to close the web app before it steals their private keys.) At that point, the game is up.