- A partir de abril de 2026, los dispositivos no verificados no podrán enviar ni recibir mensajes con cifrado de extremo a extremo (E2EE) en Element
- Este cambio sigue una actualización de la especificación de Matrix y busca reforzar la seguridad de las conversaciones de todos los usuarios
- La verificación de dispositivos es el proceso para demostrar criptográficamente que cada dispositivo realmente pertenece al usuario, eliminando la indicación de mensajes no confiables
- En adelante, solo los dispositivos verificados podrán participar en las conversaciones, y desaparecerán los íconos de advertencia o de escudo
- Esta medida es un paso clave para construir un entorno de comunicación seguro basado en la confianza
Resumen de la actualización de seguridad
- A partir de abril de 2026, Element bloqueará el envío y la recepción de mensajes cifrados de extremo a extremo desde dispositivos no verificados
- Esta medida sigue la actualización de la especificación de Matrix anunciada en la conferencia de Matrix de octubre de 2025
- Los usuarios deberán completar la verificación de dispositivos para seguir intercambiando mensajes cifrados en sus dispositivos existentes
- El objetivo de esta actualización es garantizar que los mensajes realmente provengan del remitente previsto
- Con esto, Element busca ofrecer la tecnología de comunicación más segura posible
Riesgos de los dispositivos no verificados
- Los dispositivos no verificados pueden convertirse en un vector de ataque
- Por ejemplo, cuando aparece un ícono de advertencia durante una conversación, podría tratarse simplemente de un dispositivo sin verificar o de un intento de toma de control de la cuenta
- Ignorar estas advertencias puede hacer que el riesgo de seguridad se propague por toda la red
- Element ofrece cifrado de extremo a extremo por defecto a todos los usuarios y, al hacer obligatoria la verificación, busca eliminar la incertidumbre y la posibilidad de actividad maliciosa
El papel de la verificación de dispositivos
- La verificación de dispositivos es un “handshake” criptográfico entre dispositivos que demuestra que ese dispositivo realmente pertenece al usuario
- Los mensajes enviados desde un dispositivo nuevo no verificado se muestran como mensajes no confiables
- Al hacer obligatoria la verificación, los usuarios pueden tener la certeza de que todos los mensajes están en un estado confiable
La confianza como diseño por defecto
- En adelante, los dispositivos se dividirán en uno de dos estados: “verificado” o “sin acceso a participar en la conversación”
- Ya no se mostrarán íconos de advertencia ni de escudo
- Esto busca evitar que los usuarios se insensibilicen a las advertencias
- La verificación de dispositivos no solo protege a cada persona, sino que también contribuye a reforzar el entorno de confianza de toda la red
- Element está impulsando un diseño de sistema con la seguridad como prioridad máxima, y el proceso de verificación es un componente central
Qué deben hacer los usuarios
- Los usuarios que ya verificaron sus dispositivos y configuraron una recovery key no necesitan realizar acciones adicionales
- Quienes no lo hayan hecho deberán seguir estos pasos
- Revisar el estado de verificación de todos sus dispositivos: móvil, web, escritorio, etc.
- Configurar la función de recuperación (opcional, pero muy recomendada)
- La función de recuperación simplifica la verificación de nuevos dispositivos y permite restaurar la verificación incluso si se pierden todos los dispositivos
- Los pasos específicos para cada plataforma pueden consultarse en la documentación para usuarios de Element
Restricciones si no se verifica
- Después de abril de 2026, los dispositivos no verificados tendrán estas limitaciones
- No podrán enviar mensajes
- No podrán mostrar el contenido de los mensajes recibidos (solo será posible saber que llegó un mensaje)
- En consecuencia, los dispositivos no verificados no podrán usarse en conversaciones con E2EE
- Aun así, podrán participar en conversaciones donde el cifrado esté desactivado
Construcción de confianza y soporte
- Element subraya que asegurar la confianza mediante la verificación de dispositivos es clave para una comunicación segura
- Este cambio se considera una medida pequeña, pero con un gran impacto en el nivel de seguridad
- La meta es trabajar junto con los usuarios para que todos los mensajes sean tan confiables como una conversación cara a cara
- Durante la transición, el equipo de soporte atenderá las consultas de los usuarios y ayudará a que la implementación sea fluida
1 comentarios
Comentarios en Hacker News
Hace 3 meses cerré el servidor y moví de nuevo a la comunidad a IRC
Todavía tenía corriendo IRC en un contenedor de Podman, así que volver fue fácil
Todos los meses sufríamos por errores de verificación de dispositivos, fallas al descifrar mensajes, problemas de UX y demás
Al principio avanzó rápido, pero en los últimos años casi no ha habido mejoras de UX, y eso decepciona
La relación entre Matrix y Element también se ha vuelto confusa
El equipo de desarrollo parece indiferente, y el “policy server” propuesto sigue incompleto
las salas estaban vacías o el envío se quedaba trabado; ni una sola vez logré intercambiar mensajes con éxito
Se obsesionaron con la idea de una “base de datos JSON descentralizada”
y parece que perdieron de vista la usabilidad como sistema de chat
Yo todavía lo uso, pero sigue estando lejos de poder atraer a usuarios comunes
Si hubiera que modernizar una comunidad basada en IRC, creo que Jabber(XMPP) sería una alternativa más realista
Lo probé con amigos, pero por su UX tosca era más incómodo que otros mensajeros
y cuando dejaron de dar soporte al puente con IRC, desapareció la razón para usarlo
Hace unos meses mis dispositivos quedaron desverificados al azar, y aunque inicié sesión con la clave de recuperación, seguían sin verificarse
La verificación cruzada entre iOS, Linux, Windows y Android no coincidía en absoluto
Este tipo de verificación forzada es prácticamente un offboarding involuntario
Si hay un esquema de verificación problemático, deberían anunciarlo en el blog
Me gusta Element, pero esto requería preparación previa
A veces funciona, pero enseguida me cierra la sesión, y siguen apareciendo ventanas emergentes para verificar dispositivos viejos
Me preocupa terminar perdiendo todos mis perfiles
A veces, cada vez que lo abría, tenía que dedicar 30 minutos a resolver problemas
La idea es buena, pero la relación esfuerzo-beneficio es demasiado mala
También afecta negativamente la comunicación en proyectos OSS
Yo lo uso intensivamente, pero nunca he tenido esos problemas
Hace unos meses intenté implementar un bot de Matrix, pero los SDK open source para Python
no soportaban en absoluto E2EE ni verificación de dispositivos, así que fue una experiencia terrible
En cambio encontré el SDK interno en Rust (matrix-rust-sdk) y resultó bastante bueno
También había bindings FFI para Python/Kotlin, pero faltaba documentación
Apoyándome en un LLM y en el código fuente logré hacerlo funcionar a duras penas, y hasta pude completar la verificación por emoji
Ahora la documentación ha mejorado mucho y también ofrecen un cliente de referencia
Leí una crítica a Matrix que vi en Reddit,
donde decía que su estructura de almacenamiento y duplicación permanente de datos perjudica el rendimiento y la privacidad
Signal protege incluso los metadatos, pero en Matrix quedarían expuestos nombres de salas, participantes, horarios, etc.
Quisiera saber si eso es cierto y si es un protocolo con futuro
Hoy el nivel de protección de metadatos es más bajo que en Signal, pero está mejorando
Matrix tiene un modelo de amenazas distinto, y te permite elegir directamente en quién confiar
Si lo operas en un servidor pequeño, la exposición de datos puede ser menor que en Signal
No es perfecto, pero veo de forma positiva la velocidad de avance y la dirección del proyecto
Es un requisito básico de privacidad y aun así la implementación avanza lento
Los problemas al descifrar mensajes siguen ahí
Aun así, entre los sistemas abiertos sigue siendo la mejor opción disponible
así que es vulnerable a ataques de SIM swapping
Su diseño modular y descentralizado es al mismo tiempo una ventaja y una barrera de entrada
Signal, gracias a su estructura simple, tiene un nivel de acabado más alto en sus funciones principales
Al final es una plataforma que asume la existencia de un servidor confiable
A pesar de las quejas en este hilo,
me parece razonable impedir que la gente inicie sesión sin verificar y luego intercambie mensajes cifrados
Llevo 6 años usando Matrix y el proceso de verificación ahora ya es bastante fluido
Cuando terminen también el inicio de sesión con código QR, será mucho más fácil
Puede que cada decisión puntual sea razonable, pero en conjunto hay falta de comunicación y
poca documentación, lo que termina generando confusión
Para quien lo usa seguido está bien, pero quien entra de vez en cuando tiene que jugar a la recuperación cada vez
y te permite descifrar mensajes anteriores al inicio de sesión
El problema de UX fue haber permitido saltarse el paso de verificación
En el blog deberían haber definido claramente qué significa verificación
Ante la pregunta “¿qué es la verificación?”,
al iniciar sesión desde un dispositivo nuevo se realiza una prueba criptográfica de identidad con un dispositivo existente
Se hace de una de estas formas: comparar emojis, escanear un código QR o ingresar una clave de recuperación
En la mayoría de los casos es rápido y sencillo, aunque algunos clientes tienen bugs
Es simplemente el proceso de aprobar un dispositivo nuevo desde uno existente
De todos los mensajeros cifrados que he usado, fue el mecanismo de verificación más fácil
si los emojis que aparecen en ambos dispositivos coinciden, se aprueba
Al iniciar sesión en un dispositivo nuevo, solo tienes que aprobarlo desde uno existente
Yo uso Thunderbird como cliente de Matrix,
pero cuando abro Element o Nheko ambos advierten que no están verificados entre sí
Aunque pulse el botón de verificar no pasa nada, y tampoco aparece ningún código QR
La UX de Matrix de verdad está al nivel de una pesadilla
Dejé de usarlo porque las actualizaciones son lentas
No hay ninguna señal de mejora
Probé un cliente alpha y la ventana emergente de verificación no desaparece
Algunos clientes ni siquiera implementan el flujo de verificación,
así que parece que la barrera de entrada para nuevos clientes va a subir todavía más
Los clientes sufren crashes frecuentes y también hay mucho retraso de sincronización
Por estas razones, creo que XMPP es una mejor opción de chat descentralizado que Matrix
XMPP maneja sus defectos con elegancia y tampoco tiene problemas de sincronización en tiempo real
Si quisiera convencer a colegas de trabajo, necesitaría una UI mejor
Eso sí, XMPP todavía no tiene Cross Signing ni respaldo de claves,
así que aún le faltan comodidades comparado con Matrix
Element es pesado, y los otros clientes tienen un desequilibrio fuerte en funciones
En cambio volví a probar XMPP con un servidor Prosody
La documentación es algo poco amigable, pero la eficiencia de recursos me sorprendió
Es impresionante que un servidor XMPP funcione tan bien incluso en hardware modesto
Del lado del cliente me decepcionó un poco,
pero creo que hay mucho margen para mejorar la documentación
Al final, lo que quiero es que prospere el ecosistema de mensajería libre y open source
Los videos más recientes de la Matrix Conference están en media.ccc.de
Hay mucho contenido interesante,
y aunque no operes tu propio servidor, puedes usar hosting de pago como etke.cc
A mí me gusta mucho Matrix/Element
Estoy administrando varios espacios para la sala de desarrollo de FOSDEM
e incluso las videollamadas funcionaron perfectamente
Solo me gustaría que añadieran más funciones