Etiquetas

Apenas salió la web del Senado, ya le encontraron un cuasi XSS. Le siguió una especie de indignación tuitera, como si el bug fuese la pistola humeante que probaba que se ha malgastado dinero. Es un error ir por ese camino.

El XSS conocido (puede haber peores, pero estrictamente éste ni llega a ser XSS, no se ejecuta código en el navegador, se filtran correctamente) es un bug muy estúpido. El programador de esa página quizás se merece un rapapolvo, y el director del proyecto otro más gordo por no insistir lo suficiente en cuidar temas de seguridad, sobre todo en temas básicos y muy conocido, sabiendo que estos bugs lo iban a descubrir pocos minutos después de que se hiciese pública la web. Pero no deja de ser uno de los inevitables bug, y por lo visto hasta ahora no es tan serio, no han hackeado el servidor, sólo se logra que inserten un texto del URL en el HTML de la página (sería muy grave si logran insertar javascript que pudiese publicar datos privados).

Algunos argumentan que debido al coste del proyecto, esos bugs no deberían ocurrir, una pista de que no conocen de la complejidad.  La complejidad de los programas no crecen linearmente, sino más próximo a un crecimiento exponencial. Por ello sostengo que es importante, sobre todo a largo plazo, la filosofía KISS (Keep It Simple Stupid), es la mejor forma de mantener la complejidad bajo control, y así reducir las probabilidades de bugs. El que diga que un proyecto de este tipo no puede tener bugs, es que nunca desarrolló un proyecto importante, o se olvida el historial  de bugs de seguridad de proyectos similares, aún estando bajo el escrutinio de miles de programadores, por ejemplo WordPress (y ya ni hablo de los plugins, que aún siendo mucho más simple, fueron un coladero de ataques de seguridad).

Lo del XSS es una anécdota, y que no debería servir más que para el cachondeo, y como una muestra que las decisiones que se tomaron a más alto nivel fueron las erróneas, por ejemplo, por no basarse en gestores de contenidos de software libre que ya llevan años probados, con estos bugs depurados y solucionados.

El desarrollo de una web sea privada, comercial o institucional, debe ser permantente y continua. No se puede desarrollar hoy y esperar que dure una década, para en diez años acometer un proyecto nuevamente desde cero. Así es como tenemos webs anticuados, renovaciones carísimas, con pérdida de información. y que no satisfacen las necesidades de los usuarios (¿alguién probó cómo se ve en móvil, por ejemplo?). Esto lo sabemos desde hace más de 15 años, y lo hemos experimentado con casi todas las webs de la administración, en lo que siempre repetimos el ciclo:

  1. Se saca un concurso de un proyecto «que será la monda molona».
  2. Se desarrolla un proyecto complejo, desde cero, a un alto coste, por una consultora que subcontrata, que subcontrata… a un becario sin experiencia, sin mentoring ni control de calidad adecuados.
  3. La solución que se saca a producción con acto y sarao solemne es incompleta, con bugs, como era de esperar de algo que no se probó ni evolucionó con uso real.
  4. Quejas e indignación pública.
  5. Se arreglan los bugs importantes, se olvida el tema.
  6. Ya no hay forma de acceder al código o exigir al contratista original que implemente nuevas funcionalidades.
  7. Se vuelven anticuadas, no satisfacen a nadie, quejas constantes de lo mala que es la web.
  8. Se decide volver a #1

Cada ciclo de estos duran de 5 a 10 años, hoy la web del senado está en el punto #4. En unos pocos años llegaremos al punto #8, y vuelta a empezar.

Por ello, la «indignación» con la web del senado no debería basarse en los bugs de un programador inexperto (o bajo presión), sino en las cuestiones que hacen que siempre estemos en estos ciclo repetitivo:

  • Por qué se decide un desarrollo independiente del Congreso, cuando son muy similares y deberían compartir software e infraestructura, sobre todo con esta crisis cuando se está recortando por todos sitios (en algunos temas más importantes que una web) y que los representantes deberían ser los que dan ejemplo. Es un tema político fundamental.
  • ¿El software se desarrolló desde cero? ¿Por qué habiendo tanto software gestor de contenido libre que puede servir perfectamente?
  • ¿Qué framework se usó para el desarrolló? ¿Por qué no se usó uno de los tantos existentes en software libre que son de muy alta calidad? (Rails, Django, CodeIgniter, etc.)
  • ¿Tiene el Senado todo el código para poder ir mejorando y adaptando el software progresivamente? ¿puede contratar a otros para que lo mejoren o corrijan problemas? ¿o dentro de unos años se volverá a hacer todo desde cero?
  • Cómo se distribuyó el dinero, qué parte es del web, qué parte de otros servicios digitales.
  • Cuáles son los demás servicios incluidos, y qué utilidad tienen.

El problema de estos proyectos es la creencia absurda de que «ahora sí sabemos lo que queremos», «ahora sabemos cómo hacerlo», «el dinero adecuado asegurará que se haga correctamente», «ahora tenemos la tecnología y partner adecuados», «los del otro sector de la administración no saben de nuestra casuística tan especial, por lo que mejor hacerlo desde cero.»

Esto es lo que hay que detener de una vez, pero las taras no son sólo políticas, también de los técnicos informáticos responsables.

PS: Y yo me pregunto la mayor, ¿qué información de utilidad genera el Senado? ¿qué hacen de utilidad además de ser el cementerio de elefantes?