- Die Einstellung der XSLT-Unterstützung in Chrome ist laut dem Artikel ein Schritt Googles, der eine Kerntechnologie des offenen Webs schwächt; als Grund wurden Sicherheitsprobleme genannt, doch die Funktion wird entfernt, ohne eine Ersatztechnologie bereitzustellen
- Google schlug statt einer Grundfunktion im Browser ein JavaScript-basiertes Polyfill vor, integrierte dieses jedoch nicht in den Browser und wälzte den Implementierungsaufwand auf die Entwickler ab
- Diese Entscheidung führe zur Schwächung eines unabhängigen Web-Ökosystems auf Basis von RSS und XML, wobei sich auch Mozilla und Apple in eine ähnliche Richtung bewegten
- Der Text kritisiert, dass die WHATWG nicht länger die Rolle eines Hüters des offenen Webs erfüllt, sondern Webstandards im Interesse großer Unternehmen kontrolliere
- Durch den Abbau der Browser-Erweiterbarkeit und die Standardisierung von DRM verfestige sich eine Web-Struktur mit geschwächter Nutzerkontrolle; dem setzt der Autor den Aufruf entgegen, offene Technologien wie RSS, XSLT und JPEG XL weiter zu nutzen und Widerstand zu leisten
Das Ende der XSLT-Unterstützung und Googles Vorgehen
- Google schafft in Chrome die XSLT-Unterstützung ab, verweist dabei auf Sicherheitslücken, legt jedoch weder eine Ersatzbibliothek noch Verbesserungsansätze vor
- Kritisiert wird, dass Sicherheitsprobleme bestehender FLOSS-Bibliotheken nur als Vorwand dienten
- Zudem wird angemerkt, dass nicht einmal die Gelegenheit genutzt wurde, eine moderne XSLT-Implementierung in einer sichereren Sprache einzuführen
- Das von Google vorgeschlagene JavaScript-Polyfill wird ohne Browser-Integration nur als externer Aufruf bereitgestellt und daher als nicht standardisierte und ineffiziente Ersatzlösung bewertet
- Der Text behauptet, diese Maßnahme sei ein bewusster Versuch, die Grundlage eines unabhängigen Webs auf Basis von RSS und XML zu schwächen
- Dass das Polyfill entweder nicht ausreiche oder trotz ausreichender Funktionalität nicht eingebaut werde, wird als Hinweis darauf gedeutet, dass die Nutzung von XSLT selbst unterdrückt werden soll
„Do. Not. Comply.“ — Aufruf zum Widerstand
- Der Autor betont, man solle weder Polyfills installieren noch XML anpassen, sondern die Wiederherstellung der XSLT-Unterstützung im Browser fordern
- Er will Standardtechnologien wie XSLT, MathML, SVG und SMIL weiter nutzen und Warnhinweise in Form von Infoboxen beibehalten, die Nutzer auf das nicht standardkonforme Verhalten von Browsern aufmerksam machen
- Googles Entscheidung wird nicht als technisch motiviert, sondern als Teil eines politisch-kommerziellen Vorhabens zur Kontrolle des offenen Webs dargestellt
- Auch Mozilla und Apple bewegten sich in eine ähnliche Richtung und würden Browser nicht mehr als User Agent, sondern als Werkzeuge des Überwachungskapitalismus gestalten
WHATWG und die Verzerrung von Webstandards
- Die WHATWG sei anfangs ein Gremium für das offene Web gewesen, habe sich inzwischen jedoch zu einer geschlossenen, von Großunternehmen dominierten Organisation gewandelt
- Sie verwandle das Web von einem Wissensspeicher in eine „Plattform zur Auslieferung von Anwendungen“ und priorisiere Gewinnmaximierung von Unternehmen vor der Kontrolle durch die Nutzer
- Browser fungierten nicht länger als Stellvertreter der Nutzer, sondern als Kontrollinstrumente im Interesse von Unternehmen
- Diese Entwicklung stehe in direktem Widerspruch zur offenen Web-Vision des W3C
Die Notwendigkeit eines neuen Browserkriegs
- Der heutige Browsermarkt sei durch eine von Google, Apple und Mozilla dominierte Abhängigkeit von wenigen Engines geprägt, mit kaum noch unabhängigen Alternativen
- Genannt werden alternative Browser wie Vivaldi, LibreWolf, WaterFox und Pale Moon, die aber meist von Blink oder Gecko abhängig seien
- Pale Moon wird als einer der wenigen Browser hervorgehoben, die RSS- und JPEG-XL-Unterstützung beibehalten
- Der Text fordert einen Krieg Nutzer gegen Unternehmen, also einen neuen Browserkrieg zur Rückeroberung der Kontrolle über das Web
Die Möglichkeit eines anderen Webs — Gemini und offene Protokolle
- Neben dem auf HTTP und HTML ausgerichteten Web gebe es auch neue Internet-Räume wie das Gemini-Protokoll
- Gemini sei ein leichtgewichtiges Protokoll mit einfacher Struktur sowie integrierten Sicherheits- und Authentifizierungsfunktionen und werde außerhalb von Googles Einflussbereich betrieben
- Das Problem liege jedoch nicht in der Technik, sondern in der gesellschaftlichen Struktur; die Technik selbst sei weiterhin tragfähig
- Browser sollten nicht nach Protokoll oder Format diskriminieren, und eine integrierte Unterstützung für leichtgewichtige Markup-Formate wie Markdown, AsciiDoc und Gemtext sei wünschenswert
Entfernung von Plugins und stärkere Kontrolle über das Web
- Die frühere NPAPI-Plugin-Schnittstelle unterstützte verschiedene Formate und Protokolle, wurde von Google jedoch ab 2013 schrittweise entfernt
- Dadurch sei der Weg für Web-Erweiterbarkeit und experimentelle Technologien blockiert worden
- Die nach dem Ende der Plugins eingeführten Encrypted Media Extensions (EME) hätten DRM standardisiert und damit laut Kritik die offenen Prinzipien des W3C beschädigt
- Browser-Erweiterungen seien unter dem Vorwand von Sicherheit nur ein funktional eingeschränkter Ersatz, und insbesondere Manifest V3 schwäche die Möglichkeiten zur Werbeblockierung
- Diese Veränderungen hätten zu weniger Nutzerkontrolle und stärkerer Unternehmenskontrolle geführt
„A mesh of building blocks“ — eine ideale Web-Struktur
- Ein ideales Web sollte eine pluginbasierte modulare Struktur haben, in der sich neue Protokolle, Formate und Skriptsprachen frei ergänzen lassen
- In einer solchen Struktur hätten sich RSS, SMIL, XSLT, XQuery und XHTML2 dauerhaft weiterentwickeln können
- Tatsächlich habe sich das Web jedoch zu einer Struktur gewandelt, in der Google die Richtung seiner Weiterentwicklung faktisch allein bestimmt, weshalb von Nutzern getragener Widerstand nötig sei, um das zu ändern
Resist — Erklärung des Widerstands
- Unter dem Motto „Do not comply. Resist.“ wird zu folgenden Handlungen aufgerufen
- RSS weiter verwenden
- XSLT weiterhin einsetzen
- JPEG XL als Standard-Bildformat übernehmen
- Nicht standardkonformes Verhalten von Browsern als „Browserfehler“ statt als „Seitenfehler“ betrachten
- Das wird nicht als bloße technische Entscheidung, sondern als praktischer Widerstand zum Schutz des offenen Webs dargestellt
Post Scriptum und Reaktionen
- Als XSLT-bezogene Projekte werden xslt.rip und die persönliche Website des Autors vorgestellt; erwähnt wird zudem ein Versuch, mit XSLT SVG zu erzeugen
- Auf Hacker News und Lobste.rs wurde weiter darüber diskutiert, doch laut dem Autor hätten viele Kommentare die Bedeutung von XSLT unterschätzt
- Der Autor betont, XSLT sei effizienter als Server-Rendering, besonders in kleinen, selbst gehosteten Umgebungen
- Abschließend bekräftigt der Text, dass die fortgesetzte Nutzung offener Technologien wie XSLT eine Schlüsselstrategie für das Überleben des offenen Webs sei
3 Kommentare
Man fragt zwar, warum es nicht integriert wird, aber umgekehrt scheint es auch keinen zwingenden Grund zu geben, es unbedingt integrieren zu müssen..
Hacker-News-Meinungen
Die Entfernung von XSLT aus Browsern war schon lange nötig.
Als ehemaliger Maintainer von libxslt kenne ich den Hintergrund dieser Entscheidung einigermaßen.
Noch interessanter ist, dass Chromium auf einen XML-Parser auf Rust-Basis umstellen will.
Derzeit wird xml-rs bevorzugt, das jedoch nur einen Teil von XML implementiert.
Es sieht also so aus, als wolle Google XML-Unterstützung wählen, die Standards nicht vollständig einhält.
Das erinnert an die Zeit von Internet Explorer 5.1, als man mit Marktanteilen Standards missachtete.
Seit XHTML von HTML5 verdrängt wurde, verschwindet komplexer XML-bezogener Code ganz natürlich.
Die Migration nach Rust, um die Angriffsfläche für Sicherheitsprobleme zu verringern, ist eine vernünftige Entscheidung.
Verbleibendes XML-Parsing lässt sich in JS per Polyfill oder wasm ersetzen.
Ich arbeite im Chrome-Team, bin an dieser Arbeit aber nicht direkt beteiligt.
Früher standen die Betreiber von Websites im Mittelpunkt, und Browser waren ihre Werkzeuge (Diener).
Die heutige Richtung entfernt sich von dieser Philosophie.
XML erlaubt Datenexplosions-Schwachstellen wie die Billion-Laughs-Attacke.
Erklärung dazu
Die Behauptung, XSLT sei unverzichtbar, um RSS-Feeds im Browser anzuzeigen, ist übertrieben.
Mit JavaScript ist das ebenfalls gut möglich, und Googles Polyfill funktioniert genau so.
Ich habe selbst Tausende Zeilen XSLT geschrieben, halte JavaScript aber für deutlich besser.
XSLT sollte aus Sicherheitsgründen jetzt entfernt werden.
Der dazugehörige Vortrag wurde auf OffensiveCon 2025 behandelt.
Vergleichbare Funktionen in JS sind komplex und die Einstiegshürde ist hoch.
Wenn einfache persönliche Webseiten schwerer zu erstellen werden, wird der Geist des „offenen Webs“ geschwächt.
Das Verschwinden von RSS und die Abhängigkeit von Plattformen wie Facebook sind ein Ergebnis davon.
Siehe Web-Components-Dokumentation.
Ich erinnere mich daran, wie unabhängige Browser verschwanden, weil sie mit dem sich schnell entwickelnden JS-Ökosystem nicht Schritt halten konnten.
Ich vermisse das frühere Konqueror.
document().Danach erschien mir die Entfernung von XSLT gerechtfertigt.
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;unterstützen.
Mit der aktuellen Implementierung ist es jedoch schwer, das XSLT-Niveau der Nutzungserfahrung mit JS vollständig zu ersetzen.
Ich stimme zu, dass Google das offene Web kaputtmacht, aber XSLT ist dafür ein schwaches Argument.
Es ist eine komplexe Funktion, die kaum genutzt wird, daher wirkt die Entscheidung wie der Versuch, Wartungsressourcen zu sparen.
Für die Anzeige von RSS-/Atom-Feeds wäre es besser, direkte Unterstützung im Browser einzubauen.
Man sollte nicht nur nach Nutzungshäufigkeit urteilen.
Man müsste mit wichtigen Nutzern zusammenarbeiten und die Funktion schrittweise auslaufen lassen.
Das „offene Web“ und XSLT haben nicht viel miteinander zu tun.
Das offene Web bedeutet ein Umfeld, in dem jeder einen Server betreiben, Websites erstellen und Browser entwickeln kann.
XSLT ist schon lange eine tote Technologie, und es gibt kaum Websites, die durch die Entfernung kaputtgehen.
Stattdessen werden Sicherheitslücken beseitigt.
Nicht XSLT selbst, sondern die libxslt-Implementierung hatte Schwachstellen.
Man hätte auch eine alternative Implementierung bauen können, aber Google hat sich dafür entschieden, die Funktion „sterben zu lassen“, und das ist das Problem.
Allerdings bevorzugen die Menschen heute eher konsum über soziale Feeds als das Abonnieren einzelner Websites.
Das ist kein technisches Problem, sondern eine Veränderung im Nutzerverhalten.
Ich habe kaum jemanden gesehen, der sich über die Abschaffung von XSLT beschwert und gleichzeitig klar erklärt, warum er es tatsächlich nutzt.
Meist wird es nur als Symbol des Widerstands erwähnt.
Über mehr als 20 Jahre gab es die Erwartung, dass „Webseiten für immer sichtbar bleiben“.
Nachdem der Maintainer von libxslt wegen der Last der Sicherheitsmeldungen zurücktrat,
entschieden sich die Browserhersteller eher für das Entfernen der Funktion, als die Kosten zu tragen.
Es als Symbol der Rebellion zu verwenden, ist im Grunde Selbstquälerei.
Falls nötig, lässt es sich gut durch ein Polyfill oder serverseitige Transformation ersetzen.
Ich habe es genutzt, um RSS-/Atom-Feeds lesbarer darzustellen.
Den Unterschied kann man auf meiner Website rss.style sehen.
Dass Mozilla RSS entfernt hat, lag nicht an Druck von Google,
sondern daran, dass die Nutzer RSS nicht wollten.
Google ist im Gegenteil eines der Unternehmen, die am meisten in die Weiterentwicklung des offenen Webs investiert haben.
Dass WHATWG das Web zu einer Applikationsplattform macht, ist das Ergebnis von Entwickler- und Nutzernachfrage.
Blink ist Open Source, daher kann man auch einen Fork pflegen.
RSS war für die breite Masse zu technisch, und nachdem Google den Reader eingestellt hatte,
nahmen soziale Medien diesen Platz ein.
stärkte am Ende aber eine monopolartige Struktur.
Dass Blink Open Source ist, garantiert noch keine echte Offenheit.
muss man sie nicht unbedingt entfernen, solange ihre bloße Existenz keinen Schaden verursacht.
Ich kann die Argumentation des Autors teilweise nachvollziehen,
aber die Forderung, Browser müssten sogar Gopher unterstützen, ist übertriebene Komplexität.
Aus Sicht des Chrome-Projekts wirkt es wie eine Entscheidung zur Vereinfachung.
Die Entfernung ist vernünftig, und die meisten Menschen in der Webbranche würden zustimmen.
XML-Parsing auf C-Basis löst immer Sicherheitsängste aus.
sondern sie in Form einer Erweiterung (extension) auszulagern.
dann aber alte Funktionen mit dem Argument der Vereinfachung entfernt, ist widersprüchlich.
In jedem Fall wird irgendjemand dadurch benachteiligt.
Ich überlege, meinen Blog auf XML/XSLT umzustellen.
Niemand liest ihn ohnehin, also kann ich jetzt Chrome die schwachen Zugriffszahlen in die Schuhe schieben.
Ich bin kein Google-Fan, aber die Entfernung von XSLT ist eine Chance, die Komplexität der Web-APIs zu verringern.
Für unabhängige Browser wie Ladybird könnte das die Last senken.
Im Ergebnis könnte es sogar Googles Monopolmacht schwächen.
daher kann man kaum sagen, dass es „ohne großen Widerstand“ geschieht.
In den letzten 10 bis 15 Jahren gingen Webstandards oft in die Richtung, bestimmte Nischenanforderungen in Browser einzubauen.
Die Entfernung von XSLT und die Bereitstellung eines Polyfills wirken wie ein Schritt, Komplexität aus dem Browser herauszuverlagern.
Es ist schon erfrischend, einen Beitrag zu lesen, der fordert, dass XSLT auch 2025 noch unterstützt werden sollte ... Zwar wird es tatsächlich gelegentlich für das Styling etwa von RSS verwendet, aber ob man sagen kann, dass es allgemein weit verbreitet im Einsatz ist, ist eher fraglich.