Estamos muy cerca de lanzar la versión 0.4 de CoyIM. De hecho, en el momento de escribir este artículo, tenemos previsto lanzar esta versión dentro de dos semanas. Y como hemos detallado en muchos artículos diferentes, el lanzamiento contiene un enorme número de mejoras, nuevas funciones y correcciones. Y aunque estamos muy orgullosos de todo este trabajo, también es importante mirar hacia atrás a los orígenes de CoyIM para comprender porqué existe y porqué hemos tomado algunas decisiones poco convencionales, tanto en esta versión como en versiones anteriores. En concreto, estamos muy orgullosos de todas estas mejoras y nuevas funcionalidades. Pero también estamos muy orgullosos de las características que no hemos agregado.
Eso puede sonar raro. El paradigma general que existe es que mides tu valor en función de la cantidad de características que tienes. Y si esa es la forma como valoras una aplicación, CoyIM te decepcionará absolutamente. Si comparas CoyIM con otras aplicaciones similares, básicamente todas ellas tienen una gran cantidad de características de las que carece CoyIM. Un pequeño ejemplo de esto, es que al considerar cómo agregar la transferencia de archivos y directorios para esta versión, queríamos evaluar las opciones para minimizar la cantidad de características que agregáramos. Para implementar esta funcionalidad decidimos usar una parte de XMPP llamada Stream Initiation. Y si has leído el artículo que describe las novedades de CoyIM con un enfoque en la transferencia de archivos, es posible que recuerdes que pudimos haber agregado la transferencia de archivos de dos maneras, ya sea usando Stream Initiataion o usando algo llamado Jingle. La mayoría de las otras aplicaciones probablemente habrían optado por implementar Jingle, ya que ese es el estándar más nuevo. De hecho, la mayoría de las aplicaciones XMPP implementan Jingle. También implementan Stream Initiation. ¿Por qué no? Es mejor tener ambos implementados, ¿no? Como desarrolladores de CoyIM, creemos que esta es la forma incorrecta de pensar. Y más específicamente, es un enfoque problemático cuando se trata de situaciones de alta seguridad. Entonces, en este caso, elegimos implementar el estándar anterior y no el estándar más nuevo. La lógica era bastante simple. El más antiguo es más pequeño y más fácil de implementar de una manera concisa que no agrega mucha complejidad al código. El estándar Jingle contiene muchos más elementos móviles, lo que significa que la implementación habría sido más grande, y la superficie de ataque habría aumentado también. Entonces, al elegir entre los dos, el estándar anterior presentaba un riesgo menor para nuestros usuarios. Implementar ambos habría significado una complejidad aún mayor, sin ningún beneficio real para nuestros usuarios. Cuanto más código, más riesgo. A más complejidad, más riesgo. Y cuantas más cosas puedan interactuar de diferentes maneras, más grande la superficie de ataque.
Como describimos en el post sobre cómo surgió CoyIM, una de las principales alternativas de mensajería segura en ese momento era Pidgin. Pero una de las razones por las que nos sentimos bastante incómodos con Pidgin era precisamente porque contenía una gran cantidad de funcionalidades. De hecho, Pidgin admite muchos protocolos de comunicación diferentes, no sólo XMPP. Asimismo tiene soporte para una gama enorme de estándares. Por ejemplo, permite usar videos, imágenes, audios, etc, incluidos los emojis. De hecho, es tan complicado que tiene un vasto sistema de plugins que permite a los usuarios instalar funciones personalizadas de varios tipos. Ahora bien, la complejidad no sólo trata sobre cada pieza individual de funcionalidad, sino también sobre cómo estas pueden interactuar entre sí. Es precisamente esta explosión combinatoria lo que conduce a un gran aumento en la superficie de ataque. Y la forma en que se construye Pidgin conduce exactamente a esto.
En CoyIM, decidimos muy temprano que sólo implementaríamos lo que fuera absolutamente necesario. Esto significa que la comunicación básica se realiza sólo a través de texto. No admitimos métodos de comunicación más elaborados. No permitimos que los usuarios resalten texto o cambien la fuente o cualquier cosa en este mismo sentido. Además, sólo admitimos XMPP como protocolo de comunicación y OTR como protocolo de cifrado de extremo a extremo. Esto, para minimizar el riesgo de combinaciones que den lugar a interacciones inesperadas y más posibilidades de ataque. Esta es la razón por la que no queremos agregar otros protocolos de encriptación, ya que eso significaría una multiplicación de interacciones.
De la misma manera, no implementamos todas las diferentes extensiones de XMPP que están disponibles. En algunos casos, nosotros nos decidimos en contra de ellas porque revelan información sobre el usuario. En otros casos, sentimos que implementarlos no valía la pena, tomando en cuenta la funcionalidad adicional para el usuario que se podría agregar. Tampoco admitimos plugins para funcionalidades adicionales. Por supuesto, todas estas cosas tienen valor para el usuario, pero también aportan complejidad, haciendo menos probable que podamos protegerte bien. Dicho sea de paso, esto está relacionado con nuestra decisión de convertir a CoyIM en una aplicación que usa GTK para mostrar las ventanas. En estos días, la mayoría de las aplicaciones de este tipo se realizan utilizando diferentes tipos de tecnología web. A veces, se ejecutan directamente en el navegador y, en otras ocasiones, crean sus propias ventanas, pero bajo la mesa, todavía usan el navegador. Pero un navegador viene con una gran cantidad de funciones y una superficie de ataque que es dificil de controlar. Por esta razón, decidimos no utilizar este tipo de tecnología para CoyIM, en un esfuerzo por intentar reducir y manejar el riesgo para nuestros usuarios.
En resumen, CoyIM nunca tendrá algunas funciones que podrás encontrar en otras aplicaciones de chat. CoyIM podría no verse tan elegante como otros clientes. No admitiremos el envío de emojis o imágenes en línea. Nunca tendremos soporte para otros protocolos de comunicación. Fundamentalmente, hacemos esto para reducir la complejidad de la aplicación y minimizar la superficie de ataque. CoyIM v0.4 tiene muchas mejoras, pero eso es nada comparado con todo lo que decidimos no implementar. Continuaremos tomando decisiones de esta manera. Creemos que es la única forma responsable de administrar una aplicación enfocada en la seguridad.