Quién ve el sobre: metadatos en Signal, SimpleX, Session y XMPP comparados
El cifrado de extremo a extremo responde una pregunta —puede alguien leer este mensaje mientras viaja— y no dice nada sobre la más silenciosa, que importa igualmente: quién puede ver que un mensaje ocurrió. Los metadatos de entrega, como tiempos de conexión, direcciones IP, identificadores y patrones de contacto, nunca se cifran, porque algo debe seguir siendo legible para que el tráfico se enrute.
Qué cubren los metadatos
El cifrado del contenido oculta lo que se dice. No oculta que un dispositivo contactó un servicio en un momento dado, desde una red dada, e intercambió una carga de cierto tamaño. El momento y el volumen por sí solos permiten esbozar quién habla con quién y cuándo; por eso las decisiones arquitectónicas de cada mensajería sobre metadatos importan tanto como su cifrado.Signal: sealed sender y retención mínima
Signal mantiene el almacenamiento del servidor al mínimo y desde 2018 usa sealed sender para eliminar la identidad del remitente del exterior de cada mensaje; la comparación del proyecto es un correo con "a blank space where the 'from' address used to be", entregable conociendo solo el destino. La misma publicación admite los límites: la resistencia a la "traffic correlation via timing attacks and IP addresses" sigue siendo trabajo en curso, y un dispositivo que usa Signal anuncia igual su conexión a la infraestructura de Signal. Lo que Signal retiene lo documentan menos el marketing que las divulgaciones legales. Su página de solicitudes gubernamentales publica las transcripciones de las órdenes que recibe; al responder una citación de un gran jurado en 2016, la empresa reportó que la única información que podía entregar era la fecha de registro de la cuenta y la fecha de la última conexión del usuario. Solicitudes respondidas en 2021 y tras otra citación de gran jurado en marzo de 2026 repiten el tema: los datos simplemente no existen en los servidores de Signal. Lo que queda es el residuo que tiene cualquier diseño cliente-servidor: cuándo te conectaste y desde dónde. Un identificador estructural permanece: las cuentas de Signal se crean contra un número de teléfono, aunque los nombres de usuario ahora lo mantienen fuera de las listas de contactos de otros. Eso ata cada cuenta a algo del mundo real, lo cual importa cuando el titular no debe quedar vinculado a una persona.SimpleX: sin identificadores de usuario en la red
SimpleX ataca el problema del identificador de frente. En lugar de cuentas, reenvía mensajes mediante colas de mensajes por contacto cuyas direcciones son lo único que un servidor conoce. El proyecto afirma que "SimpleX Chat has no user identifiers visible to the network", con perfiles, contactos y mensajes guardados solo en los dispositivos cliente. Una conversación suele pasar por dos relés distintos, uno por dirección, así que ningún operador ve el tráfico en ambos sentidos. Hay escrutinio independiente: una auditoría de código de Trail of Bits anunciada en noviembre de 2022 encontró dos problemas de severidad media y dos baja en la biblioteca criptográfica y de red, ninguno que socave el modelo sin identificadores. Lo que los servidores de SimpleX ven es la dirección de la cola y la conexión a ella; en gran parte por eso el proyecto ha invertido desde entonces en enrutamiento privado para blindar las IP de los remitentes frente a los operadores de relés. Como en todo diseño de relés, el margen también depende del tamaño de la red: una cola en un servidor poco usado es más fácil de correlacionar que una sumergida en tráfico denso.Session: onion requests sobre su propia red
Session elimina teléfono y correo de la creación de cuentas: una cuenta es un ID aleatorio recién generado con una semilla de recuperación. Los mensajes viajan por su red descentralizada como onion requests, en capas tales que, en palabras del proyecto, "no single server ever knows a message's origin and destination". La entrega corre por enjambres de cinco a siete nodos que guardan los mensajes cifrados hasta recogerlos. La documentación llega a afirmar que esto hace "impossible for Session to track users' IP addresses"; las afirmaciones absolutas merecen cautela, porque una red propia más pequeña depende mucho de la integridad de sus nodos.XMPP con OMEMO: cifrado sin promesas de metadatos
XMPP es el caso federado. El estándar OMEMO (XEP-0384) lleva a XMPP el cifrado tipo double ratchet de Signal con soporte multidispositivo, tratando los servidores como no confiables para el contenido. La especificación es honesta con el límite: no protege contra "metadata and traffic analysis". En una red federada, quién habla con quién es visible para los servidores que alojan las cuentas y para lo que haya en la ruta de federación entre ellos. Elegir proveedor es, por tanto, una decisión de metadatos tanto como de disponibilidad: el cifrado del contenido está estandarizado; la protección de metadatos depende del operador.Lo que ninguno elimina
La comparación solo se mantiene honesta si termina con lo que los cuatro comparten:- Signal: el servicio ve tiempos de conexión y direcciones IP, y el registro va atado a un número de teléfono; sealed sender oculta la identidad del remitente, y las divulgaciones publicadas muestran como datos entregados fechas de registro y de última conexión.
- SimpleX: los relés ven direcciones de colas y conexiones a ellas; perfiles y mensajes quedan en los dispositivos, sin identificadores de cuenta a nivel de red.
- Session: IDs de cuenta aleatorios, enrutamiento onion request que oculta origen y destino a los nodos individuales, mensajes cifrados retenidos temporalmente en enjambres de nodos.
- XMPP con OMEMO: contenido cifrado de extremo a extremo, pero servidores y rutas de federación ven quién se comunica con quién y cuándo.
- Los cuatro: un ISP o red local sigue viendo que un dispositivo habla con el servicio —o con Tor, si va túnelado— y la correlación temporal sigue abierta en todas partes.