Para empezar, debo agregar que Mastodon, como red social de microblogging, se basa en una premisa muy diferente a lo que se plantea en las redes sociales tradicionales del sector. Se enfoca especialmente en el microblogging descentralizado sin posibilidades de mensajería. Antes de que alguien quiera corregirme, los llamados “DMs” de Mastodon solo son publicaciones regulares con un nivel de privacidad más estricto. En este caso, solo la persona a quien se menciona puede leer la publicación y… acá la gran cuestión:

Cuando comenzaron las migraciones (o embarcaciones, como suelen decir internamente) de usuarios de Twitter a Mastodon, incluso mucho antes de que Elon Musk la comprara, la gran mayoría, ansiosa por experimentar, comenzó a preguntarse: ¿Cuál es el equivalente de Mastodon para los mensajes directos (DM) de Twitter? En aquel entonces, todavía había mucho por revisar en este proyecto en ciernes, lo que causó confusión. En este caso particular, la función de los “DMs” no estaba clara, ni se especificaba si eran privados o no. Por eso se agregó la advertencia con el siguiente texto:

“Las publicaciones en Mastodon no están cifradas de extremo a extremo. No comparta ninguna información sensible en Mastodon”

Redirigiendo al público a leer las políticas de privacidad y de allí pasamos al apartado de “Publicaciones directas y para seguidores” para leer lo siguiente:

“Todas las publicaciones se almacenan y procesan en el servidor. Las publicaciones directas se entregan sólo a los usuarios mencionados en ellas. En algunos casos, esto significa que se envían a diferentes servidores y se almacenan allí copias del mismo. Nosotros hacemos un esfuerzo de buena fe para limitar el acceso a esas publicaciones sólo a las personas autorizadas, pero otros servidores pueden no hacerlo. Por eso es importante revisar los servidores a los que pertenecen tus seguidores. […] Ten en cuenta que los operadores del servidor y cualquier servidor receptor pueden ver esos mensajes”.

Según Internet Archive, la primera referencia de dicho texto referente a las publicaciones directas data del 04 de Octubre de 2022. (otra referencia de los hechos).

Entonces, teniendo en cuenta todo lo anteriormente escrito, es sumamente valioso nunca intercambiar mensajes clasificados a través de Mastodon en sus “DMs” o publicaciones directas. De esta manera, se puede evitar la posibilidad de que el mensaje sea leído por un operador de cualquier lugar del servidor. Sin embargo, es crucial señalar que este es un caso hipotético, ya que la gran mayoría de la comunidad de Mastodon tiene un fuerte sentido altruista y ha trabajado duro para beneficiar a la comunidad. Montar un servicio no es fácil, y la responsabilidad que conlleva es enorme. Por lo tanto, debemos respetar, aunque teniendo en cuenta estas vulnerabilidades técnicas.

El futuro es el cifrado de extremo a extremo

La primera vez que se mencionó la integración del cifrado de extremo a extremo en Mastodon fue el 06 de Abril de 2017, en donde un usuario propuso en GitHub integrar el protocolo de cifrado OTR para los mensajes directos, si el mismo que es utilizado ampliamente en XMPP. Decía el usuario:

“Sería bueno tener mensajes OTR para mensajes directos. Esto podría habilitarse de manera oportunista cuando esté disponible (IE, cuando ambas instancias lo admitan) y deshabilitarse de lo contrario”.

A lo que Eugen respondió:

“Agregar OTR a Ruby no ganaría nada. Si Ruby (servidor) puede leer su mensaje, no es OTR (Off-the-Record). OTR debe implementarse en el lado del cliente. Tal vez podría haber un cliente que haga eso a través de DM. Pero la interfaz de usuario web no puede hacer esto porque ejecutar criptografía en JavaScript no es mucho mejor que dejar que el servidor haga la criptografía”.

Y en conclusión, cómo pasa en todos los proyectos libres: una gran discusión acerca de qué protocolo de cifrado se debería utilizar, en este caso OTR no funcionaba, en este caso por ser un protocolo síncrono mientras los mensajes directos son un medio asíncrono, por lo tanto, como mencionaba Eugen únicamente se podría a nivel de cliente y no tiene mucho sentido.

En el camino también se mencionó a OMEMO, que fue descartado rápidamente. Además, se mencionó por primera vez a Signal y su protocolo, aunque con varias dificultades, ya que no está diseñado para este propósito. A pesar de admitir lo mínimo para trabajar en este formato, los propios autores de Signal admiten que en principio es básicamente hostil a un entorno federado y está diseñado para ser una plataforma viva, lo cual lo convierte en un estándar interoperable deficiente:

“Una de las cosas controvertidas que hicimos con Signal al principio fue construirlo como un servicio no federado. Ninguno de los protocolos que hemos desarrollado requiere centralización; es totalmente posible crear un mensajero basado en el protocolo de señal federado, pero ya no creo que sea posible crear un mensajero federado competitivo en absoluto”  -Moxie, https://whispersystems.org/blog/the-ecosystem-is-moving/

Y la segunda razón es: “Si no se realiza la autenticación [a través de un canal completamente separado], las partes no reciben ninguna garantía criptográfica sobre con quién se están comunicando” Dando a pie a los ataques MITM.

Durante la discusión, los usuarios más visionarios mencionaron que WebRTC sería la clave para lograr el resultado deseado. También hicieron referencia al protocolo MLS, que en aquellos años era evidentemente inestable, pero que hoy en día es considerado por la mensajería Matrix como una integración viable (lo suponen realizar). Quienes mencionaron estos aspectos en aquel momento pueden considerarse unos visionarios completos. En la actualidad, el protocolo MLS parece ser el más realista para Mastodon y está enfocado en entornos federados, lo que lo hace aún más relevante.

Haciendo recuento rápido, se han mencionado los siguientes protocolos:

• OTR.
• OMEMO.
• Signal Protocol (interación OTR v3) – Libsignal.
• MLS.

Y sé previa que lo más viable era facilitar los clientes E2E, en lugar de integrar uno propio. Esto permite que los clientes de E2E obtengan beneficios de usabilidad de la interoperabilidad (como usar Mastodon como una plataforma de intercambio de claves no confiable o tener mensajes legibles por máquina, hipotéticamente), sin ninguna integración que pueda comprometer su modelo de seguridad.

¿Y cuál es el estado actual?

Es difícil definirlo porque en el año 2022 luego se creó una nueva discusión referente al tema y se extendio tanto que es imposible resumirlo cortamente, aunque un usuario alegaba que los mantenedores de Mastodon “Querían, pero no podían” hacer tal integración, a lo que respondió uno de los desarrolladores más activos, eso nos da una claridad del tema:

“Eso fue planeado y logramos que el lado del servidor funcionara (o al menos parte de él) como viste en #13820 . Pero falta el trabajo del lado del cliente, no principalmente por el aspecto criptográfico (aunque, como siempre, la implementación de la criptografía debe hacerse con cuidado), sino porque no hemos definido un protocolo o un formato para el contenido de los mensajes cifrados : el protocolo de servidor a servidor es ActivityPub, y gran parte también podría reutilizarse para los mensajes cifrados, pero esta no es necesariamente la mejor opción, y las aplicaciones cliente generalmente no manejan ActivityPub en sí, sino otras representaciones simplificadas y producidas por el software del servidor. . Por supuesto, con los mensajes encriptados, el servidor no puede realizar este procesamiento y, sea cual sea la forma que elijamos, las aplicaciones tendrán más trabajo que hacer”.

Y no podía faltar el PERO, siendo el único desafío real los clientes de terceros, quienes tendrían que implementar el soporte ellos mismos.

A secas… lo tenemos y no, aún pensamos en ello.

Mientras escribía este artículo me dio por revisar dicha implementación contando con nuevas respuestas, en ella comentaba hace 3 semanas un desarrollador que estaba trabajando en un cliente de tercero para llevar los mensajes de extremo a extremo los “DMs” de Mastodon, solo que ha tenido varios inconvenientes en el camino y que incluso, apenas se daba cuenta de que dicha integración ya existía en la base, en la integración de la API.

Otra cosa, el desarrollador principal del servidor koyu.space comentaba algo muy cierto y era que todavía no se adelantaran a utilizar tal API porque no se ha visto en producción, entonces de momento no tiene mucho sentido estar expuesto a fallos.

Y para finalizar… si Mastodon logra cumplir con el cifrado de extremo a extremo en producción, SI que será un gran acierto, mismo del que traerá a muchos entusiastas pro-privacy, en donde se tendrá todo en un entorno integrado sin tener que emplear “X” mensajería para una cosa y “Y” servicio de Microblogguin para lo otro, quitando menos redundancia del camino; espero esto con muchas ansias.

El futuro de Mastodon parece ser impresionante (espero no decepcionarme).

Gracias por leer. Este artículo no esta excepto a fallos, POR FAVOR, corrige amablemente  y yo estaré encantando de hacerlo.