Local-First и Zero-Knowledge: архитектура настоящей приватности

Долгие годы разработка приложений строилась вокруг облака: сервер хранил все данные, а устройства пользователей служили лишь тонкими клиентами. Пользователи доверяли компаниям свои файлы, заметки, переписку и историю активности. Компании, в свою очередь, обещали эти данные защищать. Некоторые держали слово, многие нет, а часть компаний была взломана несмотря на все меры предосторожности.

Проблема архитектурная. Когда все пользовательские данные проходят через центральный сервер в читаемом виде, этот сервер становится единой точкой уязвимости. Взломанная база данных, судебный запрос, нечестный сотрудник или изменившаяся бизнес-модель приводят к одному результату: кто-то получает доступ к вашим данным без вашего согласия.

Privacy Engineering решает эту проблему на уровне дизайна системы, а не через политику конфиденциальности. Два архитектурных подхода, применяемых вместе, позволяют строить системы, в которых сервер физически не может прочитать то, что хранит.

Local-First: устройство как основное хранилище

В Local-First приложении основная база данных находится на вашем устройстве. Когда вы создаёте заметку, редактируете документ или делаете запись, запись происходит мгновенно в локальное хранилище. Сетевой запрос не нужен. Сервер используется только для синхронизации между вашими устройствами или для совместного доступа.

Это изменение даёт три практических преимущества. Первое: приложение работает офлайн без каких-либо дополнительных механизмов, потому что офлайн является базовым состоянием. Второе: операции чтения и записи быстры, ограничены только скоростью диска, а не задержкой сети. Третье: если компания закроется, ваши данные останутся на устройстве в целости и доступности.

Техническая сложность Local-First заключается в синхронизации между устройствами без центрального арбитра. Стандартное решение: CRDT(Conflict-free Replicated Data Types) — структуры данных, которые можно объединять из двух источников без центрального координатора. Если ваш ноутбук и телефон оба редактировали один документ в офлайн-режиме, CRDT при следующем подключении даст согласованный результат без необходимости спрашивать, какая версия верна.

Zero-Knowledge Architecture: сервер, который не видит ваших данных

Даже при Local-First подходе сервер всё равно нужен для синхронизации и резервного копирования. Zero-Knowledge Architecture (ZKA) определяет, как этот сервер должен быть устроен: он получает и хранит данные, но данные зашифрованы ключами, к которым у него никогда нет доступа.

На практике это означает, что шифрование происходит на клиенте до того, как данные покидают устройство. Ключи шифрования формируются из пароля пользователя или локально хранящегося секрета. Сервер получает зашифрованный текст, который не может расшифровать. Даже при полном доступе к базе данных злоумышленник или сотрудник видит только зашифрованные байты.

Для сложных сценариев Zero-Knowledge Proofs (ZKP) позволяют серверу проверять утверждения о данных пользователя, не видя самих данных. Сервер может подтвердить, что у пользователя есть действующая подписка, не зная, кто этот пользователь. Или проверить легитимность транзакции, не видя её сумм. Это другая концепция, нежели общее шифрование, но принцип тот же: сервер узнаёт только то, что строго необходимо для его работы.

Как это работает вместе

Рассмотрим приложение для заметок, построенное на обоих принципах:

1. Вы пишете заметку. Она мгновенно сохраняется в локальную базу данных.
2. При подключении к сети приложение шифрует заметку локальным ключом.
3. Зашифрованный пакет отправляется на сервер, который хранит его, не имея возможности прочитать.
4. Другое ваше устройство скачивает зашифрованный пакет и расшифровывает его локально.
5. Если оба устройства редактировали данные офлайн, CRDT объединяет изменения при синхронизации.

Сервер в этой схеме выступает как безмолвный посредник. Он не может читать ваши данные, продавать их или предоставить в читаемом виде даже по юридическому запросу. Единственное, что меняется после взлома: злоумышленники получают набор зашифрованного текста.

Инженерные сложности

Эта архитектура требует усилий. Есть три сложные задачи, с которыми столкнётся каждая команда, строящая на этих принципах.

Восстановление ключей. Если пользователь забывает пароль, а ключи никогда не передавались серверу, ссылки для сброса пароля не существует. Стандартный подход: разделение секрета по Шамиру (Shamir's Secret Sharing), где ключ восстановления делится на части и хранится в разных местах (доверенные контакты, резервное устройство, напечатанный код). Если пользователь теряет все части, данные невосстановимы. Обходных путей нет. Это правильный компромисс, но пользователи должны его понимать.

Поиск. Поиск по зашифрованным данным на сервере нетривиален: SQL-запрос к зашифрованному тексту не работает. Практические решения: либо полнотекстовый поиск строится на клиенте (приемлемо для личных данных, медленно для больших объёмов), либо используются специальные схемы шифрования, допускающие ограниченные запросы к зашифрованным данным. Ни один из вариантов не так быстр и гибок, как серверный поиск.

Совместное редактирование. Когда два человека одновременно редактируют один документ, кто-то должен упорядочивать операции. В стандартной архитектуре это делает сервер. В системе со сквозным шифрованием один из клиентов временно выступает координатором, либо используется более сложный зашифрованный CRDT-протокол. Библиотеки Yjs и Automerge упрощают эту задачу, но она остаётся сложнее стандартного подхода.

Почему это важно сейчас

Переход от юридических обещаний к криптографическим гарантиям значим. Политика конфиденциальности — это договор, для исполнения которого нужен надзор. Криптографическое ограничение — это математика: оно работает независимо от того, проверяют ли компанию регуляторы. Local-First в сочетании с Zero-Knowledge Architecture даёт пользователям права на данные, не требующие доверия разработчику.

Инструменты вроде Obsidian (локальные заметки), Standard Notes (синхронизация со сквозным шифрованием) и Proton (почта и облачное хранилище с нулевым знанием) уже работают на этих принципах. Паттерны достаточно зрелые. Основные оставшиеся барьеры: UX управления ключами, более удобные CRDT-библиотеки и знакомство разработчиков с клиентской криптографией.

Это инженерные задачи, не фундаментальные препятствия. Архитектура готова.