Пошук у зашифрованих чатах можливий тому, що пристрій, уповноважений читати повідомлення, може й шукати в них. Поширений підхід — створення локального індексу після розшифрування. Але наскрізне шифрування саме по собі не доводить, що пошукові запити ніколи не залишають пристрій, або що всі месенджери використовують однакову архітектуру пошуку.
Ця відмінність важлива, коли пошук повільний, старі результати зникають або новий телефон не знаходить повідомлень, видимих на старому. Повнота пошуку, доступність ключів і синхронізація даних — окремі питання.
Як працює локальний пошуковий індекс
Застосунок може перетворити читабельні повідомлення на індекс, який фіксує, які терміни трапляються в яких повідомленнях. Пошук звертається до цього індексу замість перегляду кожного повідомлення від початку до кінця. Документація FTS5 SQLite описує один із прикладів технології повнотекстового індексування; її згадка тут не підтверджує, що певний клієнт Livara використовує FTS5.
Типова локальна схема має чотири етапи:
- Завантажити або отримати зашифроване повідомлення.
- Розшифрувати його за допомогою уповноважених ключів пристрою.
- Додати придатний для пошуку вміст до локального індексу.
- Повернути результати з даних, які наразі доступні на цьому пристрої.
Індекс містить чутливі дані. Навіть якщо він не зберігає повних речень, терміни й посилання можуть розкривати зміст розмов. Його зберігання, резервні копії, поведінка під час видалення та засоби контролю доступу заслуговують на таку саму увагу, як і база даних чату.
Чи завжди пошук на сервері означає, що сервер читає все?
Ні. Звичайне індексування відкритого тексту на сервері дає сервісу доступ до індексованого вмісту, але це не єдиний можливий варіант віддаленого пошуку. Криптографічні дослідження симетричного шифрування з можливістю пошуку описують способи пошуку в зашифрованих даних, переданих на зовнішнє зберігання, у межах визначених моделей безпеки.
Ці методи мають власні припущення та потенційні витоки. Корисна оцінка з’ясовує, що сервер дізнається про повторні запити, відповідні записи, шаблони доступу та розміри результатів. Ані «пошук відбувається у хмарі», ані «дані зашифровані» самі по собі не дають відповіді на ці питання.
| Підхід | Практична перевага | Що слід з’ясувати |
|---|---|---|
| Локальний індекс | Пошук у доступній історії без віддаленого запиту | Чи зашифровано індекс під час зберігання та чи виключено його з небезпечних резервних копій? |
| Серверний індекс відкритого тексту | Централізоване індексування та пошук у збережених даних | Хто має доступ до вмісту, запитів і журналів? |
| Схема зашифрованого віддаленого пошуку | Може підтримувати визначені запити до захищених даних | Які витоки та припущення довіри допускає конструкція? |
| Змішаний публічний/приватний пошук | Різна обробка публічного та приватного вмісту | Чи зрозуміла користувачеві область пошуку? |
За цією таблицею не можна ранжувати швидкість. Обладнання, якість індексу, обсяг повідомлень, затримка мережі та реалізація — усе має значення. Для цієї статті вимірювання часу виконання не проводилися.
Чому повідомлення можуть бути відсутні в пошуку
Перш ніж зробити висновок, що історію втрачено, перевірте межі проблеми:
- Чи видно повідомлення в розмові? Якщо ні, пошук може відображати недоступність історії, а не несправність індексу.
- Чи вибрано правильну розмову або обліковий запис? Фільтри дат, відправників і медіафайлів можуть виключити інакше придатний результат.
- Чи отримав новий пристрій історію та матеріал для розшифрування? Відновлення ключа ідентифікації не означає автоматичного відновлення всіх повідомлень.
- Чи завершено індексування? Великі імпорти й перервана синхронізація можуть впливати на повноту пошуку.
- Чи розпізнає пошук форму терміна? Зіставлення фраз, написання, пунктуація та мовна токенізація можуть відрізнятися.
Скористайтеся нешкідливою, характерною тестовою фразою в розмові, яку ви контролюєте. Перевірте, чи з’являється вона в пошуку до відключення мережі й після нього. Це може встановити вузький факт про локальну доступність, але не доводить, що застосунок ніколи не надсилає телеметрію чи пошукові дані, коли підключений до мережі.
Що можна сказати про Livara?
На сторінці безпеки Livara зазначено, що вміст приватних повідомлень зашифровано, а маршрутизація, членство, стан доставки та шифротекст забезпечують синхронізацію. Її публічної документації недостатньо, щоб стверджувати використання певного локального пошукового рушія, універсальний пошук без мережі, відсутність телеметрії запитів або виміряний вплив на акумулятор.
Публічні канали мають іншу межу приватності, ніж приватні чати. Сервіс може індексувати публічний вміст, не роблячи такого самого твердження про приватні розмови. Ознайомтеся з моделлю загроз, перш ніж вважати результат глобального пошуку конфіденційним.
Запитання, які варто поставити постачальнику
Запитайте, які повідомлення індексуються, де розташований індекс, чи передається або журналюється текст запитів, що отримує пов’язаний пристрій і як видалення повідомлення впливає на індекси та резервні копії. Чітка відповідь має називати клієнт і версію, а не спиратися на вислів «пошук E2EE».
Пошук — це функція з власним потоком даних. Оцінюйте цей потік разом із шифруванням повідомлень, а не припускайте, що шифрування відповідає на всі пов’язані з ним питання.
