Durante años, se ha hablado de la obsesión de Google por moldear Internet a su imagen y semejanza. Lo que quizá muchos usuarios no perciben —porque los cambios han llegado poco a poco, camuflados bajo argumentos de seguridad, rendimiento o “experiencia del usuario”— es que la compañía de Mountain View ha construido una cronología casi quirúrgica de decisiones que han reducido el margen de maniobra de la web abierta.
Lo que Microsoft no logró en la primera “guerra de navegadores” con Internet Explorer, Google lo está consiguiendo con Chrome y su control sobre el WHATWG, el grupo de trabajo que define gran parte de los estándares actuales.
El resultado: una web cada vez más centralizada, dependiente de sus propias tecnologías y menos abierta a la innovación comunitaria.
2013: el año del punto de inflexión
Ese año se produjeron varios movimientos clave:
- Cierre de Google Reader. El agregador de feeds más popular desapareció con la excusa de la baja adopción, pero con la consecuencia de marginar a RSS y Atom, piezas esenciales de la web descentralizada.
- Fin de la federación XMPP en Google Chat. Un golpe al estándar abierto de mensajería que permitía interoperabilidad.
- Primer intento de eliminar XSLT/XML. Una tecnología que permitía transformar y presentar datos directamente en el navegador sin depender de JavaScript.
- Eliminación de MathML en Chrome. Pasaron diez años hasta que una empresa externa lo devolvió, pese a su importancia en accesibilidad y educación.
Ese mismo año, Facebook hizo lo mismo con Messenger: cerró la federación. Y con ello se inauguró una etapa de centralización de servicios que aún dura.
2015: AMP, <keygen> y el arrinconamiento de estándares
Google presentó AMP (Accelerated Mobile Pages), bajo la promesa de acelerar la web móvil. En realidad, fue una forma de encadenar contenido a los servidores de grandes tecnológicas y ganar control sobre la distribución.
Ese mismo año:
- Se propuso deprecar SMIL, un estándar que permitía animaciones declarativas en SVG.
- Se eliminó el elemento <keygen>, que facilitaba a los usuarios generar claves criptográficas propias para autenticación segura. El propio Tim Berners-Lee criticó esta decisión, porque debilitaba la soberanía de los usuarios frente a los servidores.
2018–2020: RSS desaparece de los navegadores
Mozilla eliminó el soporte nativo de RSS en Firefox 64. Chrome nunca lo apoyó con entusiasmo. La consecuencia: feeds invisibles para el gran público y relegados a extensiones.
En paralelo, Google exploró en varias ocasiones la idea de ocultar las URLs en Chrome, debilitando la noción de que los usuarios pueden identificar el origen real de un contenido.
2019–2023: Manifest V3, bloqueo de bloqueadores y el golpe a JPEG XL
En 2019, Google anunció cambios en las extensiones de Chrome con el Manifest V3. Oficialmente se trataba de mejorar la seguridad; en la práctica, muchos lo vieron como una maniobra para limitar los bloqueadores de anuncios.
En 2023, la compañía eliminó el soporte para JPEG XL, un formato abierto y superior al JPEG y PNG tradicionales. JPEG XL ofrecía mejor compresión, soporte para animación y transparencia, y habría ahorrado ancho de banda a todo Internet. Google prefirió enterrarlo.
Ese mismo año, llegó la propuesta de la Web Environment Integrity API, un intento de convertir al navegador en un filtro de “aplicaciones de confianza”, que muchos calificaron de censura encubierta.
2024–2025: RSS fuera de Google News y el asalto final a XSLT
En 2024, Google dejó de aceptar feeds RSS en Google News. El descubrimiento de noticias pasó a depender de algoritmos opacos.
En 2025, se reabrió el debate sobre eliminar definitivamente XSLT en los navegadores, pese a que versiones modernas (XSLT 2.0 y 3.0) ofrecen mejoras y seguridad. Críticos denuncian que no es un problema técnico, sino una decisión política: matar un estándar que reduce la dependencia de JavaScript y de la lógica del servidor.
¿Por qué importa todo esto?
Cada una de estas piezas —RSS, XSLT, JPEG XL, <keygen>, SMIL— puede sonar anecdótica, pero todas formaban parte de una web descentralizada, interoperable y bajo control del usuario.
Al eliminarlas o marginarlas, Google obliga a desarrolladores y usuarios a depender de sus propias tecnologías, como Chrome, AMP o sus APIs de autenticación. El resultado es una web menos libre y más alineada con su modelo de negocio basado en datos y publicidad.
Incluso quienes nunca usaron XML o XSLT se ven afectados: porque cuando Google decide qué estándares viven y cuáles mueren, la soberanía tecnológica de la web queda en manos de una sola empresa.
Resistencia y alternativas
El artículo original que destapó esta cronología (publicado en Oblomov) propone varias líneas de acción:
- Visibilizar y usar XML/XSLT y RSS. Cuantos más sitios sigan ofreciendo feeds y transformaciones abiertas, más difícil será enterrarlos.
- Protestar activamente. Desde foros técnicos hasta redes sociales, la presión pública importa.
- Construir alternativas. Librerías como SaxonJS permiten ejecutar XSLT en navegadores modernos como polyfills, aunque sea menos eficiente que un soporte nativo.
Una lección histórica
Microsoft intentó dominar la web con Internet Explorer en los años 90, pero fracasó porque existía competencia real entre navegadores. La creación del WHATWG en los 2000 tuvo sentido como alternativa a la lentitud del W3C, pero al final se convirtió en un cartel dominado por Google.
Hoy, la web abierta no muere de golpe: lo hace por erosión lenta, decisión tras decisión. Y Google está escribiendo esa cronología.
Preguntas frecuentes (FAQ)
1. ¿Por qué Google eliminó tecnologías como XSLT o JPEG XL?
En teoría, por razones de seguridad o baja adopción. En la práctica, muchos expertos creen que son movimientos estratégicos para reforzar su control y favorecer tecnologías que dependen de sus servicios.
2. ¿Qué consecuencias tiene el fin de RSS en Google Reader y Google News?
Ha debilitado la capacidad de los usuarios para consumir información de forma descentralizada y ha reforzado la dependencia de algoritmos opacos de recomendación.
3. ¿Existen alternativas para seguir usando XML y XSLT en la web?
Sí. Se pueden aplicar polyfills como SaxonJS, extensiones de navegador o simplemente usar XSLT en el servidor. Además, el estándar XSLT 3.0 sigue vivo y ofrece compatibilidad con JSON.
4. ¿Cómo puede un usuario corriente apoyar la web abierta?
Usando navegadores alternativos a Chrome, apoyando estándares abiertos, exigiendo compatibilidad con RSS en los sitios que visita y, sobre todo, siendo consciente de que la comodidad de un ecosistema cerrado tiene un precio: perder la libertad y la diversidad de la web.