[camgunz]

I'm a little skeptical about this:

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

- I don't think it's possible to restrict parts of your JavaScript env from a server, so even if I get minibone from a CDN, check the hash, and encrypt things clientside the unencrypted stuff lives somewhere, or the server can setup hooks to grab it before I clean it up, etc.

- Apps that want "security after TLS" just encrypt it serverside, which is generally better. This is fine because your users have to implicitly trust your servers.

I'm also unclear on how key management works; is it managed serverside?

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

[datascienced]

This is just defence in depth. But I agree server side feels better for this. OTOH that means it is not really e2e as there is some machine with your unencrypted data on it ready to be hacked.

The ideal solution would be a web api. Seems like this is only available low level with a “don’t use this to roll your own” disclaimer. What would be ideal would be a string->byte[] function in the web api that encrypts (and one that decrypts) with key management delegated to the browser.

[camgunz]

> But I agree server side feels better for this. OTOH that means it is not really e2e as there is some machine with your unencrypted data on it ready to be hacked.

It's true this is a step up from "non-encrypted at rest", which has been pretty troublesome. But the whole point of E2EE is to defend against a hostile server. I can't understand the point of releasing an encryption toolkit, labeling it as "implements E2EE", but then ruling out the very thing E2EE is supposed to address from your threat model. The only reasonable thing to conclude is that this isn't E2EE. I'm not saying it's dangerous, or even that it's worthless, just that it's mislabeled.

[sroussey]

This would pretty much block subpoenas for user data, since the server doesn't have it.

[camgunz]

It sounds like they're doing serverside key management (maybe not?); if that's true they do have it.