The initial assumption with these types of services is always that an attacker, having compromised their servers, could simply inject malicious code into the browser.
From their docs:
> Normally, when hackers get access to your server, they can change the code that gets sent to customers. For example, they could make the code say "send your password to us". Then, even though they can't read documents immediately, passwords start coming in and they can soon read them.
> To solve this, we're using a relatively new web technology (Service Workers) to install some code which can't be changed without setting off a warning to you. That code then keeps taps on all other code, and checks that it matches the publicly available version on GitHub.
The Service Worker doesn't simply check a signature from the developer, it checks the source code against the version on GitHub. So, to know whether it contains a backdoor, read the code on GitHub.
It's similar to the keybase.io identity model (using popular services as defacto authories). It might be overkill but it could be nice to supplement that with a check of the repo mirrored on e.g. Bitbucket and Gitlab.
Yes, definitely. GitLab's API is very similar to GitHub's, except that it doesn't support CORS. If that's fixed it should be pretty simple to add support for GitLab.
I wonder what do they do with Service Worker updates that the browser normally does every day or so. Do they somehow block install and activate events? If not then the attacker just needs to update the worker and the history repeats.
There's no way to block activate events, but there's a way to delay them. In the meantime, you can check the new Service Worker file against GitHub, and if it doesn't match, warn the user.
The initial assumption with these types of services is always that an attacker, having compromised their servers, could simply inject malicious code into the browser.
From their docs:
> Normally, when hackers get access to your server, they can change the code that gets sent to customers. For example, they could make the code say "send your password to us". Then, even though they can't read documents immediately, passwords start coming in and they can soon read them.
> To solve this, we're using a relatively new web technology (Service Workers) to install some code which can't be changed without setting off a warning to you. That code then keeps taps on all other code, and checks that it matches the publicly available version on GitHub.
Interested to see how robust it is...