ユーザーのセキュリティとプライバシーを向上させる取り組みの一環として、Chrome 拡張機能プラットフォームにたくさんの変更を加えることが予定されています。昨年の 10 月に
いくつかの変更点についてお知らせしたのに続き、本日はそれに関する
追加情報も提供しています。プラットフォームに対するこれらの変更点は、Chrome 拡張機能プラットフォームの次のバージョンである Manifest V3 の一部として実装されています。
その変更点の 1 つが、ブロッキング版の
Web Request API から、
Declarative Net Request と呼ばれる新しい API への移行です。この変更については、意図と実装の両面でさまざまな混乱や誤解が生じています。その中には、今回の変更が広告ブロッカーを妨げたり、弱体化させたりするために設計されたものだという憶測があります。これは、本来の目的とはまったく違います。実際には、今回の変更はデベロッパーが安全でパフォーマンスのよい広告ブロッカーを作成できるようにするためのものです。
拡張機能プラットフォームでセキュリティやプライバシーを保証するために、拡張機能プラットフォームのコア API の一部を再考しています。ブロッキング版の Web Request API を Declarative Net Request API で置き換えようとしているのはそのためです。
Web Request の仕組み
Web Request を使うと、Chrome はネットワーク リクエストに含まれるすべてのデータを、監視している拡張機能に送ります。これには、個人の写真やメールなど、リクエストに含まれるすべてのプライベートなデータが含まれます。拡張機能はリクエストを評価でき、そのリクエストをどのように処理するか（許可、ブロック、いくつかの変更を加えて送信）を Chrome に伝えます。そのため、Web Request API を使う拡張機能は、ウェブでユーザーが行うあらゆることにアクセスし、それを読み取ったり変更したりできるのが一般的です。
善良なデベロッパーは、この API を使ってコンテンツ ブロッカーなどの強力な機能を実装しています。しかし、これは悪用される可能性もあり、実際に悪用もされています。すべてのリクエスト データが拡張機能に渡るので、悪意のあるデベロッパーは、いとも簡単にユーザーの認証情報やアカウント、個人情報へのアクセスを悪用できます。2018 年 1 月以降、悪意のある拡張機能の 42% が Web Request API を使っています。
以上のような安全性の懸念に加え、パフォーマンスにも重大なコストが発生します。ほとんどの場合、このコストは拡張機能のスクリプト処理イベントを評価する部分ではなく、スクリプトを管理する他の部分によるものです。全体的なパフォーマンスへの影響は非常に大きくなる場合があります。これは、JavaScript の実行時間が無視できるほどパフォーマンスよく書かれた拡張機能でも変わりません。
現在の設計では、ブロッキング版の Web Request API には、長時間にわたって実行される常駐プロセスが必要で、遅延処理に対応したプロセス（貴重なシステム リソースを節約できるよう、必要に応じて準備、分割されるもの）とは根本的に互換性がありません。また、リクエスト データのシリアル化、そのデータを拡張機能に送信するために必要なプロセス間通信、拡張機能からの応答の処理にかかるコストも重大です。
Declarative Net Request の導入
Declarative Net Request API は、Web Request API とは異なる仕組みで動作します。Chrome は、リクエスト時にすべてのリクエストに関する情報を、監視している拡張機能に送ることはしません。その代わり拡張機能は、あるタイプのリクエストが発生したとき何をするかを Chrome に伝えるルールを登録します。
このアプローチは、ユーザーのセキュリティやプライバシーの面だけでなく、パフォーマンスの面でも優れています。宣言的なアプローチでは、Chrome はプライベートなデータを拡張機能に渡す必要はありません。拡張機能が既にアクションを実行する条件を指定しているので、ブラウザはネットワーク リクエストに関連するすべてのデータを送ることなく、拡張機能がリクエストしたアクションを実行できます。そのため、拡張機能はユーザーのすべての個人情報にアクセスせずに、コンテンツをブロックできるようになります。
これは、パフォーマンスに大きく関係します。最も重要な点は、実行時に処理を行う必要はなく、リクエストが行われる前にルールが登録されているので 、長時間にわたって実行される常駐プロセスが必要なくなることです。すべてのリクエストをシリアル化するコストや、監視している拡張機能との間でプロセス間メッセージが往復するコストも不要になります。以上のようなパフォーマンスの改善によって、リソースに制約があるプラットフォームでも拡張機能が広く利用できるようになります。
なぜ両方とも使えるようにはしないのですか？
前述のようなパフォーマンスの懸念もさることながら、拡張機能がその機能を実行するためにアクセスする必要がないなら、メールや写真、ソーシャル メディアなどのプライベートなデータを拡張機能に見せる必要はないはずだというのが Chrome チームの考えです。これまでも、機能かセキュリティかという選択を迫られた拡張機能のデベロッパーの大半が、機能を選んでいます。イベントページ、オプションのパーミッション、activeTab がある拡張機能プラットフォームでは、これが繰り返し目撃されています。
エンタープライズ
企業や学校では、組織のポリシーに準拠するために、別のネットワークやソフトウェア制御が必要になることもよくあります。さらに、こういった組織には、環境を理解して設定する役割をもつ管理者がいるのが一般的です。
Chrome は、
管理者ポリシーによるエンタープライズ コントロールを提供しています。企業はソフトウェア スイートと Chrome を密接に統合している可能性があるため、マネージドな拡張機能では引き続きブロッキング版の Web Request API を利用できます。エンタープライズ環境では、システム管理者は OS が提供する仕組みを使って Chrome の
ポリシーをデプロイすることで、引き続き無料で Chrome を管理できます。
さらなる進化
Declarative Net Request と Manifest V3 の全体は、依然として多くの部分がまだ設計、開発の段階です。コミュニティからのフィードバックに基づいて今後も改善を繰り返し、デベロッパーの皆さんとともにさまざまなユースケースをサポートする取り組みを続けています。
Declarative Net Request API が最初に発表されて以降、このような検討の結果として API に重要な機能を追加しました。現在の Declarative Net Request API では、動的なルールの登録や削除が可能になっています。つまり、マニフェストに静的に登録するのではなく、実行時に指定することができます。また、Referer、Cookie、Set-Cookie などの一般的なトラッキング ヘッダーを削除する機能も追加しています。
私たちは、この API を拡張するその他の方法も積極的に検討しています。たとえば、一致したルールについてフィードバックを得る方法を追加することや、URL 操作と正規表現を活用した高度なリダイレクトをサポートすることなどです。さらに、現在、ルールの制限を拡張機能 1 つあたり最大 3 万個から、全体で最大 15 万個に変更することも計画しています。
今後も私たちは、さらに進化するデベロッパー コミュニティとの連携を続けます。Manifest V3 を採用するためには、デベロッパーの皆さんに拡張機能をアップデートしていただく必要があることは承知しています。引き続き、この移行をサポートする取り組みを続けてまいります。
Reviewed by
Eiji Kitamura - Developer Relations Team
