I'm planning on making a library to make it easy to make a web app trust-on-first-use. The main blocker is https://github.com/w3c/ServiceWorker/issues/1208 (which would fix the non-critical but less-than-ideal issue described under "Service Worker lifecycle" in the blog post).
Trying to achieve the trust you are is very interesting.
I put up a simple, installable, progressive offline app of this crypto here: https://semocracy.com/
This app doesn't yet contain the mediations you talk about of checking the sw code against a 3rd-party reference and warning when an update doesn't match the reference.
Even considering the limitation you discuss when the new worker terminates async requests of the old worker, checking a public log is useful -- do you have any code or boilerplate I could plug in to achieve that?
Also, would the following be useful? The worker stores the 3rd party log / reference at intervals in local storage, and then when updatefound occurs, it doesn't need to make a network request, it can check (not perfectly) if the new sw code matches the stored reference. Sometimes there will be false negatives because the reference updated before the sw checked, but I think there would be no false positives. As long as the new worker can't get to localstorage before the old one checks, could be okay.
> do you have any code or boilerplate I could plug in to achieve that?
My implementation is at [0]. It basically fetches a list of files and hashes from GitHub, based on the commit in the X-GitHub-Commit response header (but you could just fetch master instead). You'd have to replace that github url at the top with [1], and update the two functions near the top. (If you're gonna fetch from master, also make the caching in getGitHubResponse less aggressive.)
Also take a look at main.js and main.css in that commit, it contains code to notify the user.
> it can check (not perfectly) if the new sw code matches the stored reference
The problem is that currently, there is no way to get the new service worker code without a request. Even if the sw.js file is in cache, there is still a race condition between the cache responding and the new sw terminating the old one, and more often than not, the new sw wins. That's why I was talking in [2] about an alternative solution of adding a property somewhere that gives you the new sw code.
What you can also do, and which I'm doing, is to fetch the sw.js file in the updatefound event of the page, and not of the old service worker. However, it's not strictly guaranteed that there is a (visible) page, for example, a third-origin website could embed yours in an iframe, triggering an update. [3]
I put up a simple, installable, progressive offline app of this crypto here: https://semocracy.com/
This app doesn't yet contain the mediations you talk about of checking the sw code against a 3rd-party reference and warning when an update doesn't match the reference.
Even considering the limitation you discuss when the new worker terminates async requests of the old worker, checking a public log is useful -- do you have any code or boilerplate I could plug in to achieve that?
Also, would the following be useful? The worker stores the 3rd party log / reference at intervals in local storage, and then when updatefound occurs, it doesn't need to make a network request, it can check (not perfectly) if the new sw code matches the stored reference. Sometimes there will be false negatives because the reference updated before the sw checked, but I think there would be no false positives. As long as the new worker can't get to localstorage before the old one checks, could be okay.