Quem vê o envelope: metadados em Signal, SimpleX, Session e XMPP comparados
A criptografia de ponta a ponta responde a uma pergunta — alguém pode ler esta mensagem enquanto ela viaja — e nada diz sobre a mais silenciosa, que importa igualmente: quem pode ver que uma mensagem aconteceu. Metadados de entrega, como tempos de conexão, endereços IP, identificadores e padrões de contato, nunca são cifrados, porque algo precisa continuar legível para que o tráfego seja roteado.
O que os metadados cobrem
A criptografia do conteúdo esconde o que é dito. Não esconde que um dispositivo contatou um serviço em um dado momento, a partir de uma dada rede, e trocou uma carga de dado tamanho. Tempo e volume, sozinhos, permitem esboçar quem fala com quem e quando; por isso as escolhas arquitetônicas de cada mensageiro sobre metadados pesam tanto quanto sua cifra.Signal: sealed sender e retenção mínima
O Signal mantém o armazenamento no servidor ao mínimo e, desde 2018, usa sealed sender para remover a identidade do remetente do exterior de cada mensagem; a comparação do projeto é uma carta com "a blank space where the 'from' address used to be", entregável conhecendo apenas o destino. A mesma publicação admite os limites: a resistência a "traffic correlation via timing attacks and IP addresses" segue em aberto, e um dispositivo que usa o Signal ainda anuncia sua conexão à infraestrutura do Signal. O que o Signal retém está documentado menos pelo marketing e mais pelas divulgações legais. Sua página de solicitações governamentais publica as transcrições das exigências recebidas; ao responder a uma intimação de grand jury em 2016, a empresa informou que a única informação que podia entregar era a data de criação da conta e a data da última conexão do usuário. Pedidos atendidos em 2021 e após outra intimação em março de 2026 repetem o mesmo tema: os dados simplesmente não existem nos servidores do Signal. O que resta é o resíduo que qualquer desenho cliente-servidor tem: quando você se conectou, e de onde. Um identificador estrutural permanece: contas do Signal são criadas com um número de telefone, embora os nomes de usuário agora mantenham o número fora das listas de contatos de terceiros. Isso liga cada conta a algo do mundo real, o que importa quando o titular não pode ser vinculado a uma pessoa.SimpleX: nenhum identificador de usuário na rede
O SimpleX ataca o problema do identificador de frente. Em vez de contas, ele retransmite mensagens por filas de mensagens por contato, cujos endereços são a única coisa que um servidor conhece. O projeto afirma que "SimpleX Chat has no user identifiers visible to the network", com perfis, contatos e mensagens guardados apenas nos dispositivos cliente. Uma conversa normalmente passa por dois retransmissores diferentes, um por direção, de modo que nenhum operador vê o tráfego nos dois sentidos. Há escrutínio independente: uma auditoria de código da Trail of Bits anunciada em novembro de 2022 encontrou duas falhas de severidade média e duas de severidade baixa na biblioteca criptográfica e de rede, nenhuma que mina o modelo sem identificadores. O que os servidores do SimpleX veem é o endereço da fila e a conexão a ela — grande parte do motivo pelo qual o projeto passou a investir em roteamento privado para blindar os IPs dos remetentes dos operadores dos retransmissores. Como em todo desenho de retransmissão, a margem também depende do tamanho da rede: uma fila em um servidor pouco usado é mais fácil de correlacionar do que uma submersa em tráfego intenso.Session: onion requests na própria rede
O Session remove telefone e e-mail da criação de conta: uma conta é um ID aleatório recém-gerado com uma seed de recuperação. As mensagens viajam pela rede descentralizada como onion requests, em camadas tais que, nas palavras do projeto, "no single server ever knows a message's origin and destination". A entrega corre por enxames de cinco a sete nós que guardam as mensagens cifradas até serem coletadas. A documentação chega a afirmar que isso torna "impossible for Session to track users' IP addresses"; afirmações absolutas merecem cautela, pois uma rede própria menor depende muito da integridade de seus nós.XMPP com OMEMO: criptografia sem promessas de metadados
O XMPP é o caso federado. O padrão OMEMO (XEP-0384) traz ao XMPP a criptografia estilo double ratchet do Signal com suporte a múltiplos dispositivos, tratando os servidores como não confiáveis para o conteúdo. A especificação é honesta sobre o limite: não protege contra "metadata and traffic analysis". Em uma rede federada, quem fala com quem fica visível para os servidores que hospedam as contas e para tudo no caminho de federação entre eles. Escolher um provedor é, portanto, uma decisão de metadados tanto quanto de disponibilidade: a criptografia do conteúdo é padronizada, a proteção de metadados depende do operador.O que nenhum deles remove
A comparação só permanece honesta se terminar com o que os quatro compartilham:- Signal: o serviço vê tempos de conexão e endereços IP, e o registro é atado a um número de telefone; o sealed sender esconde a identidade do remetente, e as divulgações publicadas mostram que os dados entregues são datas de registro e de última conexão.
- SimpleX: os retransmissores veem endereços de filas e conexões a elas; perfis e mensagens ficam nos dispositivos, sem identificadores de conta no nível da rede.
- Session: IDs de conta aleatórios, roteamento em onion requests que esconde origem e destino dos nós individuais, mensagens cifradas retidas temporariamente em enxames de nós.
- XMPP com OMEMO: conteúdo cifrado de ponta a ponta, mas servidores e rotas de federação veem quem se comunica com quem e quando.
- Os quatro: um provedor ou rede local ainda vê que um dispositivo fala com o serviço — ou com o Tor, se tunelado — e a correlação temporal segue em aberto em todos.