Chi vede la busta: i metadati in Signal, SimpleX, Session e XMPP a confronto
La crittografia end-to-end risponde a una domanda — qualcuno può leggere questo messaggio mentre viaggia? — e non dice nulla su quella più silenziosa che conta quanto la prima: chi può vedere che un messaggio è avvenuto. I metadati di consegna, come tempi di connessione, indirizzi IP, identificatori e schemi di contatto, non vengono mai cifrati, perché qualcosa deve restare leggibile perché il traffico venga instradato.
Cosa coprono i metadati
La cifratura del contenuto nasconde ciò che viene detto. Non nasconde che un dispositivo ha contattato un servizio in un certo momento, da una certa rete, scambiando un payload di una certa dimensione. Tempistiche e volume da soli permettono di abbozzare chi parla con chi e quando; per questo le scelte architetturali di ogni app di messaggistica sui metadati contano quanto la sua cifratura.Signal: sealed sender e ritenzione minima
Signal riduce al minimo l'archiviazione lato server e dal 2018 usa il sealed sender per togliere l'identità del mittente dall'esterno di ogni messaggio; il paragone del progetto è una lettera con "a blank space where the 'from' address used to be", consegnabile conoscendo solo la destinazione. Lo stesso articolo ammette i limiti: la resistenza alla "traffic correlation via timing attacks and IP addresses" resta un lavoro in corso, e un dispositivo che usa Signal comunica comunque la sua connessione all'infrastruttura di Signal. Ciò che Signal conserva lo documentano meno il marketing che le divulgazioni legali. La sua pagina delle richieste governative pubblica le trascrizioni delle richieste ricevute; rispondendo a una subpoena di un grand jury nel 2016, l'azienda ha riferito che le uniche informazioni producibili erano la data di registrazione dell'account e la data dell'ultima connessione dell'utente. Richieste evase nel 2021 e dopo un'altra subpoena nel marzo 2026 ripetono il medesimo motivo: i dati semplicemente non esistono sui server di Signal. Resta il residuo che ha qualsiasi schema client-server: quando vi siete connessi, e da dove. Un identificatore strutturale permane: gli account Signal vengono creati con un numero di telefono, anche se i nomi utente ora tengono quel numero fuori dalle rubriche altrui. Questo lega ogni account a qualcosa del mondo reale, cosa che conta quando il titolare non deve essere collegato a una persona.SimpleX: nessun identificatore utente in rete
SimpleX attacca il problema dell'identificatore alla radice. Invece di account, instrada i messaggi tramite code di messaggi per contatto, i cui indirizzi sono l'unica cosa che un server conosce. Il progetto dichiara che "SimpleX Chat has no user identifiers visible to the network", con profili, contatti e messaggi conservati solo sui dispositivi client. Una conversazione passa in genere per due relay diversi, uno per direzione, così nessun singolo operatore vede il traffico in entrambe le direzioni. Esiste anche un riscontro indipendente: un audit del codice di Trail of Bits annunciato a novembre 2022 ha trovato due vulnerabilità di gravità media e due di gravità bassa nella libreria crittografica e di rete, nessuna delle quali mina il modello senza identificatori. Ciò che i server SimpleX vedono è l'indirizzo della coda e la connessione ad essa; è in gran parte il motivo per cui il progetto ha poi investito nel routing privato per proteggere gli IP dei mittenti dagli operatori dei relay. Come in ogni schema a relay, il margine dipende anche dalla dimensione della rete: una coda su un server poco usato è più facile da correlare di una immersa in un traffico fitto.Session: onion requests sulla propria rete
Session elimina telefono ed e-mail dalla creazione dell'account: un account è un ID casuale appena generato con una seed di recupero. I messaggi viaggiano nella sua rete decentralizzata come onion requests, a strati, così che, nelle parole del progetto, "no single server ever knows a message's origin and destination". La consegna passa per sciami di cinque o sette nodi che custodiscono i messaggi cifrati fino alla raccolta. La documentazione arriva ad affermare che ciò renda "impossible for Session to track users' IP addresses"; le affermazioni assolute meritano cautela, perché una rete propria più piccola dipende molto dall'integrità dei suoi nodi.XMPP con OMEMO: cifratura senza promesse sui metadati
XMPP è il caso federato. Lo standard OMEMO (XEP-0384) porta in XMPP la cifratura in stile double ratchet di Signal con supporto multidispositivo, trattando i server come non affidabili per il contenuto. La specifica è onesta sul confine: non protegge da "metadata and traffic analysis". In una rete federata, chi parla con chi è visibile ai server che ospitano gli account e a tutto ciò che sta sul percorso di federazione fra loro. Scegliere un provider è quindi una scelta di metadati tanto quanto di disponibilità: la cifratura del contenuto è standardizzata, la protezione dei metadati dipende dall'operatore.Cosa non rimuove nessuno
Il confronto resta onesto solo se termina con ciò che tutti e quattro condividono:- Signal: il servizio vede tempi di connessione e indirizzi IP, e la registrazione è legata a un numero di telefono; il sealed sender nasconde l'identità del mittente, e le divulgazioni pubblicate mostrano che i dati prodotti sono date di registrazione e di ultima connessione.
- SimpleX: i relay vedono gli indirizzi delle code e le connessioni ad esse; profili e messaggi restano sui dispositivi, senza identificatori di account a livello di rete.
- Session: ID account casuali, routing in onion requests che nasconde origine e destinazione ai singoli nodi, messaggi cifrati trattenuti temporaneamente negli sciami di nodi.
- XMPP con OMEMO: contenuto cifrato end-to-end, ma server e percorsi di federazione vedono chi comunica con chi e quando.
- Tutti e quattro: un ISP o una rete locale vede comunque che un dispositivo parla con il servizio — o con Tor, se tunnelato — e la correlazione temporale resta un problema aperto ovunque.