WordPress actualizará automáticamente versiones inseguras, y es muy mala/buena idea

Una de las mayores polémicas que han surgido este verano del 2019 ha sido la propuesta por parte del equipo de core de actualizar automáticamente todas las versiones de WordPress anteriores a la 4.7 como mínimo.

La propuesta

Ponte un poco de música mientras lo lees

Tras unos cuantos bandazos y muchísimas quejas y contraindicaciones expuestas por decenas de usuarios de la comunidad, la propuesta ha quedado – de momento – así:

1. Publicar una entrada en wordpress.org/news para informar (a todo el que lo lea o esté suscrito) sobre la novedad, lo antes posible. Aún no se sabe una fecha pero estará en poco más de un mes.
2. Las versiones 3.7.30 - 4.6.15:
   1. Permitirán a los administradores optar por no hacer actualizaciones mayores haciendo clic en un botón.
   2. Enviarán un correo electrónico a todos los administradores/editores del sitio para pedirles que actualicen a la última versión, y se les informará de que su sitio se actualizará automáticamente a la versión 3.8 próximamente si no optan por impedirlo (el botón). Se enlazará a documentación detallada, y se incluirá también un enlace por si quieren desde el mismo anular la actualización automática . Se les advertirá sobre las implicaciones de seguridad de optar por anular la actualización automática. Los editores no podrán instalar directamente la actualización, pero podrán avisar a los administradores, y ellos si pueden hacerlo.
   3. Añadirán un aviso de administración dentro de wp-admin, que contenga información similar a la del correo electrónico. El aviso lo verán todos los usuarios.
3. Pruebas de actualización automática de la versión 3.7 a la 3.8 en sitios de prueba, por si hay que hacer mejoras necesarias al sistema de actualización automática.
   1. Se enviará un correo electrónico al propietario del sitio sobre la modificación necesaria si falla la actualización automática y se volverá a la versión 3.7. El correo electrónico debería ser una fuerte advertencia, haciendo saber que su sitio podría no actualizarse a una versión segura, y que debería actualizar manualmente de inmediato. Si no actualizan, es casi garantizado que el sitio podría ser hackeado.
   2. De igual modo, si falla la actualización automática y el usuario se queda atascado en una versión insegura, se debería mostrar un aviso de administración en wp-admin con una advertencia similar a la del correo electrónico aquí citado. Esto reemplazaría el banner pre-lanzamiento de la versión 3.7.30descrito arriba.
   3. Se podría buscar la manera de hacer una evaluación informada sobre la posibilidad de un error indetectable, y abortar la actualización en esos sitios, para minimizar el riesgo de romper algo. En esos casos, se enviaría al administrador la misma advertencia por correo electrónico y el mismo aviso de administración, haciéndole saber que está atascados en una versión insegura, y que tiene que actualizar manualmente de inmediato..
4. Actualizar el manual del Core con detalles sobre el nuevo proceso, para que todo el mundo sepa cómo lanzar actualizaciones automáticas.
5. Publicar un documento en WordPress.org estableciendo explícitamente una política de compatibilidad, para evitar confusiones.
   1. Solo se dará soporte y se garantizará que recibirá actualizaciones de seguridad la última versión mayor.
   2. No habrá versiones de soporte a largo plazo (LTS), y todas las versiones anteriores a la actual serán versiones de fin de vida del producto (EOL).
   3. Se hará un esfuerzo para aportar correcciones de seguridad a las 5 versiones anteriores, pero sin garantía de que se harán, ya que a veces no es ni factible ni práctico.
   4. Se recomendará a todo el mundo que siempre tenga la última versión mayor.
6. Días T-30: La versión 3.7.31:
   1. Enviará a todos los administradores y editores un segundo correo electrónico similar al primero, haciéndoles saber que su sitio se actualizará automáticamente a la versión 3.8 en 30-45 días, e incluirá instrucciones sobre cómo optar por anular la actualización automática, etc.
   2. Aviso de actualizar a la versión 3.7.30 en wp-admin que incluirá el intervalo de fechas hasta la actualización inminente.
   3. Incluirá cualquier mejora necesaria del sistema de actualización automática, como está descrito en el paso 3.
7. Lanzamiento de las actualizaciones automáticas en fases:
   1. El proceso general se lanzará en un grupo de sitios con la versión 3.7, luego se esperará una semana para ver si se informa de errores. Si ocurre algo inesperado se pausará el proceso para corregir esos problemas, y luego se reiniciará.
   2. Días T-0: Lanzamiento a un 2% de sitios con la versión 3.7.
   3. Días T+7: Lanzamiento a otro 18%.
   4. Días T+14: Lanzamiento al 80% restante.
8. Si todo va bien, el proceso se repetirá actualizando los sitios con la versión 3.8 a la 3.9, y así sucesivamente hasta que todos los sitios estén ejecutando la versión 4.7. Algunos de estos pasos se pueden automatizar para hacer este proceso más sencillo en un futuro.

El exceso de trabajo como argumento

La base de la propuesta es que conlleva un enorme trabajo hacer actualizaciones de todas las versiones, y sería más rápido y asumible tener que hacer actualizaciones de seguridad solamente a las versiones con 2 años de antigüedad como máximo.

La justificación subyacente es la seguridad, pero en realidad a lo que se alude es a la carga de trabajo que supone tener que mantener tantas versiones de WordPress.

Pues si la seguridad es «el objetivo», no pasa nada por seguir ofreciendo actualizaciones de seguridad para versiones antiguas, sería seguro, cumpliría com el objetivo.

El problema surge porque es cierto que requiere un mayor esfuerzo personal y técnico mantener todas esas versiones, es mucho más sencillo mantener menos versiones.

Y aquí tenemos una de las debilidades (y a la vez grandeza) de las comunidades Open Source, el trabajo voluntario. Pues aunque haya empresas como Automattic, Human Made, SiteGround y otras muchas que donan tiempo de sus empleados al desarrollo de WordPress, la realidad es que la constancia en las dinámicas de trabajo voluntario es complicada.

Un ejemplo lo tienes en la espantada que dio Joost de Valk tras su flamante nombramiento como jefe de marketing, tras comprobar que aquí no vale el ordeno y mando, aquí todo depende … de muchas cosas (disponibilidad, transversalidad de proyectos, etc.)

Ventajas de la propuesta

Por supuesto, las ventajas de una actualización masiva de este tipo en sitios WordPress serían importantes, sin dudarlo.

Por una Internet más segura

Siendo WordPress el software que está detrás de más del 30% de todo Internet, actualizar miles, quizás millones de webs automáticamente a versiones seguras haría que Internet sea un sitio más seguro para todos.

Oportunidad de marketing

Esta acción, bien aprovechada y divulgada, sería una oportunidad impagable de promocionar aún más WordPress, en su «compromiso por hacer una Internet más segura«, al actualizar automáticamente, y sin intervención del usuario, miles/millones de webs.

De hecho, creo que es algo que se debe hacer de manera obligatoria, también en medios generalistas, por las implicaciones que más abajo explico en los inconvenientes de la propuesta.

Todo el mundo debe saber de antemano que WordPress va a liar la mundial, actualizando a capón miles/millones de webs sin la intervención necesaria de los administradores. De hecho debería abrir cabeceras en los telediarios, evitaría muchos problemas (si sigues leyendo lo entenderás).

Consciencia de la importancia de la seguridad

Aunque muchos usuarios no optasen por permitir la actualización automática, muchos administradores recibirían correos y avisos que les harían conscientes de los problemas de seguridad que conlleva mantener webs sin actualizar.

Oportunidades de negocio

Todos los profesionales que se dedican al mantenimiento web encontrarían una punta de oportunidad de venta de servicios en cuando los administradores de webs sin actualizar empezasen a recibir avisos de que su web es insegura.

Igualmente, muchos profesionales que se dedican a la seguridad web verían un incremento de petición de sus servicios.

Inconvenientes de la propuesta

Ahora bien, el hecho de actualizar automáticamente webs WordPress, implícitamente, y aunque se tenga la opción de anular la actualización, también supone meterse en problemas gordos.

RGPD

Si en algo queda claro que muchos de los que llevan el desarrollo del Core de WordPress son estadounidenses es que ven como válida una aceptación implícita (si no haces nada pasará esto), en vez de explícita (para que pase esto debes aceptar), que es lo que rige las comunicaciones y aceptaciones web en la Unión Europea y así lo determinan multitud de reglamentos, como el RGPD, por ejemplo.

Es más, el RGPD exige a los responsables de protección de datos una serie de protocolos sobre la información de brechas y/o vulnerabilidades de seguridad que los perpetradores de la propuesta no han querido atender, a pesar de que muchos usuarios así se lo han/hemos avisado.

No quiero decir que no se pueda hacer, pero los administradores de las webs y los responsables de protección de datos tendrán la obligación de informar a los usuarios de las webs afectadas de:

• La vulnerabilidad previa de no tener actualizada la web.
• La actualización a realizar (o no) y las implicaciones sobre las cuentas de usuarios.

Incompatibilidades y miles de webs WordPress caídas

Aunque se «cita» en el punto 3.3 de la propuesta, la realidad es que es absolutamente imposible detectar previamente las seguras incompatibilidades que surgirán en las actualizaciones automáticas (implícitas) con el resto de código de las miles/millones de webs afectadas.

Miles de plugins y temas que ya no tienen actualizaciones pero aún funcionan, plugins y temas sin actualizar, códigos personalizados añadidos expresamente para la web, etc., provocarán casi irremediablemente que se rompan oleadas de webs creadas con WordPress.

Correos y avisos que no ve nadie

Claro, podrías pensar que nada de lo anterior pasará si los administradores de las webs actúan cuando vean el aviso de administración o reciban los correos electrónicos previos a la actualización automática.

Pero la realidad es que hay miles de webs en las que los propietarios no reciben correos, ni entran nunca a la administración, simplemente existen y sirven a un propósito, por simple que sea, como mostrar la información de contacto de la empresa.

Si quieres un ejemplo de la multitud de propietarios de webs que no tienen acceso al correo de administración, no saben cuál es, o simplemente ya no existe ese correo, solo tienes que ver la ingente cantidad de incidencias que ha provocado el sistema de salud del sitio incorporado en WordPress 5.2, que dejó a montones de administradores de webs sin poder acceder al escritorio de su sitio.

A alguien se le ha olvidado que no todas las webs tienen un administrador responsable y activo. De hecho son minoría quienes lo tienen.

Lo más habitual es que alguien cree o encargue la web, la deje a su gusto y se siga dedicando a su negocio. De eso vivimos los que nos dedicamos a crear webs.

Y sí, lo ideal sería que el propietario fuese responsable y se ocupase de la administración y mantenimiento de su web, o encargase el trabajo a un profesional, pero aquí estamos hablando de realidades, y la realidad es que no es así, hasta la fecha.

¡A ver, responsable, quiero al responsable ya!

Habrá denuncias, no te quepa duda, va a pasar.

Da igual todos los argumentos razonables e intenciones loables que haya tras la propuesta de actualizar automáticamente todas las versiones inseguras de WordPress, la realidad es que se romperán montones de webs. Un ejemplo lo tienes en las miles de webs que cayeron por la incompatibilidad de Visual Composer con la actualización menor a WordPress 4.5.

Y eso sí que será visible para los propietarios de las webs que se caigan, y buscarán un responsable.

Luego explícales que «la comunidad ha decidido», y «que es por una Internet segura», el propietario de un sitio que funcionaba y que, de repente su web ha dejado de funcionar porque alguien en la otra punta del planeta ha decidido ejecutar un proceso en su web sin su permiso explícito, puede iniciar un proceso legal que, con toda seguridad, en países europeos ganaría sin duda, quizás también en otros muchos.

¿En qué quedamos entonces?

Pues, según va la cosa, la propuesta va para adelante, así que sí, habrá actualizaciones automáticas implícitas de versiones mayores de WordPress.

Sinceramente, espero que el botón de anular la actualización sea bien grande, que los correos sean claros, y sobre todo, ruego porque haya una enorme campaña de marketing en medios generalistas que informe de la barbaridad que va a hacer WordPress sin intervención explícita del usuario.

Sería la manera de convertir un problema gordo en una oportunidad, y de paso evitar denuncias.

¿Y tú, qué opinas de esta movida?

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!