Eve is not the threat. Eve is going along serving email for Alice and Bob just fine for quite a while.

Then one day Fred compromises Eve. Fred can dump data directly out of Eve's database. Depending on how Fred gains access, full disk encryption, database encryption, row-level encryption, etc. might or might not present themselves as layers of security that he must bypass. If Fred has compromised the running service, he will likely have access to the data and any keys, source material needed to derive the keys, or external decryption mechanisms (HSMs, database-side services) from within the service itself.

If the messages inside of the database have been encrypted on the clients with keys not held in the server (E2E), Fred now has another layer of defense in front of him, only this one requires Fred to inject script into the clients to scrape the necessary keys. When the client is running Javascript in the browser, this is obviously easier than on clients deployed through some other mechanism, but still more difficult than being able to get everything Fred needs in memory in the server.

Mainly, it's another layer of defense, and if the service is using it for other clients, a browser-based client would need to have it to function anyway (even if that weakens the security of the users choosing to use it).

An alternate scenario is that Eve is also not a threat, but is instead a business that doesn't want the liability of having certain material in the plain inside of its premises ever.

But Eve is where the attacks are going to come from. Whether it's Eve's intention, or was under coersion by Fred makes no difference to the end user. Browser E2E encryption is at best marginally harder to break, but it gives the user a bigger sense of privacy than it deserves, may be to the detriment of the unlearned user.

If as Fred my window of opportunity before I'm detected is small, I might only be able to get keys from users that are active within a small window. I may have to deal with CDN TTLs just to get my code to those users in the first place. The deployment setup might make it a little harder to change the code than just modifying a plaintext file on disk on the server (personally the project I'm working on right now packs static assets into the server binary making them easy enough for Eve to update, but a bit more effort for Fred). In more complex scenarios, there may be many things standing between Fred and injecting code into the browser that aren't in the way of reading the database.

It really depends on the specifics of the threat that you're modeling for and how your environment works. For example, if we only focus on scenarios in which we are concerned about an attacker that has wholly compromised the service as you are describing here, we would similarly conclude that TLS serves no purpose as the attacker is already receiving the decrypted data at the other end of the pipe.

One great example of this Eve is https://mega.nz - by design their servers never have access to the encryption key for any uploaded file, and files are shared by including said key in the hash of the URL. This is done for perfect legal deniability of any material on the site. As long as you trust Mega to not alter their code (you can defend-in-depth against this with various methods, including running an open-source client), and you send sharing links only to trusted parties, the content of your data cannot be detected.

https://mega.nz/SecurityWhitepaper.pdf

Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple.

The browser is really just another delivery mechanism for code that runs on the client and you can verify the hash of code delivered from the server just as you can with desktop or mobile apps. All E2E encrypted apps will require some trust from the author except when they are open source and you can verify the hash.

At a minimum, the E2E could be viewed as a best-attempt at security and would provide protection against information becoming exposed in the event of a database breach.

EDIT: To be clear, the browser is a code distribution platform, just like the App Store. Both the browser and App Store can distribute both closed and open source apps, and both closed and open source apps can securely implement E2E encryption. In both cases you placing trust in the author of the code, except in the case that it is both open source AND you verify the checksum, in which you can be reasonably secure that you know exactly what code is running.

Not exactly the same, and the difference is important.

An iOS app is an iOS app is an iOS app: every user gets the same app. Malicious updates to bonafide releases cannot be targeted to specific users and will be distributed to everybody. Same for playstore.

A browser effectively requests an update, directly, every single time the app is started.† Updates can be targeted very precisely, both to a time and a user.

Circumventing this difference is not a detail, and eliding that when talking about browsers, honestly, implies regular use. Including the behaviour described above.

† An exception is a trick using web workers and github which appeared on HN a while back. That was an actual novice use for JS crypto.

Crypto happening in the browser (or any browser-based “app”) is not ever going to be ok from a dozen different security perspectives. That makes Node the only possible platform where it makes sense, and that’s what I said.

What dozen perspectives?

> Any of the other examples can easily be decompiled or reversed. reply ... I don’t think I said any of those things?

Sorry, I interpreted "decompiled or reversed" as insecure. I'm curious why there's a problem if the frontend code can be reversed? Or another way to ask this is, how is that any different from an open source app?

Even if there were no specific attack vector guarded by client side encryption, others reasons for JS-/client-side encryption may exists.

I could imagine some legal reasoning like 'The data was already encrypted when the client stored it on our servers, we had not knowledge of the illicit content.'.

For a share-hoster that alone might be reason enough to feel the need for JS-/client-side encryption.

Is that too far fetched?

We also provide SDKs for Android and iOS. They protect against more threats as you can install an app you know the provenance and the app doesn't auto update like a website that you reload every time you open your browser. If you are concerned about security, you could even compile the apps yourself in this case.

Or you can follow the mega model where the hoster wants to protect itself from legal demands of monitoring user uploads that stop short of demanding encryption backdoors.

It is a fairly weak and narrow security model. Nothing that should be used if you need serious security against powerful attackers.

I kind of like it for that, to be honest. There's a difference between trusting the good intentions of a company as a whole, and the good intentions and flawless skill of every single employee of it and it's subcontractors.

I wonder if there's something about this approach that I'm missing.

Ask HN: wouldn't you prefer that your data is browser-JS e2e encrypted than server-encrypted or not encrypted at all? In the context of "this is a web app. There's no mobile app or desktop app".

I'm specifically talking about the (rather common?) case in which your threat model does contain morally misguided employees, black hat hackers and stupid mistakes, but not nation state level adversaries.

Carving out a much more complicated boundary around various kinds of lapses on the other hand muddies the water. It can still make sense, but it is difficult to convey that clearly. More than a pinky promise, less than certifiable security.

Also I would claim that black hat hackers could very well get into your production system and just inject some JS that exfiltrates cryptographic keys from users. It's blunt and far more easily caught than a targeted attack, but it can still possible and thus the system would fall short of that threat model.

What we did was that we built out a generic datastore system which supports any storage provider backend.

https://getpolarized.io/2019/03/22/portable-datastores-and-p...

But the app is downloaded. It's not just a web app that could be changed on you.

If it's something that's open source and you download it you have less of an issue with people swapping out the JS on you.

The idea in this situation is when you store your docs it's encrypted before we even see the data.

This way you don't have to trust us. No trust required. We could even be a hostile actor and as long as your code is legit you're good to go.

I like this honestly as I don't have to rely on our customers trusting us. We literally CAN NOT see your data.

The main issue is getting keys between machines though. Firefox has an interesting strategy for that but I haven't had time to dive into it yet.

If I hosted a website (with some kind of user-messaging functionality) on Cloudflare, and I trusted Cloudflare to not modify the data that went through them, but I was worried that they may be recording all the data that went through them, then using a javascript end-to-end encryption library would be perfect for my case.

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

1. When the client code is content-addressed, and that content addressing is enforced by the browser e.g. https://ipfs.io/ipfs/Qmfgh... with browsers supporting dweb protocols natively as Firefox is working on

2. When the web ui is served over localhost from an app you've downloaded and can independently verify. This could be a local only app, or it could be a p2p app.

If I trust Eve to provide an E2E service, in the same way I trust Whatsapp (not a given by any means), then an open source implementation of those tools lowers barriers to entry. That's a mixed bag in that it potentially enables bad security models, but overall I think access to tools is a good thing