immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-16 05:34:30 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

[Feature]: Encryption for data at rest #194

New Issue
Closed
opened 2026-02-04 18:37:14 +03:00 by OVERLORD · 14 comments
OVERLORD commented 2026-02-04 18:37:14 +03:00
Owner
Copy Link

Originally created by @gromain on GitHub (Aug 10, 2022).

Feature detail

As highlighted in #359, it would be nice for Immich to support encrypting data per user on the storage medium, so that even the admin can't access them.

This would need a bit of work on both the server side but also in the clients. Encryption at rest could be activated globally or per user perhaps. This will incur a performance penalty, but I believe it's a very nice feature to have.

Platform

Server

Originally created by @gromain on GitHub (Aug 10, 2022). ### Feature detail As highlighted in #359, it would be nice for Immich to support encrypting data _per user_ on the storage medium, so that even the admin can't access them. This would need a bit of work on both the server side but also in the clients. Encryption at rest could be activated globally or per user perhaps. This will incur a performance penalty, but I believe it's a very nice feature to have. ### Platform Server
OVERLORD commented 2026-02-04 18:37:31 +03:00
Author
Owner
Copy Link

@Nonobis commented on GitHub (Aug 10, 2022):

bad idea for me ... Or only optional and with Big warning for admin ....
I think it's too risky for losing valuable pictures of familly or other type.

Even with backup...

@Nonobis commented on GitHub (Aug 10, 2022): bad idea for me ... Or only optional and with Big warning for admin .... I think it's too risky for losing valuable pictures of familly or other type. Even with backup...
OVERLORD commented 2026-02-04 18:37:40 +03:00
Author
Owner
Copy Link

@gromain commented on GitHub (Aug 10, 2022):

The responsibility lies with the user to not forget their password in that case in my opinion. But of course, it's something that could be activated but would not be on by default.

I don't believe it's more risky in my opinion, sure you have to not lose your password (if it's used to derive the key, which is not a necessity, it could be in-app only and local to the device, each solution has its own drawbacks and advantages) but I don't see more ways to lose you pictures when encrypting data vs when not encrypting them.

There is a use case where you host Immich for family members or friends, but want to provide them with a privacy guarantee. There is currently no solution that would offer this kind of thing.

@gromain commented on GitHub (Aug 10, 2022): The responsibility lies with the user to not forget their password in that case in my opinion. But of course, it's something that could be activated but would not be on by default. I don't believe it's more risky in my opinion, sure you have to not lose your password (if it's used to derive the key, which is not a necessity, it could be in-app only and local to the device, each solution has its own drawbacks and advantages) but I don't see more ways to lose you pictures when encrypting data vs when not encrypting them. There is a use case where you host Immich for family members or friends, but want to provide them with a privacy guarantee. There is currently no solution that would offer this kind of thing.
OVERLORD commented 2026-02-04 18:37:48 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Aug 10, 2022):

This is not something that we can facilitate without a huge overhaul of the application. Currently all processing of the assets are done on the server to determine geolocation, object detection, re-encoding, thumbnail generation, etc. In order to do encryption properly so the admin wasn't able to access the files, we would be required to do all of this on the client which for some features is simply no feasible. I would say that this is not in scope for now. I will discuss this with the dev team and if they agree I will close this issue.

@zackpollard commented on GitHub (Aug 10, 2022): This is not something that we can facilitate without a huge overhaul of the application. Currently all processing of the assets are done on the server to determine geolocation, object detection, re-encoding, thumbnail generation, etc. In order to do encryption properly so the admin wasn't able to access the files, we would be required to do all of this on the client which for some features is simply no feasible. I would say that this is not in scope for now. I will discuss this with the dev team and if they agree I will close this issue.
OVERLORD commented 2026-02-04 18:37:53 +03:00
Author
Owner
Copy Link

@gromain commented on GitHub (Aug 10, 2022):

The app could share the necessary metadata with the server for some of those features.

However, I think it's an important feature for a backup application to be able to secure the data (in addition to backing it up).

Object detection is a nice toy to have, but it's not an important feature of a photo backup application in my opinion. Another way to do this could be to deactivate the features that need the pictures to be stored in clear when encryption is activated for said account.

We are talking about sensitive personal data here and a breach in security in the server could expose the raw pictures to the internet (which is something likely until a proper assessment and pentest has been made on the code, as good as it may be).

@gromain commented on GitHub (Aug 10, 2022): The app could share the necessary metadata with the server for some of those features. However, I think it's an important feature for a backup application to be able to secure the data (in addition to backing it up). Object detection is a nice toy to have, but it's not an important feature of a photo backup application in my opinion. Another way to do this could be to deactivate the features that need the pictures to be stored in clear when encryption is activated for said account. We are talking about sensitive personal data here and a breach in security in the server could expose the raw pictures to the internet (which is something likely until a proper assessment and pentest has been made on the code, as good as it may be).
OVERLORD commented 2026-02-04 18:38:05 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Aug 10, 2022):

We've discussed this internally and it's not something we are looking to implement. Although I agree with what you're saying about it providing additional security, the main focus of Immich is to provide these extra features and not just be a simple photo backup app. If we added this it wouldn't just be removing some features, all features except for viewing the photos would be gone. Thanks for the feature request but this is not within the scope of Immich for the foreseeable future

@zackpollard commented on GitHub (Aug 10, 2022): We've discussed this internally and it's not something we are looking to implement. Although I agree with what you're saying about it providing additional security, the main focus of Immich is to provide these extra features and not just be a simple photo backup app. If we added this it wouldn't just be removing some features, all features except for viewing the photos would be gone. Thanks for the feature request but this is not within the scope of Immich for the foreseeable future
OVERLORD commented 2026-02-04 18:38:12 +03:00
Author
Owner
Copy Link

@gromain commented on GitHub (Aug 10, 2022):

Thanks for your feedback.

@gromain commented on GitHub (Aug 10, 2022): Thanks for your feedback.
OVERLORD commented 2026-02-04 18:38:21 +03:00
Author
Owner
Copy Link

@omidraha commented on GitHub (Mar 30, 2023):

As far as I understand, the architecture of the app is the opposite of encryption.
While this feature will gradually become the most important.

Did you find a solution or similar apps for what you wanted? @gromain

@omidraha commented on GitHub (Mar 30, 2023): As far as I understand, the architecture of the app is the opposite of encryption. While this feature will gradually become the most important. Did you find a solution or similar apps for what you wanted? @gromain
OVERLORD commented 2026-02-04 18:38:40 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Jun 17, 2023):

I was just thinking about this today, and it would be nice but I came to a similar conclusion. It would be way too hard. It may be possible to encrypt some of the photos, but encrypting database entries and dealing with shared albums would be complicated. I would encourage users to instead encrypt their data at the block or file system level with LUKS or similar.

@uhthomas commented on GitHub (Jun 17, 2023): I was just thinking about this today, and it would be nice but I came to a similar conclusion. It would be way too hard. It may be possible to encrypt some of the photos, but encrypting database entries and dealing with shared albums would be complicated. I would encourage users to instead encrypt their data at the block or file system level with [LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup) or similar.
OVERLORD commented 2026-02-04 18:38:48 +03:00
Author
Owner
Copy Link

@gromain commented on GitHub (Jun 21, 2023):

I think it was not clear in my initial proposal @uhthomas . Encryption of data at the block or fs level does not protect you against a nosy admin or against someone breaking into the server. Only protection this affords is against someone breaking into your house or datacenter, unplugging your server and leaving with it. IMO, much less likely to happen than someone finding a 0-day or an unpatched vulnerability on your server. Hence the devices E2EE request.

@gromain commented on GitHub (Jun 21, 2023): I think it was not clear in my initial proposal @uhthomas . Encryption of data at the block or fs level does not protect you against a nosy admin or against someone breaking into the server. Only protection this affords is against someone breaking into your house or datacenter, unplugging your server and leaving with it. IMO, much less likely to happen than someone finding a 0-day or an unpatched vulnerability on your server. Hence the devices E2EE request.
OVERLORD commented 2026-02-04 18:38:59 +03:00
Author
Owner
Copy Link

@gromain commented on GitHub (Jun 21, 2023):

@omidraha no, not really unfortunately. Still looking for something viable. I thought Nextcloud would be OK, but not acceptable for my needs there (E2EE is not very functional).

@gromain commented on GitHub (Jun 21, 2023): @omidraha no, not really unfortunately. Still looking for something viable. I thought Nextcloud would be OK, but not acceptable for my needs there (E2EE is not very functional).
OVERLORD commented 2026-02-04 18:39:08 +03:00
Author
Owner
Copy Link

@etnoy commented on GitHub (Jun 21, 2023):

There is practically no way to protect users against a rouge admin

@etnoy commented on GitHub (Jun 21, 2023): There is practically no way to protect users against a rouge admin
OVERLORD commented 2026-02-04 18:39:12 +03:00
Author
Owner
Copy Link

@haveachin commented on GitHub (Sep 26, 2023):

People take photos of everything nowadays, like important legal and healthcare documents. I really want to emphasize the importance of this. Privacy is a basic right, even among your closest circle. Having a secure and easy way to back up images, especially for those not so tech-savvy, is a big deal. Immich checks all the boxes except for being private for all its users. The server admins of each instance have too much control. This opens the door for censorship and blackmail. E2EE could be a possible solution to this, even if this leaves users with less features when enabled. Users should at least be educated that their private images could be viewed by any user that has read access to the files on the server.

@haveachin commented on GitHub (Sep 26, 2023): People take photos of everything nowadays, like important legal and healthcare documents. I really want to emphasize the importance of this. Privacy is a basic right, even among your closest circle. Having a secure and easy way to back up images, especially for those not so tech-savvy, is a big deal. Immich checks all the boxes except for being private for all its users. The server admins of each instance have too much control. This opens the door for censorship and blackmail. E2EE could be a possible solution to this, even if this leaves users with less features when enabled. Users should at least be educated that their private images could be viewed by any user that has read access to the files on the server.
OVERLORD commented 2026-02-04 18:39:25 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Sep 26, 2023):

We really appreciate the concern of privacy and security, but it truly is out of scope for Immich. End-to-end encryption is fundamentally incompatible with how Immich works and is generally infeasible.

The best advice I can give is to run Immich on a device you trust with disk encryption and a secure network transport (TLS, VPN, etc).

As @etnoy highlighted, there really is not a great way to protect against malicious server administrators. Users with this level of concern for confidentiality should definitely not be uploading their private media to a server with such a level of distrust.

@uhthomas commented on GitHub (Sep 26, 2023): We really appreciate the concern of privacy and security, but it truly is out of scope for Immich. End-to-end encryption is fundamentally incompatible with how Immich works and is generally infeasible. The best advice I can give is to run Immich on a device you trust with disk encryption and a secure network transport (TLS, VPN, etc). As @etnoy highlighted, there really is not a great way to protect against malicious server administrators. Users with this level of concern for confidentiality should definitely not be uploading their private media to a server with such a level of distrust.
OVERLORD commented 2026-02-04 18:39:33 +03:00
Author
Owner
Copy Link

@etnoy commented on GitHub (Sep 26, 2023):

There is no way to implement "e2ee" in a solution like immich. If you want e2ee in a media storage, put your photos in an encrypted zip file and put it on an SFTP server. You can't have galleries, browsing, metadata with e2ee

@etnoy commented on GitHub (Sep 26, 2023): There is no way to implement "e2ee" in a solution like immich. If you want e2ee in a media storage, put your photos in an encrypted zip file and put it on an SFTP server. You can't have galleries, browsing, metadata with e2ee
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#194
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?