- La suppression de la prise en charge de XSLT dans Chrome est présentée comme une mesure qui affaiblit une technologie clé du Web ouvert ; Google invoque des problèmes de sécurité, mais retire la fonctionnalité sans fournir de technologie de remplacement
- Google a proposé un polyfill basé sur JavaScript plutôt qu’une fonctionnalité native du navigateur, mais sans l’intégrer au navigateur, reportant ainsi la charge d’implémentation sur les développeurs
- Cette décision conduit à un affaiblissement de l’écosystème Web indépendant fondé sur RSS et XML, et Mozilla comme Apple semblent évoluer dans une direction similaire
- L’article critique le fait que WHATWG ne joue plus le rôle de défenseur du Web ouvert, et contrôle désormais les standards du Web selon les intérêts des grandes entreprises
- Avec la réduction de l’extensibilité des navigateurs et la standardisation des DRM, une structure du Web qui affaiblit le contrôle des utilisateurs se fixe durablement ; l’article appelle en réponse à continuer d’utiliser et de défendre des technologies ouvertes comme RSS, XSLT et JPEG XL
Fin de la prise en charge de XSLT et orientation de Google
- Google abandonne la prise en charge de XSLT dans Chrome, invoquant des failles de sécurité, mais ne propose ni bibliothèque de remplacement ni piste d’amélioration
- L’auteur critique l’usage des problèmes de sécurité des bibliothèques FLOSS existantes comme prétexte
- Il souligne aussi que Google n’a même pas saisi l’occasion d’adopter une implémentation moderne de XSLT écrite dans un langage plus sûr
- Le polyfill JavaScript proposé par Google n’est fourni que comme appel externe, sans intégration native au navigateur, et est ainsi présenté comme un substitut non standard et inefficace
- L’article affirme que cette mesure constitue un acte délibéré visant à fragiliser les fondations du Web indépendant fondé sur RSS et XML
- Selon cette analyse, soit le polyfill est insuffisant, soit, s’il est suffisant, le fait que Google refuse de l’intégrer montre une volonté de décourager l’usage même de XSLT
« Do. Not. Comply. » — appel à la résistance
- L’auteur insiste sur le fait qu’il ne faut ni installer le polyfill ni modifier le XML, mais exiger le rétablissement de la prise en charge de XSLT dans les navigateurs
- Il prévoit de continuer à utiliser des technologies standard comme XSLT, MathML, SVG et SMIL, et de conserver des encadrés d’avertissement (infobox) pour signaler aux utilisateurs les comportements non standard des navigateurs
- La décision de Google est décrite comme motivée non par des raisons techniques, mais par des motifs politiques et commerciaux, dans le cadre d’une tentative de contrôle du Web ouvert
- Mozilla et Apple sont également critiqués pour suivre une orientation similaire, en concevant les navigateurs non comme des agents utilisateurs (User Agent), mais comme des outils du capitalisme de surveillance
WHATWG et la déformation des standards du Web
- WHATWG est décrit comme un organisme qui, à l’origine, œuvrait pour le Web ouvert, mais qui serait devenu aujourd’hui une organisation fermée centrée sur les grandes entreprises
- Selon l’article, ce groupe transforme le Web, d’un réservoir de connaissances en une plateforme de distribution d’applications, en faisant passer la maximisation des revenus des entreprises avant le contrôle des utilisateurs
- Le navigateur n’est plus présenté comme un agent au service de l’utilisateur (User Agent), mais comme un outil de contrôle au bénéfice des intérêts des entreprises
- Cette évolution entrerait en conflit frontal avec la vision d’un Web ouvert portée par le W3C
La nécessité d’une nouvelle guerre des navigateurs
- Le marché actuel des navigateurs repose sur une dépendance aux moteurs dominés par Google, Apple et Mozilla, avec très peu d’alternatives réellement indépendantes
- Des navigateurs alternatifs comme Vivaldi, LibreWolf, WaterFox et Pale Moon sont mentionnés, mais la plupart dépendent de Blink ou de Gecko
- Pale Moon est présenté comme l’un des rares navigateurs à maintenir la prise en charge de RSS et de JPEG XL
- L’article affirme qu’une nouvelle guerre des navigateurs, c’est-à-dire une lutte des utilisateurs contre les entreprises pour reprendre le contrôle du Web, est nécessaire
La possibilité d’un autre Web — Gemini et les protocoles ouverts
- Au-delà du Web centré sur HTTP et HTML, il existerait aussi de nouveaux espaces Internet, comme le protocole Gemini
- Gemini est décrit comme un protocole léger, à la structure simple, avec des fonctions intégrées de sécurité et d’authentification, fonctionnant hors de la sphère d’influence de Google
- L’auteur souligne toutefois que le problème n’est pas technique mais social, et que la technologie en elle-même reste valable
- Les navigateurs ne devraient pas discriminer selon le protocole ou le format, et il serait souhaitable d’offrir une prise en charge intégrée de formats de balisage légers comme Markdown, AsciiDoc et Gemtext
Suppression des plugins et renforcement du contrôle du Web
- Par le passé, l’interface de plugins NPAPI permettait de prendre en charge divers formats et protocoles, mais Google l’a retirée progressivement à partir de 2013
- Cela aurait bloqué l’extensibilité du Web et les voies d’introduction de technologies expérimentales
- Les Encrypted Media Extensions (EME) apparues après la suppression des plugins sont critiquées pour avoir standardisé les DRM et porté atteinte aux principes d’ouverture du W3C
- Les extensions de navigateur sont décrites comme des substituts aux fonctionnalités limitées, justifiés au nom de la sécurité ; Manifest V3 affaiblirait en particulier les capacités de blocage des publicités
- Ces évolutions sont analysées comme un recul du contrôle des utilisateurs et un renforcement du contrôle des entreprises
« A mesh of building blocks » — structure idéale du Web
- Le Web idéal devrait avoir une architecture modulaire fondée sur les plugins, permettant d’ajouter librement de nouveaux protocoles, formats et langages de script
- Dans une telle structure, des technologies comme RSS, SMIL, XSLT, XQuery et XHTML2 auraient pu continuer à évoluer
- Mais en pratique, l’évolution du Web aurait été transformée en une structure où Google décide de manière monopolistique de sa direction, d’où la nécessité d’une résistance menée par les utilisateurs
Resist — déclaration de résistance
- Sous le slogan « Do not comply. Resist. », l’article appelle aux actions suivantes
- Continuer à utiliser RSS
- Continuer à utiliser XSLT
- Adopter JPEG XL comme format d’image par défaut
- Considérer les comportements non standard des navigateurs non comme des “erreurs de site”, mais comme des “défauts du navigateur”
- Cela est présenté non comme un simple choix technique, mais comme une résistance concrète pour défendre le Web ouvert
Post Scriptum et réactions
- L’auteur présente le projet lié à XSLT xslt.rip ainsi que son site personnel, et mentionne des essais de génération de SVG avec XSLT
- Des discussions ont eu lieu sur Hacker News et Lobste.rs, mais beaucoup de commentaires auraient sous-estimé l’importance de XSLT
- L’auteur affirme que XSLT est plus efficace que le rendu côté serveur, en particulier dans les environnements de petite taille ou auto-hébergés
- En conclusion, il réaffirme que l’usage continu de technologies ouvertes comme XSLT constitue une stratégie essentielle pour la survie du Web ouvert
3 commentaires
On se demande pourquoi ce n’est pas intégré, mais à l’inverse, il ne semble pas vraiment y avoir de raison de l’intégrer à tout prix non plus..
Avis sur Hacker News
La suppression de XSLT dans le navigateur était nécessaire depuis longtemps
En tant qu’ancien mainteneur de libxslt, je connais en partie le contexte qui a conduit à cette décision
Ce qui est encore plus intéressant, c’est le projet de Chromium de passer à un parseur XML basé sur Rust
Pour l’instant, ils privilégient xml-rs, qui n’implémente qu’une partie de XML
Autrement dit, Google semble vouloir choisir une prise en charge de XML qui ne respecte pas entièrement le standard
Cela rappelle l’époque de Internet Explorer 5.1, quand la part de marché permettait d’ignorer les standards
Depuis que XHTML a été évincé par HTML5, le code complexe lié à XML disparaît naturellement
Le fait de migrer vers Rust pour réduire la surface d’attaque de sécurité est un choix raisonnable
Le parsing XML restant peut être remplacé en JS par un polyfill ou par wasm
Je travaille dans l’équipe Chrome, mais je ne suis pas directement impliqué dans ce travail
Autrefois, le web était centré sur les exploitants de sites, et le navigateur jouait le rôle de leur outil (leur serviteur)
La direction actuelle s’éloigne de cette philosophie
XML permet des vulnérabilités d’explosion de données comme l’attaque Billion Laughs
Explication associée
L’affirmation selon laquelle XSLT est indispensable pour afficher des flux RSS dans le navigateur est exagérée
C’est tout à fait faisable en JavaScript, et le polyfill de Google fonctionne ainsi
J’ai écrit des milliers de lignes de XSLT, mais je trouve JavaScript bien meilleur
XSLT devrait désormais être retiré pour des raisons de sécurité
Le sujet est abordé dans cette présentation à OffensiveCon 2025
Les alternatives en JS sont complexes et ont une barrière à l’entrée élevée
Comme il devient plus difficile de créer de simples pages web personnelles, l’esprit du “web ouvert” s’affaiblit
La disparition de RSS et la dépendance à des plateformes comme Facebook en sont le résultat
Voir la documentation sur les Web Components
Je me souviens de la disparition de navigateurs indépendants incapables de suivre l’écosystème JS en évolution rapide
Konqueror me manque
document()Après l’avoir vue, j’ai trouvé la suppression de XSLT justifiée
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;sous une forme de ce genre
Mais avec l’implémentation actuelle, il est difficile de remplacer complètement par JS une expérience au niveau de XSLT
Je suis d’accord avec l’idée que Google tue le web ouvert, mais XSLT est un argument faible
C’est une fonctionnalité complexe, très peu utilisée, et la décision semble surtout viser à réduire les ressources de maintenance
Pour l’affichage des flux RSS/Atom, il vaudrait mieux intégrer une prise en charge directe dans le navigateur
Il ne faut pas juger uniquement sur la fréquence d’utilisation
Il faudrait collaborer avec les utilisateurs importants et procéder à une suppression progressive
Le “web ouvert” et XSLT n’ont pas grand-chose à voir
Le web ouvert désigne un environnement où n’importe qui peut exploiter un serveur, créer un site et développer un navigateur
XSLT est déjà une technologie morte depuis longtemps, et sa suppression cassera très peu de sites
Elle a même pour effet de supprimer une vulnérabilité de sécurité
Le problème ne venait pas de XSLT lui-même, mais de vulnérabilités dans l’implémentation de libxslt
Il aurait été possible de créer une implémentation alternative, mais le problème, c’est que Google a choisi de “tuer” la fonctionnalité
Mais les gens préfèrent désormais une consommation basée sur des flux sociaux plutôt que sur l’abonnement à des sites individuels
Ce n’est pas un problème technique, mais un changement de comportement des utilisateurs
Parmi les personnes qui se plaignent de l’abandon de XSLT, j’en ai rarement vu expliquer clairement pourquoi elles l’utilisent réellement
La plupart s’en servent simplement comme symbole de résistance
Pendant plus de 20 ans, on s’attendait à ce que « les pages web restent visibles pour toujours »
Après la démission du mainteneur de libxslt sous le poids des rapports de sécurité,
les éditeurs de navigateurs ont choisi de supprimer la fonctionnalité plutôt que d’en assumer le coût
En faire un symbole de rébellion revient à se compliquer la vie soi-même
Si nécessaire, un polyfill ou une transformation côté serveur peut tout à fait le remplacer
Je m’en servais pour rendre les flux RSS/Atom plus lisibles
On peut voir la différence sur mon site rss.style
Si Mozilla a retiré RSS, ce n’est pas à cause d’une pression de Google,
c’est parce que les utilisateurs ne voulaient pas de RSS
Google est au contraire l’une des entreprises qui ont le plus investi dans le développement du web ouvert
Le fait que WHATWG veuille faire du web une plateforme d’applications est le résultat de la demande des développeurs et des utilisateurs
Blink est open source, donc il reste possible d’en maintenir un fork
RSS était trop technique pour le grand public, et quand Google a supprimé Reader,
les réseaux sociaux ont pris sa place
avant de renforcer au final une structure monopolistique
Le caractère open source de Blink ne garantit pas à lui seul une véritable ouverture
s’il n’y a pas de nuisance à sa seule existence, il n’est pas nécessaire de la supprimer
Je comprends en partie l’argument de l’auteur,
mais dire que le navigateur devrait aussi prendre en charge Gopher, c’est de la complexité excessive
Du point de vue du projet Chrome, cela ressemble à une décision de simplification
Sa suppression est raisonnable, et la plupart des professionnels du web seront d’accord
Le parsing XML en C inspire toujours une crainte sur le plan de la sécurité
supprime une vieille fonctionnalité au nom de la simplification, c’est contradictoire
Dans tous les cas, quelqu’un y perd
Je pense convertir mon blog en XML/XSLT
Comme personne ne le lit, je pourrai désormais accuser Chrome de mon manque de trafic
Je ne suis pas fan de Google, mais la suppression de XSLT est une occasion de réduire la complexité des API web
Cela pourrait alléger la charge pour des navigateurs indépendants comme Ladybird
Au final, cela pourrait même affaiblir la position monopolistique de Google
Il est difficile de dire que cela se fait « sans grande opposition »
Depuis 10 à 15 ans, les standards du web suivent une logique consistant à intégrer dans le navigateur des besoins de niche
La suppression de XSLT et la fourniture d’un polyfill semblent aller dans le sens de repousser la complexité hors du navigateur
L’idée qu’il faudrait prendre en charge XSLT en 2025 est assez originale… Il est vrai que c’est parfois utilisé brièvement pour le stylage, notamment avec RSS, mais il est difficile de considérer que cela soit réellement employé de manière générale.