[kisamoto]

> If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data?

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.

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.

> the unencrypted stuff lives somewhere

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?

> Apps that want "security after TLS" just encrypt it serverside, which is generally better

Why is this "generally better"?

With client side encryption I can see my data, the server and any third-parties cannot. With server side encryption I have to send plain text. TLS protects this from third-party observers but anyone server side - now or in the future - can access my data. There is also the possibility of future breaches as encryption at rest stops at attacker running away with a harddrive but does not stop an attacker accessing a running database and dumping all the decrypted contents.

[mkl]

I think the idea is that the server immediately encrypts your data with a key you provide, deletes your key, and keeps your data encrypted at rest. You're trusting the server to do the last two things, like with client-side encryption you're trusting the server to send you non-compromised encryption code and to not exfiltrate your key. This seems much more equivalent, and in either case a compromised server can get your data as soon as you next access it.

[camgunz]

> 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.