Live data from Hacker News

Immich 3.0

github.com

271–280 of 313 posts

Re: Immich 3.0

#271
post #261
post #259

Earlier quoted context omitted.

The client in your family members devices has encryption keys that you do not have in your client or on the server

Ok but again, that is introducing an arbitrary split that is not based on tech. What if I have two phones? Would you expect phone A to see images taken by phone B? If yes, obviously my phones need to share keys. So what is different in saying „All family devices should see images taken by any device“? They are all clients, including the storage&processing device. Insisting that E2EE have „ends“ on clients is not usef…

E2EE, by definition, means that the server storing the data can't decrypt it. Your server can decrypt the data. Thus, it's not E2EE. Is this a problem? No. You've decided that the server is trusted (a "peer device"), so it's fine if the server can decrypt the data. That's a perfectly reasonable security posture, but it's still not E2EE.

Re: Immich 3.0

#272

Earlier quoted context omitted.

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 m…

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…

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.

Re: Immich 3.0

#273

Earlier quoted context omitted.

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 m…

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…

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.

Re: Immich 3.0

#274
post #161

An incredible piece of software, on par with Google Photos. I've been using it behind Tailscale for months with no problems ever since I first got into homelabbing. Actually, moving from Google Photos to Immich after I hit my 100GB storage limit was the whole reason I got into self-hosting, and what a fun ride that has been! I can't believe self-hosted products of this caliber are free. Huge shout-out to HomeAssistan…

I've been considering it as well. I'm using 1.5TB in google one storage. mostly from photos/videos from the last decade from 4 family members.

Have you thought about backups and redundancy? I was thinking of hosting it on my homelab with backups on some cheap cloud storage but almost any cloud storage ends up costing somewhat similar to Google One so I've been a bit reluctant.

A good backup story is probably the only thing keeping me from switching.

Re: Immich 3.0

#275
post #258

Earlier quoted context omitted.

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 app…

> You can run it on an encrypted volume on a VPS. 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.

Re: Immich 3.0

#276

Earlier quoted context omitted.

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.

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.

Re: Immich 3.0

#277
post #209

Earlier quoted context omitted.

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 m…

You can host a family and friends' instance on your own hardware. I have a small vps which just tunnels into a laptop running at home. Half of the features of immich would become 10x harder to implement if encryption needed to be done client side.

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.

Re: Immich 3.0

#278
post #229
post #193

Earlier quoted context omitted.

What entitlement? Did I say I DEMAND something? DID I? You can't criticize a free project because God forbid that makes you entitled? And how do you know I haven't donated and don't regularly do so?

If I had to guess, the last paragraph of your original comment comes across as very harsh.

I don't see it. I made a remark that nice-to-haves are less important than the bare essentials. And I don't get how this quasi-commercial product doesn't have this locked in, despite them making an every effort to come off as polished.

Re: Immich 3.0

#279
post #261

Earlier quoted context omitted.

Ok but again, that is introducing an arbitrary split that is not based on tech. What if I have two phones? Would you expect phone A to see images taken by phone B? If yes, obviously my phones need to share keys. So what is different in saying „All family devices should see images taken by any device“? They are all clients, including the storage&processing device. Insisting that E2EE have „ends“ on clients is not usef…

E2EE, by definition, means that the server storing the data can't decrypt it. Your server can decrypt the data. Thus, it's not E2EE. Is this a problem? No. You've decided that the server is trusted (a "peer device"), so it's fine if the server can decrypt the data. That's a perfectly reasonable security posture, but it's still not E2EE.

I don’t think there is a formal definition of E2EE.

Here’s Wikipedia’s definition:

„End-to-end encryption (E2EE) is a method of implementing a secure communication system where only the sender and intended recipient can read the messages“

Note the complete lack of client/server distinction. It’s simply about intended recipients.

Re: Immich 3.0

#280
post #223
post #194

Earlier quoted context omitted.

No. They're not. You export photos using Google Takeout, iCloud has something similar. And their own iOS app also has unresolved bugs because of which I can't fully import my gallery. There's no "black box" magic here. Sure, there are some edge cases that need to be handled when importing the exported dataset, but it's all documented.

> No. They're not. You export photos using Google Takeout, iCloud has something similar. So, they are black boxes that don't make things easy or convenient for people. E.g. Google Takeout separates images and their metadata. With people running into issues like this: https://www.reddit.com/r/googlephotos/comments/1lqx331/googl... (as comments point out, Google just randomly changes file names as well, which breaks im…

This is why I said A-B testing would be important.

BUT, that's irrelevant: their own iOS app butchers Live Photos and there's unresolved bugs that get hardly any traction. This isn't rocket science here, no wild-guessing, they get access to the Photo library like any other app using their SDK. They just lose those Live Photos when backing up to immich and no one got to the bottom of it.

WHY do you keep ignoring that aspect that I have mentioned like 3 times by now?

Post reply on HN