| > Because trust has to be given somewhere and my business would likely fail if I'm telling you it's encrypted but actually it's not. I think in this case you'd probably want to control the keys, right? > Plus, if you were really concerned you could open up the developer tools, network tab and see the communication to the server and validate that it's only sending encrypted data that you know the server can't decrypt. You can't realistically do this every time; it's an opsec fail waiting to happen. That's why we hash dependencies, use TLS, etc. > Most likely the plain text will only live in-memory in the clients browser (depends on the implementation of the software using the library though). Unless I've mis-understood your concern? This is the "active attack" scenario, where the server is trying to get stuff from your browser you don't want it to have. The authors say that's not part of their threat model, but that's not super satisfying when companies of all types and sizes are suffering huge hacks these days. > Why is this "generally better"? Well for one you don't have to write and maintain a huge-ass JS encryption library. For another, implementation and maintenance is much, much easier. You don't have to: - (write a clientside JS encryption library, but already mentioned) - write serverside validation that the data you're receiving is in fact encrypted the way you expect (you can only do so much here besides) - manage clients using old versions of your library with different sets of primitives when you want to evolve > TLS protects this from third-party observers but anyone server side - now or in the future - can access my data. You just solve this with regular encryption. But if at any point you're trusting a server, e.g. you're loading JS from it (meaning using it at all for 99% of users) or it's storing your keys, you don't have E2EE. The whole point of E2EE is that it's secure in a hostile server scenario, i.e. active attacks. |