I'm trying to solve the problem of "how can I trust an e2ee messaging app on the web". Basically, the issue is that while e2ee messaging apps (think WhatsApp, Signal) assume no trust in the server, the user still has to trust the client -- and on the web, the server controls the client. Desktop and mobile platforms solve the trust issue in multiple ways: code signing, app stores, reproducible builds, publicly available hashes etc. On the web, none of that's possible. That's why Signal doesn't have a web client. WhatsApp does, but using it defeats the point of e2ee.

My proposed solution is to use Service Workers to cache a web app in the browser and employ clever tricks to prevent the server from pushing updates to either the Service Worker or the caches. This way the user can then control any updates and verify new versions using means that are already familiar from other ecosystems: comparing hashes, trusting only signed code, etc.

The goal isn't to develop a new e2ee messaging app. Instead I'm prototyping something that resembles an auto-update framework like Squirrel [1], only for web apps. Ideally it will be largely "plug and play", i.e. you could take the existing WhatsApp web app, serve it using the updater framework, and your users would now have a trustworthy version of WhatsApp.

So far I have a small amount of PoC-level code validating several small parts of the larger concept. For instance, I'm fairly confident that I will be able to reliably prevent forceful server-controlled updates, which is a core requirement. Right now I'm in the process of formalizing a threat model, hoping to spot any gaps before I move forward with the implementation.

Feedback on the idea in general would be highly appreciated, but I'd also love to hear any more specific concerns regarding technical solutions, UX, etc.

[1] https://github.com/Squirrel