Mozilla は新しい Chrome マニフェストからすべての WebExtensions API 制限を移行しない

モジラ社 発表した、Firefox で WebExtensions API に基づくアドオン システムを使用しているにもかかわらず、開発者は Chrome アドオンの将来のマニフェストの第 XNUMX 版に完全に従うつもりはないということです。 特に、Firefox は API のブロック モードを引き続きサポートします。 ウェブリクエスト、受信したコンテンツをその場で変更できるため、広告ブロッカーやコンテンツ フィルタリング システムで需要があります。

WebExtensions API への移行の主なアイデアは、Firefox と Chrome のアドオンを開発するためのテクノロジーを統合することでした。そのため、現在の形式では、Firefox は現在の 100 番目のバージョンの Chrome マニフェストとほぼ XNUMX% 互換性があります。 マニフェストは、アドオンに提供される機能とリソースのリストを定義します。 マニフェストの XNUMX 番目のバージョンでは制限措置が導入されており、これはアドオン開発者によって否定的に認識されているため、Mozilla はマニフェストに完全に従う慣行から離れ、アドオンとの互換性に違反する変更を Firefox に転送しません。オン。

それを思い出して 何と на すべて 異議あり, Googleは、ChromeでのwebRequest APIのブロックモードのサポートを停止し、読み取り専用モードに制限し、コンテンツフィルタリング用の新しい宣言型APIを提供する予定です。 宣言的なNetRequest。 webRequest API では、ネットワーク リクエストに完全にアクセスでき、トラフィックをオンザフライで変更できる独自のハンドラーを接続できましたが、新しい declarativeNetRequest API は、ブロッキング ルールを個別に処理する既製の汎用組み込みフィルタリング エンジンへのアクセスを提供します。では、独自のフィルタリング アルゴリズムを使用したり、条件に応じて重複する複雑なルールを設定したりすることはできません。

Mozilla は、アドオンとの互換性を損なう Chrome マニフェストの第 XNUMX バージョンからのその他の変更についても、Firefox サポートに移行する可能性を評価しています。

  • Service Worker をバックグラウンド プロセスの形式で実行するように移行すると、開発者はいくつかの追加コードを変更する必要があります。 新しい方法はパフォーマンスの観点からはより効率的ですが、Mozilla はバックグラウンド ページの実行のサポートを維持することを検討しています。
  • 新しい詳細な権限リクエスト モデル - アドオンは、すべてのページに対して一度にアクティブ化することはできません (「all_urls」権限は削除されています)。ただし、アクティブなタブのコンテキストでのみ機能します。 ユーザーは、アドオンが各サイトで機能することを確認する必要があります。 Mozilla は、ユーザーの注意を常に妨げることなくアクセス制御を強化する方法を模索しています。
  • クロスオリジンリクエストの処理の変更 - 新しいマニフェストに従って、コンテンツ処理スクリプトは、これらのスクリプトが埋め込まれているメインページと同じ権限制限の対象になります (たとえば、ページがlocation API を使用すると、スクリプト アドオンもこのアクセスを受け取りません)。 この変更は Firefox に実装される予定です。
  • 外部サーバーからダウンロードされたコードの実行を禁止します (アドオンが外部コードをロードして実行する状況について話しています)。 Firefox はすでに外部コード ブロックを使用しており、Mozilla 開発者は、マニフェストの第 XNUMX バージョンで提供される追加のコード ダウンロード追跡技術を使用して、この保護を強化する意向です。

出所: オープンネット.ru

コメントを追加します