So many comments here about missing end to end encryption, but seriously - why would anyone want this?
Lets say burglars break in and steal your homelab. Because you don't have e2ee, they can see all the photos you saved of your dead grandmother! Oh no!
Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that remain of your grandma - you just copy across the .jpgs to a new device.
It would make hosting a "Family and/or friends" instance possible.
I do go back and forth on the accessibility tradeoffs of E2EE for average people though. In this scenario, lose or forget your key/password and you lose ALL of your photos which are very important to some people. Losing them is pretty catastrophic. Google Photos or iPhotos really gives people a sense of security about their photos.
ps: It would also make it easier to host cloud instances for Immich without encrypting the file system of a remote server/VPS. Especially when renting servers from small-time sellers, I'm always weary about how much I can really trust their employees access control. I know some level of trust is unavoidable with physical access, but how do they handle those disks during maintenance would also be relevant.
I really don't think you want E2EE for this. I host storage for family and friends, I haven't set Immich up yet (don't think I'd have space for everyone's photos) but the choice is between:
1. "Hey just so you know, I have access to everything you upload here".
2. "Do NOT lose your password or your data will be GONE FOREVER and I CANNOT get it back".
I definitely prefer 1 and I'm sure my users do too. They shouldn't upload it if they didn't trust me anyway.
In my case I follow it up with "and I might actually go digging around in your files if I need to debug something or you're wasting disk space". But I think you could also follow it up with "but I do promise not to look" and that would be valid too.
This whole thing only makes sense for people you're pretty close to.
(I do tell people not to back up their password managers on my system though).
I guess maybe for Immich specifically it would be nice to have a "vault" feature where people can upload nudes etc where they are willing to trade risk of loss for privacy on a per-photo basis.
Ah yeah I see. I guess the fallback there would be to split the service up into a remote encrypted storage layer that goes on the VPS and then host the actual service (with the decryption keys) locally?
But ISTR reading Immich kinda assumes the storage is on a plain local filesystem so you get perf issues if you do something clever under its feet. Could be out of date on that.
> I guess the fallback there would be to split the service up
I feel like it may be different enough that it's just not worth doing for Immich. To me, if you want the convenience of Immich in a trusted server, then Immich is great. If you want to host on an untrusted server, Ente is more to the point.
Those are two different models:
- With Immich, the server can do a lot of stuff (like processing on the images) but at the cost of the server accessing the images.
- With Ente, the server cannot access the images (that's the feature) but at the cost of not being able to do that kind of processing.
I am happy both exist, I think there is space for both.
You can run it on an encrypted volume on a VPS. Technically, it is also possible to use confidential VMs, but I have not at all kept up with those developments these days. Confidential here means that the SoC/CPU provides the ability for VMs memory to be encrypted with a key that the host never has access to. There's also remote attestation for it. I personally like e2e encryption at the application layer in some applications, but I personally do not think that it'd be practical for immich unless they also do confidential compute for the classifiers and identifiers. That is something Apple can do because they have the capital, not an open source project.
If you run it on an encrypted volume on the VPS, you get encryption at rest (e.g. if someone steals the disks, it's encrypted), but still your VPS provider is able to decrypt it (otherwise it just couldn't run).
Normally I either encrypt a non-boot drive (if the VPS provider offers such a thing) or use gocryptfs. It’s still a pain though when reboots happen, unless you also put your key there. Application layer encryption makes it easier.
gocryptfs is great, I use it to encrypt storage in embedded scenarios where the OS doesn't have the userspace tools or kernel modules to manage encrypted block devices.
My cousin just dumped 50GB of photos from his weddings in a Google Drive folder and shared with his contacts. I wanted to extract photos of my immediate family members from it and just save those. I setup immich on my macbook to do this but sadly I found the face recognition is nowhere near as good as Google Photos. It missed a lot of photos with tricky angles. Other than that, everything else looked quite solid to me.
Choosing 1 is totally fine but that doesn't mean it should not be possible to choose 2, right? Just because I don't need a feature doesn't mean I loudly complain when others ask for it.
Two people in my life when I was a kid have since been sent to prison for pedophilia. There's a 0.0% chance I'm hosting encrypted media for anyone other than my spouse. The low but nonzero risk of the cops asking me about some encrypted files I'm holding for a friend simply would not be worth the risk for saving someone the tens of dollars a month to self host their own content.
I meant hosting such instance with the bare minimum privacy considerations. Otherwise you would have to be honest with them that you’ll have complete access to all their photos and make sure they understand it. People’s camera roll is often akin to their text history or email. It can contain plenty of personal and private things. Just because we’re friends, or even siblings, it doesn’t mean it’s free-for-all access to everything.
Agreed on the difficulty of implementing server side features though, especially all the things people expect from a Google Photos alternative.
I think the point of E2E encryption is that you could host it with a cloud provider and the provider would not be able to see your data. Kind of like how Proton Drive claims it does not know which files you have.
This would force features like semantic search, face detection, video transcoding and thumbnail generation into the clients instead.
Immich assumes trusting the server to have access to your photos is fine. That is always the case when you’re self-hosting.
And I think that’s reasonable, since most users give that trust to Google and Apple.
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).
> 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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
I hear ya, I was being a little bit over the top. But I really do think that for every one user who would turn on e2ee and get some genuine benefit out of it, there would be a dozen that turn it on because "encryption good" and accidentally lose all their data.
Still, good application design can help mitigate that. Apple does it with their e2ee recovery methods, although Ente does rely on a recovery key that you should print out and put in a safe as well as store in other safe locations.
But also, what I love about the E2EE of Ente is that I can securely use a cloud hosted provider but then my home NAS backups are unencrypted.
The Ente desktop app has a continuous export feature where I just leave the application on my main desktop computer and it constantly backs it up to my home NAS. It also does the local machine learning and video streaming encoding processing on the desktop.
So, if I lose my Ente account, no big deal. I get another one and wipe everything and restore from my NAS backup.
I feel like this is the best of all worlds. I get cloud convenience and no real self-hosting burden along with solid ownership of my data.
Perhaps Immich doesn’t bother with e2ee since it’s primarily designed for self-hosting, while for Ente it’s meant to be suitable for both a paid cloud service and self-hosting.
Yeah Immich and Ente are going for two different use cases. While Ente can be self hosted, I view it as more of an escape hatch if they ever enshittify vs how I would start off using the service. I like not having to manage ingress for a photos service so my family can use it but others cannot
I think the application layer is the wrong layer for encryption for immich anyways, I just encrypt the whole disk on my server. When _self_ hosting, there's no need to prevent access to files from the operator.
To me there are two good products: Immich and Ente.
* Immich doesn't have end-to-end encryption, so I see it for self-hosting (i.e. on hardware I trust, typically at home).
* Ente has end-to-end encryption, which means I can host it on a random VPS.
Two different requirements for two different setups. E2EE adds some complexity, typically to set up a backup somewhere accessible. The fact that I have an unencrypted SDD next to my server at home that my family can grab and access photos is a feature to me: if I disappear I want them to be able to access them.
>So many comments here about missing end to end encryption, but seriously - why would anyone want this?
I trust GrapheneOS's security 10x more than my server. Why would I want encryption on messaging, if it's 'just for messaging my grandma'. My data is important to me and I want to keep it secure, even if I don't have a high threat model. E2ee should be the baseline, there's no reason to make security worse on purpose. Encryption in this case is important because it allows defense in depth, it allows others to know their photos are private when using my server and it prevents data access if someone has physical access.
Why trust two devices when one trust one device do trick?
> Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that remain of your grandma - you just copy across the .jpgs to a new device.
Yes, that's what happens when you lose your keys with e2ee. Every e2ee service is like this. Apple photos, Ente photos, Signal. If I couldn't manage a few words, why would I trust myself to manage a whole server?
I want to host an instance for me and my family. Right now we have a Google One instance shared by 5 people. Having e2e means my family members can rest assured that I or whoever I share admin rights with cannot look at their private photos. It's an important enough feature even without thinking about 3rd party bad actors.
I agree, we used to have photo albums in cupboards, and they used to get burnt if the house burned down, or water damaged if the boiler broke, or even stolen. Now we have them digitally and we can back them up off-site. That's all the change I need with immich.
To fully encrypt them would just be inviting more problems.
This actually happened to me, without getting into the specifics, a family member with mental issues took all the childhood photo albums and burned them.
If they steal your homelab, e2ee doesn't help, it's encryption at rest. E2ee is for rogue devices sniffing the network, which is more or less of a concern depending on your setup. I'd not have unencrypted traffic in my network if I had for instance those shady TV boxes.
That’s incorrect. E2EE means encrypted data leaves the device, stored encrypted, and server(s) have no keys to decrypt it, only your (or other) client software does.
It's encryption both at rest and on transit. At rest there are levels of encryption, at object level or at filesystem level. E2ee for immich would mean the objects are encrypted and transmitting the data is encrypted. If the scenario is the server is stolen, you need encryption at rest. Even at FS level is enough.
I've seen a lot of companies use "e2ee" to basically just mean encryption during transit, not even in rest. It's wrong, but I can see where this idea can propagate.
That’s actually true, but that’s a different issue - companies lying in their marketing materials, making claims that do not match the reality (or well-established definitions, if a company choses to mean something else and call that E2EE).
I have a multi-region homelab cluster and I share some photos with my friends in the US and my parents in Russia. I’m auto-uploading full library (basically replacing iCloud/Google Photos) and I can share links to selected photos or albums (a reachable node will be determined by a split-view DNS). All without risks of exposing my full photo archive in case either node gets seized or otherwise compromised.
(Now, this is what I’m trying to do. I set things up, but it’s not really functional at the moment, because Ente is buggy af, and I haven’t yet learned how to rebuild and debug their iOS app.)
I have no idea, I use wireguard to access it. I have disk encryption setup. They'd need to hack my linux server SSH which I have protection turned on to shut it down after failed attempts. It would be a challenge to get access to my photos on disk. They could steal my phone and access through the app if they could get them all before I disabled access since Im using encrypted icloud account.
In the end who would want all my photos for that amount of work lol?
I just want to be able to share my hosted service with other people and not have the responsibility of being able to access their photos. Me or anyone that happens to gain access to my server.
Im wary about having my PII hosted on vpses which I suppose makes me a privacy nut. I just host immich on an old laptop and use the VPS to establish a wireguard tunnel.
I think it's ridiculous to expect immich to rearchitect everything in order to make it better able to run on untrusted hardware. It should stick to doing what it is good at.
Agreed. It's especially frustrating to read of extremely high standard (even though justified, I'm not suggesting it's OK to have a subpar experience) while most people just share everything and anything on Facebook, TikTok, SharePoint, etc and have no idea what permissions even mean.
So... yeah, sure, e2ee and encryption and all that but don't wait on perfection when the otherwise situation is pretty dire. It's only encroaching BigTech fueled by surveillance capitalism even more!
Lets say burglars break in and steal your homelab. Because you don't have e2ee, they can see all the photos you saved of your dead grandmother! Oh no!
Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that remain of your grandma - you just copy across the .jpgs to a new device.