今後の Google Chrome 拡張機能のマニフェスト V3 では、Chrome での広告ブロッカーの動作方法が変更されます。 これは広告ブロッカーと Google にとって正しい道なのでしょうか?
グーグルクローム 現在市場で入手可能な最も人気のあるクロスプラットフォーム Web ブラウザーです。 世界のブラウザ使用シェアの 62.7% を占める 2019 年 5 月までは、Apple の Safari が 15.89% で 2 位、Mozilla の Firefox が 5.07% でした。 そのシェアが最も大きいため、Google Chrome がそのプラットフォームに対して行ったほんの小さな変更は、最終的に世界中の何百万ものユーザーに影響を与えることになります。 したがって、Google が次の拡張機能マニフェスト バージョンを Google Chrome 拡張機能のマニフェスト V3 の形式で発表したとき、私たちは次の拡張機能マニフェスト バージョンを発表したとき、 特に Google が Chrome 内にコンテンツ ブロッカー API を組み込んでいたことが明らかになったとき、いくつかの大きな変更が加えられました。 自体。
マニフェスト V3 とは何ですか?
アクティブな Chrome ユーザーであれば、間違いなくいくつかの拡張機能を使用しているでしょう。 拡張機能は、ブラウジング エクスペリエンスをカスタマイズする小さなソフトウェア プログラムです。 ブラウザが提供するAPIにより、ユーザーは個々のニーズや好みに合わせて機能や動作を調整できます。 これらの拡張機能は主に次の方法で配布されます。 Chrome ウェブストア、180,000 を超える拡張機能が存在します。
以来 昨年末, Googleは、「破壊的変更」として分類できるChrome拡張機能プラットフォームへの一連の変更案である「マニフェストV3」に取り組んでいる。 として マニフェスト V3 の公開ディスカッション文書 拡張機能のマニフェスト バージョンは、特定の機能を特定のクラスの拡張機能に制限するためのメカニズムです。 これらの制限は、最小バージョンまたは最大バージョンのいずれかの形式になります。 最小バージョンに制限すると、新しい API または機能を新しい拡張機能のみで使用できるようになります。 マニフェストの最大バージョンに制限すると、古い API や機能を段階的に使用できるようになります。 廃止されました。
簡単に言うと、新しいマニフェスト バージョンにより、Chrome は API と機能をこの新しいマニフェスト バージョンに制限できるようになります。 ユーザーに悪影響を与えるため、拡張機能開発者に特定の古い API からの移行を強制するため 経験。 Manifest V3 に拡張機能を実装すると、理論的には、セキュリティ、プライバシー、パフォーマンスの観点からより強力な保証が提供されるはずです。
Manifest V3 には広範囲にわたる変更が概説されていますが、最も物議を醸している変更は、既存のマニフェストに存在するブロック機能を制限するという Google の決定に関連しています。 chrome.webRequest API (ブロックではなく監視に API を集中させます) を使用して、新しいブロック機能を通じてこれらのブロック機能を提供します。 chrome.declarativeNetRequest API。 この特定の変更により、 コミュニティを煽った 最終的には有名な広告ブロック拡張機能の広告ブロックメカニズムをターゲットにすることになるため、 uBlock オリジン、1,000 万人以上のユーザーに直接影響を与えます。
この問題に対処する前に、 webリクエスト APIとの比較 宣言的なNetRequest API。
Web リクエスト API と宣言型ネット リクエスト API
現在
Web リクエストの公式説明では、API について次のように説明されています。
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Web リクエストを使用すると、Chrome は次のメッセージを送信します 全て ネットワークリクエスト内のデータを、それをリッスンしている拡張機能に送信します。 その後、拡張機能はリクエストを評価し、リクエストを許可するかブロックするか、何らかの変更を加えて送信するかなど、リクエストの処理方法を Chrome に指示します。
イベントのシーケンスに従って、拡張機能が Web リクエスト API を使用するときに何が起こっているかを理解してください。 Web Request 拡張機能がインストールされているユーザーがリンクをクリックすると、Chrome はリクエストがサーバーに到達する前にデータ リクエストが行われたことを拡張機能に通知します。 拡張機能は、この段階でリクエストを変更することを選択できます。 その後、サーバーは応答しますが、応答は再度拡張機能を経由し、拡張機能は応答を変更する必要があるかどうかを決定できます。 その後、Chrome は最終的にページをレンダリングし、ユーザーはクリック アクションの結果を表示できるようになります。
Chrome が引き継ぐとき ネットワークリクエスト内のすべてのデータ、Web Request API を使用する拡張機能は、ユーザーが Web 上で行うすべての操作を読み取り、変更するアクセス権を持ちます。 したがって、uBlock Origin のようなコンテンツ ブロッカーがこの API の可能性を賢明に活用している一方で、Google は次のように主張しています。 悪意のある他の拡張機能もこれを悪用してユーザーの個人情報にアクセスします。 情報。 Google によると、2018 年 1 月以降、悪意のある拡張機能の 42% が Web Request API を使用しています。 Googleはまた、ブロッキングバージョンとしてのAPIには「重大なパフォーマンスコスト」がかかると主張している 永続的で、多くの場合長時間実行されるプロセスが必要であり、「遅延」とは根本的に互換性がありません。 プロセス。
Manifest V3 では、Google はこの API をブロック形式で制限することを提案しています。 代替手段として、Google は Declarative Net Request API を提供しています。
未来
Declarative Net Request の公式説明では、API について次のように説明されています。
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Declarative Net Request を使用すると、Chrome はリクエストに関するすべての情報をリスニング拡張機能に送信する必要がなくなります。 代わりに、拡張機能は Chrome にルールを登録し、特定の種類のリクエストが検出された場合に何を行うかをブラウザーに事前に指示します。
拡張機能は事前にそのルールを指定します。 次に、ユーザーのリクエストはブラウザー (拡張機能ではなく) によってこのルールと照合され、そのアクションもブラウザーによって実行され、その後ページがレンダリングされます。 Googleは、これにより結果を決定するアルゴリズムを制御でき、非効率なルールを防止または無効化できるため、効率を確保できると述べている。 また、ネットワーク要求の詳細が拡張機能に公開されないため、エンドユーザーに対してより優れたプライバシー保証が提供されます。 永続的で長時間実行されるプロセスは不要になったため（ルールが事前に登録されているため）、Google は次のように主張しています。 このアプローチはパフォーマンスの向上ももたらし、リソースに制約のある拡張機能の実行可能性を大幅に高めます。 プラットフォーム。
宣言型ネット リクエストはマニフェスト V2 (現行) とマニフェスト V3 の両方で利用できますが、これは Google がマニフェスト V3 でネットワーク リクエストの変更を許可する主な方法になります。
論争
話の裏側、主に広告ブロッカーの話を聞くまでは、Google の変更は理にかなっているように思えます。 この特定の API の移行は、最も人気のある広告ブロッカーの動作方法を根本的に変えるため、Google が広告ブロッカーを排除する方法とみなされています。 これは、Google がユーザーのセキュリティの観点からではなく、ビジネスの観点からこの変化に向けて動機付けられているという「理論」と結びついています。 結局のところ、Google は収益を広告に大きく依存しており、この面で Google のクライアントにとって広告ブロッカーは直接の脅威として認識されていることが明らかになりました。 Alphabet の 2018 SEC Form 10-K 提出書類 （経由 登録簿):
新しいテクノロジーおよび既存のテクノロジーは、広告をカスタマイズする当社の能力に影響を与えたり、オンライン広告をブロックしたりする可能性があり、当社のビジネスに損害を与える可能性があります。
カスタマイズ可能な広告をより困難にしたり、広告の表示を完全にブロックしたり、一部のプロバイダーをブロックしたりする技術が開発されています。 のオンライン サービスには、サードパーティのデジタルの中核機能を損なう可能性のあるテクノロジーが統合されています。 広告。 Google の収益のほとんどは、オンライン広告の表示に関連して当社に支払われる料金から得られます。 結果として、そのようなテクノロジーやツールは当社の業績に悪影響を与える可能性があります。
Googleはそうしなければならなかった 声明を発表する これに対処するために、この変更はユーザーのプライバシーを守るためのものであり、広告ブロッカーに対する直接的な攻撃ではないという立場を繰り返しています。
当社は、広告ブロッカーの開発を妨げたり、ユーザーによる広告のブロックを停止したりすることはありません。 代わりに、コンテンツ ブロッカーを含む開発者がユーザーのプライバシーを保護する方法で拡張機能を作成できるよう支援したいと考えています。
Google Chrome で利用できる最も人気のある 2 つの広告ブロッカーを参照する必要があります。 uBlock オリジン そして アドブロックプラス、どちらもコンテンツ ブロックの同じ結果を達成するために異なるアプローチを採用しています。 uBlock Origin は Web Request API に大きく依存しており、コミュニティは長年にわたってこの拡張機能を優先してきました。 Adblock Plus やその他のコンテンツ ブロック拡張機能も Web リクエストのブロック部分に依存しているため、この API への変更は、最終的にはほとんどのコンテンツ ブロッカーに少なくともある程度の影響を与えることになります。
Google による Web リクエストの非推奨化の推進により、現在の形式の uBlock Origin は事実上廃止され、実際に多くのユーザーに影響を与えることになります。 ロイヤルティのない（そして広告ブロックの実現方法に煩わされるつもりもない）ユーザーは、それぞれの欠点を伴う代替ソリューションを見つけるでしょうが、それは不可能になります。 支持者や愛好家は、Web サイトがこの特定の API の広告ブロッカーと戦うために最終的に考案するさまざまな手法を回避する新しいフィルタリング エンジンの設計を考え出す必要があります。
Declarative Net Request は、かなり限定的なフィルタリング エンジンとして提案されました。 当初の予定 拡張子ごとの静的フィルター ルール (インストール中に宣言されるルール) に 30,000 のルール制限を設けます。 拡張機能ごとの動的フィルター ルール (インストール後に追加できるルール) のルール制限は 5,000 です。 余分なルールは無視されますが、EasyList for Adblock Plus 自体には 70,000 のルールがあるのに対し、uBlock Origin は 100,000 を超えるルールで実行するように設定できるため、これは少し問題です。 コミュニティからの最初の反発の後、 Googleが反応した 静的ルールの制限を拡張ごとに 30,000 ルールからグローバル最大の 150,000 ルールに変更することを約束します。 これには、ユーザーが広告ブロッカーと組み合わせて他のルールを多く使用するスクリプトを使用できなくなるという副作用があるため、ユーザーは自分の設定を調整する必要があります。
フィルタリング制限以外のDeclarative Net Request 静的 URL にのみリダイレクトできますしたがって、パターン マッチングのサポートは含まれていません。 uBlock Origin はパターン マッチングと拡張機能の開発者に大きく依存しています。 後付けはできないと記載されています この拡張機能のマッチング アルゴリズムは API の要件を満たすようになっています。 API では、フィルター リストを更新するだけでも完全な拡張機能の更新が必要になりますが、これは、次のことを考慮するとあまりにも頻繁なアクティビティになります。 これらのフィルタリストが更新される頻度. もちろん、これらのアップデートは Google の拡張機能の審査基準とプロセスにも左右されます。
一方で、Google は、Web リクエストから脱却する意図は、 セキュリティの観点からは、Web リクエスト API は現在の形式では強力すぎるため、非常に広い余地が残されています。 乱用。 Google は、悪意のある拡張機能の 42% がこの API を悪用していると述べているため、この悪用は単なる理論上のものではありません。 アップルサファリの コンテンツ ブロッカー API 不正な開発者が悪用する余地が少ないため、同様の理由で Declarative Net Request と同様に設計されました。 弱体化された Web リクエストでは、ネットワーク リクエストは引き続き監視可能ですが、関連するホストに対するアクセス許可が必要になります。 Manifest V3 では、ホストの権限も大幅に変更されており、インストール時に一括して付与することはできなくなりました。
Google はまた、パフォーマンスのオーバーヘッドを切り替えの動機として利用しています。 ネットワーク リクエストの評価は拡張機能の JavaScript スレッドで行われるため、パフォーマンスが低下する可能性があります。 反論として、uBlock Origin の開発者は、彼の拡張機能が 重大なパフォーマンス上のペナルティは発生しません 140,000 もの静的フィルターを適用する場合でも同様です。 発生したコストは、リモート サーバーからのダウンロードが妨げられ、ブラウザーによって処理されないリソースによって簡単に回収できると主張されています。
Google はこの推論を使用していませんが、広告ブロックの効率性を目的として、Web リクエストに対して 1 つの議論を行うこともできます。 Web リクエストでは、拡張機能が時間内に応答しない場合（ラグやクラッシュにより）、ネットワーク処理リクエストが明確に許可され、広告が広告ブロッカーをすり抜けることができます。 一方、Declarative Net Request にはこの欠点はありません。 代わりに、広告は静的ルール内に収まらない場合は通過し、これは頻繁に発生します。
結論
上記の説明から、Declarative Net Request はブロッキングの 1:1 機能クローンではないことは明らかです。 Web リクエスト API の機能のせいで、拡張機能の開発者は、その努力が障害によって妨げられてがっかりすることになるでしょう。 そういった変化。 しかし、Google の推論にも重みがあります。Web リクエストは強力すぎるため、その権限を強化する必要があります。 ユーザーコミュニティ（平均的なユーザーと、 愛好家）。
Declarative Net Request への動きは、PR 効果もあった可能性があります。結局のところ、Google は Chrome に組み込みのコンテンツ ブロッカー API を追加しているのです。 しかし、新しい API には独自の厳しい制限があるため、コミュニティは当然のことながら、これを翼の切り取りとみなしています。 理想的な世界では、Google は新しい API を推進する前に、uBlock Origin のような広告ブロッカーの動作を調査すべきでした。 現時点では、新しい API では、ユーザーがフィルターを多用する 2 つの拡張機能を使用したいというシナリオに対応するために、ルール制限をさらに緩和することができます。
によると 登録簿、マニフェスト V3 の変更を含む最初のビルドは、2019 年 7 月以降に利用可能になります。 Google が拡張機能開発者コミュニティから受け取ったフィードバックをこれらのビルドに反映してくれることを願っています。
XDA 編集長の Mishaal Rahman 氏のご意見とご支援に心より感謝いたします。
編集: この記事では、Adblock Plus の動作を Declarative Net Request API の動作と誤って同一視していました。 それに応じて記事も修正されました。 Adblock Plus も、Web Request API のブロック機能の削除の影響を受けます。