Cyph nailed this back with appcaches, later migrating to service workers (and ultimately got a patent for the solution), but the implementation of the solution itself got an entire protocol canned by one browser (HPKP).
Source: did the talk on it.
If you could require the root page be cryptographically signed (but by who?) and optionally prompted for updates then we’re talking.
https://news.ycombinator.com/item?id=15572888
As far as I'm aware that means their approach no longer works (across browsers), and, though it was a fantastic idea, it did require you to trust that they really were throwing their keys away (a trust model slightly weaker than TOFU).
Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive!
That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:
1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.
2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.
All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
Unfortunately can't remember the name of the website nor exactly what it did...
The bootstrap JavaScript file could contain the code needed to download more files, and to download a digitally signed list of file hashes, which it could check against a hardcoded public key. Also the browser would have to remember a flag for that domain to require this same bootstrapping process every time, to stop downgrade attacks.
There’s a range of assurances you could try to provide, e.x. signatures from the author (or even 3rd parties), prompting for updates, etc. It would likely require support from browsers.
At one point I investigated using service workers to intercept subsequent app updates to check signatures but there was no way to prevent the service worker itself from being replaced (probably because it would be easy for a site to permanently “brick” itself in users browssr).