~

Actualización: Un lector – mas avispado que yo – apunta que el Banco del Estado carga el formulario de acceso en un iframe que si es encriptado. El sitio del Santander probablemente hace algo parecido, lo que implica que mis críticas en este artículo están equivocadas. Creo que aún así el diseño de estos sitios es deficiente, porque no permiten confirmar a un usuario en forma fácil (por ejemplo, en la barra de dirección) que el sitio esta encriptado como debe ser, y verificar la seguridad del certificado. Pero aún así, el punto del artículo más abajo era otro, y como uno de mis pasatiempos favoritos es echar pericos contra periodistas que no corrigen sus errores como corresponde, la versión del artículo más abajo corrige el error.

~

El año pasado, cuando comencé a recibir un sueldo regular en Chile, finalmente abrí una cuenta corriente en ScotiaBank. Como me imagino que le pasa a muchos, no le dí demasiada importancia a la elección, aparte de que la mantención de la cuenta fuera barata. Para mi horror, sin embargo, me encontré con que el sitio de acceso a mi cuenta en el banco era absolutamente inseguro, es decir, no usaba un sistema de encripción cliente-servidor que permitiera codificar y verificar el envío de el nombre del usuario y la contraseña. O en castellano, al acceder al sitio del banco, mi navegador favorito no mostraba el famoso «https://» antes de la dirección. La falta de acceso seguro a sus sitios pone en peligro a sus clientes, permitiendo posibles ataques en que el usuario y contraseña les sean robados. Mala, mala cosa.

No fue la única razón, pero después de haberles comunicado este problema en el lenguaje más claro que pude y no haber recibido respuesta satisfactoria, decidí cambiarme de banco. Obviamente, prefiero un banco al que le importe tan poco la privacidad y la protección de datos de sus clientes si voy a guardar todo mi plata en sus cajas fuertes. Justo en el período en que había abierto una cuenta en otro banco, ScotiaBank se puso las pilas, y hoy en día sus clientes pueden acceder a su cuenta vía una página segura. Un poco tarde para mí, pero bien por ellos.

Me acordé de este episodio al leer la noticia de la aparición de FireSheep, un add-on para Firefox que permite a cualquier usuario – incluso el que no tiene idea de lo que es SSL – interceptar las cookies que intercambian navegadores y sitios durante una sesión y así ver el sitio de las víctimas. Y aunque sabía que mi ex-Banco se había avispado, me dí una vuelta rápida por los bancos de nuestra querida patria.

Y [estos días] aunque la inmensa mayoría de los bancos tienen acceso seguro a sus páginas (bien por ellos y sus clientes).

P.S.: A propósito de FireSheep, vale la pena mencionar que los autores no crearon este add on para facilitar el acceso ilegítimo a cuentas ajenas, sino para forzar a los sitios que proveen servicios con acceso (o sesiones) inseguro a corregir este problema. Pero no se olvide, querido lector, que aunque han hecho el acceso tecnicamente posible, aún así es ilegítimo. Robarse la tele del vecino esta mal, aunque haya dejado la puerta abierta. O en este caso, porque el cerrajero no le dijo que cualquier llave la puede abrir.

Esta semana recién pasada se anunció un esfuerzo emanado de la Secretaría de Desarrollo Digital para generar un mecanismo más eficiente de licenciamiento de software por parte del gobierno. La cara visible de esta iniciativa es un borrador de la Licencia Gubernamental de Software (LGS), cuya motivación y estructura fueron explicadas en una serie de talleres a la que se invitó a distintos actores relacionados con el tema digital en Chile. Aunque no estuve presente en los talleres, la licencia está disponible en la red [PDF], lo que permite hacer una anatomía preliminar de la LGS. Y este ejercicio revela que, como era de esperarse, crear una nueva licencia de software como esta no es cosa fácil, y en este caso, huele a desastre.

Antes de partir, tenemos que entender que una licencia de software existe como un instrumento legal que permite usar y distribuir software. Aunque es posible usarla sin entender los objetivos que la inspiran, es útil (sobre todo en este caso) tenerlos en mente. Varios de los que estuvieron presentes en los talleres me contaron que en el caso de la LGS estos objetivos incluyen ayudar a paliar problemas tales como la falta de consenso en la forma de licenciar software en el Estado, la imposibilidad de exportar soluciones producidas dentro del mismo, falta de protección de derechos de autor, y la frecuente imposición de restricciones por parte de entidades que producen software para el estado.

La LGS se llamaba originalmente GPL-CL, y aunque el cambio de nombre es bienvenido (espero que esto esté claro después de leer este artículo), el nombre original revela inmediatamente la licencia de software libre en la cuál la LGS esta basada. Pero la LGS es una derivada de la GPL que ha sido transformada significativamente al agregar, quitar o modificar secciones completas del original. Y estas transformaciones tienen consecuencias inesperadas, quizás incluso para sus autores.

La GPLv3 tiene un preámbulo, una sección de definiciones (o sección 0) y 17 secciones que fijan las reglas para distintos aspectos del uso y distribución de software. Tomadas como un todo, la licencia tiene como objetivo defender las cuatro libertades definidas por Richard Stallman. La LGS, como ya dije, comparte mucho del texto de una traducción al español de la GPLv3, pero tiene diferencias importantes:

Sin duda, tantas diferencias dan para mucha discusión, pero quiero por ahora enfocarme en tres puntos que me parecen esenciales y que ilustran que esta licencia tiene más probabilidad de generar más problemas que soluciones para el Estado chileno:

1. La LGS crea un ecosistema semi-cerrado de desarrollo de software: aunque está basada en una licencia de software libre, me parece indudable que la LGS es una licencia totalmente incompatible con la GPLv3 y otras licencias (no las más permisivas) similares. Mientras los autores de la GPLv3 hicieron un esfuerzo por aumentar la compatibilidad con otras licencias, la LGS va en dirección contraria. Entre otras cosas, esto implica que autores de software no podrán tomar código GPL de programas existentes y mezclarlos con código LGS. Es por esto que el cambio de nombre no solo es bienvenido, sino inevitable.
2. La LGS no permite la distribución de código objeto (es decir, ejecutables): La equivalente de la sección 8 impide la propagación (es decir, distribución) de software LGS en cualquier forma que no esté explícitamente autorizada por la licencia. Ahora bien, la LGS solo regula y autoriza la transmisión de código fuente, y no tiene una sección 6 (de la GPLv3) que regula la propagación de código objeto (es decir, programas compilados o binarios). Es decir, la LGS esta entonces prohibiendo la transmisión de este. En la práctica, esto significa que no será posible para usuarios de la LGS publicar programas ejecutables, si no que cada recipiente deberá bajar el código fuente y compilar sus propios binarios en su computador para poder usarlo. ¿Un buen sistema para «exportar soluciones producidas en el Estado»?.
3. El requerimiento de uso de un repositorio es oneroso y poco práctico: Este punto es más de opinión que otra cosa, pero me parece que la obligación de enviar a un repositorio central reportes de problemas y versiones modificadas de código fuente es tremendamente oneroso para cualquier usuario del software (pero ver punto 2), y probablemente creará una pesadilla de mantención del repositorio central. Es participación forzada en el desarrollo del software.

Es entendible el por qué, partiendo de los objetivos de ordenar el gallinero que es la producción de software en el Estado Chileno, uno querría desarrollar una herramienta perfectamente ajustada a la realidad Chilena. Sin embargo, en el camino de desarrollarla sus autores parecen olvidar la naturaleza interconectada del desarrollo de software, y la facilidad con que el ignorar el contexto y los precedentes históricos (la proliferación de licencias es, después de todo, tema antiguo y muy analizado por verdaderos expertos en tecnología)  en que se lleva a cabo este proceso pueden llevar a un desastre de proporciones.

Aunque no descarto que sea posible cambiar la licencia de modo de solucionar los problemas enumerados acá (aunque no son los únicos),  me parece que la creación de una licencia exclusiva para la producción de software en Chile es una pésima idea, que sin solucionar los que el Estado ya tiene creará una serie de problemas nuevos. Es de esperar que los autores del borrador de la LGS consideren éstas y otras críticas y decidan simplificar significativamente el proceso de licenciamiento mediante la adopción de una licencia existente (la GPLv3 es una excelente candidata) que conserve el espíritu de colaboración y libre intercambio de información que sin duda los inspiró a escribir la LGS.

Hace algunos años, me comenzó a pasar que el tiempo de pinchar en un enlace alcanzó un valor que no tenía antes. Y como consecuencia, el encontrarme con un blog que no publicara sus artículos completos despertaba una mini-evaluación: ¿vale la pena tener que visitar el sitio para leer el artículo?. La respuesta se ha vuelto «no» con más y más frecuencia, y apenas me quedan algunos indispensables en GReader que pasan la barrera del valor/molestia.

Hay, evidentemente, razones válidas para no incluir los artículos completos en la sindicación. La publicidad vía RSS aún es bastante deficiente, y la industria de la publicidad en línea está todavía obsesionada con los números de vistas por página. Pero incluso cuando no hay interés comercial, más de un autor prefiere usar su RSS para atraer lectores a su sitio, donde quizás cree que podrán disfrutar de otro contenido, admirar el fantástico diseño y sentirse impulsado a comentar. Y, por supuesto, aprovechar de mejorar las estadísticas del blog.

En el uso de la sindicación como anzuelo, parece que muchos autores razonan que si tienen 200 suscritos a su RSS, reemplazar artículos completos por un resumen y un «lea más» incrementará sus visitas a su sitio en 200. Pero esta noción me parece profundamente errada, y no considera el efecto de barrera que causa esta estrategia de publicación. No solo habrá extremistas como yo que no se suscribirán a dicho sitio, sino que muchos artículos quedarán sin leer porque su extracto no alcanza un estándar de interés – instantáneo y voluble – que uno puede esperar de un lector estos días. Cuando el objetivo es difundir contenido lo más posible, tener RSS incompletos tiene un costo serio, y los autores deberían considerar que, como dije, hay muchas razones válidas para tener RSS incompletos, pero ninguna de ellas conlleva un beneficio para el lector.

Por supuesto, mi evidencia para apoyar este argumento esta basada en mi propia experiencia, y me pregunto si hay alguna evidencia sólida que apunte a la pérdida – si la hay – de lectores en función de la estrategia de sindicación. En mi caso, ya saben el efecto. ¿Que dice el público?