分析コンテンツや広告ブロッカーを破壊し、他のブラウザ拡張機能を駄目にする恐れのある Chrome の変更案に対する開発者やネットユーザーからの激しい非難を受けて、Google のソフトウェア エンジニアである Devlin Cronin 氏は、計画は確定したものではないと保証しました。
「このデザインはまだ草案段階であり、変更される可能性が高い」と彼はChromium拡張機能ユーザーグループに投稿したメッセージで述べた。
私たちの目標は拡張機能を壊すことではありません。拡張機能開発者と協力して、この破損を最小限に抑えつつ、すべてのユーザーのセキュリティ、プライバシー、パフォーマンスを向上させるプラットフォームの進化に努めています。
クロニン氏は、透明性とオープン性が、Google Chrome が構築されているオープンソース プロジェクトである Chromium の中心であり、プロジェクトでは技術的な意見を歓迎していると強調しました。
Googleは、開発者コミュニティと協力する意向を示唆する追加声明も発表した。「これらの変更は、ドキュメントやChromiumのバグでも言及されているように、設計段階にあります。これらの変更によっても、すべての基本的なユースケースが引き続き利用可能であることを確認し、拡張機能開発者と協力して、拡張機能が引き続き機能するように取り組んでいます。」
Google の意図は、一部の開発者が表明した、これらの変更はコンテンツや広告ブロック拡張機能から自社の広告ビジネスを守りたいという願望によるものだという憶測に反論しようとする努力を表しているようだ。
試験気球を浮かべる
Googleは昨年10月、ブラウザ拡張機能の信頼性を高める計画を説明するブログ投稿で、これらの変更を初めて発表しました。この計画では、拡張機能がアクセスできるサイトを制限するユーザーコントロール、拡張機能開発者による難読化コードの使用禁止、Chrome拡張機能の審査プロセスの変更などが概説されていました。
Googleは、Chrome拡張機能プラットフォームの改訂版ドラフトであるManifest v3も発表しました。これは現在、開発者の悩みの種となっています。同社は当時、改訂版の仕様により拡張機能開発者がコードの書き換えを必要とする可能性があることを認めていましたが、互換性を損なう変更は「すべてのユーザー、開発者、そしてChrome拡張機能エコシステムの長期的な健全性のために、その労力に見合う価値がある」と主張しました。
しかし、多くの開発者は、Googleのユーザーのプライバシーとセキュリティ向上計画が正反対の結果をもたらすと見ている。「これらの変更により、多くのセキュリティ拡張機能が正しく機能しなくなると考えています」と、アムネスティ・インターナショナルのシニアテクノロジスト兼研究者であるクラウディオ・グアルニエリ氏は、クロニン氏がChromiumのバグトラッカーではなく、Chromium拡張機能ディスカッショングループへの投稿で述べた。
マニフェストv3は、Chrome拡張機能開発者が利用できるアプリケーションプログラミングインターフェース(API)の様々な変更点について説明しています。拡張機能開発者にとって最も懸念されるのは、webRequest
APIからdeclarativeNetRequest APIへの移行を促す取り組みです。
このAPIは、コンテンツブロッキングアプリケーションなどに利用されているdeclarativeNetRequest
の代替として設計されています。Googleは、セキュリティ、パフォーマンス、プライバシーの観点から、 のネットワークリクエスト操作能力を制限しつつ、今後はを推奨APIとして提供していく予定です。webRequest
webRequest
declarativeNetRequest
Googleがこれらの変更を行った理由は、たとえその結果が完全には考慮されていなかったとしても、妥当なものに思えます。拡張機能はセキュリティリスクをもたらす可能性があり、拡張機能開発者は必要以上に多くの情報にアクセスできてしまう可能性があります。
同社がManifest v3のドキュメントで指摘しているように、2018年8月時点で、上位1,000の拡張機能のうち80%がすべてのドメインへのアクセスを要求しており、スクリプトの挿入、ネットワークリクエストの傍受、あらゆるドメインのCookieの読み取りが可能になっています。必要以上に広範な権限を要求するスマートフォンアプリと同様に、これは必ずしも不正行為を示すものではありませんが、正当な懸念事項です。
開発者は不満だ
しかし、セキュリティとプライバシーの強化は、拡張機能の機能低下やブラウザユーザーが利用できるツールの制限につながる可能性がある。uBlock Originの開発者であるRaymond Hill氏は、Manifest v3提案の問題点を指摘し、自身の拡張機能は制限の厳しいAPIでは動作しないと警告した。
ヒル氏の苦情を受けて、Chromium拡張機能ユーザーグループを通じて他の人々も懸念を表明した。Privownyの共同CTO兼エンジニアリング担当副社長であるダニエル・グラズマン氏は、提案された変更は同社のソフトウェアに甚大な影響を与えると述べた。
このdeclarativeNetRequest
APIは(現在の草案では)拡張機能によるネットワークリクエストの変更を許可していませんwebRequest
。リクエストをブロックまたはリダイレクトすることしかできないため、コンテンツブロッカーの能力は大幅に低下します。また、ネットワークリクエストの処理に適用できるルールの数は30,000に制限されています。
これは、Adblock Plusのように比較的限定的なフィルターリストに依存する拡張機能には十分かもしれませんが、より野心的な拡張機能には不十分です。Ermes Cyber SecurityのCTO、ステファノ・トラヴェルソ氏によると、フィッシング対策リストの中には数百万件ものエントリが含まれているものもあります。
ちなみに、Adblock Plusは7万件以上のフィルターリストを使用しており、これは提案されているAPI制限の2倍に相当します。つまり、Adblock Plusは提案されている変更によってある程度影響を受けることになり、開発者を苛立たせていますが、より高度なuBlock Originなど、単純なフィルターリストを適用する以上の機能を持つ拡張機能は、APIの刷新によってより大きな影響を受けるでしょう。
すごいですね。ウェブ広告大手のGoogleがChromeの広告ブロッカーをブロックするそうです。どうやら安全のためらしいですね。
続きを読む
クロニン氏は、アクセス制限の強化が一部の開発者を動揺させるだろうと認めている。「webRequest
宣言型APIを採用することでAPIの機能を制限しようとすると、多くの懸念があることは理解しています。宣言型APIは制限がはるかに厳しく、webRequest APIのような柔軟性を提供しません」と、彼はディスカッショングループへの投稿で述べている。
しかし、APIの変更はそれだけではありません。Manifest v3には、拡張機能開発者に影響を与える様々な変更が含まれています。例えば、拡張機能がバックグラウンドでコードを実行できるバックグラウンドページを、Service Workersと呼ばれるより現代的なバックグラウンドプロセスAPIに置き換えるよう開発者に指示しています。Glazman氏によると、この変更は同社にとって数ヶ月の作業を要するとのことです。
彼は、MozillaとAppleが過去に、軽率な変更によって拡張機能のエコシステムに損害を与えるような措置を講じたと警告している。また、WebExtensions APIはWeb標準のように管理されておらず、そうあるべきだと述べ、MicrosoftがW3Cコミュニティグループを通じて標準化に取り組もうとした努力が惨めに失敗したことを指摘した。
「私はGoogleに対し、WebExtensionsに関する現実的かつ積極的な標準化の取り組みを復活させることを強く求める」と同氏は述べた。
ブラウザ空間において、この方法が採用されていないのはここだけです。そして、v3提案によって、サードパーティの実装者にとってもはや機能しないことが明らかになりました。大規模な変更にタイムリーに対応することは不可能です。今回の変更が拡張機能ベンダーに与える経済的影響は(そもそも見積もられていたとしても)大幅に過小評価されており、それだけでも戦略的な観点から見て、決定的なシグナルとなるはずです。®