Cuando llegas a este nivel, casi tienes que reevaluar todo sobre tu modelo de amenaza y lo que estás haciendo para protegerte. Incluso las cosas más pequeñas pueden traer un torbellino de problemas si te enfrentas a las personas equivocadas. Justo en la sección anterior estábamos hablando de lo bueno, muy bueno, que es el software de código abierto. Y ahora necesitamos hablar de algunos problemas que tiene y de lo que puedes hacer para combatirlos y mantenerte a salvo.
El FOSS es genial porque nos permite mirar el código en su totalidad y verificar que lo que vemos hace lo que nos hacen creer que hace. Pero para que esta afirmación sea cierta, necesitamos entender todo sobre el código publicado. Yo, por ejemplo, no sé programar nada más allá de una página web sencilla en HTML, así que tengo que confiar en la palabra de otros. Sin embargo, esa palabra vale tanto como las personas que la verifican. Así que digamos que planeamos usar ServiceX (solo como ejemplo) para comunicarnos de forma segura con otra persona, pero ServiceX publica actualizaciones con bastante frecuencia (mensualmente). A menos que sepamos leer, entender y validar el código nosotros mismos, necesitamos otra persona de confianza que sea capaz de hacerlo. Además, esa persona tiene que hacerlo con cada actualización que se publique. Entonces surge la pregunta de si basta con una sola persona competente revisando el código. Si esa persona pasa por alto algo que tiene el potencial de comprometernos, estaríamos usando ServiceX hasta el momento en que otra persona sí lo detecte. Aunque ese periodo pueda ser solo cuestión de días, son días en los que todo lo que hacemos en relación con este servicio queda comprometido, lo que por asociación nos compromete a nosotros y a todo nuestro modelo de seguridad, privacidad Y anonimato que tanto nos ha costado construir.
Otro problema del software libre y de código abierto son las plataformas móviles. En la mayoría de los sistemas operativos para ordenadores de escritorio, podemos tomar el código fuente de GitHub (u otra web de publicación de código) y construirlo o compilarlo nosotros mismos si se ha escrito para funcionar con nuestro sistema operativo. Pero en los sistemas operativos móviles no podemos hacerlo con facilidad. E incluso en los casos en los que sí podemos, seguimos enfrentándonos a un enorme reto que todavía no tiene una solución mágica. Para descargar una aplicación en mi iPhone, la empresa que desarrolló dicha aplicación tiene que publicarla en la App Store. No puedo ir a la web de Open Whisper Systems y descargar Signal directamente en mi teléfono. Así que, aunque revisemos el código fuente del servicio o la aplicación (o hagamos que otra persona lo haga por nosotros), seguimos sin poder validar que esa misma aplicación es la que se envía a la App Store para que la descarguemos. Si la empresa fuera comprometida por un cuerpo policial y obligada a cooperar, podría publicar una actualización limpia en GitHub, con ligeros cambios de interfaz para evitar sospechas, pero luego enviar una versión de la misma aplicación con una puerta trasera a la App Store para que la descarguen miles de usuarios. Esto se cumple en cierto sentido también para los dispositivos Android y la Google Play Store. La única forma de sortear esto con la Google Play Store es enviar compilaciones reproducibles para que el público las vea y las utilice. Open Whisper Systems acaba de implementar esto para Signal y estaría muy bien ver a otros servicios hacer lo mismo (guiño, guiño: ProtonMail, Tutanota, ChatSecure) https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds. Así que, dado que no podemos verificar con facilidad que la aplicación que usamos en nuestros teléfonos no hace cosas maliciosas, debería ser una suposición razonable que renunciar a los dispositivos móviles y usar estrictamente versiones de escritorio de los programas, aquellas que podemos compilar desde el código fuente y supervisar nosotros mismos, es el mejor camino a seguir.
Auditorías de código para las herramientas de privacidad
Incluso después de leer todo lo anterior sobre el software de código abierto, sigue existiendo un enorme problema que hay que superar antes de poder estar seguros de que el software que usamos es seguro. No es justo suponer que el 100 % de las personas que leen esta sección van a poder revisar por sí mismas el código de una aplicación. Diablos, ni siquiera es justo suponer que el 5 % de las personas que leen esto podrían llevar a cabo una tarea tan abrumadora. Toma TrueCrypt como ejemplo. Las auditorías de código realizadas para asegurarse de que era seguro llevaron meses, a manos de personas que me llevan años luz de ventaja en el campo del cifrado; algunas de ellas con másteres en el área y años de experiencia a sus espaldas (ejem, ejem @matthew_d_green). Así que suponer que una sola persona puede hacer este tipo de cosas para mantenerse a salvo es una tontería. Las auditorías de código en las aplicaciones y servicios a los que confiamos nuestra seguridad a este nivel son cruciales. Y una vez que se completa esa auditoría de código, tienes que considerar que la auditoría no será válida para versiones posteriores de la aplicación. En el momento en que envían una actualización y la instalas, has vuelto a la casilla de salida, a menos que alguien revise los cambios y los verifique con cada actualización.
Ver: La importancia del software libre y de código abierto para las herramientas de privacidad