Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immich 3.0

github.com

Post reply on HN
Print view View original

251–260 of 313 posts

Re: Immich 3.0

#251

Post by onel »

onel wrote: post #227
DavideNL wrote: post #4

I don't want yet another self hosted service to manage (update, backups, possible hardware failures, energy costs, ups, etc.). Unfortunately Immich is not end-to-end encrypted. If that would have be the case i'd use https://pixelunion.eu/ Seems like a great app though. So... i'm still pondering what to do :-)

There are simpler options now to self-host these kinds of apps. It's not that hard anymore

Valid points. But I see self-hosting even as renting a VPS from someone and running the service there. Which solves most of the dev ops problems that I dont wanna bother with. Maybe it's not "actual" self-hosting, but concenient enough to use it

Re: Immich 3.0

#252

Post by palata »

Mashimo wrote: post #218
palata wrote: post #204

How does the mobile app sync work with Immich? My use-case is that I want to install the mobile app on the phone of my relatives (including iPhones), and it should keep syncing their pictures "forever" even though they never, ever open the app. I tried Nextcloud, but the apps/server end up failing to sync after at most a couple month, and it's painful to recover from that. So it doesn't work for me. I have been consi…

With works for me on Android with Pixel phone, after I added Immich to the list of apps that can work in the background. But as you can see in the linked release note, they made a lot of change to background sync on Android and iOS. It should (TM) work out of the box now.

Yeah I saw that, which suggests that it was not totally working before. Not criticising of course, I know it's hard especially on iOS.

> works for me on Android with Pixel phone

But do you open the Immich app on Android from time to time, or never and just use it to sync transparently in the background?

Re: Immich 3.0

#253

Post by FabCH »

flossly wrote: post #250
FabCH wrote: post #242

Earlier quoted context omitted.

This is only true if you are so highly individualistic you don’t consider a family unit as a single entity. If you consider nuclear family as an entity, it’s e2ee. Practically. Putting aside the fact that yes, the server can be compromised if somebody chose to attach to the live RAM and recover keys. But practically, nobody will. Same way Google will not deliver a special compromised image of the mobile app on my pho…

It's a definition question. E2ee means in this cases that "the server" cannot decipher the data: the keys to that are only on the client and never shared with the server. This setup simply does fit the definition. And trying to say it is "e2ee practically" is a bit dishonest: there is no definition for "practical e2ee". The point of e2ee is that you do not have to trust the server (see Bitwarden for instance).

What is the relevant definition of client and server if they are both peer devices under roughly equal level of control of a single entity?

Re: Immich 3.0

#254

Post by smallerize »

FabCH wrote: post #241
TalkingCodeMonk wrote: post #205

Earlier quoted context omitted.

FYI the setup you mention is not "end-to-end" encrypted. E2EE means client-to-client encrypted, with the server processing encrypted bits only. Your approach is encryption in transit and at rest. At rest is relatively irrelevent for large cloud providers, as they are probably better at managing the lifecycle of disks than most businesses or people. It's unlikely someone's going to physically rob a data center or end…

I do happen to have some experience. For 99.99% of the population, does the threat model really include targeted NSA attack with higher probability than „Google’s automated system sent the police to my door“? No, no it doesn’t. It is demonstrably more secure for even a semi experienced sysop to host Immich for their family than for them to use Google/Apple. But I do agree that _some_ experience is required.

Hetzner has fewer employees I guess, but since your photos are decrypted there, you have basically the same problem.

Re: Immich 3.0

#255

Post by sva_ »

internet_points wrote: post #199
FabCH wrote: post #180

A lot of people talking about encryption in the comment section, thought I would share my setup. I have been running Immich for family and friends on a Hetzner auction server for about 1.5 years now. Hetzner community provides official full-disk encryption documentation: https://community.hetzner.com/tutorials/install-debian-with-... Letsencrypt gives free reliable SSL. You can easily hide Immich behind Nginx proxy t…

how much storage and how much do you pay Hetzner?

If you want a cheaper alternative, maybe look into ServaRica. That's where I run my Immich instance for my wife and me. 4TB for $11 per month. The servers (cpus) are not super fast, but fast enough for me.

Re: Immich 3.0

#256

Post by palata »

TalkingCodeMonk wrote: post #214
palata wrote: post #202

Earlier quoted context omitted.

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

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

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.

Re: Immich 3.0

#257

Post by palata »

bjackman wrote: post #248
palata wrote: post #200

Earlier quoted context omitted.

I do agree that this is a use-case. Now a use-case for E2EE is if you want to host it on a VPS, I would say. I wouldn't trust the VPS with the photos of my friends/family.

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.

Re: Immich 3.0

#258

Post by palata »

eptcyka wrote: post #238
palata wrote: post #200

Earlier quoted context omitted.

I do agree that this is a use-case. Now a use-case for E2EE is if you want to host it on a VPS, I would say. I wouldn't trust the VPS with the photos of my friends/family.

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

Re: Immich 3.0

#259

Post by sylens »

FabCH wrote: post #253
flossly wrote: post #250

Earlier quoted context omitted.

It's a definition question. E2ee means in this cases that "the server" cannot decipher the data: the keys to that are only on the client and never shared with the server. This setup simply does fit the definition. And trying to say it is "e2ee practically" is a bit dishonest: there is no definition for "practical e2ee". The point of e2ee is that you do not have to trust the server (see Bitwarden for instance).

What is the relevant definition of client and server if they are both peer devices under roughly equal level of control of a single entity?

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

Re: Immich 3.0

#260

Post by sva_ »

psadauskas wrote: post #40

Has the ios photo sync gotten better? I've got 20k photos on my phone, and last I tried it filled up the storage on my phone with the originals, and never completed the process, even after leaving my phone open, unlocked, and the immich app running in the foreground for several days, on the same local network as the server. I know they were working on it, but haven't kept up, I just want to know if it works better no…

Sync was already fixed in the last major version, at least for us (android and iphone)
Post reply on HN