Google is killing the open web
Google está logrando lo que Microsoft no pudo: acabar con la web abierta. Los esfuerzos de los gigantes tecnológicos para hacerse con el control y encerrar los bienes comunes con fines extractivos resultan claros para cualquiera que haya estado siguiendo la historia de Internet durante al menos la última década, y las estrategias adoptadas son tan variadas en técnica como en el éxito que alcanzan, desde Abrazar, Extender, Extinguir (#EEE) a la monopolización y el encierro.
De lo que quiero hablar en este artículo es de la guerra que Google lleva librando contra XML durante más de una década, por qué importa que finalmente hayan invadido lo suficiente como para obtener lo que quieren, y qué podemos hacer para luchar contra esto.
Un poco de historia
Google ingresó en el mercado de los navegadores en un momento en que el desarrollo web comenzaba a ver la luz nuevamente después de la «victoria» de Microsoft en la Primera guerra de los navegadores mediante el abuso del monopolio de su sistema operativo al enviar su Internet Explorer de forma gratuita y, por lo tanto, cortar el «suministro de aire de Netscape», según lo previsto.
Lo que logró romper la corta victoria de Microsoft fue una alianza de navegadores (Opera con su motor Presto, Firefox de Mozilla con su motor Gecko y el recién nacido Safari de Apple, cuyo motor WebKit se bifurcó del motor KHTML que se estaba desarrollando para el entorno de escritorio KDE GNU Linux) que decidieron aprovechar el cumplimiento de sus estándares para reforzar la posición de los demás contra el efecto paralizante del dominio de Microsoft, un dominio que Microsoft trató de proteger recurriendo a los trucos más viles.
Google ingresó al mercado abusando en gran medida de su dominio en la búsqueda web para impulsar la adopción de su navegador Chrome, una práctica no muy diferente a la utilizada por Microsoft para impulsar la adopción de IE, y de legalidad y moralidad igualmente cuestionables, algo que con frecuencia se pasaba por alto con varias excusas, entre ellas el hecho de que Chrome se construyó sobre un núcleo de código abierto, Chromium, que se ensambló principalmente a partir de software y bibliotecas desarrolladas por otras compañías (principalmente, Mozilla y Apple).
En los años del lanzamiento de Chrome, Internet estaba experimentando cambios masivos, con la aparición de plataformas de redes sociales centralizadas como Facebook que comenzaron a erosionar la red social distribuida anterior de plataformas de blogs, el propio servicio de correo Gmail de Google ganando terreno tanto a la oferta de ISP como a otras ofertas «en la nube» como Yahoo! y el Hotmail de Microsoft, y la conectividad móvil creciendo más allá de los «profesionales», gracias principalmente al iPhone de Apple y la reciente adquisición de Android por parte de Google en ese momento, además de algunos jugadores menores de los que he hablado anteriormente.
Para los propósitos de nuestra discusión, estos cambios tuvieron dos puntos principales de enfoque en términos de desarrollo de sitios web.
Por un lado, los desarrolladores web comenzaron a prestar más atención al cumplimiento de los estándares, ya que les brindaba más oportunidades para la creciente base de usuarios de dispositivos móviles, que era poco probable que tuvieran el Internet Explorer dominante en el escritorio como navegador. Esto ayudó a acelerar la desaparición de IE (que todavía era fuerte cuando Chrome se lanzó por primera vez), cuyo cumplimiento de los estándares escamosos fue en última instancia responsable de su desaparición casi una década después y, posteriormente, de la descontinuación completa de su línea (después del breve intento de una repetición bajo el apodo heredado de Edge), y envalentonó a los «desvalidos» del momento (Mozilla, Apple, Opera).
Por otro lado, hubo un claro cambio hacia la centralización de los servicios web, lo que a su vez aceleró el desarrollo de aplicaciones web, interfaces gráficas de usuario para los servicios subyacentes (centralizados) que dependían efectivamente de los navegadores como kits de herramientas multiplataforma, un enfoque que más tarde daría a luz a la abominación conocida como Electron y la pesadilla de seguridad mejor conocida como node.js.
Por supuesto, Google tenía un interés fundamental en hacer de las aplicaciones web una alternativa creíble a las aplicaciones de escritorio, con su servicio de correo ya mencionado y la aplicación Google Maps adquirida y convertida en web. Y dado que su navegador era principalmente una colección de software #FLOSS ya existente y grapado, podían enfocar su esfuerzo de desarrollo en crear una implementación más rápida de #JavaScript, más conocido como V8. No importa el hecho de que incluso años después, las implementaciones nativas de cualquier característica útil seguirían siendo más rápidas y económicas que JavaScript.
Pero incluso antes de su participación directa en el desarrollo de navegadores, Opera y Mozilla habían comenzado a distanciarse de los esfuerzos de estandarización del W3C y establecieron WHATWG, un consorcio de desarrolladores de navegadores dedicado a coordinar el rápido desarrollo de nuevas funciones web sin pasar por el lento proceso de estandarización percibido del W3C.
En verdad, como quedaría claro unos años más tarde, y más aún con Google asumiendo efectivamente el WHATWG y convirtiéndose en un títere de calcetín para dar una apariencia de independencia a sus elecciones, el objetivo principal del WHATWG era secuestrar el desarrollo de tecnologías web en beneficio de los inversores corporativos, mientras que el W3C, con todos sus defectos, había dado prioridad principalmente a las características que serían de interés más general.
(No es casualidad que el estándar más controvertido que haya salido del W3C haya sido probablemente las Extensiones de Medios Cifrados, lanzadas como un intento fallido de seguir siendo relevantes en el espacio web, y que, en cambio, resultaron en un ataque crítico contra su propia credibilidad como administradores de la web abierta.)
La guerra de Google contra XML como proxy de la guerra contra la web abierta:
Podría decirse que el punto de inflexión para la centralización de la web fue el año 2013. Este es esencialmente el año en que GAFAM dejó de intentar fingir que le gustaba el juego limpio y comenzó a «tomar las riendas» de la interoperabilidad. Casualmente, también es el año en que Ópera dejó de ser Ópera, pero hablaré de esto más adelante.
Veamos algunos de los principales hechos relevantes para nuestra discusión:
⮵
1.- 2013 es el año en que Google decide poner fin a Google Reader, un agregador de feeds web (si no el más utilizado) (para feeds #RSS y Atom); la razón oficial dada es que el uso fue declinando; «casualmente» esto sucede poco después de que cierren su AdSense para Feeds (por razones no especificadas, que probablemente se puedan resumir como «nadie quiere anuncios en sus feeds», y especialmente no anuncios de video, no es que no sigan intentándolo);
⮵
2. 2013 es el año en que Google decide cerrar la federación de servidor a servidor XMPP en su servicio de Chat de Google; Facebook hará lo mismo con su producto Messenger el año siguiente;
⮵
3. 2013 es el año en que Google propone por primera vez la eliminación de XSLT, una propuesta tan impopular que seguirá recibiendo comentarios en su contra hasta 5 años después (el último comentario
en el hilo es de 2018);
4. 2013 es el año en que Google elimina el soporte MathML recién introducido de Chrome; se necesitarán 10 años y una empresa externa para devolver el soporte #MathML al navegador.
Esto fue solo el comienzo. Se emprendieron otras acciones diferentes e intentos en los años siguientes.
⮵
1. en 2015, WHATWG presenta la API Fetch, supuestamente pensada como el reemplazo moderno de la antigua XMLHttpRequest; falta de manera destacada en la nueva especificación cualquier mención o método para administrar documentos # XML, a favor de JSON que, en cambio, obtiene un dedicado método de presentación del cuerpo del documento;
⮵
2. en 2015, Google propone desaprobar SMIL, el estándar de animación declarativa e interactividad en SVG; He escrito en el pasado sobre la utilidad de #SMIL y por qué no solo no debe desaprobarse, sino que su uso debería integrarse en # HTML, como señala el W3C;
⮵
3. en 2015, Google también anuncia el proyecto Accelerated Mobile Pages, supuestamente como una forma de hacer que las páginas web sean más accesibles y más rápidas de cargar en dispositivos móviles, que casualmente dependía en gran medida de aprovechar grandes CDN como Google para almacenar en caché el contenido (y opcionalmente pre-renderizarlo); no importa el hecho de que el artículo seminal de Diseño Web Receptivo sobre cómo diseñar para diferentes tamaños de pantalla era de 2010, que el atributo srcset para que las imágenes admitan pantallas de diferentes tamaños ya era compatible con los navegadores actuales de escritorio y móviles en ese momento, y que las razones principales por las que las páginas web no se cargaban rápidamente en dispositivos móviles se debían a la llamada crisis de obesidad web que se conocía al menos desde 2012., y que la razón principal por la que las páginas AMP se cargaban más rápido era porque venían con una décima parte de la basura inútil adjunta a las páginas «normales», por lo que el único beneficio real de AMP era obligar a los dispositivos web a escribir páginas más ágiles, con al menos un mínimo de capacidad de respuesta (y, por supuesto, para Google, para alentarlos a canalizar todo a través de los servidores de Google, o de cualquier otro gigante tecnológico, para facilitar la recopilación de métricas, la publicación de anuncios más rápida y más perfiles de usuarios);
⮵
4. todavía en 2015, Google anuncia la intención de desaprobar el elemento keygen, una característica de seguridad poco conocida pero poderosa que simplificó la generación de pares de claves criptográficas controladas por el usuario para una comunicación segura entre el cliente y el servidor; puede leer más sobre esto en la reacción de Tim Berners-Lee y en las relevantes «Memorias de la vieja web» de Hugo Landau.; cabe destacar que el interés principal de TBL en este elemento era ayudar a construir Solid, una mejora incremental en la WWW para hacerla más resistente a la centralización en la que se había pervertido su idea original (ver también el problema relevante en el rastreador de problemas de Solid); la importancia del manejo simplificado de los certificados de usuario y el papel que desempeñan en la autenticación mutua también se puede suponer por ser una de las características del protocolo Gemini liviano que también nació como respuesta a la centralización y la consiguiente complejidad de la World Wide Web.;
⮵
5. en 2018, Mozilla elimina el soporte RSS de Firefox a partir de la versión 64 y evita activamente abrirlos en el navegador, dándoles un trato aún peor que los archivos XML genéricos, para los que sigue mostrando la estructura (por ejemplo: compare cómo maneja su navegador el XML de estadísticas de uso para esta columna con la forma en que maneja el feed RSS y el feed Atom); la razón oficial es que la función «Marcadores activos» no se pudo portar fácilmente a la nueva arquitectura; el hecho de que el soporte para RSS aún pudiera implementarse a través de extensiones, que Mozilla no enviara una extensión para reemplazar ni siquiera parcialmente la función de Marcadores activos, dejando a sus usuarios en manos de extensiones de terceros potencialmente inseguras, y que los feeds recibieran un trato aún peor que el documento XML genérico muestran que la razón oficial es solo una excusa; esta es una de las principales grietas en la fachada de Mozilla, ya que comienza a mostrar que su existencia es solo una oposición controlada para que Google evite problemas antimonopolio: lo que Google quiere se va, y Google no quiere feeds web, por lo que los feeds web tienen que irse.;
⮵
6. en 2019, Google anuncia una serie de cambios para supuestamente hacer que las extensiones del navegador sean «más seguras» para los usuarios, comenzando a trabajar en lo que luego se convertiría en el Manifiesto de extensión V3; es inmediatamente evidente que al menos algunos de los cambios introducidos están destinados principalmente a evitar que funcionen los bloqueadores de anuncios y, en realidad, no hacen mucho para mejorar la seguridad o la privacidad.; a pesar de varios informes en contra de los cambios propuestos, en el mejor de los casos, ineficaces y, en el peor, perjudiciales, en los años siguientes Google continuará con el cronograma para desaprobar las API de extensión anteriores y finalmente tener éxito en sus esfuerzos de bloqueo de anuncios; aunque este cambio no es relevante actualmente para el enfoque XML/XSLT de este artículo, lo menciono no solo porque es uno de los muchos ejemplos de Chrome convirtiéndose menos en un Agente de usuario y más en una «herramienta de Google en tu ordenador» con el tiempo, sino porque este aspecto es importante para el futuro de XML y XSLT del lado del cliente, como diré más adelante.;
⮵
7. en 2021, Google intentó eliminarperiodistas a este ritmo, pronto no quedará ninguno en Gaza para informarte. algunos modismos comunes de interacción de JavaScript, blandiendo de nuevo la «seguridad» como razón, a pesar de que los cambios propuestos son mucho más extensos que la supuesta amenaza a la seguridad y se proponen mejores soluciones; puede leer sobre esto aquí y notar patrones de comportamiento similares al asalto del que quiero hablar aquí;
⮵
8. en 2023, Google cambia el nombre de su chatbot de Bard a Gemini, eclipsando así por completo el protocolo independiente de 4 años con el mismo nombre; posiblemente sea una coincidencia, lo que lo convertiría en el único ataque involuntario a la web abierta por parte de Google en los últimos 15 años aproximadamente —y en este momento incluso eso es dudoso;
⮵
9. en 2023, Google propone la API de Integridad del Entorno Web, de la que he hablado en su momento; aunque esto solo está relacionado tangencialmente con las iniciativas centradas en XML que es el tema de este artículo, resulta relevante mencionarlo aquí, ya que es otro ejemplo indicativo del impulso para hacer que los navegadores tengan menos Agentes de usuario y más spyware controlado por la empresa;
⮵
10. en 2023, Google elimina el soporte para el formato de imagen JPEG XL, introducido apenas dos años antes, privando a Internet de un formato que finalmente habría cumplido la promesa de un formato unificado para proporcionar compresión competitiva, tanto sin pérdidas como con pérdidas, decodificación progresiva, transparencia y animación, lo que le habría permitido reemplazar los formatos JPEG, PNG y GIF generalizados (y menos eficientes) que han sido el elemento básico de la web durante las últimas décadas. ; esto tampoco está directamente relacionado con XML (a menos que el motivo del odio sea que JPEG XL admita metadatos XMP), pero debe archivarse como «contra la web abierta e independiente», ya que evita al menos la reducción de costos de alojamiento y ancho de banda que ofrecería una transición a JPEG XL.
⮵
11. en 2023, después de reducir la clasificación de los sitios web HTTP simples durante años, Google anuncia una postura aún más agresiva para impulsar la adopción de HTTPS.; Tengo mucho que decir sobre la supuesta «seguridad» de HTTPS (y en particular sobre cómo no significa lo que la mayoría de la gente piensa que significa, particularmente en lo que respecta a la distinción entre la integridad de la conexión entre el cliente y el servidor versus la autenticidad del contenido, particularmente de relevancia tanto para los silos corporativos como para las redes sociales federadas), pero eso es material para un artículo diferente, así que aquí solo vincularé algunos artículos de Dave Winer (uno de los inventores de RSS), especialmente este particularmente profético, y señale la hipocresía de reclamar un interés por la seguridad por parte de la misma compañía que presionó para la eliminación del keygen;
⮵
12. en 2024, Google descontinúa la posibilidad de enviar feeds RSS para su revisión para incluirlos en Google News; la forma en que Google descubre ahora nuevos sitios de noticias o cómo recopila información sobre noticias publicadas es completamente opaca.
⮵
13. en 2025, Google anuncia un cambio en su Política del Programa Raíz de Chrome que, en 2026, dejará de admitir certificados con un Uso Extendido de Claves que incluya cualquier uso que no sea el servidor (subproceso Fediverso relevante, otro hilo Fediverso relevante); esto elimina efectivamente los certificados comúnmente utilizados para la autenticación mutua (¡oye, mira, es el tema de supresión de keygen nuevamente!) que incluyen roles tanto de cliente como de servidor; casualmente, esto también dificulta la implementación de S/MIME, a menos que pase por los servicios de Google, por supuesto, pero la guerra de Google contra el correo electrónico autohospedado merece su propio artículo, así que eso será para otro momento.
Y finalmente llegamos a estos días. Justo cuando las fuentes RSS están regresando y los usuarios comienzan a volverse escépticos de los silos corporativos, Google hace otra carrera para matar a XSLT, esta vez usando WHATWG como títere de calcetín. Particularmente digno de mención, el problema de Chromium correspondiente se creó antes del problema de Github de WHATWG. Por lo tanto, no sorprende a nadie que las reacciones abrumadoramente negativas al problema, las explicaciones detalladas sobre por qué #XSLT es importante y útil, las recomendaciones de que, en lugar de eliminarlo, los navegadores deberían pasar a versiones más recientes del estándar e incluso las indicaciones de bibliotecas mejores y más seguras existentes en las que basar estas nuevas implementaciones, todos los contrapuntos a la eliminación se hayan ignorado por completo.
Aún así, las reacciones negativas fueron tan extensas que, en última instancia, el problema quedó bloqueado, particularmente cuando la gente comenzó a señalar que «no tenemos suficientes recursos para gastar en esta» fue una excusa completamente idiota de compañías multimillonarias, o incluso de empresas más pequeñas como Mozilla que aparentemente tienen suficiente dinero para desperdiciar en funciones que nadie quiere como la integración de chat LLM: esto finalmente ha confirmado que el propósito del problema nunca fue realmente discutir si XSLT debería eliminarse o no, sino solo proporcionar una excusa endeble para pretender que la eliminación fue impulsada por un consenso en lugar de una directiva de arriba hacia abajo de Google.
Las únicas frases verdaderas declaradas por el Google responsable de este problema fueron que los navegadores han estado atascados con una versión obsoleta de XSLT durante más de dos décadas, y que las implementaciones en las que confían (Google y Apple) tienen algunos problemas de seguridad. El Googler en cuestión también omitió convenientemente varios otros hechos importantes.
Por ejemplo, omitió que se han lanzado dos nuevas versiones principales de XSLT desde que esta tecnología se implementó por primera vez en los navegadores: XSLT 2 en 2007 y XSLT 3 en 2017. Esto significa que cuando Google propuso por primera vez eliminar XSLT, ya se había lanzado una versión más nueva y considerablemente más poderosa del estándar durante seis años. Y ya en ese momento la gente pedía que se actualizara el soporte de los navegadores a la nueva versión.
Por lo tanto, no es por casualidad o por falta de recursos que los navegadores se queden atascados con el XSLT 1 de 1999: ha sido una elección intencionada contra la voluntad de los usuarios desde al menos 2013, el año que ya mencionamos como el punto de inflexión para la centralización de la web. XSLT ha sido boicoteado intencionalmente por Google, Apple y Mozilla: usar la excusa de que no se usa ampliamente en la actualidad, después de décadas de socavar cualquier esfuerzo en adopción, negarse a corregir errores o incluso a propperiodistas a este ritmo, pronto no quedará ninguno en Gaza para informarte.orcionar errores significativos para ayudar a depurar problemas relacionados, es una completa burla de las víctimas de estas políticas.
El Googler también omite mencionar que la implementación XSLT de Google y Apple (no la de Mozilla, que desarrolló la suya propia) se basa en un conjunto de bibliotecas de software libre cuyo mantenedor ha sufrido recientemente un bombardeo de informes de problemas casi abusivos de la explotación corporativa característicamente extractiva de # FLOSS, con solicitudes para brindar servicios profesionales sin pagarlos de ninguna manera. Repitámoslo de nuevo: estamos hablando de empresas multimillonarias que han estado explotando el trabajo de los mantenedores de software libre, exigiendo un trato preferencial sin costo para ellos, limitando sus esfuerzos a encontrar errores, sin mover un dedo para solucionarlos realmente, casi como si la intención principal fuera encontrar excusas para borrar la biblioteca en lugar de trabajar para mejorar los bienes comunes. (Y esto es incluso antes de entrar en la forma irresponsable en que se usaban estas bibliotecas.)
Pero, por supuesto, cualquiera que cuestione los motivos de las corporaciones que controlan el WHATWG o señale la abundancia de recursos que tienen, y cómo estos podrían gastarse fácilmente en llevar el soporte de XSLT al siglo XXI en lugar de gastarse en características antagónicas con el usuario, está «fuera de tema» y «en violación del código de conducta».
Al final, el WHATWG se vio obligado a cerrar los comentarios al proMemorias de la vieja webblema de Github para detener la avalancha de comentarios negativos, de modo que el Googler pudiera dar al siguiente paso: comenzar el proceso de formalizar el despido de XSLT.
Y sí, ese problema es una mina de oro si está buscando ejemplos de comportamiento abusivo: en el clásico gaslighting DARVO, el último comentario actual del Googler que abrió el problema en primer lugar es realmente una obra maestra. Y como no puedo responder allí, permítanme responder aquí:
Solo soy un ingeniero y no tengo un presupuesto ilimitado.;
Tú no, Google sí. Pide un presupuesto mayor. La necesidad de solucionar un riesgo de seguridad que, según tu, es tan importante debería ser una muy buena excusa para obtener más recursos. Si fallas en eso, ese es tu problema, no el nuestro, y no es, de ninguna manera, una razón válida para acabar con la web abierta. Los problemas de seguridad no están en el estándar web, están en la implementación que está utilizando (o más específicamente: leeching off).
Solo trato de hacer mi trabajo.
⮵
Esa excusa tampoco funcionó en los juicios de Nuremberg.
Me preocupo mucho por la salud de la web en general.
Mentira patente. Si te importara, tu única prioridad sería cómo mantener XSLT, ya que esa es la única solución que no afecta a los millones de usuarios que todavía usan XML y XSLT en la actualidad. Pero en realidad no te importa la salud de la web, solo te importan los resultados finales de tu empleador. Noticias instantáneas, serás despedido como todos los demás, independientemente de lo duro que los aguantes.
Quiero encontrar soluciones a problemas reales,
No hay nada que encontrar. Todo el hilo de comentarios está lleno de soluciones a los problemas reales. Simplemente no te gusta la respuesta. Han dicho repetidamente que las vulnerabilidades de seguridad se solucionan corrigiendo los errores en la biblioteca que usa Chrome o cambiando a bibliotecas más robustas y modernas como xrust o xee.
Entonces ya has encontrado las soluciones. Pero esa no es la solución que querías encontrar, porque esos «problemas» son solo excusas para finalmente hacer lo que Google ha estado intentando (hasta ahora sin éxito) durante más de diez años: matar XSLT.
y quiero minimizar el dolor que siente la gente por esta discusión sobre la eliminación de XSLT.
Ajá, y aquí vemos el desliz: la discusión nunca fue sobre si debería eliminarse o no. Siempre se trató de: vamos a eliminarlo sin importar lo que pienses; prepárate para sufrir.
Pero es importante recordar que los usuarios comunes que son víctimas de vulnerabilidades de seguridad también sienten dolor, y estoy tratando de minimizarlo también.
Hay una solución muy simple para resolver el «dolor» de tales usuarios, y como todos te han dicho, es arreglar la biblioteca o cambiar a una diferente.
Propuse algunas soluciones a los casos de uso concretos que escuché sobre este asunto. Si todavía hay brechas, me gustaría trabajar para cerrarlas.
Lo siento, pero eso es una completa mierda. Literalmente, no hay forma de resolver todos los casos de uso que XML+XSLT puede y para los que se está utilizando.
Es una lástima que no podamos tener esa discusión aquí; supongo que no podemos reabrir este problema para comentarios externos, debido al tono general de los comentarios anteriores. De cualquier manera, de ahora en adelante, solo responderé a conversaciones técnicas e ignoraré el resto, por mi propia cordura.
Eso es hilarante. Nunca has suministrado un argumento técnico para la eliminación de XSLT. Literalmente, ni uno solo.
«La biblioteca XSLT que estamos utilizando tiene errores» no es un argumento técnico para eliminar el soporte XSLT del lado del cliente de las especificaciones.
«XSLT «solo» solo lo utilizan millones de personas para decenas de millones de cargas de página por mes» no es un argumento técnico para eliminar el soporte XSLT del lado del cliente. Las métricas ni siquiera son una excusa válida según las propias reglas de Chrome sobre cómo leer datos de telemetría.
«Una empresa de un billón de dólares no tiene los recursos para arreglar o cambiar la biblioteca XSLT», además de ser una completa estupidez, no es un argumento técnico de por qué no debería arreglar o cambiar la biblioteca XSLT.
Todos los comentarios sobre el tema han sido muy técnicos hasta que comenzó a decir tonterías y se negó a proporcionar respuestas técnicas a los comentarios técnicos que había recibido. Usted y sus colegas son los únicos que nunca han presentado un solo argumento técnico para defender su posición de que se debe eliminar el XSLT del lado del cliente. Porque esa nunca fue la intención en primer lugar: solo se trataba de «con qué queremos reemplazar nuestro antiguo soporte XSLT 1.0 con errores».
Y la verdad, independientemente de cuánto no le guste y de cuánto intente suprimirlo, es que solo hay una respuesta a eso, y es: un soporte XSLT más moderno del lado del cliente.
Se espera una actualización aquí como respuesta rápida a esta ridícula defensa de Google y del ingeniero que propuso el cambio, una defensa que procede de un ingeniero que trabajaba para Igalia, la misma compañía que implementó MathML para Chrome 10 años después de que Google lo eliminara, difícilmente un tercero objetivo.
En primer lugar, que Apple y Mozilla estén de acuerdo con algo que Google ha estado presionando para hacer durante más de 10 años no es la defensa de Google y Mason Freed por el cambio que crees que es. Apple no es menos #GAFAM que Google, y Mozilla es una oposición controlada.
Tratar de justificar este acuerdo como una oportunidad para «adelgazar su base de código» también es una completa tontería, cuando esos mismos ingenieros siguen presionando para agregar funciones y API de JavaScript que nadie necesita o desea, o que a veces incluso los usuarios rechazan activamente. Fue una excusa de mierda cuando Mozilla la usó para no restaurar el soporte para el formato de archivo MNG y sigue siendo una excusa de mierda en la actualidad.
La excusa del presupuesto tampoco cuela. Como ya dije anteriormente, si la compatibilidad con XSLT en Chrome tiene tantos errores que se considera un problema de alta seguridad, el enfoque correcto es enfocar los recursos en solucionar ese problema de seguridad, no en cambiar la especificación para que pueda justificar la eliminación del componente defectuoso. Si los equipos de Chrome, Safari y Mozilla no tienen suficientes recursos para solucionar sus problemas de seguridad, nadie debería usar esos navegadores. Y no, cambiar la especificación HTML para eliminar cualquier mención de XSLT para que pueda eliminarse de los navegadores no cuenta como «solucionar el problema de seguridad». Nadie en Google, Apple o Mozilla ha propuesto eliminar el soporte de JavaScript del navegador cada vez que surge un nuevo problema de seguridad relacionado con JavaScript, ¿verdad? Entonces tampoco hagas eso con XSLT.
Si Mozilla realmente se preocupa por aligerar su base de código de Firefox, puede comenzar eliminando todas las funciones de ML que nos han estado empujando con fuerza en contra de nuestra voluntad. Entonces podemos empezar a hablar de «recursos limitados», «aligerar la base de código» e incluso «la seguridad y privacidad del usuario». Lo mismo ocurre con Apple y Google. Por enésima vez: los «recursos limitados» no pueden usarse como excusa cuando los desarrolladores siguen agregando funciones que nadie quiere y se niegan a arreglar cosas de las que la gente se queja: ese no es un problema de recursos limitados, es un problema de recursos mal asignados. Es una cuestión de política.
Además, informarnos sobre el procedimiento de eliminación no tiene sentido, cuando Google ya ha dejado muy claro que en realidad no escucha los comentarios de los usuarios cuando su política lo requiere (¿Alguien manifiesta la eliminación de V2?
Y su TL; DR se equivoca en algo extremadamente importante: nunca se ha dado una buena razón para eliminar el soporte XSLT de los navegadores. Literalmente nunca y ninguna. El hilo estaba bloqueado porque la gente señalaba que las excusas dadas eran todas una mierda, y una mierda son.
(En la segunda entrega continuamos el viaje entre el nazismo web y la libertad)
eulaliobe 