ニュース

「Chrome」は広告ブロッカーを殺さない、安全にするだけだ ~Googleが新APIを解説

“Declarative Net Request API”は拡張機能の開発者やユーザーに受け入れられるか?

公式ブログ“Google Online Security Blog”

 「Google Chrome」の拡張機能で広く利用されている“Web Request API”は、近々新しい“Declarative Net Request API”へ置き換えられる予定だ。しかし、この変更により広告ブロッカーのような拡張機能を開発するのが難しくなることが指摘されている。一部の開発者の間では“自社の広告事業を守るための広告ブロッカー潰しではないか”との批判の声も上がる中、米Googleは6月12日(現地時間)、それに反論する記事を公式ブログへ掲載した。

 それによると、同社は「Google Chrome」の拡張機能を安全に利用できるようにするため、エンジニアチームの規模を300%以上、レビュアーの数を400%以上増やし、悪意ある拡張機能の排除に取り組んでいる。この取り組みは一定の成果を収めているが、所詮はイタチごっこであり、「Google Chrome」側での対策も不可欠だ。

 そこで、同社は不正な拡張機能がインストールされたり、拡張機能のデータ収集をユーザー側でコントロールできるようにする取り組みを進めている(参考記事1参考記事2)。その一環として、プラットフォーム側にも「Manifest V3」と呼ばれる変更を導入しているが、“Declarative Net Request API”の採用もその1つに過ぎないという。

 既存の“Web Request API”と新しい“Declarative Net Request API”の大きな違いは、拡張機能の自由度だ。

両APIの違いは、拡張機能の自由度にある

 “Web Request API”は、ユーザーがリンクをクリックしてWebサーバーとの間でデータをやり取りが発生すると、リクエスト(要求)処理とレスポンス(応答)処理の両方を拡張機能へ丸投げしてしまう。このやり方には、拡張機能側で高度で柔軟な改変処理が行えるというメリットがある一方、拡張機能に悪意があればデータを簡単に盗まれてしまう。また、拡張機能が処理を長期間ブロックしてしまうため、最近「Google Chrome」で進められているパフォーマンス改善策とも相性が悪い。

“Web Request API”のプロセス

 それに対し、“Declarative Net Request API”は拡張機能があらかじめ(宣言的に)ルールを「Google Chrome」へ登録し、それに従って「Google Chrome」が改変処理を行う仕組みになっている。こうした“宣言的”な方法は透明性が高く、また処理の主体が拡張機能ではなく、あくまでも「Google Chrome」本体にあるため、拡張機能からデータを保護するのが容易で、パフォーマンスの向上にも取り組みやすい。

“Declarative Net Request API”のプロセス

 “Web Request API”は広告ブロッカーを含む多くの一般的な拡張機能で利用されているため、影響が大きくなることは否めない。しかし、2018年1月以降、悪意のある拡張機能の実に42%で“Web Request API”が利用されており、対策が必要とされているのも確かだ。さまざまな議論を経て、当初の発表以降“Declarative Net Request API”にも機能の拡充や制限の緩和といった改善が施されているが、拡張機能の開発者やユーザーに受け入れられるかどうかは依然不透明だ。