“Código abierto” no siempre significa “seguro”

En este sitio web, y en muchos otros sitios web de privacidad y seguridad, encontrará personas que defienden el evangelio de la tecnología de código abierto. Esto es algo importante. Este año, Suiza sufrió dos escándalos separados en los que se descubrió que la Agencia Central de Inteligencia de EE. UU. operaba corporaciones ficticias dentro del país que vendían equipos tecnológicos a gobiernos extranjeros y ejércitos que estaban equipados con puertas traseras en la encriptación, que brindaba a la comunidad de inteligencia estadounidense acceso a fácil y de primera fila las comunicaciones sensibles de otras naciones. El código abierto podría haber evitado esto. El software de código abierto habría permitido a cualquiera observar la programación y el sistema operativo en el dispositivo y decir “oye, aquí algo no está bien”. Sin embargo, creo que a veces la comunidad de privacidad exagera con el código abierto.

A menudo veo a novatos en privacidad abrazando el código abierto sin saber por qué. Veo a la gente decir cosas como “Escuché que [el servicio X] es malo porque no es de código abierto”, pero en realidad no saben por qué. La respuesta es que el código abierto, como regla general, tiende a respetar tu privacidad más que el promedio. Debido a que el código está abierto, cualquiera puede examinarlo para asegurarse de que hace lo que dice. Además, debido a que cualquiera puede examinarlo, es más probable que las personas encuentren errores y ofrezcan soluciones que se pueden implementar rápidamente. Sin embargo, la palabra operativa allí es “puede”.

Un estudio reciente de GitHub encontró que, en promedio, las vulnerabilidades existen en el software de código abierto durante más de cuatro años antes de que se parcheen. Ahora es importante comprender el contexto de este estudio: GitHub examinó a 56 millones de desarrolladores y más de 60 millones de repositorios. De esos 60 millones de códigos, estoy seguro de que muchos de ellos son solo pasatiempos, subidos por el creador como respaldo, abandonados o incluso como un “Hice esto para mí, pero si alguien más lo quiere, aquí está”. Todos ellos probablemente vinieron con advertencias como “el comprador debe tener cuidado” en sus términos. Pero incluso eso solo puede representar unos diez mil, como mucho. La mayoría de estos códigos probablemente se cargaron con la intención de compartirlos y difundirlos.

Aquí es donde nos encontramos con un tema interesante. Creo en apoyar al pequeño. Todo el mundo fue una vez un hombrecito. Walmart, Starbucks, Microsoft, todos. Y puedes creer que esos tipos grandes se han desviado desde entonces, y tal vez es cierto, pero alguna vez fueron pequeños. Incluso en las comunidades de código abierto, las estrellas de rock (Ubuntu, Bitwarden, Signal) alguna vez fueron don nadie. Los pequeños necesitan nuestro apoyo para ser sostenibles y exitosos. Creo firmemente y respeto eso. Pero los pequeños vienen con riesgos que deben reconocerse. Los investigadores de seguridad también son personas. Tienen trabajos diarios (por lo general, algunos de ellos tienen la suerte de ser investigadores a tiempo completo), tienen vidas personales y solo tienen un tiempo limitado que pueden dedicar a examinar el código. Cuanto más pequeño es el desarrollador, menos popular es el código, y eso significa que menos ojos lo examinan en busca de debilidades. En un proyecto grande y bien conocido como Signal y Mastodon, hay miles o incluso millones de personas que lo usan y lo observan, sin mencionar que muchos de ellos pueden pagar las auditorías de seguridad adecuadas. Pero en proyectos más pequeños y menos populares no pasa todo esto.

Así que no, código abierto no significa automáticamente que se respete la privacidad o que sea seguro. La mayoría del malware es, por definición, de código abierto. Una vez que se descubre un malware, hay sitios web donde los investigadores pueden compartirlo para que otros investigadores puedan examinarlo, separarlo, actualizar sus propias definiciones de virus y estudiarlo. Malware es literalmente “software malicioso”. Es un ejemplo perfecto de cómo el código abierto no significa automáticamente privado, seguro o protegido. Entonces, ¿es importante? ¡Sí! En igualdad de condiciones, el código abierto siempre es mejor. Todavía existe la posibilidad de que el código sea revisado por alguien que entienda este tema y pueda mejorarlo. También existe la posibilidad de que alguien más venga y diga “oye, este es un gran proyecto, pero esto en particular podría ser mejor, aquí está mi fork”. Es por eso que hay mil millones de navegadores web, porque alguien vio el código abierto de Firefox y Chromium y dijo “esto podría ser mejor”.

¿Es realmente mejor? Esa es una pregunta difícil. Ahí es donde entra en juego el modelado de amenazas. Pero es importante que estés informado al crear tu modelo de amenazas. El código abierto es mejor, indiscutiblemente, pero eso no significa que debas confiar ciegamente en él más que en el uso de la palabra “encriptado”. Lo que importa es cómo se implementa el cifrado, y cómo se utiliza la naturaleza de código abierto del software para mejorarlo lo que determina si se puede confiar en él. Aún debes considerar qué información planeas confiar a ese software, qué podría salir mal, así como una serie de otras consideraciones como la frecuencia de actualización, la reputación y más. Como pequeño emprendedor, no estoy diciendo que no confíes en los pequeños. Solo digo que ejerzas la precaución.

Puede encontrar más servicios y programas recomendados en TheNewOil.org. También puedes recibir actualizaciones diarias de noticias sobre privacidad en @thenewoil@freeradical.zone o apoyar mi trabajo de diversas maneras aquí. Puedes apoyar estas traducciones con Monero.