1. The author is correct that the real purpose of E2EE, and the reason companies expend considerable R&D resources on it, is to have a plausible excuse not to produce records; and to protect against malicious insiders. That's it. You don't have real "end-to-end" encryption unless you or someone you really trust has thoroughly audited the hardware and software stack. Obviously, almost no-one has the resources to do that.

2. The author's argument also applies to the App Store distribution model. Apple or Google may choose or be compelled to publish an app or OS update that is only visible to certain users. By default, iOS and Android install app updates without user approval. (You can and should, of course, disable that if you're concerned about such things.) The key difference is that app developers can't mount targeted attacks in this manner; only Apple and Google can.

3. Here's a simpler iteration on the author's idea for applying subresource integrity to service workers: an "immutable" variant of the https scheme that requires the lowest level of the domain to match a hash of all resources loaded on the page. JS is only enabled if the hash matches.

https+immutable://mhzwdnyyv5turofr8kkivabqyvamg7yteeitzwrg64o00taouw.signal.org

As far as I can tell, this mitigates the issues outlined by the author, and has the following nice properties:

- You can bookmark the URL and be certain that the code can't change in future.

- You can share the URL with someone else and be certain that they will be served the same code.

- Not affected by client-side state (e.g. cache) and thus can't be abused for fingerprinting.

- No risk of bricking the app in perpetuity.

- Thanks to Certificate Transparency, the existence of any published update is public knowledge.