Опенсорсный криптофотохостинг Ente Photos, десктопное приложение и мобильный клиент
Когда запустился YouTube, люди спокойно публиковали там трогательные приватные видео. Сегодня никому в голову не придёт выкладывать такое в открытый доступ. Времена сильно изменились. То же относится к фотографиям.
Во-первых, с массовым профилированием пользователей ценность пользовательских файлов сильно возросла. Во-вторых, профилированием занимаются алгоритмы машинного обучения, которые извлекают массу ценной информации из личных фотографий. И самое неприятное, что эти алгоритмы ИИ обучаются на наших фотографиях.
Не говоря уже о том, что среди фотографий могут быть очень личные, которые вообще нежелательно никому видеть, кроме самых близких людей.
Ни один популярный фотохостинг сегодня не удовлетворяет правилам сквозного шифрования (E2EE). У этого как минимум два неприятных последствия.
- Компания-владелец сервиса имеет доступ к незашифрованным файлам — и по условиям соглашения может использовать их в своих целях. Например, есть подозрение, что Google, Meta и Twitter (X) обучают свои ИИ-модели на пользовательском контенте. Людей не ставят об этом в известность, так что многие продолжают спокойно публиковать твиты, фотографии и видеоролики в соцсетях.
- Утечка личных данных в случае компрометации (взлома) сервиса.
Лучшее решение проблемы — использовать сильную криптографию, а именно E2EE. В этом случае только собственник хранилища владеет ключом и имеет возможность посмотреть фотографии в оригинальном виде. Другими словами, файлы шифруются ещё на компьютере пользователя, до передачи на удалённый сервер:
Ранее применять такие технологии на фотохостингах было не принято, но сейчас времена изменились.
Для примера можно посмотреть на один из первых фотохостингов со сквозным шифрованием Ente Photos. Здесь используется следующая схема шифрования:
- При регистрации в сервисе на стороне клиента генерируется мастер-ключ
masterKey.
- При установке пароля на его основе создаётся ключ шифрования
keyEncryptionKey, который никогда не покидает устройство пользователя.
- Далее
masterKeyшифруется с помощьюkeyEncryptionKey, а полученный зашифрованный мастер-ключencryptedMasterKeyотправляется на удалённый сервер для хранения:
- При авторизации второго устройства (второго клиента) после проверки электронной почты сервер отдаёт зашифрованный ключ
encryptedMasterKey, затем предлагает ввести пароль. После ввода пароля создаётсяkeyEncryptionKey, с помощью которого восстанавливается оригинальныйmasterKey.
- Каждый файл в Ente принадлежит отдельной коллекции, а у каждой коллекции свой ключ
collectionKey.
- Перед закачкой файлов на сервер для каждого файла случайно генерируется индивидуальный ключ файла
fileKey. Каждый ключ файла зашифрован ключом коллекции. Ключ коллекции затем шифруется мастер-ключом.
- При скачивании файлов с сервера процедура выполняется в обратном порядке.
- Отдельные снимки или коллекции из своего хранилища можно расшарить для конкретного получателя: при этом генерируется публичный ключ
publicKeyна базе секретного ключаprivateKeyполучателя.
Ente Photos позиционируется как свободная альтернатива Google Photos и Apple Photos, исходный код доступен в репозитории на Github. В 2023 году архитектура платформы и исходный код успешно прошли независимый аудит от специалистов немецкой компании Cure53, которая специализируется на информационной безопасности и французской компании Symbolic Software, которая занимается прикладной криптографией.
Самохостинг
Если пользоваться центральным сервером от разработчиков, то это платная услуга (5 ГБ предоставляется бесплатно). Но можно развернуть систему на своём сервере, и тогда он будет бесплатным при любом размере хранилища. В документации есть инструкция по установке сервера.
Разработана процедура удобного переноса данных с Google и Apple: нужно экспортировать файлы через стандартную процедуру Takeout, а потом просто перетянуть мышкой полученные архивы в десктопное приложение.
В разработке находится консольная утилита, которая частично дублирует функциональность десктопного приложения. Компания также работает над движком машинного обучения, который будет обрабатывать фотографии на стороне клиента, чтобы реализовать поиск похожих снимков, распознавание объектов и другие функции ML в своей зашифрованной фотоколлекции.
Аутентификатор
Смежный проект Ente Auth — это приложение-аутентификатор, построенное на аналогичных принципах: открытый исходный код и сквозное шифрование.
Аутентификатор бесплатен, и разработчики обещают оставить его таким навсегда. По их словам, это первое свободное приложение-аутентификатор на рынке.
Комментарии (34)
RealBeria
16.02.2025 19:44"Сегодня никому в голову не придёт выкладывать такое в открытый доступ." Сегодня выкладывают ТАКОЕ на ютюб, что фильтры ютюба красные от перегрузки и стыда.
13werwolf13
16.02.2025 19:44с большим удовольствием бы развернул себе фотогалерею вообще без вебморды, только с мобильными и десктопными клиентами. но увы таких нет (или я не нашёл).
а доверять шифрование конечному приложению не вижу смысла, по пути трафик шифруется сертификатом, на диске трафик шифруется luks, нет смысла шифровать каждый файл по отдельности..
sena
16.02.2025 19:44с большим удовольствием бы развернул себе фотогалерею вообще без вебморды, только с мобильными и десктопными клиентами. но увы таких нет (или я не нашёл).
Ну просто не пользуйся вебмордой или я не понял твоё пожелание?
13werwolf13
16.02.2025 19:44Какой смысл крутить на сервере какой нибудь тяжеленный тупоскрипт или недожс и не пользоваться ими? А крутить прийдётся потому что обычно api для клиентов ездят через них.
Селфхостед галерей сейчас куча, но ни одна из них просто не разворачивается в "урезанном" варианте без безполезной вебморды.. к сожалению..
sena
16.02.2025 19:44Какой смысл крутить на сервере какой нибудь тяжеленный тупоскрипт или недожс и не пользоваться ими? А крутить прийдётся потому что обычно api для клиентов ездят через них.
Клиенту же нужен api, как без него? Ты хочешь сервер без api? Не понимаю.
> в "урезанном" варианте без безполезной вебморды.. к сожалению..
Если ты не будешь пользоваться вебмордой, то она и не будет жрать ресурсы. Если клиент вызывает api то морда не работает при этом. Скрипты для морды будут лежать на диске, но это не так много места, чтобы из-за этого переживать.
khajiit
16.02.2025 19:44Какое полезное ссылко… спасибо!
nidalee
16.02.2025 19:44Есть таки лучше: https://awesome-selfhosted.net/
И вот такое, посерьезнее: https://github.com/awesome-foss/awesome-sysadmin
sena
16.02.2025 19:44доверять шифрование конечному приложению не вижу смысла
Смысл в том что никто не получит доступ к твоим фото, даже если взломает сервер, даже сам хостер имеющий физический доступ. Это может быть полезно в некоторых случаях и не только для фото.
Минусов несколько
нужен клиент (если ты расшарил фото приятелю он должен тоже поставить клиента)
вся обработка, например умный поиск фото, должна вестись на клиенте, обработка на сервере невозможна, если база данных большая, то нужен жирный клиент и толстый канал
потерял пароль -> потерял все фото (и бэкап не поможет - он тоже зашифрован!)
всякие приколы с шифрованием (например вышла новая схема шифрования - надо всё перешифровать)
c0r3dump
16.02.2025 19:44Почему тогда просто не пользоваться rsync+ssh, как минимум с десктопа?
13werwolf13
16.02.2025 19:44суть немного в другом, для выгрузки фото на сервер я использую syncthing и foldersync. но это не синхронизация а именно выгрузка (потому что объём фото/видео архива давно перевалил за пару теробайт), и когда нужно найти какое нибудь старое фото я обычно сажусь за комп, монтирую nfs и открываю digikam, это в целом удобно, но не быстро и требует именно пк. чтобы иметь доступ к галерее на сервере я раньше использовал plex, но сейчас в целях экономии ресурсов храню новые фото в формате heic, а plex упорно не хочет работать с heic несмотря на просьбы юзверей на форуме. пришлось искать альтернативу, и альтернатив много, но ни одна меня не устроила. задача тут не синхронизировать фоточки (хотя этот функционал полезен тоже) а отображать старые, при этом не в тяжеловесной вебморде в браузере а в удобном приложении.
выше @sena подмечает (да, из-за низкой кармы я решил объеденить два ответа в одном комментарии):
Клиенту же нужен api, как без него? Ты хочешь сервер без api? Не понимаю.
вот только api можно реализовать на go/rust/c++/etc меньшей кровью, с меньшим потреблением ресурсов и с нормальной сборкой
Если ты не будешь пользоваться вебмордой, то она и не будет жрать ресурсы.
вот только внутренний перфекционист всё равно будет недовольно бухтеть о безполезном сервисе и куче ассетов которые существуют но не используются и в целом безполезны.
к тому же хотелось бы оставаться в рамках "чистой инфраструктуры", а это значит не ставить софт которого нет в пакетах, если чего-то нету в репозиториях я опакечиваю это сам и кладу в свою репу (ну и иногда пропихиваю в основные репы), а опакечивать тупоскрипт или недожс это тот ещё геморрой.
несмотря на то что сейчас большинство сервисов являют собой UX построенный вокруг браузера мне всё же намного удобнее и приятнее пользоваться отдельным нативным софтом для большинства задач (да я тот странный человек который даже твиттер и федивёрс почитывает не в браузере).
sena
16.02.2025 19:44чтобы иметь доступ к галерее на сервере я раньше использовал plex
plex не использовал, но судя по описанию это довольно большой проприетарный комбайн
13werwolf13
16.02.2025 19:44Ну у меня plex поселился изначально совсем не для фоток да, 50тб фильмов и сериалов для семьи и друзей, плюс audiobookshelf для книг и аудиокниг. А вот с фотовидео галереей пока решения которое бы устроило не нашёл..
P.S.: альтернативы плексу это by и jelyfin, пробовал оба, они проиграли плексу в удобстве и производительности на голову
sena
16.02.2025 19:44несмотря на то что сейчас большинство сервисов являют собой UX построенный вокруг браузера мне всё же намного удобнее и приятнее пользоваться отдельным нативным софтом для большинства задач (да я тот странный человек который даже твиттер и федивёрс почитывает не в браузере).
Ну тогда надо просто использовать облако, либо чьё-то, либо собственное. Для собственного отличный вариант nextcloud или owncloud. owncloud даже пакетирован.
Ставишь на десктоп клиента, выбираешь папки которые хочешь синхронизировать и дальше работаешь со старым привычным софтом. Что может быть удобнее?
13werwolf13
16.02.2025 19:44nextcloud опакетить тоже не составит большого труда, но что это изменит? зачем мне синхронизировать 2+ tb фоток на локальную тачку, а если не синхронизировать то это всё та же неудобная вебморда.
я вроде бы выше прямо описал какой хочется получить..sena
16.02.2025 19:44Я не совсем понял из твоего описания, как-то расплывчато. Ведь не обязательно синхронизировать все 2 ТБ, можно только те папки что нужны, я именно так пользуюсь. Или может ты имеешь в виду что-то типа smb/nfs?
13werwolf13
16.02.2025 19:44Ведь не обязательно синхронизировать все 2 ТБ, можно только те папки что нужны
ну так 2тб это и есть нужная папочка с фотками о которой идёт речь, а объём всего моего облака сииильно больше.
sena
16.02.2025 19:44Но ведь наверняка в каждый момент нужна лишь какая-то небольшая часть из этих 2ТБ? Тогда просто разделить на папки поменьше и всё.
Я просто не представляю, какие у тебя задачи. Папочки по 2ТБ это явно не про домашнее фото, это явно что-то другое. Трудно угадывать, что там тебе нужно.
13werwolf13
16.02.2025 19:44Да нет, простой семейный фотоархив (просто семья большая а самые старые фотки сделаны ещё на k790i). А задачи как у всех "как назывался отель в котором я ночевал в 2017 году" или "нука посмотрю все фотки счётчиков за последние 3 года", ну или например "на день рождения дочери жена хочет выбрать по паре фоток за каждый год её жизни и сделать из них какую-то фигню". Заниматься этим в вебморде чистый мазохизм, а тащить весь объём на десктоп накладненько. Попробуйте в гуглофото или в immich отлистать таймлайн на пару лет назад выделяя по пути некоторые фотки, сразц поймёте о чём я, в то время как дигикам с этим справляется потрясающе даже с учётом того что фотки лежат на nfs хранилке и на оооочень медленных дисках. Проблема моего подхода только в том что он не универсален, дигикама нет на телефон, его нет и на телевизор, а то что есть на телефон отсутствует на пк, это неудобно.
sena
16.02.2025 19:44Заниматься этим в вебморде чистый мазохизм, а тащить весь объём на десктоп накладненько.
Не понимаю предубеждения против вебморды. Вот именно что тянуть 2ТБ это мазохизм, эту проблема вебморда и решает для всех платформ. Ну да ладно, проблема не в этом по-моему.
Гуглофото или immich не пользуюсь.
Как именно справляется дигикам? У него распознавание встроенное и поиск по ключевым словам? Ну так значит и нужна галерея с распознаванием и автоматическим расставлением тегов прямо на сервере. Ну либо вручную эти тэги/названия расставлять (когда закачиваешь, а не сейчас).А кто потом по этим тэгам искать будет, вебморда или клиент на телефоне - какая разница?
13werwolf13
16.02.2025 19:44Когда ищешь по тегам это конечно шустро, но когда нужно найти некоторое кол-во фото за долгий период не объеденённые каким-то тегом дигикам просто не будет тормозить, как глубоко бы ты не ушёл в историю он будет работать одинаково, в то время как любая из проверенных мной вебморд поведёт себя одним из двух сценариев:
1) начнёт тормозить и/или глючить (плюс часто обжираться оперативкой и насиловать проц)
2) "забывать" выделенное ранее если с тех пор пролистано уже много
Оба случая конечно не армагедон, но неприятны сильно. Моё отношение к вебу это не предубеждения а печальный опыт, я и правда перепробовал все варианты из списка по ссылке выше..
sena
16.02.2025 19:44нужно найти некоторое кол-во фото за долгий период не объеденённые каким-то тегом дигикам просто не будет тормозить, как глубоко бы ты не ушёл в историю
sena
16.02.2025 19:44нужно найти некоторое кол-во фото за долгий период не объеденённые каким-то тегом дигикам просто не будет тормозить, как глубоко бы ты не ушёл в историю
То есть найти в смысле просто просмотреть? 2ТБ фото? Или о чём ты? Как ты будешь "просто" искать среди 2ТБ фото без тегов и нейронки?
Если я тебя правильно понял, то дигикам не будет тормозить на локальном диске или по локальной сети. Но если ты будешь это делать через Интернет, то тормозить будет и очень сильно. Верно?
13werwolf13
16.02.2025 19:44Я говорю про использование нативного софта вместо неудобной и сильно неоптимальной вебморды на каком нибудь тупоскрипте.
Дигикам конечно не самый подходящий, но единственный пример. Да, если nfs шара до сервера не в локалке а через пол планеты то дигикам будет работать сильно медленнее, но всё ещё юзабельно, он не провалится от пролистывания всё глубже и глубже в историю как делает любая веб галерея по ссылке выше, я перепробовал их все. Заменить файловую систему на api, но оставить нативный ui и всё будет всё ещё юзабельно. А веб галереи подходят только тем у кого фотографий не больше пары сотен.
Легко кстати проверить то о чём я говорю: взять nginx с автоиндексом, подложить ему в рут сайта все свои фотки, и на другом компе смонтировать этот http индекс как фс через rclone, и уже на этот маунт натравить тот же дигикам или любой другой каталогизатор/вивер. Да, rclone работает через fuse, поэтому будет ещё медленнее чем nfs, но будет всё ещё работоспособным на любых объёмах галереи. Отчасти засчёт локально лежашей sqlite базейки (хотя если сменить дигикаму sqlite на mysql на том же сервере что и шара по сути ролучится фотосервис полностью серверный) с метаданными, отчасти из-за того что всё же нативный софт написанный пряморукими разрабами всегда будет лучше веб поделия от тех кто не осилил взрослые яп.
Тоесть по сути взять и написать например на go сервис который будет делать каталогизацию, хранить теги и вешать лычки, искать лица.. И он же будет отдавать в сеть api для нативного клиента который можно написать например на qt для десктопа и котлине для ведроида, или на kirigami и туда и туда. Я уверен на 100% что это будет работать так как должно без недостатков развесистых вебморд. Может быть я ошибаюсь, но пока что наблюдения говорят что это не так.
ritorichesky_echpochmak
16.02.2025 19:44Любой WebDAV? Превьюшки только тормозить могут. Или даже тот же некстклауд - превьюшки летят с бэка.
Или Jellyfin, хотя у него местами странный UX. Но при большом желании можно кастомизировать.
Всё ещё непонятно чем вас не устраивает веб-морда хоть и к тому же digicam ( https://gitlab.com/AlessandroLucchet/digikamwebviewer ) или 100500 галер пошаренных в вашей домашней сети, если основные тормоза там будут - фото. Много фото через медленную сеть, которым ещё нужно на бэке миниатюры настрогать чтобы не тащить через сеть вообще всё и сразу
13werwolf13
16.02.2025 19:44и к тому же digicam ( https://gitlab.com/AlessandroLucchet/digikamwebviewer )
это жестоко дать надежду и тут же отобрать..
оно не собирается за пределами винды
mrluciferovich
16.02.2025 19:44Вероятно Вы не совсем верно понимаете как это работает. Приложения, будь то мобильное, десктоп или веб исполняются у пользователя и используют исключительно API который крутится на сервере.
Anselm_nn
16.02.2025 19:44есть 100500 решений для самохостинга фото/документов и много чего. но гугл фото обладает поиском по содержимому, например по запросу "черный кот" он сам отфильтрует фотки, для этого не требуются ни теги, ни папки, ничего. когда фоток действительно много, это важный функционал. поиск людей, тоже полезно. так что при наличии своего nas, предпочитаю именно для фото гугл
erley
16.02.2025 19:44Широко известное решение которое позволяет искать по содержимому - это например Immich. Прекрасно работает у меня "на стареньком core2duo" с базой около 70 тыс фото+видео. Поиск моментальный.
Там возможностей побольше чем в этом Google Photo, советую & рекомендую...
sena
16.02.2025 19:44гугл фото обладает поиском по содержимому
сейчас это всё прикручивается и к домашней галерее, хотя не все ещё внедрили и не так просто
sena
Если сервер свой, то зачем тогда сквозное шифрование? Любой фотоальбом подойдёт. Я вот пользовался piwigo. Потом перешёл на owncloud, но сейчас думаю переключиться на nextcloud, потому что у него больше возможностей. Кстати и в owncloud и в nextcloud есть несколько схем с шифрованием. Одна из них с шифрованием на стороне сервера, другая - сквозное шифрование E2EE (второе только в некстклауд, если не ошибаюсь), но для E2EE разумеется нужен клиент, поэтому я им не пользуюсь.
В этом минус E2EE - в браузере это не будет работать нормально никогда. Поэтому server-side-encryption SSE вполне разумный и удобный компромисс. При этом все файлы зашифрованы и расшифровать их можно только если взломщик перехватит пароль. Что тоже возможно, конечно, но потребует заметно больше усилий. Зато клиент не обязателен, а это критически важно для галереи, как по мне.
В любом случае шифрование несёт неудобства и некоторые неочевидные опасности. Поэтому трижды подумайте, стоит ли оно того.
aleksejs1
Ну... во-первых свой сервер не обязательно невзламываемый... А во-вторых, тут вроде речь не идёт о "собственном" сервере. У ребят есть свой хостинг с платными и бесплатными планами.
А о чём тогда статья вообще? Попробуйте бесплатный план. В браузере всё отлично работает без каких либо клиентов. И это не единственный представитель такой технологии. У proton.me ценая экосисмема браузерного E2EE выстроена. И любой password-manager в браузере работает по тому же принципу. Конечно, клиент будет работать быстрее, но браузеры дискомфорта тоже не доставляют, особенно со всеми современными API.