webRequestGoogle Chrome ユーザーは、有料のエンタープライズ顧客の場合のみ、ブラウザ拡張機能で APIの完全なコンテンツ ブロック機能を引き続き利用できます。
それ以外のユーザーは、Chrome拡張機能の動作方法の変更の一環として開発されている、無効化されたAPIを使用する拡張機能に頼らざるを得なくなりますdeclarativeNetRequest。また、一部の開発者が拡張機能を新しいシステムで動作するように修正できない、あるいは修正を望まないため、Chromeユーザーの選択肢は少なくなる可能性があります。
舞台裏
マニフェストファイルは、開発者がアプリがファイルやAPIなどの特定のリソースを使用することを宣言するための手段を提供します。Googleは、Chromeの機能や性能の変化に対応するため、長年にわたりChrome拡張機能のマニフェスト仕様を改訂してきました。マニフェストv1は2014年1月に段階的に廃止されました。現在のバージョンであるマニフェストv2も、今年後半にマニフェストv3がリリースされれば、同様の運命を辿ることになります。
昨年 10 月に発表されてまだ流動的である v3 ドラフトは、今年初め、Google のwebRequestAPI 廃止計画やその他の変更案によって、コンテンツや広告のブロッカー、プライバシー拡張機能、およびコンテンツがブラウザに表示される前にそれを傍受することに依存するその他のブラウザ アドオンが機能しなくなることがわかり始め、Chrome 拡張機能の開発者に不安を与えた。
先月、EFF の Privacy Badger 拡張機能の開発者らが提起した懸念に応えて、Google の Chrome 拡張機能開発者アドボケートの Simeon Vincent 氏が先週、同社の Manifest v3 計画の最新情報を公開した。
良いニュース！ある意味
朗報もあります。様々なAPIで、Webリクエスト、リクエストヘッダー、URLパラメータの動的な変更がさらにサポートされるようになります。これにより、コンテンツブロッキングの影響は、当初のManifest v3ドラフトで示唆されていたほど深刻ではなくなるでしょう。しかし、根本的な問題は依然として残っています。Manifest v3では、拡張機能による不要なコンテンツのブロック効果が低下してしまうのです。
ヴィンセント氏はアップデートで、webRequest有料顧客向けの のオリジナル フレーバーがなくなることはなく、API は一般向けに縮小された形で存在し続けることを明らかにしました。
webRequest「Chrome は API全体ではなく、Manifest V3 の APIのブロッキング機能を廃止しますwebRequest(ただし、企業向けの展開ではブロッキングは引き続き利用できます)」と彼は書いています。
ヴィンセント氏は、適切に許可された拡張機能は、API を使用してネットワーク リクエストを引き続き監視できるとwebRequest述べ、これは「実行時に監視するパターンに基づいて動作を変更する拡張機能の基礎となる」と主張しました。
しかし、人気のコンテンツ制御拡張機能uBlock Originを開発した開発者レイモンド・ヒル氏は、監視よりもブロック機能の方が重要だと主張しています。APIによるコンテンツブロック機能が失われることが、webRequest彼の最大の懸念事項です。
「これはuBlock OriginとuMatrixの機能不全を引き起こします。これらはGoogleが採用した、表面上はEasyListのようなフィルターリストを強制するように設計された基本的なマッチングアルゴリズムと互換性がありません」と彼はThe Registerへのメールで説明した。「ブロッキングwebRequestAPIは、コンテンツブロッカーが自社のビジネスにとって脅威であると述べているGoogleが定めた特定の設計や制限に縛られることなく、オープンエンドのコンテンツブロッカー設計を可能にします。」
ブロックに手を出すな！EFFはGoogleに対し、プライバシーバジャーをマニフェスト・デスティニーで殺さないよう懇願する
続きを読む
Googleはコメント要請に応じなかった。同社は以前、Manifest v3の目的は「より強固なセキュリティ、プライバシー、そしてパフォーマンスの保証を実現すること」だと述べていた。
しかしヒル氏は、週末にGitHubに投稿したメモの中で、パフォーマンスの問題は拡張機能によるコンテンツの傍受と処理よりも、トラッキングコードで埋め尽くされた肥大化したウェブページから発生することが多いと指摘している。そして、webRequestAPIのブロッキング特性が本当にパフォーマンス上の懸念事項であるならば、GoogleはFirefoxのアプローチを採用すれば良いと主張している。Firefoxのアプローチは、Promisesと呼ばれる技術を用いて非ブロッキング／非同期のレスポンスを返すものだ。
ヒル氏は、Googleの技術的変更は、広告ブロックによる収益への脅威に対処するための試みだと考えている。彼は、Googleが2018年に提出した10-K財務報告書を、その懸念の証拠として挙げている。
ヒル氏は、APIのブロッキング機能webRequestによってコンテンツブロッキングのコントロールが開発者の手に委ねられ、Googleの権限が奪われたと述べた。Chromeが現在主流のブラウザとなっているため、Googleには再び市場参入するチャンスがあると彼は主張する。
「API のブロック機能を廃止することwebRequestで、この制御を取り戻し、Web ページがどのようにフィルタリングされているかをさらに計測して報告することができるようになります。Web ページに適用される正確なフィルターが、Google Chrome によって収集可能な情報となるためです」と彼は述べた。
ヒル氏はThe Registerへのメールで、「Googleの主要事業は、妨害されないコンテンツブロッキングとは相容れない。Google Chrome製品が高い市場シェアを獲得した今、10-K報告書に記載されているコンテンツブロッキングの懸念は解決されつつある」と述べた。®
