If the service is hacked and if the "update found" alert isn't a very rare event, users will not validate every single update against GitHub, and a place check would see an update, allowing the attacker to push code when an update is made. A good portion of users will run the infected code before the service is shutdown.
I never said it was easy. I said it was possible and doable.
First, you said “easily”, so I thought it must be effortless. Second, only paranoids and security conscious individuals will ever validate against GitHub. Your average Joe really doesn’t care. I do however agree with you that security must be hardened as much as possible, but your hypothetical case is weak. It will work for any software that auto update. Browser? OS? Let me give you another one, what if a satellite flies over your head and capture your password as you type? Oh and how about your CPU? Should we start making our own hardware now? You know.. can’t trust anyone after all.
Yes, I did and was wrong. Easy does not mean effortless and I also meant it in a context where the machine was already compromised, but didn't make that clear.
> only paranoids and security conscious individuals will ever validate against GitHub.
The op expects this to happen anytime a user gets a message saying the code is updated. I agree that no one will do it and it'll become a click through.
> but your hypothetical case is weak. It will work for any software that auto update. Browser? OS?
I state in another post that you are always subject to this issue. However, when running local software, and not at the mercy of someone else's computer/server, you have the ability to choose when and how you update.
I can also validate all code against signatures and public logs before running it, which is not something that can be done with service workers or any website in general. twiss says as much themselves: https://github.com/w3c/ServiceWorker/issues/1208
And yes, there is normally an implicit assumption that the hardware is not spying on you simply because there are no alternatives.
It really comes down to how often I need to validate my trust and how easy it is to do so.
Web apps, under the best conditions, are hard to grab and pull all the source into external files for examination and almost impossible to do so before executing it, baring using tools like curl or wget, and running the js yourself to figure out what else needs to be downloaded. Not to mention that needs to be done every time I access the app.
With a traditional app or is, I could (not that anyone does) verify the code (which for f/oss is easy to obtain) before I compile it myself. (Where I'm trusting the compiler, yes.)
I'm not trying to argue that there is a perfect method. I'm arguing that this application isn't even in the running for a good, fairly trustable method. I don't believe it solves the fundamental issue of having to trust the code download every single time, regardless of their service worker check because it itself is not protected. We'll, protected by the vigilance of the end user, which is where we started anyway.
