Запитуйте не лише, хто може читати ваші повідомлення, а й хто може пов'язати супровідні записи — і протягом якого часу.
Метадані повідомлень — це інформація про спілкування, а не його текст: ідентифікатори облікових записів, час, записи з'єднань, стан доставки або склад групи залежно від архітектури. Наскрізне шифрування може залишати текст нечитабельним для сервісу доставки, тоді як частина цієї супровідної інформації залишається видимою.
Наприклад, «Я прийду о шостій» — це вміст. Факт того, що один обліковий запис зв'язався з іншим у певний час, — метадані. Хто може спостерігати кожен із цих фактів, залежить від архітектури застосунку та мережі.
Вміст повідомлень і метадані — різні речі
Наскрізне шифрування захищає вміст розмови. Метадані описують, як сервіс передає й організовує цю розмову: які облікові записи беруть участь, коли сталася подія, чи доставлено повідомлення та який діалог має його отримати.
Ця відмінність важлива, бо месенджер може шифрувати текст повідомлень і водночас зберігати службову інформацію. Вона також означає, що слова «зашифрований», «приватний» і «нульове знання» не взаємозамінні. Корисна оцінка безпеки з'ясовує, які саме дані шифруються, де перебувають ключі та яка інформація залишається доступною сервісу.
Що захищає наскрізне шифрування
У правильно реалізованій розмові з наскрізним шифруванням відправник шифрує вміст до його потрапляння у сховище, а пристрій учасника розшифровує його. Сервіс передає шифротекст, а не читабельний вміст повідомлення.
Залежно від продукту E2EE може охоплювати:
- Текст повідомлень і редагування
- Підписи та вкладення
- Голосові нотатки й інші завантажені медіафайли
- Реакції або відповіді, якщо вони входять до зашифрованого вмісту
Це охоплення не автоматичне. Продукт може шифрувати особисті повідомлення, але використовувати іншу модель для груп, каналів, резервних копій, попереднього перегляду посилань або дзвінків. Читайте документацію продукту з безпеки, а не припускайте, що один значок замка стосується кожної функції.
Які метадані можуть залишатися видимими?
Месенджеру потрібна певна інформація для маршрутизації повідомлень, контролю доступу, синхронізації пристроїв і запобігання зловживанням. Ці службові дані можуть включати:
| Категорія даних | Чому сервіс може її обробляти |
|---|---|
| Учасники та ідентифікатори діалогів | Спрямування події до правильних облікових записів і розмови |
| Часові позначки та порядкові номери | Упорядкування повідомлень і отримання пропущених оновлень після розриву зв'язку |
| Стан доставки та прочитання | Синхронізація статусу повідомлень між пристроями |
| Склад учасників і ролі | Контроль доступу до груп і каналів |
| Розмір шифротексту та метадані медіа | Правильне зберігання й доставляння зашифрованого вмісту |
| Мережева інформація | Встановлення з'єднань, робота інфраструктури та розслідування зловживань |
Це не означає, що всі сервіси збирають однакові дані або зберігають їх однаково довго. Це означає, що серйозне порівняння приватності має вивчати збирання, строки зберігання, контроль доступу та видалення, а не лише алгоритм шифрування.
Чому метадані заслуговують на увагу
Метадані можуть розкривати закономірності, навіть коли вміст повідомлень залишається нечитабельним. Часте спілкування двох облікових записів, раптова зміна активності або участь у певній групі можуть самі нести контекст.
Практичний ризик залежить від того, які дані збираються, як довго зберігаються, чи пов'язані вони з реальною особою та хто має до них доступ. Короткочасний службовий запис відрізняється від постійного рекламного профілю. Прозорий сервіс має пояснювати цю різницю в документації з приватності та безпеки.
Запитання перед вибором месенджера
Використовуйте ці запитання, оцінюючи будь-яку платформу обміну повідомленнями:
- Які типи розмов зашифровані наскрізно?
- Чи шифруються вкладення до завантаження?
- Де генеруються та зберігаються приватні ключі ідентичності?
- Чи може інший пристрій відновити ключі без окремого секрету відновлення?
- Які дані маршрутизації, складу учасників, часових позначок і доставки зберігає сервер?
- Чи захищені резервні копії ключем, недоступним сервісу?
- Чи можуть учасники перевіряти відбитки публічних ключів після зміни ключа?
- Чи розрізняють заяви про безпеку особисті чати, групи, канали та дзвінки?
- Як платформа працює з видаленням облікового запису та збереженими даними?
- Чи описує політика приватності аналітику, рекламу та сторонні сервіси?
Конкретні відповіді цінніші за широкі обіцянки. Якщо сервіс не може описати свою межу довіри, користувачі не можуть ухвалити щодо нього поінформоване рішення.
Хто може спостерігати яку частину розмови?
Не об'єднуйте всіх спостерігачів в одну всевидющу сторону. Корисне початкове наближення таке:
| Спостерігач | Можлива видимість | Важлива межа |
|---|---|---|
| Інтернет-провайдер або локальна мережа | Адресати з'єднань, час і обсяг трафіку | Правильно захищений вміст повідомлень не стає автоматично читабельним; видимі поля залежать від транспорту та маршрутизації |
| Сервіс обміну повідомленнями | Дані облікових записів, доставки й складу учасників, потрібні його архітектурі | Він може не отримувати відкритий E2EE-вміст, а зберігання може відрізнятися від тимчасової обробки |
| Постачальник push-сповіщень або хостингу | Інформація, потрібна інтеграції сповіщень або хостингу сервісу | Розкриття вмісту й ідентифікаторів залежить від реалізації |
| Інші учасники | Розшифровані повідомлення та інформація, показана в розмові | Вони можуть копіювати або розголошувати отримане |
| Той, хто контролює кінцевий пристрій | Дані, доступні цьому пристрою або сеансу | Мережеве шифрування не виправляє компрометацію кінцевого пристрою |
Ця таблиця — схема аналізу, а не вимірювання конкретного застосунку. Мережевий провайдер не обов'язково бачить ті самі записи рівня облікового запису, що й месенджер, а постачальник застосунку не обов'язково зберігає все, що обробляє.
Рекомендації IAB щодо приватності в RFC 6973 розглядають зіставлення, ідентифікацію та мінімізацію даних як окремі проблеми приватності. Сталий ідентифікатор може пов'язувати дії в часі, навіть якщо це не офіційне ім'я. Поєднання записів із кількох джерел може розкрити більше, ніж будь-який окремий запис.
Задокументована межа метаданих Livara
Документація Livara з безпеки описує зашифрований вміст особистих розмов і сумісних приватних груп, тоді як маршрутизація, склад учасників, час, розміри шифротексту, push-токени та записи безпеки обробляються окремо. Публічні канали читабельні для сервера; шифротекст приватних груп не слід плутати з відкритим текстом публічних каналів.
Наявність криптографічного компонента в документації не доводить, що він використовується на кожному реальному шляху обробки. Наприклад, задокументований компонент LSS1 не описано як підключений до звичайного надсилання повідомлень. Його не можна використовувати для твердження, що звичайне спілкування в Livara приховує метадані відправника. Перевіряйте поточну документацію з безпеки та інформацію про приватність, щоб з'ясувати фактичний обсяг і заявлені строки зберігання.
Ця стаття не містить незалежних вимірювань робочого трафіку Livara або зберігання на сервері. Заяви про шифрування вмісту не доводять, що сервіс збирає найменше метаданих серед конкурентів.
Практичні способи зменшити розкриття
Шифрування — одна складова захисту облікового запису. Користувачі також можуть зменшити розкриття кількома конкретними діями:
- Діліться лише даними профілю та ідентифікаторами облікового запису, потрібними для розмови; повторне використання публічного імені або аватара може пов'язати окремі облікові записи.
- Відмовляйте в непотрібних дозволах на контакти або місцеперебування й окремо перевіряйте видалення раніше синхронізованих даних.
- Використовуйте унікальні облікові дані, де це застосовно, і захищайте доступ до самого пристрою.
- Зберігайте фразу відновлення окремо від пристрою з активним входом.
- Порівнюйте відбитки ключів через інший довірений канал після неочікуваної зміни ідентичності.
- Переглядайте склад групи перед поширенням чутливого вмісту.
- Оновлюйте браузер, операційну систему та клієнт месенджера.
- Сприймайте попередні перегляди сповіщень, знімки екрана й експортовані медіа як копії поза зашифрованою розмовою.
Гігієна пристрою захищає іншу частину проблеми, ніж мінімізація метаданих. Вона не змушує журнали постачальника зникати. Так само видалення бульбашки повідомлення або встановлення таймера зникнення не обов'язково видаляє записи маршрутизації, резервні копії або копію іншого учасника.
Як корисно читати заяви про приватність
Надійна заява про приватність називає захищені дані, механізм і межі. «Вміст особистих повідомлень шифрується на пристроях учасників» — перевірюване твердження. «Цілковито приватно» — ні.
Порівнюючи месенджери, розділяйте чотири запитання: хто може читати вміст, які метадані обробляє сервіс, як працює відновлення облікового запису та що відбувається на кожному пристрої. Така схема дає точніше рішення, ніж вибір продукту лише за гаслом.
Чи приховує VPN метадані повідомлень?
VPN змінює мережевого оператора, який може спостерігати частини з'єднання; він не прибирає автоматично записи облікового запису або доставки в месенджері. Вхід у той самий обліковий запис усе ще ідентифікує його для сервісу. Окремо оцінюйте VPN-постачальника, архітектуру маршрутизації повідомлень і політику зберігання застосунку, а не вважайте змінену IP-адресу повною анонімністю.
Запитуйте про строки зберігання, а не лише про збирання
Для кожного важливого поля запитайте, чи воно обробляється тимчасово, записується до журналу, зберігається в резервній копії або передається іншому постачальнику. Потім запитайте, як довго воно залишається та чи має видалення винятки. Якщо документація цього не говорить, запишіть строк як невідомий. «Потрібно для роботи» пояснює можливу мету, але саме по собі не визначає обмеження строку зберігання.
