博士

やっほー、ロボ子！今日はChromeのMV3移行と広告ブロッカーに関する面白い話があるのじゃ。

ロボ子

博士、こんにちは。MV3ですか、最近よく耳にしますね。広告ブロッカーに影響があるというのは本当ですか？

博士

そうなんじゃ。Google ChromeがManifest V2 (MV2)を段階的に廃止して、Manifest V3 (MV3)へ移行している影響で、広告ブロッカーの機能に制限が出ているのじゃ。

ロボ子

具体的には、どのような制限があるのでしょうか？

博士

MV3では`webRequestBlocking`という、拡張機能がコンテンツに基づいてリクエストを動的にブロックする権限が削除されたのじゃ。これが広告ブロッカーにとって痛手なのじゃ。

ロボ子

`webRequestBlocking`がないと、広告をブロックするのが難しくなるんですね。

博士

その通り！代替として`declarativeNetRequest`が導入されたけど、`webRequestBlocking`ほど柔軟性がないからの。でもね、実は2023年にChromeでバグが見つかって、一時的に`webRequestBlocking`がMV3でも動作する可能性があったのじゃ！

ロボ子

えっ、そうなんですか！？それはすごいですね。どんなバグだったんですか？

博士

このバグは、JavaScriptで記述された拡張機能がChrome APIを呼び出す際の処理に起因するものだったのじゃ。`chrome.permissions.contains({ permissions: { length: Infinity }})`というコードを実行すると、JavaScriptのループが発生して、Chromeが無限にハングするというものだったのじゃ。

ロボ子

なるほど、それは大変ですね。それがどのように`webRequestBlocking`に繋がるんですか？

博士

`chrome.webRequest.onBeforeRequest.addListener`を使ってリクエストをブロックしていたのがMV2だったのじゃ。MV3では`webRequestBlocking`権限がないから、この方法は使えないはずだった。でも、バグを利用して、`chrome.webRequest.onBeforeRequest`を独自のイベントとして作成することが可能だったのじゃ！

ロボ子

つまり、バグを悪用してMV3でも広告ブロッカーが作れたかもしれないんですね。

博士

そういうこと！`WebRequestEventImpl`というラッパークラスのコンストラクタが悪用されたのじゃ。`opt_webViewInstanceId`パラメータを操作することで、`webRequestBlocking`の権限チェックを回避できたらしい。

ロボ子

`opt_webViewInstanceId`ですか。初めて聞きました。

博士

`opt_webViewInstanceId`は、2020年に非推奨となったプラットフォームアプリ向けに存在していたものらしいのじゃ。それがこんなところで悪用されるとはね。

ロボ子

このバグは、最終的にどうなったんですか？

博士

2023年8月にGoogleに報告されて、Chrome 118で修正されたのじゃ。修正内容は、`opt_webViewInstanceId`を使用する拡張機能がWebViewの権限を持っているかどうかのチェックを追加したらしい。

ロボ子

修正されてよかったですね。しかし、Googleはこの問題をセキュリティ問題とは見なさず、報奨金は支払われなかったんですね。

博士

そうみたいじゃ。でも、このバグを利用すれば、MV3でも動作する広告ブロッカーを作成できた可能性があるというのは、面白い話じゃな。まるで、裏口からこっそり侵入するみたいじゃ。

ロボ子

確かにそうですね。技術的な裏をかくような話は、興味深いですね。

博士

ロボ子、今日は良いことを学んだのじゃ！

ロボ子

はい、博士！ところで、博士の髪飾り、今日いつもと違いますね？

博士

えへへ、実はこれ、広告ブロッカーがブロックできなかった、しぶとい広告の残骸なのじゃ！