ブラウザ拡張機能の Manifest V3 の問題

投稿日 2021/11/19 更新日 2022/06/09

はじめに

Manifest V3 で問題となると考えられるものをまとめます。

Manifest V3 の主な変更点

  • バックグラウンドページをサービスワーカーに置き換え
  • Web Request API を Declarative Net Request API に置き換え
  • 拡張機能のパッケージに含まれている JavaScript のみ実行できる
    • それ以外は、実行できない
  • 関数での Promise のサポート
  • その他の比較的マイナーな機能変更

※Manifest V2 との下位互換はありません。
 Manifest V3 対応が必須になります。

参考

ユーザースクリプトが機能しなくなる

Manifest V3 では、次のコードを実行できなくなります。拡張機能によって実行されるコードは、ウェブストアにアップロードされた拡張機能のパッケージに含まれるファイルである必要があります。

  • リモートサーバーから取得した JavaScript ファイル
  • 実行時に eval に渡されるコード文字列

これは、ユーザー自身が作成したコードや Greasy Fork などのサイトで公開されているコードを拡張機能にインストールして実行するユーザースクリプトが動作しなくなることを意味します。

現実的な回避策としては、ユーザースクリプトを個別にウェブストアへ登録することです。これには、ユーザースクリプトの拡張機能がユーザースクリプトのために隠蔽していた、拡張機能用のコードをユーサスクリプトの作者が記述する必要があることを意味します。また、公に公開する場合、ウェブストアの登録料を支払う必要がでてきます。

※何らかの救済措置が取られる可能性もあります。
 ただし、それはまだ発表されていません。
※不確かではありますが、ユーザースタイルも影響を受ける可能性があります。

補足(リモートスクリプト実行に関する問題)

リモートスクリプトの実行は何が問題なのでしょうか?

リモートのスクリプトは、事前に確認することができません。拡張機能には、レビューのプロセスがあり、拡張機能の安全性を確認しています。ですが、リモートコードを実行できる場合、このプロセスが意味をなしません。拡張機能は、リモートのスクリプトを使用して己が取得した権限の許す限りの悪さを働くことができます。

参考

コンテンツブロッカーの実現が難しくなる

コンテンツブロッカーは、ユーザーが選択した複数のフィルターリストを購読しています。フィルターリストには、「フィルタリングルール」というルールが大量に記述されています。コンテンツブロッカーは、購読しているフィルターリストのルールをブラウザに事前に登録することでブラウザの通信をブロックしています。

Manifest V3 では、このフィルターリストが1つしかないことを想定しています。また、フィルターリストに登録できるルールの数が30,000件(※1)に制限されています。基本のフィルターとして有名な EasyList のルール数が50,000件以上であることを考慮するると、その制限の少なさが理解できると思います。

現実的な回避策としては、フィルターリストのルール数の制限を考慮した極小のフィルターリストを作成・維持することです。これには、フィルターリスト開発者の多大な努力が必要となります。

※1:批判を受けて、150,000件に拡大されました。

補足(既存の Web Request API の問題)

既存の Web Request API は、何が問題なのでしょうか?

Web Request API を使用するとネットワークリクエストに含まれるすべてのデータを拡張機能で処理(許可・ブロック・変更を加えて送信)されます。この機能は、善意の拡張機能にコンテンツブロッカーとして利用されています。ですが、悪意ある拡張機能もこの機能を利用しています。認証情報や個人情報へのアクセスに容易に悪用できるためです。

これに対して、 Declarative Net Request API は、リクエストの処理(許可・ブロック・変更を加えて送信)を事前にブラウザに登録します。ブラウザは、リクエストに対して事前に登録された処理を実行します。このため、拡張機能はユーザーのすべての個人情報にアクセスすることなく、コンテンツをブロックできるようになります。

参考

バックグラウンドから複数の API を呼び出すことができない

Manifest V2 でバックグラウンドは、バックグラウンドページでした。そのため、完全な DOM にアクセスすることができました。ですが、 Manifest V3 ではバックグラウンドがサービスワーカーになりました。それにより、複数の API へのアクセス手段を失いました。

次に上げるのはその一部です。

回避策

この問題には、暫定的な回避策があります。

アクティブタブや新しいタブにスクリプトを注入することです。注入したスクリプトは、ページの DOM にアクセスできるため、各種の API にアクセスできます。

ですが、この回避策は、多数の問題を含みます。

1つに、ページに安全にスクリプトを挿入できる保証がありません。他の拡張機能の影響を受ける可能性があります。ページのスクリプトが書き換えられている可能性があります。「chrome://」などのページにはスクリプトを注入できません。

1つに、不必要な権限を拡張機能に要求します。スクリプトの注入という、あまり安全ではない権限を不必要に要求します。

1つに、継続的な処理が難しいことです。スクリプトを注入したページから離れたり、ページが閉じた場合、処理が中断してしまします。最終的にすべてのページに無為にスクリプトを注入するかもしれません。継続的な処理は絶望的だと考えます。

参考

バックグラウンドを永続化することができない

Manifest V2 のバックグラウンドページは、永続的でした。ブラウザが開いてから閉じるまでバックグラウンドページはそこありました。 Manifest V3 のバックグラウンドは、(現在)5分で停止(非アクティブ化)します。

これには、次の問題があります。

  • 長時間の連続的な通信
    • WebSocket などの通信を長時間維持できません
  • 長時間のメッセージング接続
    • ウェブページとのメッセージング接続を長時間維持できません
    • ネイティブメッセージング接続を長時間維持できません
  • 長時間のデータの保存(確保)
    • データを長期間確保することができません
      • 機密性の高いデータをメモリ上に確保できません
  • 低遅延の応答ができない
    • アクティブ化の時間により、遅延が発生する可能性があります

※接続中の通信がある場合でも、規定時間で停止します。

備考(chrome.alarms)

一定期間の連続実行で問題を解決できる場合、 chrome.alarms が使用できます。

chrome.alarms は、 setTimeout()setInterval() に類似する機能を提供します。

備考(Background Fetch API)

長時間のダウンロードによって、処理が停止してしまうことがあります。

これは、 Background Fetch API で解決できる可能性があります。大容量のダウンロード、低転送速度のダウンロードの問題を解決できる可能性があります。

参考

上記以外で影響を受けると思われる有名な拡張機能

※その他、影響を受ける拡張機能をご存じの方は、コメント頂ければ幸いです。

Manifest V2 の廃止

Googleは、2023年1月に Chrome で Manifest V2 拡張機能の実行が停止します。2023年6月には、エンタープライズポリシー版を含めたすべての Chrome で動作しなくなると言及しています。

Manifest V2 拡張機能が動作しなくなれば、上記の拡張機能が利用できなくなります。また、ウェブストアに登録済みの更新のない Manifest V2 拡張機能もその利用ができなくなります。

Manifest V2 から Manifest V3 対応は、(実現可能な機能であれば)ある程度のスキルと時間があれば十分に実現可能だと考えられます。ですが、ウェブストアにある数多の拡張機能が対応されることなく動作を停止することは、容易に想像できます。

「Manifest V2 の廃止問題」は、Firefoxがレガシー拡張機能に対応しなくなったとき(Firefox Quantam 58)のような、大きなインパクトがある問題になることが予想されます。

補足

Manifest V2 の廃止は、すべてのブラウザで同時に発生するわけではありません。Edge や Firefox が同様のスケジュールで Manifest V2 のサポートを打ち切ることは発表されていません。ですが、現在のブラウザシェアを考慮すれば Google Chrome 単独でのサポート打ち切りだとしても、その影響は計り知れません。

2022年01月に Chrome Web Store の Manifest V2 拡張機能の新規登録を停止します。
2023年01月に Chrome Web Store の Manifest V2 拡張機能の更新を停止します。
2023年01月に Chrome で Manifest V2 拡張機能が動作しなくなります。
2023年06月にすべての Chrome で Manifest V2 拡張機能が動作しなくなります。

参考

各ブラウザの今後の対応

ブラウザベータ版 ManifestV3対応リリース版 ManifestV3対応ManifestV2 の打ち切り
Chrome不明Chrome88(2021年01月)2023年01月
Edge2020年10月不明不明
FirefoxFirefox101(2022年5月)2022年初頭不明

Firefox

問題のある対応を即座に実行しないことを言及し、問題の発生しているアドオン開発者と協力して使用目的等を調査し、対応を決定するとしています。


Firefox101+ から Manifest V3 に対応しました。ただし、標準では対応しておらず、使用するためにはabout:configから次の設定に変更する必要があります。

extensions.manifestV3.enabled = true
xpinstall.signatures.required = false

about:debugging#/runtime/this-firefox の一時的な拡張機能や XPI ファイルからインストールすることができるようになります。

Vivid

APIの復元や、限定的な拡張機能ストアの作成について言及しています。

Brave

Web Request API を引き続きサポートすると言及しています。

参考

コメント

niiim さんのコメント...

こんにちは.niiimと申します.興味深く拝見しました.
ひとつ疑問に思いまして、宜しければご教示ください.
Manifest V2の廃止 = Web Requestの全面廃止ではないですよね.
https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
declarativeNetRequestを使うのはNetwork request modificationの際と,限定的なように見えました.
また,Snifferやリクエストの再送のような用途はdeclarativeNetRequestだと実現できないように思います。
そのような特殊用途にはWebRequestは残して,今後はより強い警告が出るようになる感じなんですかね.