![](https://lemmy.ml/pictrs/image/a146cb96-f93f-4dc6-a584-5b37adb9d7f8.png)
![](https://sh.itjust.works/pictrs/image/c38fd5ff-821e-45c9-b2ee-957d0321d2e2.webp)
Regarding your browser-based thing: what are the specific capabilities of the “threat agents” (in your threat model’s terminology) which your e2ee is intended to protect against?
It seems like the e2ee is not needed against an attacker who (a) cannot circumvent HTTPS and (b) cannot compromise the server; HTTPS and an honest server will prevent them from seeing plaintext. But, if an attacker can do one of those things, does your e2ee actually stop them?
The purpose of e2ee is to protect against a malicious server, but, re-fetching JavaScript from the server each time they use the thing means that users must actually rely on the server’s honesty (and HTTPS) completely. There is no way (in a normal web browser) for users to verify that the JavaScript they’re executing is the correct JavaScript.
If you run a browser-based e2ee service like this and it becomes popular, you should be prepared that somebody might eventually try to compel you to serve malicious JavaScript to specific users. Search “lavabit” or “hushmail” for some well-documented cases where this has happened.
For some reason that article doesn’t link to it, but it is a real tweet he made in February (and didn’t even delete after being called out for the highlighted search terms in his screenshot).