[TalkingCodeMonk]

Seriously! How do techies and devs of all people not understand that the cloud is someone else's computer, and that the best way to prevent leaks, exploitation, or abuse of user data is to prevent anyone from being able to decrypt it but the end users themselves.

IMO this is the single greatest problem with the selfhosted community; the idea that E2EE is only necessary for passwords and other highly sensitive PII. It should be standard for anything hosted on someone else's computer.

You might argue it's not neccessary for cat photos, but mistakes happen and you can accidentally upload things you don't intend to. You might argue it's not neccessary for games, ebooks or other copyrighted media, but the cloud provider could scan and delete anything you own that matches a hash of copyrighted material, at any time. You can accidentally paste a password, or other sensitive piece of text, into any text field of any website or application, and have it distributed to computers around the world.

E2EE can mitigate against numerous attack vectors, and reduces the surface area and blast radius of most attacks. That also applies to your own computers, if someone steals your hardware or hacks into your network. It is vital in the age of AI where all of your data could be exploited for training and profit, or used against you. The only data that should not be E2EE is situations where it is technically impossible, or the data is explicitly shared as "public" (e.g. the clearnet).

[konart]

> It should be standard for anything hosted on someone else's computer.

As long you understand the risks.

I'd rather have my family photos beying unencrypted than a very good possibilty of loosing them which happed more than once with other e2e things simply because I have no key to decrypt.

Then again - if I have to chose I'd rather have the at my home lab.

[reorder9695]

I'd personally rather have E2EE and periodically back things up to an encrypted hard drive so any losses aren't catastrophic, but I am probably more cynical than most in my trust of companies/other people with my data and am technical so understand the risk model both ways better than most people.

[konart]

>I'd personally rather have E2EE and periodically back things up to an encrypted hard drive so any losses aren't catastrophic

Are suggesting backing up decrypted data to an encrypted hard drive?

>better than most people.

Typically people who are so high on themself either too young or simply actually lack the understanding and usually it shows. But sure, most people out of 8 billion around the world have no idea about those things.

Anyway the whole point of my comment is:

- there is data I'm not willing and don't have to share - and it stays with me. Like family documents, photos etc.

[TalkingCodeMonk]

Why is there "a very good possibility" of losing your photos because they are E2EE? Do you not use a password manager and backup your data?

There is no reason why E2EE services can't provide recovery or emergency access mechanisms, or implement plaintext export functionality from clients for storage elsewhere. Most reputable providers already have functionality to enable recovery and backup.

[gf000]

> can't provide recovery or emergency access mechanisms

If they can do that then they are not e2ee.

[TalkingCodeMonk]

see other comment https://news.ycombinator.com/item?id=48772802

[konart]

Other commentes already pointed out to you the reasons E2EE may be not what you think it is, but I still feel the need to answer the question:

1. Password manager gives you access to your secrets (key included), yes, but it does not eliminate human factor.

You may forget to add your key in the first place or you can delete a note with it without even realising that this was THE key.

This may seem like a fantasy, but if you ask people or search the web - this happens all the time.

2. Backups will be encrypted the same was as the original. So this wont's save you in case you have lost your keys.

Bottom line: the whole point of E2EE is a guarantee that only keyholders can ever access the data. Period. Lost key == Lost data. No exceptions.

[palata]

> How do techies and devs of all people not understand

I find it interesting to start with this, and follow with:

> There is no reason why E2EE services can't provide recovery or emergency access mechanisms

If the service can help you recover your data after you lose the key, it means that they have the key, and therefore it's not end-to-end encrypted.

That's the whole point of E2EE.

[TalkingCodeMonk]

> That's the whole point of E2EE.

No it's not. The point of E2EE is that only the client apps decrypt/encrypt content, and the server just processes the encrypted bits. Most E2EE service providers do this by encrypting your encryption key. That's how you can login on other devices without you having to store and import an encryption key every time. When you login they send you an encrypted blob that contains your encryption key, which is decrypted client side, then the key is used to decrypt your data locally on the client. This does not break E2EE, but it does mean you have to trust the provider, which is why most of them are entirely open source.

Sharing and emergency access also use similar public key cryptography techniques to provide shared access to E2EE data. A similar principle applies to your phones encryption aswell, and is the reason you can wipe/reset your device in seconds, instead of minutes/hours. They only wipe the encryption key; not the encrypted data.

[palata]

I think you are slightly confused about E2EE, let me try to address a few points:

- The whole point of end-to-end encryption is that nobody in the middle (e.g. the server) can possibly have access to the encrypted data. If they can (e.g. by giving you a way to reset your password), then it is not end-to-end encryption, period.

- It is possible for a provider to "encrypt an encryption key" with another key they cannot access, e.g. a password. In that case your password (probably through a KDF) is the key to decrypt the encryption key that is used further.

- It is possible for an app to store your key locally. Ideally you would store your key in a secure element on your phone for instance, and unlock it e.g. with biometry.

- In any case, if the client (e.g. the app) is not open source, you cannot easily know if it does what it says. That's why it's easier to trust Signal than WhatsApp.

- If you lose your "key" (whatever it is that the server doesn't know), your data is lost. If you can lose your key and the server can help you recover, it means that the data was not end-to-end encrypted and the server could access it without needing you at all (obviously, because you lost the part that they needed).

Now, in order to seriously trust E2EE, you need to trust the implementation. That means that if you cannot audit the code (typically, WhatsApp), then it's difficult to trust it. Another example is ProtonMail: you open the webpage in your browser, and at this point it downloads a client that is supposed to do the decryption locally. How do you trust that client? You could try to audit it, but next time you reload the page, it may download modified sources, and you won't know (there aren't tools to pin the version of a webapp from the browser).

In that sense it's even harder to trust ProtonMail than WhatsApp: it would be trivial for Proton to serve a different client that would exfiltrate your password just for you, just this one time, and no audit by anyone else in the world would ever detect it. So when you use ProtonMail in the browser, you trust the Proton server, which defeats the purpose of E2EE. It is still better than non-E2EE like GMail (where you know Google reads all emails of everybody), but you still trust the Proton server, which is not what is usually expected with E2EE.

[mr_mitm]

In a recovery scenario, you don't have the password or whatever you used to encrypt the key.

And again: the whole point E2EE is that you don't have to trust the provider. Open source in general doesn't help you here because you don't know what software or which version of the code the provider is running. Your only chance is to run open source client software, review it to ensure E2EE has been implement properly, then you don't need to trust the provider.

Either the provider knows the secret, then they can help you in a recovery scenario, but then they also can read your data. Or they don't know the secret, in which case they cannot help you in a recovery scenario.

[drdexebtjl]

I don’t agree E2EE is right for everything, and especially not for a personal photo library.

I don’t want to hold the keys to my photo library on someone else’s computer. I want to actually have all the bits and all the hardware in my house. I want to have access to it even if the Internet ends.

[gf000]

Especially that it would come with the loss of quite a few features, or at least a significantly worse way to implement them.

Like if you have to bring the data to your client device to do any kind of processing, you are quite bottlenecked when it comes to bulk operations (e.g. searching).

Sure there is very interesting research into managing that (homomorphic encryption), but I think it only makes sense on a Google cloud/apple scale. For a small, self-hosted app, I would much rather have my own hardware with FS-level encryption , or some kind of trusted compute as a whole. I don't think this has to be solved by an image host service.

[drdexebtjl]

Also bottlenecked when it comes to background operations.

Trusting the server, all the app in your phone has to do in the sliver of CPU time the OS gives it in the background is send it off to the server, where it can do compute-intensive things like transcoding video.

If you don’t trust the server, you’ll probably have to do these things while your app is in the foreground.

[eddythompson80]

E2EE means the keys are on your own computer (or device or brain etc). The “someone else’s” computer is just hosting encrypted blobs.

[drdexebtjl]

I understand what it is. I still don’t want the encrypted blobs outside my control.

Sure, they’re useless without the keys. But the key is also useless without the blobs, in the sense that I don’t have my photos.

[TalkingCodeMonk]

Sounds like you want your photos on a unencrypted HDD, which you can do regardless of whether or not a cloud service is E2EE, so I don't see how E2EE is an issue...

[drdexebtjl]

No, I do not want that. I have my photos on an encrypted HDD, in a server running Immich in my basement, and I connect to it using WireGuard. Everything is encrypted at rest and in transit.

There’s no cloud.

I get to reap the benefits of not using E2EE encryption, like offloading machine learning tasks and transcoding to a server, and having extremely simple clients that don’t need to roll their own application-layer crypto.

E2EE isn’t a silver bullet. It solves a specific problem — trusting the server — and introduces another — pushing complexity to the clients. If you already trust the server, because it’s running on your infrastructure, there are no upsides.

And Immich was designed specifically for self-hosting. To not depend on the cloud. It makes no sense for it to make trade-offs that don’t benefit self-hosting.