Kto widzi kopertę: porównanie metadanych w Signal, SimpleX, Session i XMPP
Szyfrowanie end-to-end odpowiada na jedno pytanie — czy ktokolwiek może przeczytać tę wiadomość w drodze — i nie mówi nic o cichszym pytaniu, które ważne jest równie mocno: kto widzi to, że wiadomość w ogóle powstała. Metadane doręczania, takie jak czasy połączeń, adresy IP, identyfikatory i wzorce kontaktów, nigdy nie są szyfrowane, bo coś musi pozostać czytelne, by ruch w ogóle dało się routować.
Co obejmują metadane
Szyfrowanie treści ukrywa to, co powiedziane. Nie ukrywa, że urządzenie w danym momencie, z danej sieci, skontaktowało się z usługą i wymieniło ładunek określonego rozmiaru. Sam timing i objętość pozwalają naszkicować, kto z kim i kiedy rozmawia; dlatego architektoniczne wybory komunikatora w sprawie metadanych ważą tyle, co jego szyfry.Signal: sealed sender i minimalne przechowywanie
Signal ogranicza przechowywanie po stronie serwera do minimum i od 2018 roku używa sealed sender, który zdejmuje tożsamość nadawcy z zewnątrz każdej wiadomości; porównanie projektu to list z "a blank space where the 'from' address used to be", doręczalny przy znajomości tylko adresata. Ten sam wpis przyznaje granice: odporność na "traffic correlation via timing attacks and IP addresses" to wciąż praca w toku, a urządzenie korzystające z Signala i tak zgłasza swoje połączenie infrastrukturze Signala. To, co Signal faktycznie przechowuje, dokumentują mniej materiały marketingowe, a więcej ujawnienia prawne. Jego strona żądań rządowych publikuje transkrypcje otrzymanych wezwań; odpowiadając na wezwanie wielkiej ławy przysięgłych w 2016 roku, firma podała, że jedynymi informacjami, które mogła wydać, były data rejestracji konta i data ostatniego połączenia użytkownika. Żądania obsłużone w 2021 roku i po kolejnym wezwaniu w marcu 2026 powtarzają ten sam motyw: danych po prostu nie ma na serwerach Signala. Pozostaje resztka, którą ma każdy układ klient-serwer: kiedy się łączyłeś i skąd. Jeden strukturalny identyfikator zostaje: konta Signal są tworzone na numer telefonu, choć nazwy użytkownika trzymają teraz ten numer z dala od list kontaktów innych osób. To wiąże każde konto z czymś w realnym świecie — istotne, gdy posiadacz nie może zostać powiązany z osobą.SimpleX: żadnych identyfikatorów użytkownika w sieci
SimpleX uderza w problem identyfikatorów wprost. Zamiast kont przekazuje wiadomości przez kolejki wiadomości na kontakt, których adresy to jedyna rzecz znana serwerowi. Projekt oświadcza, że "SimpleX Chat has no user identifiers visible to the network", a profile, kontakty i wiadomości są przechowywane wyłącznie na urządzeniach klienckich. Rozmowa zwykle biegnie przez dwa różne przekaźniki, po jednym na kierunek, więc żaden operator nie widzi ruchu w obie strony. Jest też niezależna weryfikacja: audyt kodu przez Trail of Bits ogłoszony w listopadzie 2022 znalazł dwie podatności średniej i dwie niskiej wagi w bibliotece kryptograficzno-sieciowej — żadna nie podważa modelu bez identyfikatorów. Serwery SimpleX widzą adres kolejki i połączenie z nią — to w dużej mierze powód, dla którego projekt inwestuje potem w prywatny routing, chroniąc IP nadawców przed operatorami przekaźników. Jak w każdym układzie przekaźnikowym, margines zależy też od wielkości sieci: kolejka na mało używanym serwerze łatwiej ulega korelacji niż ta zanurzona w gęstym ruchu.Session: żądania onion we własnej sieci
Session usuwa telefon i e-mail z tworzenia konta: konto to świeżo wygenerowany losowy ID z ziarnem odzyskiwania. Wiadomości podróżują przez jego zdecentralizowaną sieć jako żądania onion, warstwowe tak, że — słowami projektu — "no single server ever knows a message's origin and destination". Doręczanie biegnie przez roje z pięciu do siedmiu węzłów, trzymające zaszyfrowane wiadomości do odbioru. Dokumentacja twierdzi nawet, że czyni to "impossible for Session to track users' IP addresses"; absolutne twierdzenia zasługują na ostrożność, bo mniejsza własna sieć mocno zależy od integralności swoich węzłów.XMPP z OMEMO: szyfrowanie bez obietnic dotyczących metadanych
XMPP to przypadek federacyjny. Standard OMEMO (XEP-0384) przynosi do XMPP szyfrowanie w stylu double ratcheta znanego z Signalu, z obsługą wielu urządzeń, traktując serwery jako niezaufane dla treści. Specyfikacja jest szczera co do granicy: nie chroni przed "metadata and traffic analysis". W sieci federacyjnej widać, kto z kim rozmawia — serwerom utrzymującym konta i wszystkiemu po federacyjnej drodze między nimi. Wybór dostawcy to więc decyzja o metadanych równie mocno jak o dostępności: szyfrowanie treści jest ustandaryzowane, ochrona metadanych zależy od operatora.Czego nie usuwa żaden
Porównanie pozostaje uczciwe tylko wtedy, gdy kończy się tym, co łączy wszystkie cztery:- Signal: usługa widzi czasy połączeń i adresy IP, a rejestracja jest związana z numerem telefonu; sealed sender ukrywa tożsamość nadawcy, a opublikowane ujawnienia pokazują, że wydawane dane to daty rejestracji i ostatniego połączenia.
- SimpleX: przekaźniki widzą adresy kolejek i połączenia z nimi; profile i wiadomości zostają na urządzeniach, bez identyfikatorów kont na poziomie sieci.
- Session: losowe ID kont, routowanie żądań onion ukrywające źródło i cel przed pojedynczymi węzłami, zaszyfrowane wiadomości tymczasowo w rojach węzłów.
- XMPP z OMEMO: treść zaszyfrowana end-to-end, ale serwery i ścieżki federacji widzą, kto z kim i kiedy się komunikuje.
- Wszystkie cztery: dostawca internetu czy sieć lokalna nadal widzi, że urządzenie rozmawia z usługą — albo z Torem, jeśli ruch jest tunelowany — a korelacja timingów pozostaje wszędzie otwarta.