- ChromeでのXSLTサポート終了は、グーグルがオープンウェブの中核技術を弱体化させる措置であり、セキュリティ問題を理由に挙げながらも、代替技術を提供せずに機能を削除した
- グーグルはブラウザ内の標準機能の代わりにJavaScriptベースのポリフィル(polyfill) を提案したが、これをブラウザに組み込まず、実装の負担を開発者に転嫁した
- こうした決定はRSS・XMLベースの独立したウェブ生態系の弱体化につながり、MozillaやAppleも同様の方向に進んでいる
- 記事は、WHATWGがもはやオープンウェブの守護者としての役割を果たせず、大企業の利益を中心にウェブ標準を統制していると批判する
- ブラウザ拡張性の縮小やDRM標準化によって、ユーザーの統制権が弱められたウェブ構造が固定化しつつあり、これに対抗してRSS・XSLT・JPEG XLなどの開放技術の継続利用と抵抗を呼びかけている
XSLTサポート終了とグーグルの動き
- グーグルはChromeでXSLTサポートを廃止し、セキュリティ脆弱性を理由に挙げたが、代替ライブラリや改善策は提示しなかった
- 既存のFLOSSライブラリのセキュリティ問題を口実にしたのだと批判している
- より安全な言語で書かれた最新のXSLT実装を導入する機会すら活用しなかったと指摘している
- グーグルが提示したJavaScriptポリフィルは、ブラウザ内蔵ではなく外部呼び出し方式でしか提供されず、非標準的で非効率な代替手段と評価されている
- 記事は、この措置がRSSとXMLベースの独立ウェブの基盤を弱めようとする意図的な行為だと主張する
- ポリフィルが不十分であるか、十分であったとしてもグーグルがそれを内蔵しない理由は、XSLTの利用そのものを抑制することにあると分析している
「Do. Not. Comply.」— 抵抗の呼びかけ
- 筆者は、ポリフィルの導入やXMLの修正に応じるのではなく、ブラウザでのXSLTサポートの復元を求めるべきだと強調する
- XSLT、MathML、SVG、SMILなどの標準技術を引き続き使い、ブラウザの非標準的な挙動をユーザーに知らせる警告ボックス(infobox) を維持する計画だという
- グーグルの決定は技術的理由ではなく、政治的・商業的動機によるもので、オープンウェブを統制しようとする試みの一環だと説明される
- MozillaやAppleも同様の方向に進み、ブラウザをユーザーエージェント(User Agent) ではなく、監視資本主義の道具として設計していると批判している
WHATWGとウェブ標準の歪み
- WHATWGは当初、オープンウェブのための協議体だったが、現在では大企業中心の閉鎖的組織へと変質したと評価されている
- この団体はウェブを知識の保管庫ではなく「アプリケーション配布プラットフォーム」へと変えつつあり、ユーザーの統制権よりも企業の収益最大化を優先している
- ブラウザはもはやユーザーの代理人(User Agent)ではなく、企業の利益のための統制ツールとして機能している
- こうした変化は、W3Cが目指した開かれたウェブのビジョンと真っ向から衝突すると指摘している
新たなブラウザ戦争の必要性
- 現在のブラウザ市場はGoogle・Apple・Mozillaを中心としたエンジン依存構造で、独立した代替はほとんどない
- Vivaldi、LibreWolf、WaterFox、Pale Moonなどの代替ブラウザが言及されるが、その大半はBlinkやGeckoエンジンに依存している
- Pale MoonはRSSとJPEG XLサポートを維持している数少ないブラウザとして評価されている
- 記事は、ユーザー対企業の戦争、すなわちウェブの統制権を取り戻すための新たなブラウザ戦争が必要だと主張する
もうひとつのウェブの可能性 — Geminiと開放プロトコル
- HTTP・HTML中心のウェブ以外にも、Geminiプロトコルなどの新しいインターネット空間が存在する
- Geminiはシンプルな構造とセキュリティ・認証の組み込み機能を備えた軽量プロトコルで、グーグルの影響圏の外で運用されている
- しかし問題は技術ではなく社会的構造であり、技術そのものは依然として有効だと強調している
- ブラウザはプロトコルやフォーマットによって差別してはならず、Markdown・AsciiDoc・Gemtextのような軽量マークアップフォーマットの統合サポートが望ましいとしている
プラグイン削除とウェブ統制の強化
- かつてのNPAPIプラグインインターフェースは多様なフォーマットやプロトコルをサポートしていたが、グーグルは2013年から段階的に削除した
- その結果、ウェブの拡張性と実験的技術の導入経路が遮断された
- プラグイン削除後に登場したEncrypted Media Extensions(EME) はDRMを標準化し、W3Cの開放原則を損なったと批判されている
- ブラウザ拡張はセキュリティを名目にした機能制限付きの代替物であり、とりわけManifest V3は広告ブロック機能を弱体化させる
- こうした変化は、ユーザーの制御権の縮小と企業統制の強化につながったと分析している
「A mesh of building blocks」— 理想的なウェブ構造
- 理想的なウェブはプラグインベースのモジュール構造であり、新しいプロトコル・フォーマット・スクリプト言語を自由に追加できるべきだ
- もしそうした構造であれば、RSS・SMIL・XSLT・XQuery・XHTML2 などは継続的に発展していたはずだと述べている
- しかし現実には、Googleがウェブの進化の方向を独占的に決定する構造へと変わっており、これを取り戻すためにはユーザー主導の抵抗が必要だと結論づける
Resist — 抵抗の宣言
- 「Do not comply. Resist. 」というスローガンのもと、次のような行動を呼びかけている
- RSSの利用を維持する
- XSLTを使い続ける
- JPEG XLを標準画像フォーマットとして採用する
- ブラウザの非標準的な動作を「サイトの不具合」ではなく「ブラウザの欠陥」とみなす
- これは単なる技術選択ではなく、オープンウェブを守るための実践的な抵抗として提示されている
Post Scriptum と反応
- XSLT関連プロジェクトとしてxslt.ripと筆者の個人サイトを紹介し、XSLTでSVGを生成する試みについて言及している
- Hacker NewsやLobste.rsなどで議論が続いたが、多くのコメントはXSLTの重要性を過小評価していたと指摘している
- 筆者は、XSLTはサーバーレンダリングより効率的であり、とくに小規模・セルフホスティング環境で有利だと強調している
- 結論として、XSLTのような開放技術を継続して使うことが、オープンウェブの生存に向けた中核戦略であることを改めて確認している
3件のコメント
なぜ組み込まないのかと言われるけど、逆にあえて組み込まなければならない理由もなさそうだけど..
Hacker Newsの意見
ブラウザから XSLT を削除するのは、ずっと前から必要だったことだと思う
私は libxslt の元メンテナーとして、この決定の背景になった事情をある程度知っている
さらに興味深いのは、Chromium が Rust ベースの XML パーサへ移行しようとしている計画だ
現在は xml-rs が有力視されているが、これは XML の一部しか実装していない
つまり、Google は標準を完全には満たさない XML サポートを選ぼうとしているように見える
昔の Internet Explorer 5.1 の時代のように、市場シェアを背景に標準を無視していた頃を思い出す
XHTML が HTML5 に押し負けて以降、XML 関連の複雑なコードは自然と消えつつある
Rust に移して セキュリティ上の攻撃面を減らすことは合理的な選択だ
残る XML パースは JS の polyfill や wasm で代替できる
私は Chrome チームで働いているが、この作業には直接関わっていない
昔の Web はサイト運営者が主体で、ブラウザは彼らの 道具（召使い） だった
今の方向性は、その哲学から離れつつある
XML は Billion Laughs 攻撃のようなデータ爆発型の脆弱性を許してしまうからだ
関連説明
RSS フィードをブラウザで表示するのに XSLT が必須だという主張は大げさだ
JavaScript でも十分可能で、Google の polyfill もそのように動作する
私は何千行もの XSLT を書いたことがあるが、JavaScript のほうがずっと良いと思う
XSLT は今やセキュリティ上の理由で削除されるべきだ
関連発表は OffensiveCon 2025 で扱われる
JS の代替手段は複雑で、参入障壁が高い
単純な個人 Web ページ作成が難しくなることで、『オープンな Web』の精神が弱まる
RSS が消え、Facebook のようなプラットフォームに依存する現象がその結果だ
Web Components ドキュメント 参照
独立系ブラウザが急速に進化する JS エコシステムについていけず消えていった記憶がある
昔の Konqueror が懐かしい
document()関数のセキュリティ問題が分かるこれを見て、XSLT 削除は妥当だと感じた
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;のような形式をサポートする必要がある
しかし現在の実装では、XSLT レベルの体験を JS で完全に置き換えるのは難しい
Google がオープンな Web を殺しているという主張には同意するが、XSLT は根拠として弱い
ほとんど使われていない複雑な機能で、メンテナンス資源を減らすための決定に見える
RSS/Atom フィード表示のためには、ブラウザに 直接サポート機能を入れるほうが良い
利用頻度だけで判断すべきではない
重要な利用者と協力して、段階的に廃止すべきだ
「オープンな Web」と XSLT にはあまり関係がない
オープンな Web とは、誰でもサーバーを運営し、サイトを作り、ブラウザを開発できる環境を意味する
XSLT はすでにずっと前に死んだ技術で、削除で壊れるサイトもほとんどない
むしろ セキュリティ脆弱性の除去という効果がある
脆弱性があったのは XSLT 自体ではなく libxslt 実装のほうだった
代替実装を作ることもできたのに、Google が機能を『殺す』ことを選んだのが問題だ
ただし人々は今や個別サイトの購読よりも ソーシャルフィード中心の消費を好む
これは技術の問題ではなく、ユーザー行動の変化だ
XSLT 廃止に不満を言う人の中で、実際の利用理由を明確に説明している例はほとんど見たことがない
多くは単なる 抵抗の象徴として言及している
20年以上にわたって「Web ページは永遠に見られる」という期待があったからだ
libxslt のメンテナーがセキュリティレポート対応の負担で辞任し、
ブラウザベンダーは費用を払うより 機能を削除するほうを選んだ
これを反抗の象徴として使うのは、自分で自分を苦しめるようなものだ
必要なら polyfill やサーバー側変換で十分代替できる
RSS/Atom フィードを見やすく変換するのに使っていた
私が作った rss.style サイトでその違いが見られる
Mozilla が RSS を削除したのは Google の圧力のせいではなく、
ユーザーが RSS を望まなかったからだ
Google はむしろ、オープンな Web の発展に最も多く投資してきた企業の一つだ
WHATWG が Web を アプリケーションプラットフォームへ変えようとしているのは、開発者とユーザーの需要の結果だ
Blink は オープンソースなので、fork を維持することも可能だ
RSS は一般大衆には技術的すぎて、Google が Reader を終了させたことで
ソーシャルメディアがその座を占めるようになった
結局は 独占構造を強化した
Blink がオープンソースであることだけでは、真の開放性は保証されない
存在自体で害がないなら、わざわざ削除する必要はない
筆者の主張には一部共感するが、
ブラウザが Gopher までサポートすべきだというのは 複雑性の過剰だ
Chrome プロジェクトの立場では、単純化のための決定に見える
削除は合理的で、Web 業界の大半も同意するだろう
C 言語ベースの XML パースは常に セキュリティ上の恐怖を感じさせる
拡張機能(extension) の形で分離するほうがよい
単純化を理由に古い機能を削除するのは 矛盾している
どちらにせよ誰かが不利益を被る
自分のブログを XML/XSLT に変えようと思う
どうせ誰も読まないので、これからは アクセス不振を Chrome のせいにできる
Google のファンではないが、XSLT 削除は Web API の複雑さを減らす好機だ
Ladybird のような独立系ブラウザにとっては負担軽減になるかもしれない
結果として Google の独占力を弱める可能性すらある
「大きな反発なく」進んでいるとは言いがたい
この10〜15年、Web 標準は特定の ニッチな要件をブラウザに取り込もうとする流れだった
XSLT 削除と polyfill 提供は、複雑さをブラウザの外へ押し出す方向に見える
2025年にXSLTをサポートすべきだという話は新鮮ですね……RSS などのスタイリングで一時的に使われるのは事実ですが、汎用的によく使われていると見るのは難しいのではないでしょうか