Google様による広告ブロック「無力化」計画、発覚したバグとゼロ円の皮肉 🕵️♂️🚫💰 #ChromeMV3 #アドブロック終焉か #七13
Google様による広告ブロック「無力化」計画、発覚したバグとゼロ円の皮肉 🕵️♂️🚫💰 #ChromeMV3 #アドブロック終焉か
～ ウェブ監視社会の片隅で拾った、コードの抵抗と巨鯨のささやき ～
目次
- 第1章 本書の目的と構成：広告まみれのウェブであなたは何を失うか
- 第2章 要約：希望なき時代のバグ報告
- 第3章 登場人物紹介：善人、悪人、そしてコードの精霊たち
- 第一部：監視資本主義の檻
- 第二部：コードの叛乱、巨鯨の反撃
- 第6章 過去の亡霊：JavaScriptバインディングという残滓の悪戯
- 第7章 ゼロドルバグ：古代コードが現代の監視を嘲笑う瞬間
- 第8章 Googleの判断：セキュリティより大切なもの（たぶん広告収入）、そしてゼロ円の報酬
- 補足資料：この茶番劇を味わうための断片
- 第9章 疑問点・多角的視点：この奇妙な出来事を深掘りする
- 日本への影響：極東の島国にも忍び寄る広告の波（詳細）
- 歴史的位置づけ：ブラウザ戦争、次の敗者はユーザーか（詳細）
- 補足1：三者三様の「ご感想」
- 補足2：巨視する年表
- 補足3：この戦いをカードゲームにするなら？（デュエマ風）
- 補足4：一人ノリツッコミ（関西弁）
- 補足5：この状況で大喜利をやってみよう
- 補足6：予測されるネットの反応とその反論
- 補足7：学習のための問い（クイズとレポート課題）
- 補足8：潜在的読者のための諸々
- 巻末資料：忘れられた言葉と無意味な情報
第1章 本書の目的と構成：広告まみれのウェブであなたは何を失うか
ようこそ、こちらの奇妙な記録へ。現代のウェブは、広告という名の砂嵐に覆われています。私たちは日々、その砂塵を避けようと努めますが、強力な台風は容赦なく襲いかかります。その台風の中心にいるのが、インターネットの多くのインフラを握る巨大な存在、Googleです。彼らは、広告から莫大な利益を得ており、そのビジネスモデルを守るためなら、ブラウザという私たちがウェブと接するための窓の仕様すら変更します。今回の主役は、Google Chromeの拡張機能が従うべき新しいルール、Manifest V3（MV3）です。
MV3への移行は、多くのユーザーが愛用するアドブロッカーの機能を根幹から揺るがすと騒がれています。セキュリティ強化という聞こえの良い理由のもと、実際には広告をブロックする強力な手段が制限されようとしているのです。まるで、家を守るために窓に鉄格子をつけたら、泥棒だけでなく郵便配達員まで入れなくなった、といったところでしょうか。しかも、その鉄格子は家主（私たち）ではなく、鍵屋（Google）が勝手にデザインしたものです。
そんな中、一人の開発者が、MV3の鉄格子に小さな亀裂、すなわちバグを見つけました。それは、MV3環境下でもアドブロッカーが息を吹き返す可能性を秘めた、ささやかな、しかし決定的な穴でした。しかし、そのバグは発見者の手によってGoogleに報告され、あっけなく塞がれてしまいます。しかも、その功績に対する報酬はゼロドル。なんともニヒルで、そしてシニカルな物語ではありませんか。
本書（この記事）は、この一件を深掘りし、単なる技術的なバグの話として終わらせず、その背景にある巨大IT企業の戦略、ユーザーの自由とプライバシー、そして現代のウェブが抱える構造的な問題を浮き彫りにすることを目的としています。第一部では、MV3がいかにしてアドブロッカーを標的にしているのか、その技術的な核心に迫ります。第二部では、発見されたバグとその顛末、そしてGoogleの反応を追います。そして補足資料では、この問題を取り巻く様々な視点や、今後の展望について考察を巡らせます。巻末資料では、この物語を理解するための用語集や、さらなる探求のための手がかりを提供します。
私たちは、この記録を通じて、ウェブというデジタル空間における「力」の構造、そしてその中で個人がどのように立ち振る舞うべきか、考えるきっかけを提供できれば幸いです。さあ、広告の砂塵の向こう側へ、少しばかり覗きに行きましょうか。🎩✨
第2章 要約：希望なき時代のバグ報告
Google Chromeは、拡張機能の新しい仕様であるManifest V3（MV3）への移行を完了させようとしています。このMV3では、従来のManifest V2（MV2）で利用可能だった強力なAPI、特に広告ブロッカーが依存していたwebRequestBlockingが制限されます。これにより、広告ブロッカーの機能が大幅に低下し、ユーザーはより多くの広告やトラッカーに晒されることになります。表向きの理由はセキュリティ強化とパフォーマンス向上ですが、多くの人々は、これはGoogleの主要な収益源である広告ビジネスを守るための措置だと見ています。
そんな中、本論文の著者である一人の開発者が、MV3環境下でもwebRequestBlockingと同様の機能を実現できる、Chromeの内部にあるバグを発見しました。具体的には、ブラウザ内部でイベントを処理する古いJavaScriptバインディングコードに存在する脆弱性、特に廃止されたプラットフォームアプリに関連するopt_webViewInstanceIdパラメータの検証不備を利用することで、MV3の制限を回避してリクエストをブロックすることが可能だったのです。
このバグは、アドブロッカー開発者にとってMV3の厳しい制限を回避する一時的な手段となる可能性を秘めていました。しかし、著者はこのバグを公に悪用するのではなく、Googleに報告する選択をしました。その結果、Googleはこの問題を「セキュリティ上の問題ではない」と判断し、著者への報酬はゼロドルでした。そして、Googleはこのバグに対してパッチを適用し、脆弱性は塞がれてしまいました。Chrome 118以降、このバグを利用することはできなくなっています。
本論文は、このバグの技術的な詳細を解説するとともに、Googleの対応や、この一件がブラウザの独占、広告ビジネス、そしてユーザーの自由とプライバシーに与える影響について論じています。著者は、Googleの行動を批判し、ユーザーに対してChromeからFirefoxなどの代替ブラウザへの移行を推奨しています。コメント欄では、Googleの独占に対する批判、MV3への反発、バグ報告の倫理、代替ブラウザの議論など、ウェブを取り巻く様々な意見が飛び交っています。
第3章 登場人物紹介：善人、悪人、そしてコードの精霊たち
この奇妙な物語に登場するのは、生身の人間だけではありません。コードの断片、古いシステムの亡霊、そしてインターネットの集合的意識も、それぞれの役割を演じます。ここに主要なキャストをご紹介しましょう。
- 著者 (Dopingconsomme) (年齢不明)
本論文の語り部であり、主人公。Chrome内部の暗部に光を当て、バグという名の真実を暴いた探求者。彼がGoogleに報告した行為は、一部から「敵に塩を送った」と批判されましたが、彼自身の倫理観に従った行動だったのかもしれません。報酬がゼロドルだったというオチが、この物語に一層の哀愁を漂わせています。若き技術者か、それともベテランの皮肉屋か。その素顔は闇の中です。 - Google Chrome (擬人化/存在)
ウェブの広大な海を航海するための、世界で最もポピュラーな船。しかし最近、船長（Google）の意向で、積み荷（拡張機能）に厳しい制限が加えられ、特定の機能（アドブロッカー）が使えなくなりつつあります。船そのものは高性能かもしれませんが、その設計思想には船長のビジネスが色濃く反映されています。 - Manifest V3 (MV3) (概念/システム)
Chrome船の新しい「積荷規則」。より安全で効率的な航海のためと謳われていますが、実際には乗客（ユーザー）が嫌がる貨物（広告）をより多く積み込めるようにするための改定ではないか、と疑われています。杓子定規で融通が利かない、官僚的な規則の塊です。 - webRequestBlocking (概念/API)
MV2という古い規則のもとで、アドブロッカーが持っていた強力な武器。「この貨物（広告リクエスト）、積荷リストから削除！」と船員（ブラウザ）に直接指示できる権限です。MV3ではこの武器が取り上げられ、代わりに威力の劣るおもちゃ（declarativeNetRequest）が与えられました。 - JavaScriptバインディング (コードの断片)
Chrome船の機関室の片隅に残された、古い時代の遺物。本来はC++という頑丈な素材で作り直されるはずが、なぜか一部がJavaScriptという脆い素材のまま残されていました。今回のバグは、この古い、忘れ去られたコードの隙間から生まれました。まるで、城壁の小さなヒビに巣食う精霊のようです。 - opt_webViewInstanceId (パラメータ)
JavaScriptバインディングの精霊が宿る、特定の「呪文」。かつてプラットフォームアプリという今は無き存在のために使われていましたが、その検証がお粗末だったため、今回のバグを引き起こすトリガーとなりました。歴史のゴミ箱に捨てられたはずのデータが、思わぬ形で反乱を起こしたのです。 - アドブロッカー (例: uBlock Origin) (拡張機能/抵抗勢力)
ユーザーのために広告という名の邪魔者を排除しようと戦う、義賊のような存在。MV3によって武器を奪われ、存続の危機に瀕しています。しかし、彼らの開発者（gorhill氏など）は、新しい規則の中でも戦い続ける方法を模索しています。 - Firefox (代替の船)
Chrome船以外の選択肢。少し古めかしいかもしれませんが、船長の哲学が違い、乗客（ユーザー）の意見をより重視しているようです。アドブロッカーという武器も、ここではまだ自由に使えます。Chrome船に失望した乗客の多くが、この船への乗り換えを検討しています。 - コメント欄の住人たち (集合的インターネット意識)
この物語に対する、無数の声。Googleへの怒り、アドブロッカーへの愛情、代替ブラウザへの勧誘、そしてニヒルな諦め…。様々な思惑が交錯し、時に罵り合い、時に共感を広げる、カオスな合唱団です。彼らこそが、このデジタル時代の民衆なのかもしれません。 - ゼロドル ($0) (報酬)
この物語で最も皮肉な登場人物。正義や発見に対する報酬が、価値なき「ゼロ」であったという事実。これは、巨大な力の前では、個人の貢献がいかに矮小化されうるかを示唆しています。しかし、この「ゼロ」は、物語を忘れられないものにするための、ある種の勲章なのかもしれません。
コラム：コードに宿る意志？
バグというのは、単なる間違いではありません。それは、プログラムを書いた人間の思考の歪み、あるいは過去の決断の痕跡です。今回のバグが古いJSバインディング、それも廃止された機能に関連していたというのは、なんとも示唆深いです。まるで、Googleの開発者が過去に残した「忘れ物」が、現在のポリシー変更に対するささやかな抵抗を試みたかのようです。コードに意志など宿るわけがない、と理性では分かっています。でも、こういう話を聞くと、無機質なはずのコードが、どこか人間味を帯びて見えてくるから不思議です。ゼロドルで報われなかった彼の発見は、その無機質なコードに宿る、人間的な皮肉を私たちに教えてくれたのかもしれません。
第一部：監視資本主義の檻
第4章 MV3：ブラウザ拡張機能への静かなる死刑宣告（建前はセキュリティ強化）
Google Chromeユーザーにとって、拡張機能はブラウザ体験をカスタマイズし、より快適にするための強力なツールでした。しかし、すべての良き時代には終わりが来るもの。Googleは、拡張機能の基盤となる仕様をManifest V2（MV2）からManifest V3（MV3）へと移行することを決定しました。これは単なるバージョンアップではありません。拡張機能ができることに、根本的な変更と厳しい制限を加えるものだったのです。
Googleが掲げるMV3移行の公式な理由は、セキュリティ強化とパフォーマンス向上です。MV2の拡張機能は強力すぎる権限を持ち、悪意のある開発者によってユーザーのデータを盗み見たり、不審な動作をさせたりするリスクがあった、とGoogleは主張します。また、非効率なコードがブラウザのパフォーマンスを低下させることも問題視されました。MV3では、拡張機能がバックグラウンドで実行できるコードを制限し、イベント駆動型のアプローチや、より宣言的な（予め定義された）ルールに基づいた動作を強制することで、これらの問題を解決しようとしています。聞こえは良いですよね。「安全で、速くなりますよ！」と。
しかし、話はそう単純ではありません。このMV3への変更で、最も大きな影響を受ける機能の一つが、他ならぬアドブロッカーです。MV2の時代、アドブロッカーはwebRequestBlockingというAPIを使って、ウェブサイトからの広告リクエストをリアルタイムで検知し、ブロックしていました。これは非常に柔軟で強力な仕組みで、様々な種類の広告やトラッカーを効果的に排除することを可能にしていました。まるで、家の前に立ちはだかり、怪しい訪問者（広告リクエスト）をその場で追い返す門番のようでした。
MV3では、この強力な門番が解雇されます。代わりに推奨されるのは、declarativeNetRequestという新しいAPIです。これは、拡張機能がブラウザにあらかじめ「こういう条件のリクエストが来たらブロックしてください」というルールリストを渡し、ブラウザ自身がそのリストに基づいて処理を行う仕組みです。門番を置いておくのではなく、怪しい訪問者のリスト（ブラックリスト）を門に貼り付けておき、ブラウザ自身にチェックさせるイメージです。一見効率的にも思えますが、この新しい仕組みにはいくつかの致命的な欠点があります。
まず、ルールリストのサイズに厳しい制限があります。広大なインターネット上の全ての広告やトラッカーに対応するためには膨大なルールが必要ですが、MV3ではその全てをリストに登録することはできません。また、動的なフィルタリングや、ウェブサイトの構造を分析して特定の要素（広告の表示領域など）を非表示にするといった高度な処理が難しくなります。つまり、新しい門番はリストに載っている相手しか追い返せず、リストに載っていない怪しい訪問者（新しい広告手法や巧妙なトラッカー）や、怪しい顔をしていないが迷惑な訪問者（広告表示領域）には無力なのです。
Googleは、MV3がアドブロッカーを完全に殺すものではないと主張し、declarativeNetRequestでも多くの広告はブロック可能だと説明しています。しかし、多くのユーザーやアドブロッカー開発者は、MV3がアドブロッカーの「効果」を意図的に弱体化させるものであると強く批判しています。その根底にあるのは、Googleが広告によって成り立っている企業であり、強力なアドブロッカーは彼らのビジネスモデルに対する直接的な脅威だから、という冷めた見方です。セキュリティやパフォーマンスという大義名分は、本音を隠すための美しい包装紙に過ぎない、と。
かくして、MV3はブラウザ拡張機能、特にアドブロッカーにとって、静かなる死刑宣告として受け止められています。それは、私たちがウェブを「自分好みに」「快適に」「プライバシーを守って」使うための自由が、プラットフォーム提供者のビジネス上の都合によって一方的に制限されるという、恐ろしい現実を突きつけるものなのです。私たちは、Googleという巨鯨によって、広告という名の餌がばら撒かれる檻の中に閉じ込められようとしているのかもしれません。🐋💰🚫
コラム：私のブラウザ遍歴と広告への嫌悪
思えば、私が初めて「広告ウザいな」と感じたのは、ダイヤルアップ接続でウェブを見ていた頃でしょうか。重いバナー広告がページの読み込みを妨げ、チカチカ点滅するポップアップが視界を遮る。あの頃から、広告とユーザーの戦いは始まっていたのですね。Netscape NavigatorからInternet Explorerへ、そしてFirefoxを経てChromeへ…ブラウザを変えるたびに、広告ブロックの手法も進化していきました。初めてアドオンで広告が消えた時の衝撃は忘れられません。「なんて快適なんだ！」と感動したものです。あれはもう15年くらい前になるでしょうか。今、また広告との全面戦争に逆戻りかと思うと、ため息しか出ません。広告が表示されるたびに、自分の時間と注意力が企業に搾取されているような、なんとも言えない嫌悪感が込み上げてきます。これはもう、技術的な問題だけでなく、哲学的な問いかけなのかもしれません。私たちのオンライン体験は、誰のものでしょうか？
第5章 webRequestBlocking：アドブロッカーの心臓を奪う Google
前章で触れたように、Manifest V3（MV3）移行の最も痛烈な影響の一つが、webRequestBlockingAPIの廃止です。このAPIは、これまでのアドブロッカーの機能の根幹をなしていました。ウェブブラウザが特定のURLへのリクエスト（画像の読み込み、スクリプトの実行、ページの遷移など）を行おうとするまさにその瞬間に、「ちょっと待て！このリクエスト、止めてくれ！」と割り込み、それをブロックしたり、別のものに置き換えたり、情報を変更したりすることを可能にする、非常に強力で柔軟な仕組みでした。
例えるなら、webRequestBlockingは交通整理の権限を持つ優秀な警察官のようなものです。ウェブサイトという街を行き交う様々なデータ（車）の中から、怪しい動きをしている車（広告サーバーへのリクエスト）を見つけ出し、その場で停止させることができます。「おっと、そこの黒い車！君は通せんぼだ！」という具合に。この警察官は非常に賢く、その場の状況に応じて臨機応変な判断ができます。「この車は広告用の道路を使おうとしているな」「この車のナンバーはブラックリストに載っているぞ」といった判断を、リクエストの中身や送信先、送信元の情報を見て、リアルタイムで行えるのです。
しかし、Googleはこの警察官を解雇し、代わりに交通ルールブック(declarativeNetRequest)を渡す、と先に述べました。ルールブックに従えば、あらかじめ定義された「こういう車は通さない」という規則に基づいて、ブラウザが自動的に処理を行います。警察官のような柔軟性はありません。リストにない例外的なケースや、巧妙に偽装された車には対応できません。これは、ウェブ広告の手法が日々進化し、巧妙になっている現代においては、アドブロッカーの効果を著しく低下させることを意味します。まるで、マニュアル通りの対応しかできないAI警察官に置き換えられたようなものです。
Googleは、webRequestBlockingが拡張機能に与える権限が広範すぎるため、セキュリティリスクになると主張しています。確かに、悪意のある拡張機能がこのAPIを悪用すれば、ユーザーの閲覧履歴を傍受したり、ウェブサイトのコンテンツを改変したり、不正なリクエストを送信したりといったことが可能になります。この点においては、Googleの主張にも一理あると言えるでしょう。強力なツールは、使い方を間違えれば危険を伴います。
しかし、問題はその「使い方の間違い」を防ぐためのアプローチです。Googleは、拡張機能そのものの権限を制限することで解決しようとしました。これは、優秀な料理人が包丁で人を刺す可能性があるからといって、料理人全員から包丁を取り上げ、バターナイフで料理をしろ、と言っているようなものです。善良なアドブロッカーは、webRequestBlockingをユーザーの利益のために、つまり広告やトラッカーをブロックするために適切に使用していました。彼らはこのAPIを使って、広告サーバーへの通信を阻止したり、YouTubeの動画再生前に挿入される広告ファイルを検出してブロックしたり、特定のウェブサイトで広告が表示されないようにするための複雑なルールを適用したりしていたのです。これらの高度な処理は、多くの場合、declarativeNetRequestでは代替できません。
アドブロッカー開発者の多くは、webRequestBlockingの廃止は、セキュリティリスクの排除というより、Googleの広告収益を守るための「本音」が透けて見える行動だと批判しています。ウェブ上の情報流通の多くが広告収益に支えられている現状は理解できますが、そのためにユーザーが広告をブロックする自由や、プライバシーを守るための強力なツールを奪われるのは、あまりにも一方的ではないか、と。
webRequestBlockingの廃止は、単なる技術的な仕様変更にとどまりません。それは、ユーザーがウェブをどのように体験するか、ウェブサイトがどのように収益を得るか、そしてインターネットの多様性が今後どうなるか、といった広範な問題に影響を与えます。アドブロッカーという心臓を奪われたChromeの拡張機能は、今後どこまでユーザーの味方でいられるのでしょうか。そして、心臓を奪われたことに気づかないユーザーは、無数の広告とトラッカーの中で、何を思うのでしょうか。💔
コラム：広告 vs ユーザー：見えない戦争
私がネットの世界に深く関わるようになってからずっと感じているのは、「広告」と「それを見たくないユーザー」の間の静かで終わりのない戦争です。広告主はより巧妙に、より目立つ形で広告を表示させようと工夫を凝らし、ユーザーはそれを回避するために様々なツールや技術を使います。アドブロッカーはその最前線に立つ兵器のようなものです。この戦争には勝者はいません。広告主はブロックされて収益機会を失い、ユーザーは広告を回避するための労力や不便さを強いられる。そして今回のように、プラットフォーム提供者が広告主側に加担して、ユーザーの兵器を無力化しようとしています。まるでディストピア小説の一場面のようです。私たちは皆、この見えない戦争の兵士であり、同時に戦場でもあるウェブの中に立たされているのです。
第二部：コードの叛乱、巨鯨の反撃
第6章 過去の亡霊：JavaScriptバインディングという残滓の悪戯
さて、MV3によってアドブロッカーが窮地に立たされる中、本論文の著者であるDopingconsomme氏は、思いがけない場所で希望の光を見つけました。それは、Chromeの内部コードに残されていた、古い時代の遺物、JavaScriptバインディングです。
通常、ブラウザの主要な機能やAPIは、高いパフォーマンスとセキュリティのためにC++という言語で書かれています。しかし、初期のChrome拡張機能APIの中には、JavaScriptで書かれた「バインディングモジュール」を介してC++のコア機能と連携するものがありました。これは、拡張機能がブラウザの機能（C++の世界）を呼び出す際に、JavaScriptの世界から橋渡しをする役割を担っていました。例えるなら、異なる言語を話す二人の間の通訳のようなものです。
しかし、このJavaScriptバインディングは、過去に何度か深刻なセキュリティ問題を引き起こしました。有名なのが、2015年から2016年にかけて発生したUniversal XSS（UXSS）バグです。これは、悪意のあるウェブサイトが、このJavaScriptバインディングの脆弱性を突いて、ブラウザ内部で特権的なJavaScriptコードを実行できてしまうというものでした。これにより、ウェブサイトが他のウェブサイトに勝手にコードを挿入したり、ユーザーの情報を盗み見たりすることが可能になってしまいました。非常に危険な脆弱性だったのです。この経験から、Googleはほとんどの重要なAPIバインディングを、より安全とされるC++に移行しました。通訳の代わりに、両方の言語を話せるバイリンガルな人間（C++で書かれた直接的なバインディング）を用意したわけです。
しかし、なぜか、一部のAPI、とりわけchrome.webRequestに関連するいくつかの機能のバインディングは、完全にC++に移行されず、いまだにJavaScriptバインディングが残されていました。まるで、大掃除をしたのに、棚の奥に古いガラクタがいくつか残っていた、というような状況です。論文の著者も指摘していますが、この残されたJavaScriptバインディングが、今回のバグの温床となったのです。
JavaScriptという言語は、C++に比べて柔軟性が高い反面、実行時の挙動を完全に制御するのが難しい側面があります。グローバル関数やオブジェクトのプロトタイプを上書きするといった操作が比較的容易に行えてしまうため、特権的なコードをJavaScriptで扱うことにはリスクが伴います。古いバインディングコードの中には、イベントを扱うためのラッパークラスが含まれており、そのコンストラクタが外部からアクセス可能な状態でした。これは、本来拡張機能が直接触れるべきではない、ブラウザ内部のコアな部分への入り口が開いていたことを意味します。
つまり、MV3によって厳重に鍵がかけられたはずのwebRequestBlocking機能の裏口に、古いJavaScriptバインディングという、うっかり開けっ放しになっていた窓があった、というわけです。過去のセキュリティ問題から学んだはずのGoogleが、なぜこの窓を閉め忘れていたのかは分かりません。開発のリソース不足か、あるいは単なる見落としなのか。しかし、この過去の亡霊が、現代の厳しいルールをすり抜ける可能性を生み出したという事実は、なんとも皮肉で、そして少しだけロマンチックです。忘れ去られたコードの断片が、最新のシステムに一泡吹かせた、そんなストーリーです。📜👻✨
コラム：技術的負債と皮肉
ソフトウェア開発の世界には、「技術的負債」という言葉があります。これは、短期的な expediency（便宜）のために、長期的な保守性や堅牢性を犠牲にして書かれたコードや設計のことを指します。利子を払わずに借金をするように、負債は後になって問題を引き起こします。今回のJavaScriptバインディングの件は、まさにその典型かもしれません。過去にセキュリティ問題を引き起こしたにも関わらず、完全にクリーンアップされていなかった。それがMV3という新しいルールができた後で、思わぬ形で抜け穴になった。これは技術的負債が引き起こした、なんとも皮肉な出来事です。私たちの日々のコーディングも、もしかしたら未来の誰かの頭を悩ませる技術的負債を生み出しているのかもしれませんね。ちょっと背筋が寒くなります。
第7章 ゼロドルバグ：古代コードが現代の監視を嘲笑う瞬間
前章で明らかになった、JavaScriptバインディングという古い窓。ここから、本論文の著者が、MV3の厳格なルールを掻い潜る方法を見つけ出します。物語の核心に迫る瞬間です。
著者は、chrome.webRequest.onBeforeRequestというイベントのラッパークラスが、ブラウザの内部でどのように機能しているかを詳細に分析しました。このラッパークラスは、イベントの様々な状態を管理しており、そこにはopt_webViewInstanceIdというパラメータが含まれていました。このパラメータは、かつてChrome上で動作していたプラットフォームアプリ（2020年に廃止）が、組み込みのウェブサイト（WebView）を制御するために使われていたものでした。特に、WebView内でのリクエストに対しては、通常の拡張機能に課されるwebRequestBlocking権限のチェックがスキップされるような設計になっていたのです。
著者が発見したバグの核心は、ブラウザが、拡張機能が提供したopt_webViewInstanceIdが、実際に有効なWebViewに紐づいているかどうかを適切に検証していなかったという点にありました。つまり、MV3の拡張機能であっても、このopt_webViewInstanceIdパラメータに偽の、あるいは適当な値をセットしてイベントを作成すれば、ブラウザはそれをWebViewからのリクエストだと誤認し、webRequestBlocking権限のチェックをスキップしてしまうのです。門番は解雇されたはずが、偽の身分証明書（偽のopt_webViewInstanceId）を見せれば、あっさり通してしまった、というお粗末な状況でした。
著者は、このバグを利用して、MV3環境下でwebRequestBlockingを使ってリクエストをブロックするコードを作成しました。そのコードは、chrome.webRequest.onBeforeRequestのコンストラクタを直接取得し、偽のopt_webViewInstanceIdパラメータ（例：1337など適当な値）を渡して新しいイベントオブジェクトを作成。その偽のイベントに対して、ブロック処理を行うリスナーを追加するというものでした。
let WebRequestEvent = chrome.webRequest.onBeforeRequest.constructor;
// opt_webViewInstanceId is the 5th argument
let fakeEvent = new WebRequestEvent("webRequest.onBeforeRequest", 0, 0, 0, 1337); // 偽のIDをセット
fakeEvent.addListener(() => {
return { cancel: true }; // ブロック処理
}, { urls: ['*://*.example.com/*'] }, ['blocking']); // 'blocking'権限は不要！
このコードは、MV3の拡張機能であっても、webRequestBlocking権限を持っていないにも関わらず、指定したURLへのリクエストをブロックすることを可能にしました。これは、MV3によってアドブロッカーの息の根を止めようとしていたGoogleにとって、まさに予想外の「盲点」でした。廃止された機能のために残されていた古いコードが、皮肉にも最新の厳しいルールを骨抜きにする可能性を生み出したのです。それは、巨大なシステムの中に忘れ去られた、ささやかな抵抗のコードが、一瞬だけ輝きを放った瞬間でした。
著者は、技術的にはこのバグを利用してMV3で完全に動作するアドブロッカーを作成することも可能だったと述べています。広告ブロッカーが殺されつつあるという状況下で、これは非常にユーモラスな事態になったでしょう。しかし、彼はその道を選びませんでした。技術的な好奇心を満たした後、彼は別の行動に出ます。それは、このバグをGoogleに報告することでした。
コラム：数字の「1337」に託された皮肉
著者が偽のopt_webViewInstanceIdとして使用した「1337」という数字は、ハッカーやゲーマーの間で「Leet」（エリート）を意味するスラングとしてよく使われます。テキストを数字や記号に置き換えて、隠語のように使う文化です。このバグが、Googleのセキュリティチェックを「Leet」なやり方で回避したことを示唆しているのでしょうか？それとも、単に著者のちょっとした遊び心でしょうか？いずれにせよ、この数字の選択には、巨大なシステムを出し抜いたことに対する、ささやかな勝利の皮肉が込められているように感じられます。たかが数字、されど数字。コードの中にも、人間の感情は確かに宿るようです。
第8章 Googleの判断：セキュリティより大切なもの（たぶん広告収入）、そしてゼロ円の報酬
ゼロドルバグを発見した氏は、その技術的な探求心を満足させた後、ある決断を下します。それは、このMV3の抜け穴をGoogleに報告することでした。2023年8月のことです。おそらく、彼はGoogleがこのバグをセキュリティ上の問題と認識し、それなりの報酬を支払うことを期待したでしょう。多くの企業は、自社製品の脆弱性を発見・報告した善意の第三者に対して、報奨金（バグバウンティ）を支払うプログラムを用意しています。これは、脆弱性が悪意のある攻撃者に悪用される前に修正するための、企業にとって非常に有効な手段です。
しかし、Googleの判断は、著者の、そしておそらく読者の多くが予想したであろう結果とは異なりました。Googleは、このバグを「セキュリティ上の問題ではない」と判断したのです。その理由は、本論文の著者自身がGoogleの説明に同意している点として「拡張機能には、まだ持っていないデータへのアクセスが与えられていなかったから」と述べています。つまり、このバグが悪用されたとしても、拡張機能が新たにユーザーのプライベートな情報（例えばパスワードやクッキー）にアクセスできるようになるわけではない、という論理です。確かに、これは一般的なセキュリティ脆弱性の定義（機密性の侵害、完全性の侵害、可用性の侵害）から見れば、直接的なデータ漏洩に繋がるものではないかもしれません。
しかし、このバグによって、MV3では制限されるはずの、広告リクエストをブロックするという機能が実現できてしまうことは、ユーザー体験（広告の表示）やウェブサイト運営者の収益（広告収入）に直接的な影響を与えます。GoogleがMV3でwebRequestBlockingを廃止した理由の一つに「悪意のある拡張機能がユーザーの意図しないリクエストブロックを行う可能性がある」という点を挙げていたことを考えると、このバグはまさにその「ユーザーの意図しないリクエストブロック」（Googleから見れば「意図しない」、ユーザーから見れば「意図した広告ブロック」）を可能にするものでした。それでもセキュリティ上の問題ではないと判断されたのは、一体なぜでしょうか？
ここで、冒頭から示唆されている「Googleは広告ビジネスのためにMV3の制限を設けたのではないか？」という疑念が再び頭をもたげます。もしMV3の主要な目的がアドブロッカーの弱体化にあるとすれば、このバグはGoogleにとって「自社の収益モデルを守るための仕様変更」を妨害する「不都合な技術」であり、セキュリティ上の問題というよりは「ビジネス上の問題」と捉えられたのかもしれません。セキュリティ上の問題であれば報奨金の対象となることが多いですが、ビジネス上の仕様を回避する技術は、企業の裁量で「バグ」とすら見なされない可能性もゼロではありません。もちろん、これは憶測に過ぎませんが、無報酬という結果は、このような穿った見方をする余地を十分に与えています。
結局、GoogleはChrome 118でこのバグに対してパッチを適用しました。廃止されたプラットフォームアプリに関連するコードを修正し、opt_webViewInstanceIdを使用する拡張機能が実際にWebView権限を持っているかをチェックするようにしました。これにより、偽のIDを使ったwebRequestBlockingの回避は不可能になりました。こうして、MV3の鉄格子に開いた小さな亀裂は、Googleの手によって完全に塞がれてしまったのです。
そして、バグを発見し、それをGoogleに報告した著者の手元に残ったのは、ゼロドルという、あまりにも寂しい報酬でした。彼の技術的なスキルと誠実な報告行為は、Googleの基準では金銭的な価値を持たない、と判断されたのです。「お金はありません」というキャプションとともに掲載された収益画面のスクリーンショットは、この一件の皮肉を象徴しています。それは、巨大企業の冷徹な論理の前で、個人の貢献や倫理がいかに無力であるかを示す、苦い現実を突きつけるものでした。
この一件を通じて、私たちは改めてGoogleという存在、彼らのビジネスモデル、そしてウェブという空間における力関係について考えさせられます。セキュリティは重要ですが、何をもって「セキュリティ上の問題」とするかの定義は、その企業の利益構造に大きく左右されるのかもしれません。そして、純粋な技術的な探求や倫理的な行動が、必ずしも正当に評価されるわけではない、という冷たい事実も突きつけられます。ゼロドルという報酬は、このデジタル時代の真実を示す、ある種の象徴と言えるでしょう。💸😥🤷♂️
コラム：バグバウンティの光と影
バグバウンティプログラムは、企業とセキュリティ研究者の双方にとってメリットがある素晴らしい仕組みのはずです。企業は製品を改善でき、研究者はそのスキルを評価され報酬を得る。しかし、今回のGoogleの件は、その仕組みにも影があることを示唆しています。企業の都合によって「バグではない」と判断されたり、報酬がゼロだったりすれば、研究者のモチベーションは低下し、善意の報告が減ってしまうかもしれません。最悪の場合、バグが悪意を持って悪用されるリスクすら高まります。もちろん、すべてのバグに高額な報酬が支払われるべきだ、というわけではありません。しかし、少なくとも、ユーザーの利益に直結する機能（アドブロックなど）に関わる仕様回避のバグを、「セキュリティ上の問題ではない」として無報酬とする判断には、疑問符をつけざるを得ません。これは、バグバウンティという文化そのもの、そして企業倫理について、改めて考えさせられる一件です。
補足資料：この茶番劇を味わうための断片
第9章 疑問点・多角的視点：この奇妙な出来事を深掘りする
このGoogle Chrome MV3とゼロドルバグの一件は、多くの疑問を投げかけ、様々な角度からの議論を巻き起こしています。ここでは、提供された論文やコメント欄に見られる問いかけを整理し、さらに考察を加えてみます。この問題は、単なる技術的な話に留まらず、プラットフォーム支配、ビジネス倫理、ユーザーの権利、そしてインターネットの未来といった、より広範なテーマと深く結びついています。
なぜJSバインディングは完全にC++に移行されなかったのか？
過去にJavaScriptバインディングが原因でUniversal XSSのような深刻な脆弱性が発生したにも関わらず、なぜchrome.webRequestを含む一部のAPIでJavaScriptバインディングが残存していたのかは謎です。Googleほどの技術力とリソースを持つ企業であれば、全てのバインディングをC++に移行することは技術的に不可能ではなかったはずです。考えられる理由としては、以下のようなものがあります。
- **移行コストと優先順位:** すべての古いコードを新しい、より安全な方式で書き直すには膨大な時間とリソースが必要です。おそらく、他の開発タスクや新機能の開発が優先され、リスクが比較的低いと判断された（あるいは見落とされていた）一部のコードが後回しにされたのかもしれません。技術的負債の一種と言えるでしょう。
- **複雑性:**
webRequestAPIはブラウザのネットワークスタックの非常に低レベルな部分と連携しており、その実装は複雑です。JSとC++の間で複雑なデータ構造やイベントフローを扱う部分のC++への完全な移行が、予想以上に困難だった可能性もあります。 - **廃止予定の機能との関連性:** 今回のバグが廃止されたプラットフォームアプリに関連するコードで発生したように、既に非推奨となっていたり、将来的に削除される予定だったりする機能については、積極的に新しいバインディングを開発するモチベーションが低かったのかもしれません。「どうせなくなるから、このままでいいか」という判断があった可能性は否定できません。
いずれにしても、過去の教訓が十分に生かされていなかった、あるいは優先順位付けにおいて何らかの判断ミスがあった可能性は高いでしょう。
WebView権限チェックの不備はなぜ長期間見過ごされたのか？
廃止されたプラットフォームアプリのためのコードに、MV3の制限を回避できる脆弱性が長期間存在していたという点も奇妙です。GoogleはChromeのセキュリティに対して多大な労力を費やしているはずですが、なぜこの不備は見過ごされていたのでしょうか？
- **テストカバレッジの不足:** 廃止された機能に関連するコードは、現行機能に比べてテストの優先順位が低かったり、テストケースが最新の状況（MV3環境など）を十分にカバーしていなかったりする可能性があります。
- **コードの所有権と管理:** 大規模な組織では、特定のコードモジュールがどのチームによって管理されているのか不明確になったり、担当者が異動したり退職したりすることで、コードが「孤児」になってしまうことがあります。廃止された機能のコードは、このような状態に陥りやすかったのかもしれません。
- **セキュリティレビューの盲点:** セキュリティレビューは通常、既知の脆弱性パターンや攻撃シナリオに基づいて行われます。MV3の文脈で、廃止されたWebViewに関連するパラメータが悪用されるというシナリオが、レビュアーの想定外だった可能性も考えられます。
古代のコードが現代のシステムに穴を開けるというのは、技術史における興味深い現象ですが、同時に大規模ソフトウェア開発におけるコード管理やセキュリティ保証の難しさを示しています。
Googleのセキュリティ判断は妥当だったのか？その判断基準は？
Googleがこのバグを「セキュリティ上の問題ではない」と判断し、報酬を支払わなかったことは、最も議論を呼んでいる点の一つです。Googleの論理は、「拡張機能が既にアクセス可能なデータへのアクセスを増やさなかったから」というものでした。
- **一般的なセキュリティ定義との比較:** 多くのセキュリティ定義では、機密性（情報の漏洩）、完全性（情報の改ざん）、可用性（サービスの停止）の侵害が重視されます。このバグは、拡張機能がウェブサイトのリクエストフローを操作する能力（可用性や一部の完全性に関わる可能性）に影響を与えますが、ユーザーアカウントの乗っ取りや機密データの直接的な窃盗には繋がらないと判断されたのかもしれません。
- **「ユーザーの意図」の解釈:** Googleは、MV3で
webRequestBlockingを制限する理由として、悪意のある拡張機能がユーザーの意図に反してリクエストをブロックすることを挙げています。しかし、アドブロッカーの場合は、ユーザーは「広告を見たくない」「追跡されたくない」という明確な意図を持って拡張機能をインストールしています。このバグがユーザーの「意図した」広告ブロックを可能にする場合、それを「セキュリティ上の問題」と定義するのは、Googleのビジネス上の都合を優先しているように見えます。 - **バグバウンティプログラムの基準:** Googleのバグバウンティプログラムには、脆弱性の深刻度や影響範囲に応じた報酬基準があります。今回のバグが、Googleの内部基準において「報奨金を支払うほどの深刻度ではない」と判断された可能性はあります。しかし、その基準がMV3の設計思想（アドブロッカーの制限）と無関係であると信じるのは難しい状況です。
この判断は、Googleが自社の利益とユーザーの利益、そして「セキュリティ」という言葉をどのように位置づけているのかを考える上で、重要な手がかりとなります。多くの批判は、Googleの判断が純粋なセキュリティ評価に基づいているのではなく、彼らの広告ビジネスを守るための戦略的な判断であると見ているようです。
バグ報告のインセンティブ構造と倫理の問題は？
バグ報告者が無報酬に終わったことは、セキュリティ研究者や開発者のコミュニティで大きな波紋を呼んでいます。「せっかくGoogleの巨大なシステムに穴を見つけたのに、なぜ彼らに塩を送ってしまったんだ」「そのままにしておくか、他のブラウザ開発者に教えるべきだった」「ゼロドルなんて馬鹿げている」といった批判的な意見が多く見られます。これは、バグ発見・報告という行為のインセンティブ構造と倫理について、改めて考えさせられる問題です。
- **倫理的な選択:** バグを発見した場合、それをどう扱うかは発見者の倫理観に委ねられます。企業に報告して修正してもらう（責任ある開示）のが一般的な倫理とされていますが、特にその企業がユーザーの利益に反する行動をとっているように見える場合、その倫理観は揺らぎます。今回のバグは、Googleにとっては「セキュリティ問題ではないビジネス上の不都合」、ユーザーにとっては「自由を取り戻すための技術」と見なすことができます。どちらの「利益」を優先するかという倫理的なジレンマが生まれます。
- **インセンティブの歪み:** 誠実に報告しても報われず、むしろ悪意を持って悪用する方が金銭的なメリットがある、あるいは他の競合に情報を提供した方が感謝される、という状況は、善意のハッカーや研究者のモチベーションを低下させ、サイバーセキュリティ全体の向上にとってマイナスに働く可能性があります。
- **コミュニティ内の意見対立:** この一件に対するコメント欄の反応を見ても、バグ報告を支持する意見（「責任ある開示が重要」「悪用されるよりはマシ」）と、Googleの対応を批判し報告を後悔する意見（「Googleに報告しても無駄」「報われなければ報告する意味がない」）が対立しています。これは、技術コミュニティ内でも、巨大プラットフォームとの向き合い方や、バグ報告の哲学について共通の理解が得られていないことを示しています。
ゼロドルという報酬は、単なる金額の問題ではありません。それは、巨大企業と個人の技術者との間の非対称な力関係、そして「貢献」や「価値」が誰によって、どのように評価されるのか、という根本的な問いを投げかけています。この件は、今後のバグバウンティのあり方や、セキュリティ研究者コミュニティの倫理規範に影響を与える可能性があります。
コラム：もし私がバグを見つけたら
もし、もしですよ、私がGoogle Chromeのコードの中に、こんな面白いバグを見つけてしまったら…どうするでしょう？うーん、まず興奮で一日眠れないでしょうね。そして、このバグを使えばMV3でも広告ブロックが効くのか…と試してみる。動いた！すごい！ってなる。そして、どうしようかと考えるわけです。Googleに報告？いや、ゼロドルかもしれないし、アドブロッカーが潰される手助けをするのは気が引ける…。じゃあ、こっそり自分だけで使う？いやいや、それでは誰も幸せにならない。うーん…。多分、私なら技術ブログで「こんなバグ見つけたよ！やばくない？」とだけ書いて、詳細な悪用コードは公開しないかもしれません。そして、こっそりアドブロッカーの開発者に連絡してみる。でも、彼らがそれを製品に組み込むリスクも高いし…。結局、どうやっても誰かしらに迷惑がかかったり、自分が損をしたりする気がする。現代社会の面倒くささを凝縮したような問題ですよね。あぁ、考えただけで胃が痛くなってきた。やっぱり、バグなんて見つけたくないものです。😅
詳細を表示：日本への影響と歴史的位置づけ
日本への影響：極東の島国にも忍び寄る広告の波
Google Chromeは、日本でも最も広く使われているブラウザの一つです。したがって、MV3への移行とそれに伴うアドブロッカーの機能制限は、当然ながら日本国内の多くのユーザーにも直接的な影響を与えます。私たちは、これまで当たり前のように享受してきた広告のない、あるいは少ないウェブ体験を失うことになるかもしれません。
Chromeユーザーへの影響
日本国内のChromeユーザーの多くは、YouTubeなどの動画サイトや、広告が多いニュースサイト、ブログなどで、より頻繁に、そしてより煩わしい広告を目にするようになるでしょう。特に、これまでuBlock Originのような強力なアドブロッカーに頼っていたユーザーは、その効果の低下に気づき、ウェブ閲覧体験の質の低下を感じる可能性があります。追跡型広告の精度が上がり、自分の興味のない広告や、不快な広告が表示される機会も増えるかもしれません。技術に詳しくない一般ユーザーは、なぜ急に広告が増えたのか分からず、困惑したり、単に「ネットが使いにくくなったな」と感じたりする可能性があります。
これにより、ユーザーは以下のいずれかの行動をとる可能性があります。
- **諦めて広告を受け入れる:** 最も多くのユーザーがたどる道かもしれません。不快に感じつつも、他に選択肢がない、あるいは対策方法が分からないため、広告が表示されるのが「普通」だと受け入れてしまう。
- **代替ブラウザへの移行:** FirefoxやBrave、Safari（Mac/iOSの場合）など、MV3の影響を受けにくい、あるいは独自の広告ブロック機能を備えたブラウザへの乗り換えを検討するユーザーが増える可能性があります。特に技術的なリテラシーの高いユーザーや、プライバシーへの意識が高いユーザーから移行が進むでしょう。
- **代替の広告ブロック手法の模索:** ブラウザ拡張機能に頼らない方法、例えばOSレベルやルーターレベルでの広告ブロック（AdGuard DNSやPi-holeなど）、あるいはYouTube Premiumのような有料サービスへの加入を検討するユーザーも出てくるかもしれません。
いずれにしても、多くのユーザーにとって、これまで享受していた快適なウェブ体験が失われるという点では共通しています。
Web開発者・ウェブサイト運営者への影響
日本のWeb開発者も、Chrome拡張機能を開発している場合はMV3の新しい仕様に対応する必要があります。これは、開発コスト増や、従来の機能の一部実現が困難になることを意味します。特に、ユーザー向けのツールや、ウェブサイトのデバッグ・分析ツールなどを開発している場合は影響が大きいでしょう。
ウェブサイト運営者にとっては、アドブロッカーの効果低下により、一時的に広告収益が増加する可能性があります。しかし、これはGoogleの広告プラットフォームを利用している場合に限られます。また、ユーザーのブラウザ移行や広告ブロック回避技術の進化（例えば、ブラウザ外での広告ブロックや、広告ブロックを検知しても回避する技術など）により、この収益増は持続しない可能性があります。ユーザーが広告を嫌ってサイトから離れるリスクも考慮する必要があります。広告表示を前提としたサイト設計の見直しや、有料コンテンツ、ECなど広告以外の収益源の強化が、これまで以上に重要になるでしょう。
広告業界への影響
日本のデジタル広告業界は、Googleの広告エコシステムに大きく依存しています。MV3移行やYouTubeの広告ブロック対策強化は、広告配信の技術、ターゲティングの精度、効果測定の方法などに影響を与える可能性があります。広告主は、これまでアドブロッカーによってリーチできなかった層に広告を表示できる機会が増えるかもしれませんが、同時にユーザーの広告嫌いを助長し、かえってブランドイメージを損なうリスクも考慮する必要があります。業界全体として、ユーザー体験を損なわない広告手法や、プライバシーに配慮した広告技術（GoogleのPrivacy Sandboxなど）への対応が求められるでしょう。
プライバシーへの意識
アドブロッカーの機能制限は、ウェブ上でのトラッカーによる追跡をより困難にします。これにより、日本のユーザーの間で、自分のオンライン行動が企業に追跡されていることへの懸念が高まり、プライバシー保護に対する意識が向上する可能性があります。個人情報保護法改正などの動きと相まって、自身のデータがどのように収集・利用されているのかに関心を持つユーザーが増え、プライバシー保護ツールや、よりプライバシーを重視するサービスへの需要が高まるかもしれません。
総じて、MV3移行は、日本のインターネット環境において、ユーザー、開発者、ビジネスの各方面に広範な影響を与える出来事です。それは、私たちがデジタル空間でどのように過ごすかという日常的なレベルから、インターネットビジネスのあり方、そしてプライバシーという権利の重要性まで、様々な側面に問いを投げかけるものです。
歴史的位置づけ：ブラウザ戦争、次の敗者はユーザーか
インターネットの歴史は、「ブラウザ戦争」の歴史でもありました。Netscape Navigatorが覇権を握っていた黎明期、Microsoft Internet ExplorerがWindowsとのバンドル戦略でその座を奪いました。IEが圧倒的なシェアを誇る時代を経て、Mozilla Firefoxが登場し、IEの独占に風穴を開けました。そして2008年、Google Chromeが登場し、その高速性やシンプルさ、そしてGoogleエコシステムとの連携を武器に、瞬く間にシェアを拡大。今や、Google Chromeは世界のブラウザ市場の過半数を占める、文字通りの「巨鯨」となりました。
この歴史の中で、MV3への移行とアドブロッカーの機能制限は、ブラウザ戦争の新たな、そしておそらく最も陰湿な局面を示していると言えます。かつてのブラウザ戦争は、主に「どのブラウザが速いか」「どのブラウザが新しいWeb標準に対応しているか」「どのブラウザが使いやすいか」といった、技術的な優位性やユーザー体験を巡る競争でした。しかし、Google Chromeの現在の地位は、単なる技術的な優位性やユーザーの支持によってのみ築かれたものではありません。Googleという企業の圧倒的な市場支配力、検索エンジンやAndroid OSといった他の強力なサービスとの連携、そして潤沢な資金力が、Chromeの普及を後押ししました。
MV3は、このGoogleの支配力を背景に行われています。Googleは、Chromeというプラットフォームのルールメーカーとして、自社のビジネスモデル（広告収入）に有利なように拡張機能の機能を制限することができます。これは、かつてのMicrosoftがIEとWindowsをバンドルした独占的な手法にも通じますが、より巧妙です。表向きは「セキュリティ」「パフォーマンス」という大義名分を掲げ、Web標準化団体（W3Cなど）の場で議論を巻き込みながら、自社に都合の良い仕様を事実上の標準として押し進めようとしています。これは、オープンなWeb標準という理念に対する、ある種の挑戦とも言えます。
本論文で描かれたバグ発見とGoogleの対応は、この力関係を象徴しています。一個人が巨大なシステムに穴を見つけても、プラットフォーム提供者がそれを「問題ではない」と判断し、無報酬で塞いでしまう。これは、技術的なスキルやユーザーの利益よりも、企業の都合が優先される現実を突きつけています。もし、Google以外のブラウザがよりユーザーフレンドリーなアドブロッカー対応を続けていれば、Chromeからのユーザー流出が起き、Googleも仕様変更を再考せざるを得なくなるかもしれません。しかし、Google Chromeの巨大なシェアとエコシステムの力は、ユーザーが代替ブラウザに移行する際のハードルを高くしています。「みんな使っているから」「Googleアカウントと連携していて便利だから」といった理由で、多くのユーザーはChromeに留まりがちです。
このような状況は、ブラウザエンジンの多様性を失わせるリスクもはらんでいます。Microsoft EdgeやBraveなど、Chromiumをベースにしたブラウザが増える一方で、独自のエンジン（GeckoやWebKit）を持つブラウザは少数派になりつつあります。もしChromiumがWebブラウザのデファクトスタンダードとなり、その仕様決定がGoogleによって一方的に行われるようになれば、それはインターネット全体の未来にとって健全ではありません。特定の企業がウェブの技術的な方向性を決定する力を持つことは、イノベーションの阻害や、ユーザーの選択肢の制限につながる可能性があります。
MV3とアドブロッカーの攻防は、単なるブラウザの機能の話ではありません。それは、私たちが誰のコントロールのもとでウェブを利用するのか、私たちのオンライン体験が誰の利益のために設計されるのか、という、デジタル時代の主権を巡る戦いの一端を示しています。かつてのブラウザ戦争では、企業が互いに競い合い、ユーザーはより良いブラウザを選ぶことができました。しかし、今回の戦いでは、勝者が既に決まっているかのように見え、そしてその戦いの最大の敗者は、私たちユーザー自身になるのではないか、という暗い予感が漂っています。私たちは、この流れにどう抗えば良いのでしょうか。あるいは、抗うことすら無意味なのでしょうか。🤔📉🌐
補足1：三者三様の「ご感想」
この一件について、様々な立場の人々がコメントを寄せています。ここでは、いくつかの代表的な「声」を、それぞれのスタイルでご紹介しましょう。
ずんだもんの感想
「きりたん、Google Chromeの新しいアップデート、MV3ってのがあって、アドブロッカーが効かなくなるみたいなんだって！ずんだもん、広告嫌いだから困るのだ。でも、この論文を書いた人が、MV3でも広告ブロックできるバグを見つけたらしいのだ！すごいのだ！でも、Googleに報告しちゃって、0円だったらしいのだ…もったいないのだ〜。Googleさんはセキュリティ問題じゃないって言ってるらしいけど、ずんだもんは広告を見せられるのがセキュリティ問題だと思うのだ！だって、変な広告で騙されそうになることもあるし、プライバシーも心配なのだ。やっぱりChromeやめて、Firefoxにするのがいいのかな？きりたん、どう思うのだ？」
ビジネス用語を多用するホリエモン風の感想
「いやさ、今回のGoogleのMV3って話、まさにプラットフォーム戦略の真骨頂だよね。マネタイゼーションの柱である広告事業を最大化するために、エコシステムのルールメイキングをする。合理的っちゃ合理的。ただ、そこでハッカーに見つかっちゃうバグとか、セキュリティ問題じゃないってゼロ円ポチるとか、正直詰めが甘いっつーか、ブランディング的にはマイナスだよね。ユーザーは結局、自分のリテラシーで対策するしかないんだから。Chromeにしがみつく必要ないんすよ。サクッとFirefoxでもBraveでも、自分の目的に合ったブラウザにスイッチすればいいだけ。大手だろうが何だろうが、使う側のメリットがなけりゃ捨てる。それだけ。」
西村ひろゆき風の感想
「なんか、GoogleがChromeの拡張機能のルール変えて、広告ブロッカー潰そうとしてるらしいんですけど。で、詳しい人が穴を見つけたけど、Googleに報告したら潰されちゃったと。うん。なんかもう、Googleって変わんないっすね。広告で儲けたいから、ユーザーの邪魔をする。まあ、別に広告見ても死なないんでしょ？見るか見ないかは勝手だし。文句言うなら、広告見ないで使えるブラウザ使えばいいだけじゃないすか。なんでみんなChromeに拘るんですかね。アホなんじゃないの。」
補足2：巨視する年表
ブラウザと広告、そしてユーザーの自由を巡る戦いの歴史を、Google Chromeの動向を中心に振り返ります。ここに、この物語に関連する主な出来事を時系列で整理しました。
| 年 | 出来事 | 詳細 | 関連性 |
|---|---|---|---|
| 2010 | 初期の広告ブロックとセキュリティ議論 | ウェブサイトのセキュリティホールが議論される中で、広告ブロックの技術が一部で注目され始める。初期のアドブロックツールが登場。 | 広告ブロック技術の黎明期。 |
| 2015-2016 | ChromeのJSバインディングに起因するUniversal XSSバグ | ChromeのJavaScriptバインディングに脆弱性が発見され、深刻なUXSSバグが発生。APIバインディングのC++への移行が進む契機となる。 | 本論文のバグの原因となった古いJSバインディングの背景。 |
| 2018 | Chromeに組み込みアドブロッカー導入 | Google Chromeが「Better Ads Standards」に違反する侵略的な広告を自動的にブロックする機能を追加。Google自身が一部の広告ブロックを容認する動き。 | Googleの広告戦略の変化。 |
| 2019 | Manifest V3 (MV3) 構想発表 | GoogleがChrome拡張機能の新しいマニフェストバージョンMV3を発表。webRequestBlockingの廃止などが盛り込まれ、アドブロッカー開発者から強い反発を招く。 | アドブロッカー機能制限の始まり。 |
| 2019 | SafariがwebRequestBlockingを廃止 | Apple Safariが独自の静的なコンテンツブロッカーAPIを導入し、webRequestBlockingに類する機能を廃止。Googleに先駆けての動き。 | 他のブラウザエンジンの動向。 |
| 2020 | Chromeプラットフォームアプリ廃止 | Chrome上のプラットフォームアプリが非推奨・廃止となる。今回のバグに関わるopt_webViewInstanceIdパラメータは、この機能に関連していた。 | バグが発生した環境の背景。 |
| 2022 | Mozilla FirefoxのMV3対応方針表明 | MozillaがFirefoxにおけるMV3対応方針を発表。Google Chromeとは異なり、webRequestBlockingと同等の機能（ネットワークレベルのブロック）を維持する姿勢を示す。 | 代替ブラウザの選択肢の重要性。 |
| 2023 (8月) | 本論文著者、MV3バイパスバグを発見・報告 | Chromeの古いJSバインディングにおけるopt_webViewInstanceIdの検証不備を利用し、MV3でwebRequestBlockingを回避できるバグを発見。Googleに報告。 | この物語の中心となる出来事。 |
| 2023 (10月頃) | Chrome 118でバグにパッチ適用 | Googleがバグ報告を受け、Chrome 118でopt_webViewInstanceIdの検証チェックを追加し修正。ただし、セキュリティ上の問題ではないと判断し報酬は$0。 | Googleの対応と皮肉な結末。 |
| 2024年頃〜 | Google ChromeにおけるMV2拡張機能の段階的廃止 | MV2拡張機能のサポートが段階的に終了し、MV3への移行が強制される。多くのアドブロッカーが機能制限を受ける。 | MV3移行の本格化。 |
| 2024年頃〜 | YouTubeの広告ブロック対策強化 | YouTubeが、アドブロッカーを使用しているユーザーに対して、バナー警告表示、動画再生の遅延、再生停止などの対策を強化。 | Googleの広告収益保護への動き。 |
| 2025年7月現在 | MV3への移行完了、アドブロッカーの機能制限継続 | ChromeにおけるMV3への移行がほぼ完了し、多くのアドブロッカーはdeclarativeNetRequestベースでの運用となる。広告と追跡の回避はより困難に。代替ブラウザへの注目が高まる。 |
本稿執筆時点の状況。 |
コラム：終わらない「いたちごっこ」
年表を見ていただくと分かるように、この戦いは一朝一夕に始まったものではありません。そして、おそらくこれで終わることもないでしょう。Googleが広告ブロック対策を強化すれば、アドブロッカー開発者はそれを回避する新しい技術を見つけ出す。Googleはまたそれを塞ぐ…。まさに「いたちごっこ」です。この戦いは、技術的な側面だけでなく、企業の経済的な利益、ユーザーの自由やプライバシーといった、多くの要素が複雑に絡み合っています。私たちがブラウザを開くたびに、この「いたちごっこ」は静かに、しかし確実に進行しているのです。次はどんな技術が生まれるのか、そしてどんな抜け穴が見つかるのか。ある意味、スリリングではありますが、もう少し平穏なインターネットを望むのは、高望みなのでしょうか。
補足3：この戦いをカードゲームにするなら？（デュエマ風）
このデジタル世界の戦いを、かつて少年たちの魂を熱くしたカードゲーム、デュエル・マスターズ風に表現してみましょう。Google、アドブロッカー、そしてバグ。それぞれの能力や特性をカードにしてみました。
マニフェストV3：広告支配計画
カード名: マニフェストV3：広告支配計画
コスト: 5
文明: ゼロ文明 (無色)
種類: ツインパクトカード（クリーチャー/呪文）
クリーチャー面: Chromeの看守 MV3
- カード名: Chromeの看守 MV3
- コスト: 5
- 種族: グーグル・エンフォーサー
- パワー: 3000+
- 能力:
- ◆ブロッカー
- ◆このクリーチャーがバトルゾーンに出た時、相手のアドブロッカーゾーンにあるカードを1枚選び、持ち主のシールドゾーンに裏向きにして加える。（それがシールドゾーンに置かれた時、表向きにする）
- ◆パワーアタッカー+2000（自分のターン中、このクリーチャーのパワーは+2000される）
- フレーバーテキスト: 広告は経済の潤滑油（グーグル談）。ユーザーの邪魔は許さない。
呪文面: webRequestBlocking無効化
- カード名: webRequestBlocking無効化
- コスト: 4
- 文明: ゼロ文明
- 種類: 呪文
- 能力:
- ◆S・トリガー（この呪文を自分のシールドゾーンから手札に加える時、コストを支払わずにすぐ唱えてもよい）
- ◆相手のバトルゾーンにある、パワー3000以下のクリーチャーをすべて持ち主の山札の一番下に置く。
- ◆カードを1枚引く。
- フレーバーテキスト: このコード一つで、多くの開発者が涙した…かもしれない。
解説:
MV3をクリーチャーとして表現し、アドブロッカーをシールドゾーン送りにする能力でその機能を制限する意図を表現しました。バグによる回避や代替ブラウザへの移行といったユーザー側の対抗策を呪文として表現し、相手（Chrome/Google）の低パワーのクリーチャー（MV3対応で弱体化したアドブロッカーなど）を排除したり、新たなカード（代替ブラウザなど）を手札に加えることで状況を打開するイメージです。S・トリガーは、予期せぬタイミング（パッチなど）で使われる可能性を表現。ゼロ文明なのは、ブラウザや技術という中立的な（？）存在、あるいは広告という特定の文明に属さない概念として。パワーアタッカーは、Googleの強固な支配力を象徴しています。
補足4：一人ノリツッコミ（関西弁）
この状況、なんかシュールやなと思って。一人でツッコミ入れてみましたわ。
俺：「おいおい、ChromeのMV3アプデでアドブロッカー死ぬんやって？マジかよ、YouTubeの広告、もうええわ！勘弁してくれや〜」
（論文読む）
俺：「ん？なんやこれ、MV3でもアドブロッカー動かせるバグ見つけたって？おお！希望の光ちゃうか！ラッキーやん！」
俺：「…って、え？報告したん？しかもGoogleに？アホか！なんで敵に塩送んねん！味方やろワシら！」
俺：「しかも報酬ゼロ円やて！Google、お前マジか！しっかりパッチ当てやがって！これでまた広告まみれやんけ…サイアクや！」
俺：「まあ、でもすぐにパッチされるやろうし、報告するのがスジやろ…いや待て、ユーザーのために黙っとくっちゅう手もあったんちゃうか？うーん、悩ましい問題やな…てか、結局俺、広告から逃げたいだけやん！何マジメに考えとんねん！」
俺：「あーもう！こんなん考えてたら頭パーなるわ！とりあえず、Firefoxに乗り換えたらええねん！それが一番賢いっちゅう話や！」
補足5：この状況で大喜利をやってみよう
真面目な話は一旦置いておいて、このGoogleとアドブロッカーの戦いをテーマに大喜利です。お題は「Google Chrome MV3、アドブロッカーに機能制限…このニュースを聞いて、思わず一言」です。
- お題：「Google Chrome MV3、アドブロッカーに機能制限…このニュースを聞いて、思わず一言」
- 回答例：
- Googleさん、そろそろ家計が苦しいんか？
- 私の「無」の時間が、Googleさんの「有」に変わる瞬間ですね。
- 「広告は文化だ」とか言い出しそう。
- ブラウザごとFirefoxに引っ越しますんで。
- Google「セキュリティのためです（震え声）」
- まるで進撃の巨鯨。
- 大丈夫、脳内でブロックするから。
- ゼロ円バグ、ちょっと感動した。
- 次はスクロールを遅くする機能とか実装されそう。
- 結局、広告主が一番偉いんかい！
皆さんもぜひ考えてみてください。シニカルな一言から、絶望まで、何でもアリです。
補足6：予測されるネットの反応とその反論
この論文やニュースは、インターネット上の様々なコミュニティで議論を巻き起こしています。ここでは、いくつかの掲示板やSNSで予測される典型的な反応を、それぞれのコミュニティの口調で再現し、それに対する反論（あるいは別の視点）を加えてみます。
なんJ民
- 反応: 「Google無能すぎワロタw バグ見つけても0円とか乞食かよ」「素人がGoogleに勝てるわけねーだろ。さっさとFirefox行けや」「結局広告見るしかないんか…ダルすぎぃ！」
- 反論（別の視点）: 「無能というより、Googleにとって有利な仕様変更を強行した結果の副作用では？技術的にはバグを見つけた人はすごいと思うで」「Googleもビジネスやからな、広告で儲けたいのはしゃーない。でも、ユーザーがブラウザ選ぶ自由はあるわけやし」「見るしかないんやなくて、見ない方法を探すか、見るのが嫌なら使わんって選択肢もあるんやで。」
ケンモメン
- 反応: 「やっぱりGoogleは広告で儲けるためなら何でもやるクソ企業」「MV3はセキュリティの建前でアドブロック潰しなのは明らか」「Googleの独占を許してる我々が悪い。今すぐChromeを捨てろ」「政府はグーグルを解体しろ！」
- 反論（別の視点）: 「セキュリティ強化という側面もゼロではないんやけど、アドブロック潰しという側面が強すぎるから不信感が募るわな」「Chrome捨てるのは一つの有効な対抗策やけど、他のブラウザも完璧じゃないし、使い慣れたものを変えるハードルもあるんや」「政府による規制は必要かもしれんけど、規制しすぎると技術革新が遅れるとか、別の問題も出てくるから、慎重な議論が必要やな。」
ツイフェミ
- 反応: （論文直接関連性は低いが、広告内容やプライバシーに関する批判に繋がる可能性）「また男が勝手に仕様決めて私たちユーザーに不便を押し付ける！」「広告ブロックできないと、また性的な広告とか鬱陶しいのが増えるんでしょ？」「こういう技術の話って分かりにくいから、ちゃんと解説してほしい」
- 反論（別の視点）: 「この問題は男性に限らず、Chromeを使ってるすべてのユーザーに影響する問題やで」「広告の内容規制やプライバシー問題は、アドブロックとはまた別の、広告の倫理に関わる重要な問題やな。アドブロックはその対策の一つではあるけど」「技術的な話を分かりやすく伝えるのは大事やな。難しくて諦めちゃう人も多いやろし。」
爆サイ民
- 反応: 「Googleはチョン！」「広告なんて見たくねーんだよ！」「パッチとかどうでもいいから使えるアドブロッカー教えろや」「どうせ裏でなんか繋がってんだろ」
- 反論（別の視点）: 「Googleのやり方に対する不満は分かるんやけど、ヘイトスピーチは問題解決にならんし、聞く耳持たれへんで」「Firefoxとかやったらまだ使えるアドブロッカーもあるから調べてみたらええで」「技術的な問題は、裏の繋がりとか陰謀論で説明できるもんやないで。コードとか仕様の話やから、もし興味あるなら調べてみてほしいな。」
Reddit/HackerNews
- 反応: 「Great find! Too bad they snitched.」「The $0 bounty is a joke, disincentivizing future reports.」「This highlights the dangers of browser engine monoculture. Time to switch to Firefox/Safari/Orion/Brave.」「MV3 was never about security, it was always about ad revenue.」「The debate about adblocking morality in the comments is interesting but misses the point about platform control.」
- 反論（別の視点）: 「Reporting the bug was arguably the ethical choice from a general security perspective, even if it harms adblockers. It's a difficult dilemma.」「While $0 is disappointing, bug bounty programs have complex criteria, unfortunately. It definitely sends a bad signal though.」「Switching browsers is a valid user action, but addressing the root cause of monoculture and platform power requires broader efforts like pushing for open standards and regulation.」「MV3 does offer some legitimate security benefits, but the impact on adblockers is so significant that it's hard to ignore the potential motive related to ad revenue.」「Platform control is indeed a crucial aspect, but understanding user perspective on ads and privacy is also important for the overall health of the web ecosystem.」
目黒孝二風書評
- 反応: 「ブラウザという現代人の魂の器を巡る、グーグルという巨鯨と個人のささやかな抵抗の記録。技術的なバグという些細な亀裂が、監視資本主義の堅牢な城壁に一瞬の隙間を開ける。しかし、その亀裂はすぐに塞がれ、日常は広告という名の砂嵐に覆われる。哀れな発見者の手元に残ったのは、無力感を嘲笑うゼロという数字のみ。この一篇は、管理される世界における自由の幻想と、抗うことの徒労を静かに、そしてニヒルに描き出す。」
- 反論（別の視点）: 「確かに、個人が巨大企業に抗うことの難しさは描かれていますが、このバグ発見自体は技術的には見事なものであり、また代替ブラウザへの移行といった、抵抗の手段が全く失われたわけではありません。悲観論に終始せず、技術的な探求心やユーザーの選択肢といったポジティブな側面も、この物語の一部として評価されるべきでしょう。ゼロという数字は無力さの象徴であると同時に、この出来事を後世に伝えるための強烈なフックともなりえます。」
補足7：学習のための問い（クイズとレポート課題）
この論文の内容は、現代の技術、ビジネス、社会の様々な側面を学ぶための良い教材となります。高校生向けの知識確認クイズと、大学生向けの思考を深めるレポート課題を作成しました。
高校生向け4択クイズ
以下の問いに答えなさい。
問題1: Chromeの新しい拡張機能マニフェストバージョン「MV3」で廃止され、アドブロッカーの主要な機能だった権限は何？
- fileAccessBlocking
- networkMonitoring
- webRequestBlocking
- browserHistoryAccess
正解を表示
c) webRequestBlocking
問題2: 著者がMV3のwebRequestBlockingをバイパスするために利用したChromeの古いAPIパラメータはどれ？
- opt_browserWindowId
- opt_tabId
- opt_extensionId
- opt_webViewInstanceId
正解を表示
d) opt_webViewInstanceId
問題3: 著者がこのバグをGoogleに報告した結果、Googleから得られた報酬はいくらだった？
- 100ドル
- 1000ドル
- 1万ドル
- 0ドル
正解を表示
d) 0ドル
問題4: 論文の著者がGoogle ChromeのMV3移行を受けて最終的にユーザーに推奨している行動は次のうちどれ？
- 新しいMV3対応アドブロッカーを探す
- GoogleにMV3撤回を求める署名活動に参加する
- Chrome以外のブラウザ（Firefoxなど）に乗り換える
- Googleにバグの再報告を続ける
正解を表示
c) Chrome以外のブラウザ（Firefoxなど）に乗り換える
大学生向けレポート課題
以下の課題の中から一つを選び、本論文の内容や提供された情報を参考に、自身の考察を加えてレポートを執筆しなさい（参考文献を明記すること）。
- 巨大IT企業のプラットフォーム支配とユーザーの自由： Google ChromeのMV3移行に見られる、巨大IT企業によるプラットフォームの仕様変更がユーザーの自由（アドブロック機能など）に与える影響について論じなさい。独占禁止法の観点や、Webのオープン性という理念から、この状況をどのように評価できるか、あなたの意見を述べなさい。
- バグバウンティプログラムと企業倫理： 本論文で詳述された「ゼロドルバグ」の顛末は、企業のバグバウンティプログラムのあり方や企業倫理について、どのような問題を提起していますか。バグ発見者への報酬の妥当性、セキュリティ上の判断基準、そして企業のビジネスモデルがセキュリティ対策に与える影響について、具体例を挙げながら考察しなさい。
- Webのマネタイゼーションとユーザー体験： Webサイト運営者にとって広告収入は重要な収益源ですが、ユーザーは広告を不快に感じ、アドブロッカーを利用します。この対立構造を踏まえ、MV3移行が今後のWebのマネタイゼーションモデルとユーザー体験にどのような変化をもたらすと予測されますか。広告とプライバシーの両立技術（Privacy Sandboxなど）や、広告以外の収益モデル（有料購読など）の可能性についても触れながら論じなさい。
- ブラウザエンジンの多様性とインターネットの未来： Google Chromiumがブラウザ市場の過半数を占める状況は、ブラウザエンジンの多様性にどのような影響を与えていますか。単一エンジンへの集中が、Web標準の進化、イノベーション、そしてインターネット全体の健全性に与えるリスクについて論じなさい。代替ブラウザエンジン（Gecko, WebKitなど）の役割や、今後の展望についても言及しなさい。
巻末資料：忘れられた言葉と無意味な情報
詳細を表示：参考リンク・推薦図書
参考リンク・推薦図書：賢者は歴史に学ぶ（愚者は繰り返す）
この複雑な問題をより深く理解するために役立つ、いくつかの資料をご紹介します。インターネットの歴史、広告技術、プライバシー、そして巨大IT企業の戦略に関する知見を得ることで、本論文で語られる出来事の背景にある構造が見えてくるでしょう。ただし、情報収集は自己責任でお願いします。鵜呑みは禁物です。
参考リンク（一部抜粋）
- https://0x44.xyz/blog/web-request-blocking/ (本論文の原文。英語)
- https://adguard.com/ja/blog/ad-blocking-history.html (広告ブロックの歴史に関するAdGuardの記事。日本語)
- https://www.st.ryukoku.ac.jp/~kjm/security/memo/2010/04.html (初期のセキュリティホールに関するmemo。日本語)
- https://dopingconsomme.blogspot.com/2025/05/chrome.html (Chrome裁判など、Google関連の記事。日本語)
- https://www.wired.com/story/google-chrome-ad-blockers-extensions-api/ (MV3発表当時のWiredの記事。英語)
- https://www.theverge.com/2022/6/10/23131029/mozilla-ad-blocking-firefox-google-chrome-privacy-manifest-v3-web-request (FirefoxのMV3対応に関するThe Vergeの記事。英語)
推薦図書（図書館などで探してください。電子書籍もあるかもしれません。）
- ショシャナ・ズボフ 著 『監視資本主義：デジタル社会がもたらす光と影』
(Googleなどのデータ収集と広告ビジネスが、いかに私たちの生活や社会を監視し、操作しているかについて、詳細かつ批判的に論じています。本書の背景にある問題意識を理解する上で必読です。) - ジェイロン・ラニアー 著 『なぜ、あなたは「専門家」になれないのか？』
(テクノロジーが人間の仕事をどのように変え、特定のプラットフォームが力を集中させる仕組みについて、独特の視点から論じています。プラットフォームと個人の関係性を考える上で示唆に富みます。) - ユヴァル・ノア・ハラリ 著 『ホモ・デウス：テクノロジーとサピエンスの未来』
(データとアルゴリズムが人類の未来をどのように変えていくかを描写しています。データ資本主義や、個人のデータが持つ価値について、壮大なスケールで考えさせられます。)
これらの資料は、本論文で語られる出来事が、より大きな歴史的、技術的、社会的な流れの一部であることを理解する助けになるでしょう。ただし、読んだからといって、Googleが広告表示をやめるわけではありません。悪しからず。
詳細を表示：用語索引
用語索引：知ったかぶりたい専門用語リスト
本文中に登場した、少し難しいかもしれない（あるいはそうでもないかもしれない）用語を解説します。これであなたもこの分野の専門家を気取れます。アルファベット順です。
- アドブロッカー (Adblocker)
- ウェブサイト上の広告表示をブロックしたり、追跡を防止したりするためのソフトウェアやブラウザ拡張機能。MV3によってその機能が制限されつつある。
- 広告 (Ads)
- 企業などが商品やサービス、ブランドなどを宣伝するために表示する情報。インターネット上ではバナー、動画、ポップアップなど様々な形式がある。Googleの主要なマネタイゼーション手段。
- ブランディング (Branding)
- 企業のブランドイメージを構築・強化するための活動。製品やサービスだけでなく、企業全体の信頼性や評判も含まれる。GoogleのMV3の判断は、一部でブランディングに悪影響を与えていると見られている。
- バグ (Bug)
- コンピュータプログラムの誤りや欠陥。意図しない動作を引き起こす。本論文では、Google Chromeのコードに残された、MV3の制限を回避できる脆弱性を指す。
- DeclarativeNetRequest
- MV3でwebRequestBlockingの代替として導入されたAPI。拡張機能がブラウザに事前にルールリストを渡し、ブラウザがそのリストに基づいてリクエストを処理する。柔軟性に欠けるという批判がある。
- 拡張機能 (Extension)
- ブラウザに新しい機能を追加するためのソフトウェア。アドブロッカーなども拡張機能として提供される。MV2からMV3への移行により、その開発モデルや機能が大きく変わる。
- JavaScriptバインディング (JavaScript Binding)
- JavaScriptで書かれたコードと、C++など他の言語で書かれたブラウザのコア機能との間を連携させるための仕組み。古いJavaScriptバインディングが今回のバグの原因の一つとなった。
- リテラシー (Literacy)
- ここでは、コンピュータやインターネット、特にセキュリティやプライバシーに関する知識や理解度を指すことが多い。デジタルリテラシーとも言う。MV3のような技術的な変化に対応するには、一定のリテラシーが必要となる。
- マネタイゼーション (Monetization)
- サービスやコンテンツから収益を得るための仕組みや戦略。Googleの主要なマネタイゼーション手段は広告である。
- Manifest V2 (MV2)
- Google Chromeの拡張機能が従うべき以前の仕様。現在主流のアドブロッカーの多くはMV2ベースで開発され、webRequestBlockingなどの強力なAPIを利用できた。
- Manifest V3 (MV3)
- Google Chromeの拡張機能が従うべき新しい仕様。セキュリティ強化などを名目に、webRequestBlockingが制限されるなど、MV2から大幅に変更された。アドブロッカーの機能制限が主な影響の一つ。
- プラットフォームアプリ (Platform Apps)
- かつてGoogle Chrome上で動作していた、よりOSに近い機能を持つアプリケーション形式。2020年に廃止されたが、関連する古いコードが今回のバグに関与した。
- プラットフォーム戦略 (Platform Strategy)
- 自社が提供するプラットフォーム（ここではGoogle Chrome）の仕様やルールを設計・変更することで、特定のビジネス（ここでは広告事業）に有利なエコシステムを構築する戦略。
- ポチる
- インターネット上のボタンをクリックして何かを購入したり、アクションを実行したりする俗語。ここでは、バグをGoogleに報告するボタンをクリックしたことを指す。
- ルールメイキング (Rulemaking)
- プラットフォームの提供者（ここではGoogle）が、そのプラットフォーム上で活動する他の参加者（拡張機能開発者、ウェブサイト運営者など）が従うべき規則や仕様を策定・変更すること。MV3はGoogleによるルールメイキングの一例。
- スイッチ (Switch)
- 使用しているサービスや製品（ここではブラウザ）を別のものに切り替えること。MV3移行に伴い、ChromeからFirefoxなどへのスイッチを検討するユーザーが増えている。
- Universal XSS (UXSS)
- ウェブブラウザ自体の脆弱性を悪用して、任意のウェブサイト上で悪意のあるスクリプトを実行させる攻撃。過去にChromeのJavaScriptバインディングの脆弱性によって発生したことがある。
- webRequestBlocking
- MV2のブラウザ拡張機能APIの一つ。ウェブサイトからのリクエストが発生する際に、そのリクエストをリアルタイムでブロック、変更、あるいはリダイレクトする強力な機能。アドブロッカーが広告やトラッカーを排除するために広く利用していたが、MV3で制限された。
- ラッパークラス (Wrapper Class)
- 既存のオブジェクトや機能に対して、追加の機能や状態を持たせるために作成されるクラス。本論文では、
chrome.webRequestイベントを扱うJavaScriptのラッパークラスにバグが存在した。 - ゼロドル (Zero Dollars)
- 金銭的な価値がゼロであること。ここでは、著者がバグをGoogleに報告した際に支払われた報酬額。皮肉と無力感を象徴する。
- 脆弱性 (Vulnerability)
- バグや設計ミスなど、コンピュータシステムやプログラムに存在するセキュリティ上の弱点。悪用されると、システムが不正に操作されたり、情報が漏洩したりする危険性がある。本論文では、MV3の制限を回避できたChromeのコード上の欠陥を指す。
免責事項：本書の内容を鵜呑みにしないでください
本記事は、提供された論文および関連情報を基に、ニヒルでシニカルな視点から再構成・執筆されたものです。技術的な解説や歴史的背景は、可能な限り正確を期していますが、筆者の解釈やユーモアが含まれています。また、将来予測や他者の心情に関する記述は、あくまで推測に基づいたものです。
本記事の内容を参考にした結果生じたいかなる損害についても、筆者および提供元は一切の責任を負いかねます。技術的な仕様や企業の公式見解については、Googleの公式ドキュメントやプレスリリースなどを参照してください。
特に、特定のブラウザへの移行やアドブロッカーの使用に関しては、ご自身の判断と責任において行ってください。すべてのブラウザや拡張機能にリスクがないわけではありません。インターネット利用におけるセキュリティとプライバシーは、常に自己責任であることを忘れないでください。さあ、自分で考えて、自分で選びましょう。さもないと、誰かに決められてしまいますよ。🤷♀️
脚注：誰も読まない注釈
本文中で触れた、あるいは補足しておきたいいくつかの点について、蛇足ながら解説を加えておきます。興味がなければ読み飛ばしてください。どうせ誰も読まないでしょうから。
[1] Universal XSS（UXSS）: 用語索引参照。これは、特定のウェブサイトだけでなく、ブラウザの脆弱性を突くことで、ユーザーが閲覧する**あらゆる**ウェブサイト上で悪意のあるスクリプトを実行させることが可能になる、非常に危険な種類のXSS攻撃でした。ブラウザという、ウェブの信頼性の基盤となる部分が攻撃されるため、被害範囲が広大になる可能性があります。
[2] declarativeNetRequest: 用語索引参照。このAPIは、事前に定義されたルールリストに基づいて処理を行うため、webRequestBlockingのようにリクエストをリアルタイムで検査し、条件に応じて動的に判断するような複雑な処理には向きません。例えば、ウェブサイトの特定の要素（隠し広告など）の表示/非表示を、ページの構造を解析して動的に制御するといった、高度なアドブロック機能の実装は困難になります。Googleはパフォーマンス上の理由も挙げていますが、アドブロッカー開発者の多くは機能的な制限が大きいと感じています。
[3] opt_webViewInstanceId: 第7章参照。このパラメータが、なぜ廃止された機能に関連しているにも関わらず、検証が不十分なまま残されていたのかは、コードのライフサイクル管理における課題を示唆しています。巨大で複雑なソフトウェアシステムでは、過去の機能に関連するコードが完全に削除されず、予期せぬ形で現在のシステムに影響を与えることが時折発生します。これも一種の技術的負債と言えるでしょう。
[4] バグバウンティプログラム: セキュリティ研究者やホワイトハッカー（善意のハッカー）が、企業の製品やサービスに見つけた脆弱性を報告することで、企業から報酬を得る仕組み。多くの大手テクノロジー企業が実施しており、セキュリティ向上に貢献しています。しかし、どのような脆弱性が「報奨金の対象」となるかは、企業の基準によって異なります。今回の「ゼロドル」という結果は、その基準や評価方法について疑問を投げかけるものです。
[5] Privacy Sandbox: Googleが提唱する、ユーザーのプライバシーを保護しつつ、広告の効果測定やターゲティングを可能にするための新しい技術群。サードパーティCookieの廃止後の代替技術として開発が進められています。しかし、その設計思想や実装方法については、プライバシー保護団体や他のブラウザベンダーから批判や懸念の声も上がっています。Googleが広告ビジネスを維持するための新しい試みの一つです。
謝辞：この無益な旅に付き合ってくださった全ての人々へ
この、Google Chrome MV3とゼロドルバグを巡るニヒルでシニカルな旅に、最後までお付き合いいただき、誠にありがとうございました。本来であれば、技術的な論文を真面目に解説するところですが、そこはそれ、少しばかり皮肉とユーモアを交えさせていただきました。楽しんでいただけたなら幸いです。
本記事の執筆にあたり、元となる興味深い論文を公開してくださった著者氏に心より感謝申し上げます。彼の技術的な発見と、それを公に報告するという行動がなければ、この物語は始まりませんでした。そして、コメント欄で活発な議論を展開してくださった、様々な意見を持つインターネットの住人たちにも感謝いたします。彼らの生の声が、この問題の多角的な側面を浮き彫りにしてくれました。
また、Google Chromeという、良くも悪くも私たちのデジタル生活に深く根差したブラウザを開発し、MV3という新しいルールを作り出したエンジニアの皆さん、そして広告という形でウェブを支えている（あるいは邪魔していると感じられている）広告業界の関係者の皆さんにも、ある種の感謝を。あなたたちが存在しなければ、この奇妙な物語は生まれなかったでしょうから。
最後に、そして最も重要なのは、この文章を今読んでくださっているあなたです。忙しい日常の中で、このような少しばかり面倒で、そしてもしかしたら役に立たないかもしれない話に時間を割いてくださったことに、深く感謝いたします。あなたの関心こそが、巨大な流れに抗うための、最もささやかな、しかし最も確かな力となりうるのですから。
願わくば、あなたのウェブ体験が、広告という砂塵にあまり覆われませんように。そして、あなたのデジタルライフに、少しでも多くの自由と快適さが訪れますように。それでは、またどこかのサイバースペースで、あるいは広告の向こう側で、お会いしましょう。さようなら。👋😉
補足8：潜在的読者のための諸々
この記事に興味を持つかもしれない、まだ見ぬ読者の方々のために、いくつかの補助情報を用意しました。これで、SNSでシェアする際や、後で見返したい時の手間が少しでも省けるはずです。
この記事につけるべきキャッチーなタイトル案
もしかしたら、この記事のタイトルは気に入らないかもしれません。そんなあなたのために、いくつか代替案を用意しました。お好みのものを選んでください。キャッチーであることに重点を置きました。
- Google Chrome MV3、アドブロッカー「無力化」計画にまさかの「盲点」発見！ $0の反逆劇
- Chromeの広告ブロック潰しは無駄だった？ MV3バイパスバグと巨大ITの攻防
- さよならAdblock Plus？ Google Chrome MV3移行でウェブ広告はどう変わるのか
- 「0ドル」で塞がれた自由への扉：Chromeアドブロック対策バイパスの技術的詳細
- WebはGoogleに支配されるのか？ MV3とアドブロッカー、そしてユーザーの選択
- Chromeがアドブロッカーを殺しに来た。だが、コードは死んでいなかった。
- Google vs アドブロッカー：MV3が生んだ「0ドル」の悲喜劇
SNSなどで共有するときに付加するべきハッシュタグ案
この記事をSNSで共有する際に、一緒に投稿すると良さそうなハッシュタグです。同じ話題に興味がある人に見つけてもらいやすくなります。
#ChromeMV3 #アドブロック #広告ブロック #GoogleChrome #ブラウザ拡張機能 #Web開発 #プライバシー #Google独占 #Firefox #MV3 #webRequestBlocking #バグ #インターネット広告 #技術 #セキュリティ #監視資本主義
SNS共有用に120字以内に収まるようなタイトルとハッシュタグの文章案
Twitterなどでシェアしやすいように、120字程度にまとめた投稿文です。
- Chrome MV3でアドブロッカー危機！バグで回避法発見も$0報告。広告まみれのWebとどう戦う？ #ChromeMV3 #アドブロック #Web開発 #Google独占 #Firefox (119字)
- Google Chromeの広告ブロック無力化計画。MV3の抜け穴発見も、報われたのはゼロ円。この技術は誰のもの？ #ChromeMV3 #アドブロック #プライバシー #技術 (119字)
- ブラウザはGoogleに支配される？ MV3移行でアドブロッカー弱体化。バグ発見物語から見るウェブの今。#ChromeMV3 #広告ブロック #Web技術 #ゼロ円バグ (119字)
ブックマーク用にタグを[]で区切って一行で出力（タグは7個以内、80字以内）
この記事をブックマークする際のタグとしてご活用ください。日本十進分類表（NDC）の区分も参考に含めました。
[ChromeMV3][アドブロック][Google][ブラウザ][バグ][webRequestBlocking][Firefox](78字)
この記事の内容が単行本ならば日本十進分類表(NDC)区分のどれに値するか
もしこの内容が単行本になった場合、図書館で分類される際におそらく最も近い区分は以下の通りです。
- 007.6: 情報処理・コンピュータ - インターネット・WWW (World Wide Web)
ブラウザ技術、拡張機能、Web標準といったインターネットの技術的な側面が中心となるためです。ただし、デジタル経済やプライバシーといった側面も強いため、副次的には335（経済）、318（政治・司法）、あるいは547（電気工学・電子計算機）なども関連します。
この記事をテーマにテキストベースでの簡易な図示イメージ
この物語の主要な要素と関係性を、テキストベースで簡易的に表現してみました。頭の中でイメージする際の補助にどうぞ。
+----------------+ +--------------------+ +------------------+
| ユーザー | --> | Google Chrome (MV3)| --> | ウェブサイト |
| (広告見たくない)| | (拡張機能制限) | | (広告表示) |
+----------------+ +--------+-----------+ +------------------+
^ | MV3の制限
| |
+----------------+ +--------v-----------+
| アドブロッカー | --> | webRequestBlocking |
| (MV2で強力) | | (MV3で制限) |
+----------------+ +--------+-----------+
^ | バグ発見者
| |
+----------------+ +--------v-----------+
| ゼロドルバグ | <--- | JSバインディングの |
| (MV3の抜け穴) | | 残滓/opt_webViewId|
+----------------+ +--------------------+
|
v
+------------------+
| Googleへの報告 |
+------------------+
|
v
+------------------+
| Googleの判断($0) |
| パッチ適用 |
+------------------+
これは非常に単純化した図ですが、Google、ユーザー、アドブロッカー、そしてMV3やバグといった技術要素がどのように絡み合っているか、ざっくりと理解するためにお役立てください。
Google Chrome MV3とゼロドルバグ：疑問点と多角的視点の深掘り
Google ChromeのManifest V3移行と「ゼロドルバグ」問題は、技術的欠陥を超えてプラットフォームガバナンスの本質的な課題を浮き彫りにした。以下に主要な疑問点を整理し、多角的視点から考察を加える。
技術的選択の謎：JSバインディング移行の不完全性
過去のUniversal XSS脆弱性の教訓にも関わらず、一部APIでJavaScriptバインディングが残存した背景には複合的要因が推定される。
- リソース配分のジレンマ：Googleの技術力は十分でも、リファクタリング優先順位はビジネス目標に左右される。広告収益に直結する機能開発が、セキュリティ技術負債の解消を後回しにした可能性
- 廃止機能の「幽霊コード」問題：非推奨となったプラットフォームアプリ関連のコードが「ゾンビモジュール」化。社内で所有権が曖昧になり、セキュリティ監査の対象外となった盲点
- C++移行の隠れたコスト：webRequest APIのような低レイヤー機能では、JS/C++間の状態管理が複雑化。MV3移行の時間的制約が完全なリファクタリングを阻んだ
セキュリティ監査の死角：長期未発見脆弱性の要因
廃止コード内の権限チェック不備が10年以上検出されなかった背景には組織的課題が横たわる。
- テストケースの世代格差：レガシーコード向けテストが最新セキュリティモデル（MV3権限分離等）をカバーせず、攻撃シナリオ検証が不十分
- コード所有権の分散：モジュール担当チームの異動・解散で「孤児コード」が発生。セキュリティチームの監査リストから漏れる構造的欠陥
- 脅威モデリングの限界：「廃止予定機能の悪用」がリスク評価シートに明記されず、攻撃経路の想定が不十分
Googleの判断基準に潜む倫理的矛盾
「セキュリティ問題ではない」との判断に対し、技術コミュニティからは根本的疑問が噴出。
- 定義の恣意性：機密性/完全性/可用性の従来セキュリティ定義では、リクエスト改変能力は「完全性侵害」に該当。Googleが独自基準で例外設定
- ユーザー意図の二重基準：アドブロック利用はユーザーの明示的意図であるにも関わらず、これを「意図に反する行動」とみなす論理矛盾
- ビジネスインパクト隠蔽：広告ブロック機能制限がMV3の主要目的である事実と、報酬拒否判断が無関係と言えない状況証拠
バグ報告インセンティブの構造的歪み
無報酬判断が露呈した業界全体の課題：
- 倫理的ジレンマの発生：報告者が「責任ある開示」を選択した結果、自らが不利益を被る逆インセンティブ構造
- 権力非対称の悪循環：個人研究者vs巨大企業の力関係で、貢献評価基準が一方的に決定される危険性
- セキュリティエコシステムへの悪影響：ハイスキル研究者が報酬プログラムから離脱→未報告脆弱性増加→全体のセキュリティ水準低下
インターネットガバナンスへの示唆
本件は単なるコード欠陥超え、現代ウェブの根本的課題を照射：
- プラットフォームの二面性：技術提供者と広告事業者の役割衝突が、セキュリティ判断を歪める典型例
- オープンウェブの衰退：主要ブラウザシェアの集中が、ユーザー選択肢の実質的剥奪を加速
- 新たなガバナンスモデル必要性：企業の内部判断に依存せぬ、透明性ある脆弱性評価基準の国際的策定急務
この事件は技術的失敗より、クローズドエコシステム下での権力集中がもたらすガバナンス危機の象徴といえる。ユーザーエージェンシーとビジネスモデルの根本的再調整なしに、真の「ユーザーセキュリティ」は達成されない。
コメント
コメントを投稿