広告ブロックが無効になるChromeプレビュー版が7月末に公開。拡張機能開発者が未だに心配する理由。
AdBlock が有効になっている可能性があります。
任意ですが、無効にしていただけると管理人が喜びます。
説明: マニフェストV3の初期バージョン ― 物議を醸した広告やコンテンツブロックに影響を与える、Chrome拡張機能のシステムの変更 ― 約1ヶ月以内には登場する。
拡張機能の開発者はインターネット広告の巨人が、パフォーマンス、プライバシー、セキュリティの名の下に、拡張機能から多くの有用な機能を削除することを懸念しています。
開発者の代弁としてSimeon Vincent氏がGoogleグループのディスカッションスレッドでこう述べました。「マニフェストV3はまだ実験やフィードバックを行える準備ができていません」「拡張機能チームはCanaryチャンネルで7月下旬〜8月上旬に開発者向けプレビューのリリースを目指しています。そのリリースの時に詳細は説明します」。
同氏はさらに、熱心な開発者はChromiumソースコードレポジトリのマスターブランチを手動でビルドすることで開発途中バージョンを試すことができる、と付け加えました。
Vincent氏は先週、Googleのミニ広告騒動を受けて開発者の一連の懸念について答えました。彼は昨年10月以降にChrome拡張機能プラットフォームのAPI改訂によって、コンテンツブロッカー、プライバシー、その他ブラウザ拡張機能が機能しなくなったり、機能が制限されたりするという懸念を払拭しようとしました。
この議論の中心となっているのは、ネットワークトラフィックの受信を確認、変更、ブロックできるwebRequestAPIのブロッキング(同期)バージョンを削除する計画です。例えば、広告ブロックはこれを使って不要な広告、利用者追跡スクリプトをブロックしています。
しかし、現在進行中のプロジェクトであるマニフェストV3では、Google社員がChrome拡張機能の能力に影響を与える他の多くの変更も検討しています。
例えば、webRequestを置き換える機能として予定されているdeclarativeNetRequestは、要求トラフィックを検出して変更を行うためにパターンマッチングルールを設定できます。拡張機能はChromeがトラフィックを識別し処理を行うためのルールを作る必要があります。各アドオンに通信の確認やブロックを任せることはありません。
現在、設定できるルールの制限は30,000の静的ルールと5,000の動的ルールです。動的ルールはコンテンツブロックにかなり役立ちます。
Vincent氏は先週、「私たちは今、静的ルール数の制限を今の1つの拡張機能で3万から、最大15万のグローバルルールに変更することを計画しています」と言いましたが、木曜日の投稿で彼が言った通り「Chromeはインストールされている全ての拡張機能総合で最大15万のルールを持つようになります」
それはとてもよく聞こえるかもしれませんが、例えばHTTPS Everywhereの開発者William Budingtonが言うように、HTTPS Everywhereは15万7千以上のルールを使っていて既に足りていません。全ての拡張機能でルール制限が共通のため、一つの拡張機能が多くのルールを使うと、他の拡張機能で使えるルールが少なくなります。
Vincent氏は、この制限はおそらく最終的なものではないと言って、Budington氏を安心させようとしました。「実際の速度はルール制限の量で異なるため、今は分析中です」。しかし、同氏は動的ルールのほうが静的ルールよりもはるかに有用だという事実には触れませんでした。
Googleのエンジニアが挙げた3つの理由のうち、最も説得力がないのはパフォーマンスです。Vincent氏は、Chrome拡張機能のChrome全体へのパフォーマンスの影響は、「JavaScriptの実行時間が無視できるほど可能な限り高速であるようにと作成された拡張機能であっても、全体へのパフォーマンスの影響は非常に大きくなる可能性があります」と主張しています。
Google ChromeのセキュリティエンジニアであるChris Palmer氏はディスカッションスレッドで同様の主張を繰り返し、「パフォーマンスの問題は現実だ」と言いました。彼はブラウザまたはネットワークサービスプロセスに多数のルールや同期呼び出しの解決を待つことによる遅延を指摘しました。
十分にコード化されていない拡張機能が原因で機能が低下する可能性は確かに考えられますが、拡張機能の開発者は、このような遅延を避けることができないという話に疑問を抱いています。
今週公開された『Exthouse』というオープンソースのツールは、拡張機能によって起こる速度の低下を測定するものですが、これがこの「疑問」に拍車をかけています。ExthouseはAdblock Plusがパフォーマンスに影響を与えることを示しましたが、uBlock Originでは、Time to InteractiveとFirst Input Delayの2つに全く遅延が無いことを示しています。これは、コンテンツブロッカーの開発者の主張である「Webページ上の広告や追跡コードを削除することによって、パフォーマンスが向上する」をより強調させています。
指摘されたVincent氏は、マニフェストV3に関するGoogleの公式ブログの投稿でパフォーマンスの問題を見落としていたことを認め、近いうちに詳細を明らかにしたいと述べています。ブロック(同期)版webRequestコールバックをブロックする実行時間が問題ではないと彼は述べました。むしろ、Chromeがリクエストを処理するため全体へのパフォーマンスの影響が問題です。
「webRequestのブロック版では、Chromeは大量のデータ(リクエスト自体とリクエストメタデータなど)をシリアル化して、各拡張機能に送らなければいけません」「これは、それぞれの通信データを確認する拡張機能(別々のプロセス)のタイプ変換、コピー、プロセス間通信、(逆)シリアル化などで大きな遅延が発生します。」と彼は言いました。
同時にVincent氏は、パフォーマンスがマニフェストV3の主な動機ではないことを認めました。むしろGoogleの主な関心事は「リクエストを変更することに関するプライバシーとセキュリティを改善し、悪意のある拡張機能を減らすため」であると言います。基本的に、Googleの社員たちはユーザーのネットワークトラフィックを操作したり盗聴したりするという考えはあまりよく思っていません。
Palmer氏が述べているように、プライバシーに関する主な利点は、開発者が「Declarative Net Requestを使ってコンテンツを受動的に監視する権限を必ずしも取得する必要が無く、コンテンツをブロックする拡張機能を作成」できることだと言います。
権限を必要とする追加のAPIを実装する可能性はあります、と彼は説明します。
The Registerが報じたように、Chrome拡張機能のセキュリティには大きな問題があります。しかし、厳しい審査、セキュリティ監視員の雇用、Chrome Web Storeのポリシーの厳格化など、APIの変更以外の方法で対処できる可能性があります。
「私たちが拡張機能プラットフォームにどうアプローチするかを考えている際に、達成しようとしている目標の1つは拡張機能がユーザーのプライバシーを侵害しないように今行っていることを行えるようにすることです」「大まかに言えば、declarativeNetRequest (DNR) APIはリクエストオブジェクトを見せることなく、また(できるだけ)リクエストを変更する権限を持つことなく、リクエストを変更する方法を拡張機能に提供することで、この目標を達成します」とVincent氏は説明します。
Vincent氏は理論上、マニフェストV3で実装されたコンテンツブロッカーはマニフェストV2と同じように使えますが、データが盗まれる危険性はまったくないと主張しています。
しかし、彼の投稿の次の行では今の形のwebRequestが不可欠であることを認めています。これほど危険なのに、なぜエンタープライズユーザ向けにはブロック版のwebRequestを残しておくのでしょうか。
「まず、拡張機能がより安全なAPIでは再現できない重要な機能を提供するため、」「次に、権限の取得(と維持)を行うことでwebRequestに伴うリスクを軽減できます。」とVincent氏は言います。
彼は続けて、declarativeNetRequestはwebRequestでできることを全てできるわけではないと認めました。「Chromeチームの見解ではこの変更と他の変更を組み合わさることで、あらゆる種類の悪用を阻止しています、」「[Declarative Net Request]は完璧に(webRequestを)置き換えられるわけではありませんが、プライバシーの保証は機能の損失を上回ると確信しています。つまり、大量のデータを公開したり、悪意のある人に権限を与えることなく、できる限りコンテンツブロッカーを守るため、拡張機能の変更を行いたいのです。」と彼は言いました。
つまり、ウェブ広告(ブロック)やコンテンツブロッカー、その他のChrome拡張機能は機能が低下するのです――あなたを守るために®
