uMatrixの再構築：Manifest V3で粒度の高いリクエスト制御を実現する

Tavis Ormandy は、廃止された uMatrix 拡張機能の機能を Chrome の Manifest V3 と Content Security Policy を用いて再構築する方法を探ります。

uMatrixの再構築：Manifest V3で粒度の高いリクエスト制御を実現する

パワーユーザーやプライバシー愛好家にとって、廃止された uMatrix 拡張機能は単なるツール以上のもので、ブラウザの指令センターでした。uBlock Origin の開発者である Raymond Hill によって作られた uMatrix は、サイトの権限とサブリソースリクエストを制御する直感的なマトリックス形式のインターフェースを提供しました。ユーザーはサードパーティが提供できるもの—スクリプト、フレーム、フォント、動画—を正確に制限でき、手間のかかる手動プロセスを管理しやすいワークフローに変換しました。

uBlock Origin (uBO) がこれらの機能の多くを取り込んだものの、Chrome の Manifest V3 (MV3) への移行によりギャップが生じました。MV3 に準拠した後継である uBO Lite には、uMatrix が不可欠とした粒度の高い制御が欠けています。このため、Tavis Ormandy は新しい拡張機構の制約下で uMatrix に似た体験が実現可能かどうかを調査しています。

技術的課題：MV2 と MV3

uMatrix を再現する上での主な障壁は、Manifest V2 から Manifest V3 への移行です。MV2 では、拡張機能は「ブロッキング」ウェブリクエストを使用し、JavaScript コールバックを実行してリアルタイムでリクエストを許可するかブロックするかを判断できました。

MV3 はこの機能を削除します。その代わり、拡張機能は declarativeNetRequest API を使用しなければなりません。つまり、拡張機能は各リクエストごとにロジックを実行できず、事前にルールのセットを宣言し、ブラウザがそれを実行します。批評家はこれが広告ブロッカーやプライバシーツールの機能を「弱体化」させると主張しますが、Ormandy は uMatrix の代替としての特定のユースケースでは、これらのルールは実用的に柔軟であると示唆しています。

matrix³ の提案アーキテクチャ

uMatrix の粒度の高い制御を取り戻すために、Ormandy はブラウザの新たな制限と戦うのではなく、既存のウェブ標準を活用する設計を提案しています。戦略は主に二つのコンポーネントから構成されます。

1. Content Security Policy (CSP) の活用

declarativeNetRequest ルールであらゆるリクエストを管理しようとするのではなく、提案された解決策は API を使用してカスタムの Content-Security-Policy (CSP) ヘッダーを注入することです。CSP は、どのリソースをどこから読み込むかを制御するために設計されたブラウザ固有のメカニズムです。実際のブロック処理をブラウザの CSP エンジンに委ねることで、拡張機能は単にこれらのポリシーを管理するインターフェースとなります。

2. report-to による自動検出

uMatrix の最も優れた機能の一つは、サイトが読み込もうとしているサブリソースを正確にユーザーに示し、リアルタイムで許可または拒否できる点でした。MV3 でこれを再現するために、Ormandy は CSP の report-to ディレクティブを使用することを提案しています。

CSP 違反が発生すると、ブラウザは特定のエンドポイントへレポートを送信するよう指示できます。declarativeNetRequest を使用してこれらのレポートをインターセプトすることで、拡張機能はリアルタイムでブロックされたリソースのリストを作成できます。これによりフィードバックループが形成されます：ブラウザがリクエストをブロックし、違反をレポートし、拡張機能がその違反をユーザーに提示して「許可」ルールの作成を促す、という流れです。

現状：matrix³

この概念的枠組みは、matrix³ と呼ばれる概念実証につながっています。現在は最小限の UX でプロトタイプ段階ですが、"block → report → user decision → allow" のコアループが Manifest V3 の下で実現可能であることを示しています。

コミュニティの視点と代替案

このプロジェクトを巡る議論は、ブラウザエコシステムにおける深い緊張を浮き彫りにしています。多くのユーザーは、こうした回避策が必要になるのは、Google が広告ブロッカーの効果を制限するために MV3 へと推し進めていることが直接の原因だと主張しています。

代替パス

機能性を妥協したくないユーザー向けに、複数のコミュニティメンバーが代替案を提示しています。

• Firefox: Firefox は Chrome と同様の制限的な MV3 アプローチを採用していないため、uBlock Origin はそこで完全に機能します。他のユーザーは Firefox ユーザー向けのモダンな代替として nuMatrix を提案しました。
• Brave: 一部のユーザーは、Brave が uMatrix に似た機能のサポートを明言したことに言及しました。
• Chrome Flags: Chrome にこだわるユーザー向けに、コマンドラインフラグ（例：--disable-features=ExtensionManifestV2Unsupported）を使用して一時的に MV2 拡張機能を維持する方法が提案されましたが、これは脆弱な解決策です。

「ユーザーエージェント」哲学

技術的実装を超えて、会話はブラウザを「ユーザーエージェント」として捉える哲学に及びました。批評家は、現代のブラウザにおけるネイティブな粒度の高いリクエスト制御の欠如をシステム的な失敗と指摘しています。あるコメント者は次のように述べています。

uMatrix のようなものはブラウザに組み込まれるべきです… それは絶対に必要な唯一の拡張機能です… ボタン一つでほとんどのサイトが読み込もうとする無駄なものを確認できるのは、本当に目を開かせられます。