Коли я допомагаю клієнтові підготуватися до делікатної розмови, то питаю не лише про те, яким застосунком він користується. Мене цікавить, що з нього витікає назовні, хто зберігає резервні копії й який пристрій у співрозмовника. Шифрування важливе, але саме по собі ще не привід для спокою.
Делікатна розмова починається не із застосунку, а з того, що про вас витікає
Шифрований зв’язок я сприймаю як перший рівень захисту, а не як готове рішення. Наскрізне шифрування (E2EE) захищає вміст повідомлення на шляху між пристроями. Ні провайдер сервісу, ні той, хто перехоплює дані дорогою, цього вмісту не бачать. У цьому принципова відмінність від шифрування лише під час передавання, коли сервер бачить повідомлення у відкритому вигляді.
На практиці це означає, що для справді делікатних розмов я прагну залишати якомога менше прямих слідів. Чим менше людей і систем можуть бачити вміст, тим менше простору для помилки й тиску ззовні. Клієнтам я пояснюю просто: один добрий замок корисний, але весь дім він не захищає.
Тому E2EE для мене — необхідний мінімум, а не розкішне доповнення. Якщо йдеться про делікатну тему, насамперед з’ясовую, чи справді вміст захищений на обох кінцях і чи не відкривається при цьому решта шляху.
Signal для мене — еталон
Якщо для делікатних розмов треба порадити один базовий варіант, я обираю Signal. Причина не в маркетингу, а в тому, як він побудований. Протокол публічно перевірили незалежні криптографи, застосунок має відкритий вихідний код, а Signal працює як неприбутковий фонд, що існує на пожертви. Тож ніщо не змушує його заробляти на даних чи рекламі.
Signal, на мою думку, варто обирати ще й тому, що він зберігає мінімум метаданих. На вимогу суду він технічно здатен видати практично лише дату створення облікового запису й час останнього підключення. Функція Sealed Sender до того ж приховує навіть від сервера, хто відправник. Сервер тоді — лише точка пересилання, а не той, хто читає більше, ніж мусить.
Для мене тут важливе ще одне. Захищаючи клієнта, я не задовольняюся тим, що лише звучить безпечно. Мені потрібен інструмент, який обмежує і вміст, і супутні сліди. Із цього погляду Signal — еталон саме тому, що спирається не на гучні слова, а на мінімум даних і відкриту модель.
Метадані бувають не менш важливими, ніж сам вміст
Люди часто чують слово «шифрування» і вважають, що справу зроблено. Але E2EE не приховує метаданих. Залежно від сервісу й від того, хто дивиться (провайдер, спостерігач у мережі чи сам пристрій), усе ще може бути видно, хто з ким спілкується, коли, як часто, звідки й як довго. У делікатних стосунках цей слід може сказати більше, ніж саме повідомлення.
Тому я й розрізняю сервіси. WhatsApp шифрує вміст і побудований на протоколі Signal, проте збирає чимало метаданих: номери телефонів, мережу ваших контактів, участь у групах, IP-адресу та звички користування. Для повсякденного спілкування цього може бути досить, але для делікатної розмови різниця суттєва.
Я порівнюю це з дверима, які хтось зачинив, але перед будинком залишив чіткі сліди: хто й коли приходить і йде. Те, що всередині, може бути захищене, а от рух довкола — вже значно менше. І саме тут зловмисник чи спостерігач може спертися на метадані.
WhatsApp, iMessage, Telegram і RCS: у кожного свої обмеження
У WhatsApp я бачу ще один практичний ризик — резервні копії в хмарі. За замовчуванням вони не мають наскрізного шифрування, і зашифровані копії доводиться вмикати вручну. Без цього до вмісту розмови можна дістатися іншим шляхом, через резервну копію, хоча самі повідомлення передаються з наскрізним шифруванням.
Схоже слабке місце має iMessage. Між пристроями Apple повідомлення захищені E2EE, але стандартна резервна копія в iCloud традиційно містила ключі, які відкривали доступ до вмісту. Повний захист дає лише функція «Розширений захист даних» (Advanced Data Protection). Без неї хмарна резервна копія — слабша ланка, ніж люди зазвичай готові визнати.
Щодо Telegram поширена хибна думка. Звичайні хмарні чати в ньому не мають E2EE, тож Telegram технічно може отримати доступ до їхнього вмісту. E2EE є лише в секретних чатах (Secret Chats), які працюють тільки для розмов віч-на-віч і не синхронізуються між пристроями. З RCS історія новіша: наскрізне шифрування між Android та iPhone почали запускати в бета-режимі у травні 2026 року, але воно працює лише тоді, коли в обох співрозмовників актуальне програмне забезпечення, а оператор таке шифрування підтримує. Метадані від цього не зникають, а запуск відрізняється від країни до країни й від мережі до мережі.
- увімкнути у WhatsApp резервні копії з наскрізним шифруванням
- на iPhone увімкнути «Розширений захист даних» для iCloud
- не вважати звичайні чати Telegram захищеними E2EE
- для RCS зважати на те, що доступність залежить і від програмного забезпечення, і від оператора
Особа співрозмовника й стан пристрою важать не менше, ніж шифрування
Коли йдеться про безпечний зв’язок, я завжди додаю ще один крок — перевірку особи співрозмовника. У Signal для цього є номери безпеки (safety numbers), у WhatsApp — код безпеки (security code). Перевірка під час особистої зустрічі через QR-код або звіряння номерів іншим каналом захищає від підміни ключа. Без цього ви не можете бути певні, хто на іншому боці.
Так само важливо думати не лише про канал, а й про сам пристрій. Скомпрометований телефон дає змогу обійти будь-яке E2EE. Шпигунські програми на кшталт Pegasus читають повідомлення просто з екрана, у відкритому вигляді, тобто до шифрування або після розшифрування. Шифрування тоді захищає шлях, але не пристрій, який контролює зловмисник.
Тому я вважаю доречними й повідомлення, що зникають. Вони зменшують обсяг історії на пристрої, а отже, і шкоду, якщо його зламають. Але вони не захищають від того, що співрозмовник сфотографує чи збереже повідомлення. Чесно кажучи, від людського фактора вони не щит.
- під час першого контакту перевірити номер безпеки або код безпеки
- у делікатних чатах вмикати повідомлення, що зникають
- вчасно оновлювати систему й застосунки
- звести кількість установлених застосунків до мінімуму й не випускати телефон із рук
Чому, дбаючи про конфіденційний зв’язок, я стежу й за законодавством
Свою роль відіграє й законодавство. У європейській ініціативі Chat Control / CSAR, тобто пропозиції ЄС щодо масового сканування приватних повідомлень, я бачу передусім одне: це не перегорнута сторінка, і ситуація постійно змінюється. Тимчасовий виняток для добровільного сканування (так званий Chat Control 1.0) втратив чинність у квітні 2026 року; у липні Європейський парламент проголосував за його відновлення, вивівши з-під його дії комунікацію з наскрізним шифруванням, а 23 липня 2026 року Рада ЄС остаточно його схвалила. Діяти він має до 3 квітня 2028 року. Щодо постійного регламенту CSAR переговори тривають: наприкінці 2025 року Рада ЄС вилучила з нього загальні обов’язкові накази про виявлення, але текст і далі змінюється. І все ж я ніколи не назвав би це питання розв’язаним назавжди.
Мене як людину, що захищає клієнтів, тут цікавить суто практичний бік. Якби обов’язкове масове сканування вмісту зрештою ухвалили, воно послабило б саме те наскрізне шифрування, на якому тримається весь цей підхід, а з ним і конфіденційність, якої ви очікуєте від безпечного зв’язку. Тому в делікатних справах я покладаюся на інструменти з E2EE, що пройшли аудит, і не розраховую, що правове поле залишиться незмінним. Я стежу, куди рухається дискусія, і відповідно коригую свої рекомендації.
Підсумую як практик: шифрування — необхідна основа, але не вся система безпеки. Потрібні ще перевірка співрозмовника, захищений пристрій, розумно налаштовані резервні копії та сервіс, що збирає мінімум метаданих. Якщо ви хочете налаштувати зв’язок для делікатної розмови по-діловому й без зайвого драматизму, це саме той випадок, коли все варто зробити спокійно й заздалегідь.
«Шифрування — це один добрий замок на дверях, а не вся система безпеки дому». — Robert Václavík
