Що відбувається із зашифрованим чатом, якщо компанію юридично зобов'язують його передати
Поширене питання про приватні месенджери — що станеться, якщо державний орган чи правоохоронці вимагатимуть дані від компанії-розробника. Чесна відповідь повністю залежить від того, до чого компанія взагалі має доступ, а це відрізняється набагато сильніше, ніж думає більшість людей.
Компанія може передати лише те, що в неї є
Це найважливіший факт у всій цій темі: компанія не може розкрити дані, якими не володіє.
Якщо зміст повідомлень зашифрований наскрізно і компанія ніколи не тримає ключів для розшифрування, то навіть дійсний, юридично обов'язковий запит, що зобов'язує компанію передати зміст повідомлень, не дасть жодних читабельних повідомлень. Компанія може повністю виконати запит і водночас не мати нічого корисного для передачі, оскільки контент їй просто недоступний.
Це відрізняється від небажання компанії співпрацювати. Це структурне обмеження: сама архітектура визначає, що можна передати, незалежно від намірів компанії чи її юридичних зобов'язань.
Що компанія зазвичай може передати навіть за наявності сильного шифрування
Шифрування захищає зміст. Воно автоматично не захищає все інше, до чого сервіс має відношення. Залежно від того, як побудований месенджер, юридичний запит усе одно може отримати:
Інформацію про створення акаунта, наприклад номер телефону, електронну пошту чи IP-адресу, використану при реєстрації
Часові мітки створення акаунта чи останньої активності
Метадані про доставку повідомлень — коли вони були надіслані, кому і як часто
Будь-які незашифровані дані на сервері, наприклад інформацію профілю
Резервні копії, якщо сервіс зберігає бекапи чатів на власних серверах, а не лише на пристрої користувача
Саме тому саме лише шифрування не дає повної відповіді на питання "що можна отримати про мене через юридичний запит". Ідентифікатори й метадані, які сервіс збирає на рівні акаунта, важать не менше, ніж те, як він шифрує повідомлення.
Чому тут важлива мінімізація даних
Сервіс, який ніколи не збирав певний фрагмент інформації, не може бути зобов'язаний його передати, бо цієї інформації просто не існує в системах компанії.
Саме тому мінімізація даних вважається основним принципом приватності, а не просто приємним бонусом. Месенджер, який не вимагає номер телефону для реєстрації, не має номера телефону для розкриття. Сервіс, що не завантажує списки контактів, не має графа контактів для передачі. Сервер, який видаляє зашифрований текст після доставки, не має нічого для розкриття про це повідомлення після того, як воно вже доставлене.
Мінімізація даних і шифрування працюють разом: шифрування захищає те, що існує, а мінімізація зменшує те, що взагалі існує.
Звіти про прозорість і що вони насправді показують
Багато компаній-розробників месенджерів публікують звіти про прозорість, розкриваючи, скільки юридичних запитів вони отримали і як на них відповіли. Ці звіти корисні, але відповідають на вужче питання, ніж часто думають: вони показують, як компанія відповіла на запити, а не те, що вона в принципі могла б передати.
Компанія, що звітує "ми виконали запит, надавши метадані", повідомляє щось реальне про свою архітектуру — а саме те, що в неї були метадані для передачі. Компанія, яка звітує, що не змогла надати зміст повідомлень навіть за примусу, підтверджує, що її модель шифрування справді тримає контент поза її досяжністю.
Читання таких звітів з урахуванням цієї різниці корисніше, ніж сприймати "кількість отриманих запитів" як головну статистику.
Що це означає для вибору месенджера
Варто розділяти два питання, оцінюючи стійкість месенджера до юридичних запитів:
Чи зашифрований зміст повідомлень наскрізно, так що компанія ніколи не тримає ключів розшифрування?
Яку інформацію на рівні акаунта та метадані компанія збирає і зберігає, незалежно від змісту повідомлень?
Месенджер може мати хороший результат за першим питанням і поганий за другим, і це все одно залишає значний обсяг інформації, доступної для юридичного запиту, навіть якщо сам зміст повідомлень залишається захищеним.
Як Clam підходить до цього
Clam спроєктований так, що зміст повідомлень зашифрований наскрізно за допомогою протоколу Double Ratchet із Sealed Sender, тобто компанія не тримає ключів, потрібних для читання змісту повідомлень, незалежно від будь-якого запиту, який вона могла б отримати.
На рівні акаунта Clam не вимагає номера телефону чи пошти для створення акаунта, а сервер зберігає лише зашифрований текст, який видаляється після доставки, а не зберігається постійно. Це свідомий вибір у дизайні: чим менше збирається і зберігається спочатку, тим менше існує для запиту пізніше.
Жодна архітектура не може гарантувати, що компанію ніколи ні про що не попросять. Але архітектура може визначати, скільки з того, що просять, взагалі існує для передачі.
Підсумок
Питання "чи можуть змусити мій месенджер передати мої дані" має складнішу відповідь, ніж просто "так" чи "ні". Вона залежить від того, що сервіс збирає, що шифрує і що зберігає після того, як повідомлення вже доставлене. Розуміння цієї різниці корисніше, ніж сприймати слово "зашифровано" як єдину гарантію, що охоплює все, що сервіс знає про вас.
