分析広告やコンテンツブロッカーに影響を与える、Chrome の拡張機能システムの Google による物議を醸す改訂版である Manifest v3 の初期バージョンは、約 1 か月以内に登場する予定です。
アドオン開発者らは、インターネット広告大手がパフォーマンス、プライバシー、セキュリティを理由に拡張機能から過剰なユーティリティを削除するのではないかと懸念し続けている。
「Manifest V3はまだ実験やフィードバックを受け付ける準備ができていません」と、開発者アドボケイトのSimeon Vincent氏は木曜日のGoogleグループのディスカッションスレッドで述べた。「拡張機能チームは現在、7月末か8月初旬にCanaryチャンネルで開発者プレビュー版をリリースすることを目指して作業を進めています。リリース次第、詳細をお知らせします。」
彼はさらに、意欲的な開発者はChromiumソースコードリポジトリのマスターブランチを手動でビルドすることで、中途半端なバージョンを試すこともできると付け加えた。しかし、そうすることはガイダンスやサポートを放棄し、何が起こっているのかを理解するまでにソースを一行ずつ読み解くことになる。
ヴィンセント氏は、先週のGoogleによる小規模なPR攻撃を受けて開発者から提起された一連の懸念に応えた。同氏は、昨年10月以降Chrome拡張機能プラットフォーム向けに計画されているAPI改訂によって、コンテンツブロッカー、プライバシー拡張機能、その他のブラウザアドオンツールの機能が低下したり、性能が低下したりするのではないかという懸念を払拭しようと試みた。
論争の中心は、APIのブロッキング（同期）バージョンが削除される予定である点ですwebRequest。このバージョンは、ブラウザに表示される前にネットワークトラフィックを傍受、改ざん、または遮断することができ、コンテンツブロッキングやプライバシー保護アプリケーションにとって重要な介入手段となります。例えば、広告ブロッカーは、不要な広告やトラッカースクリプトの表示リクエストを検出し、停止するためにこのバージョンを使用しています。
しかし、現在進行中のプロジェクトである Manifest v3 に取り組んでいる Google 社員たちは、Chrome 拡張機能の能力と範囲に影響を与える他の多くの変更も検討している。
例えば、 の代替として計画されている ではwebRequest、declarativeNetRequestリクエストトラフィックの検出と対処に、一定数のパターンマッチングルールを使用できます。拡張機能は、各アドオンがトラフィックを傍受してブロックするのを信頼するのではなく、新しいインターフェースを使用して、Chrome がトラフィックを識別して対処するためのルールを提供することが期待されています。
現在、プリセットルールの制限は静的ルールが 30,000 個、動的ルールが 5,000 個ですが、動的ルールはコンテンツのブロックに非常に役立ちます。
先週、ヴィンセント氏は「現在、拡張機能ごとのルール数制限を最大3万ルールから、グローバルで最大15万ルールに変更する予定です」と述べました。しかし、木曜日の投稿で彼が確認したように、「Chromeでは、すべての拡張機能で共有されるルールのグローバル最大数は15万ルールになります」。
多いように聞こえるかもしれませんが、HTTPS Everywhereの開発者であるウィリアム・バディントン氏が指摘したように、HTTPS Everywhereは15万7千以上の対象サイトを認識しています。Googleの共有モデルでは、多くのルールを持つ拡張機能を1つ使用すると、他のルールを多用する拡張機能が使用できなくなります。
ヴィンセント氏は、この制限はおそらく最終的なものではないと述べて、バディントン氏を安心させようとした。「ルールセットのサイズを変えた場合の実際のパフォーマンスコストをまだ分析中です」と彼は述べたが、動的なルールが固定ルールよりもはるかに有用であるという事実には触れなかった。
パフォーマンスは問題ではない
Googleのエンジニアが変更の理由として挙げた3つの理由のうち、パフォーマンスは最も説得力に欠けるものでした。Vincent氏は、Chrome拡張機能の全体的なパフォーマンスへの影響は「JavaScriptの実行時間が無視できるほど、可能な限りパフォーマンスを重視して作成された拡張機能であっても、非常に大きくなる可能性がある」と主張しています。
Google Chromeのセキュリティエンジニアであるクリス・パーマー氏も、ディスカッションスレッドで同様の主張を繰り返し、「パフォーマンスに関する懸念は現実のもの」だと主張した。パーマー氏は、永続的なブラウザやネットワークサービスプロセスに多数のルールを保存することによるリソースコストと、同期呼び出しの解決を待つことで発生する遅延を指摘した。
確かに、適切にコーディングされていない拡張機能によって処理が滞り、ユーザー エクスペリエンスが低下する可能性は考えられますが、拡張機能の開発者は、そのような遅延が避けられないことに対して依然として懐疑的です。
今週、拡張機能による速度低下を測定するオープンソースツール「Exthouse」がリリースされたことで、こうした懐疑的な見方はさらに強まった。ExthouseはAdblock Plusがパフォーマンスに影響を与えると指摘しているものの、uBlock Originは「インタラクティブになるまでの時間」と「初回入力遅延」という2つのインタラクション指標において全く遅延を生じさせていないことも示している。これは、コンテンツブロッカーの開発者が、拡張機能はウェブページ上の広告トラッキングコードを排除することでパフォーマンスを向上させると主張していることを裏付けるものだ。
ヴィンセント氏は、GoogleのManifest v3に関する公式ブログ投稿ではパフォーマンス問題についてあまり触れられていないことを認め、近いうちに詳細を明らかにしたいと述べた。問題はブロッキング（同期）webRequestコールバックの実行時間ではなく、Chromeでリクエストを処理する際の全体的なコストにあると彼は述べた。
「のブロッキングバージョンではwebRequest、Chromeは大量のデータ（リクエスト自体やリクエストのメタデータなど）をシリアル化し、各拡張機能に送信する必要があります」と彼は述べた。「その結果、（通常は別プロセスで実行される）各リスニング拡張機能ごとに、型変換、コピー、プロセス間通信、シリアル化（デシリアル化）などの処理に多大なコストがかかります。」
同時に、ヴィンセント氏はパフォーマンスがManifest v3の主な目的ではないことを認めた。むしろ、Googleの主な関心事は「リクエスト変更のプライバシーとセキュリティを向上させ、悪意のある拡張機能の攻撃対象領域を縮小すること」だ。率直に言って、Google社員は、悪質な拡張機能がユーザーのネットワークトラフィックを操作したり盗聴したりするという考えに、本当に抵抗を感じている。
熱心なGoogle社員たちがChromeに広告ブロッカーを壊すような変更を加えるのはなぜか？それは彼らがモンスターを生み出し、それを守るために奮闘しているからだ。
続きを読む
したがって、プライバシーの向上という点では、Google の取り組みはプライバシーオプションの改善に近いように思われます。webRequest開発者はブロッキングメソッドがなければリクエストを傍受することはできませんが、ネットワークリクエストを監視する許可を要求することは依然として可能なため、この問題によって生じるプライバシーの問題は解消されません。Palmer 氏が説明するように、プライバシー面での主なメリットは、開発者が「リクエストやページコンテンツを受動的に監視する権限を必ずしも得ることなく、Declarative Net Request を使用してコンテンツをブロックする拡張機能を作成できるようになる」ことです。
同氏の説明によると、拡張機能はホスト権限を必要とする追加の API を実装する可能性があるが、それらを付与するプロセスにはユーザーからのより明示的な権限が必要になるという。
そして最後に...
残るはセキュリティです。既にお伝えしたように、Chrome拡張機能のセキュリティには深刻な問題が存在します。しかし、これはAPIの大幅な変更以外にも、開発者の審査強化、拡張機能セキュリティ検査員の採用、Chromeウェブストアのポリシー適用の厳格化、セキュリティ監査など、様々な方法で対処できる可能性があります。
「拡張機能プラットフォームへのアプローチを再考する中で、私たちが目指す目標の一つは、拡張機能が現在行っていることをユーザーのプライバシーを侵害することなく実行できるようにすることです」とVincent氏は説明します。「大まかに言えば、declarativeNetRequest（DNR）APIは、拡張機能にリクエストオブジェクトを公開することなく、あるいは（可能な限り）拡張機能にリクエスト変更のためのホスト権限を要求せずにリクエストを変更できる手段を提供することで、この目標に合致しています。」
ヴィンセント氏は、理論上は、Manifest v3 で実装されたコンテンツ ブロッカーは、データ盗難のリスクなしに、Manifest v2 で実装されたものと同じ結果になる可能性があると主張しています。
しかし、投稿の次の行では、webRequest現状では不可欠であると認めています。webRequestそんなに危険なのに、なぜ企業ユーザー向けにブロッキング版を残しておくのでしょうか？
「まず、より安全なAPIでは再現できない重要な機能を拡張機能に提供できるからです」とVincent氏は言います。「次に、webRequestホスト権限の取得（および維持）の手間を増やすことで、関連するリスクを軽減できます。」
彼はさらに、できることdeclarativeNetRequest全てを行えるわけではないことを認めていますwebRequest。「Chromeチームの観点から言えば、今回の変更と他の変更を組み合わせることで、様々なエクスプロイトを完全に排除することができます」と彼は述べています。「（Declarative Net Requestは）完璧なトレードオフではありませんが、それによって得られるプライバシーの保証は、機能の喪失を上回ると強く信じています。とはいえ、私たちはコンテンツブロッカーとリクエストを変更する拡張機能を、過度のデータ漏洩や悪意のある行為者への支援なしに、可能な限り有効にしたいと考えています。」
つまり、ウェブ広告やコンテンツブロッカー、その他の Chrome 拡張機能の機能は、ユーザー保護のために制限されることになります。®
