[これは Mozilla wiki の記事 Addons/Extension Signing (2015/09/01 時点) の翻訳です]
[9/14: リリース版への導入スケジュールを更新]

Firefox のリリース版とベータ版にインストールされるすべての拡張機能に署名が必要になります。署名は、addons.mozilla.org (AMO) によって行われます。配布されるサイトにかかわらず、すべての拡張機能で署名が必須となります。

目次

• 1 ドキュメント
• 2 スケジュール
• 3 よくある質問
• 4 ディスカッション

ドキュメント

• Introducing Extension Signing (原文)、より安全なアドオン体験を提供するため拡張機能に署名を導入します(日本語訳) 、Add-ons Blog
• The Case for Extension Signing、Add-ons Blog
• Main tracking bug

スケジュール

具体的な期日については、Firefox Release Calendarを参照してください。

• Firefox 40-42: 署名に関する警告が Firefox に表示されますが、インストールは可能です。
• Firefox 43: 署名チェックを無効化できる設定項目 (about:config の xpinstall.signatures.required) が Firefox で提供されます。
• Firefox 44: 未署名の拡張機能は、Firefox のリリース版とベータ版にインストールできません。また署名チェックを無効化する機能が Firefox から削除されます。

ESR が署名に対応するのは、Firefox ESR 45 以降です。現在の計画では、ESR は Firefox 41 と同様に動作し、署名チェックを無効化できる設定項目が提供される予定です。ただし、この仕様は今後、変更される可能性があります。

現在 AMO で配布されている Firefox の審査済み拡張機能は、すべて署名が完了しています。Firefox for Android は署名に関してデスクトップと同じリリーススケジュールが使用されることになったため、Firefox for Android の拡張機能も、まもなく自動的に署名されます。

非登録の (AMO で配布されない) アドオンは、Mozilla に提出して署名を取得することができますが、不具合の検出・修正中であるため正式発表はされていません。

よくある質問

• 署名が必要なのは、どの種類のアドオンですか？
  • 拡張機能 (install.rdf の type 2) のみです。テーマ、辞書、言語パック、プラグインには署名は不要です。

• Thunderbird、Seamonkey、Palemoon などの他のアプリケーションの拡張機能にも署名が必要ですか？
  • それらのアプリケーションで、署名を必須とするか、今後も設定項目の 1 つとして位置付けるか、既定で無効にするかは、各プロジェクトのリーダーの判断にゆだねられます。現在のところ、他のアプリケーションが署名に対応する予定はありません。

• 署名済みの拡張機能は、他のアプリケーションや従来のバージョンの Firefox で動作しますか。
  • はい。この署名システムは、これまで Firefox や他のアプリケーションで使用されていた既存のアドオン署名機能を基盤としています。

• 署名チェックを無効化する設定項目や変更機能は提供されますか？
  • Firefox のリリース版とベータ版では、署名チェックを無効化する設定や機能は提供されません。ただし、次の質問への回答内で示されている他のバージョンでは、署名チェックを無効化できます。

• 未署名の拡張機能を Firefox にインストールする方法はありますか？
  • Developer Edition および Nightlyバージョンの Firefox では、署名チェックを無効化する設定項目が提供されます。また、アドオン開発者向けに公開される特別なノーブランド版のリリース版とベータ版でも、署名チェックを無効化する機能が提供されるので、アドオン開発時にビルドごとに署名する必要はありません。署名チェックを無効化するには、次の手順で xpinstall.signatures.requiredを「false」に設定します。
    • Firefox のアドレスバーに、about:config と入力します。
    • 検索ボックスに、xpinstall.signatures.required と入力します。
    • 検出された環境設定をダブルクリックするか、右クリックして「切り替え」を選択して「false」に設定します。

• ノーブランド版の Firefox は、どのように動作しますか？
  • ノーブランド版の動作は、通常版の Firefox と同じです。ただしノーブランド版は、通常版では無効化できない署名チェックを無効化でき、また Firefox という名前とロゴが入っていない (代わりに汎用の名前とロゴを使用) という 2 つの違いがあります。ノーブランド版は、英語 (en-US) ロケールのみで提供されます。

• 組織内でのみ使用される非公開のアドオンにも署名が必要ですか？
  • このようなアドオンの取り扱いについては未定です。後日詳細をお知らせしますので、しばらくお待ちください。当面の間、ESR は署名に対応しません。ESR が証明に対応するのは、早くとも 2016 年にリリース予定のバージョン 45 以降となります。

• 開発したアドオンを AMO で配布している場合、署名を取得するにはどうすればよいですか？
  • 特に手続きは必要はありません。現在 AMO で配布されているアドオンの審査済みのバージョンは、すべて自動的に署名が完了しています。また新しいバージョンは、審査を通過した後、自動的に署名されます。

• AMO で配布していないアドオンの署名を取得するにはどうすればよいですか？
  • AMO アカウントを作成して、アドオンを提出する必要があります。アドオンの提出時に、このアドオンを AMO 非登録にするオプションを選択できるので、AMO サイトで公開しないアドオンファイルも提出できます。詳細については、Distribution Policy を参照してください。

• 非登録アドオンの署名プロセスについて教えてください。
  • 非登録アドオンの場合、署名の申請用にファイルを提出すると、そのファイルが自動審査プロセスに掛けられます。審査を通過したアドオンは自動的に署名され、ダウンロードリンクが開発者に送付されます。このプロセスは、通常、数秒で完了します。ファイルが審査を通過しなかった場合、開発者は手動審査を要求することができ、その場合も、2 日未満で審査が完了します。これは、現在の AMO アドオンに対して実施されている審査とは異なるプロセスであり、AMO アドオンよりも迅速に処理が行われます。

• AMO で配布されるベータ版についても、審査と署名が必要ですか？
  • はい。ベータ版は、AMO で配布されないアドオンと同様、自動審査プロセスに掛けられて、審査を通過すれば自動的に署名されます。

• 既存のアドオンのコードを変更したり、ロケールを追加したりしたカスタム版のアドオンにも署名が必要ですか？
  • リリース版やベータ版で使用する場合は必要です。また、そのようなアドオンを提出して署名を申請するには、アドオン ID を変更する必要があります。

• 今回の措置は、Mozilla にとって都合の悪いアドオンを検閲し、著作権や政府の意向などを強制することが目的ですか？
  • いいえ。この目的は、ユーザーを不正なアドオンから保護することにあります。Mozilla では、どのような場合にアドオンのブロックリストへの登録が妥当かについて明確なガイドラインを定めており、それ以外の理由によるブロックの要求を幾度も拒否しています。

• アドオンの新規バージョンを毎回手動でアップロードしなくて済むような、アップロードと署名用の API が提供される予定はありますか。
  • このプロジェクトの第1段階である現行の計画には含まれていません。しかし、この機能に対する要望が数多く寄せられているため、現在、実施方法を検討中です。

• 今回の措置により、ユーザーはあらゆる形態のアドオンマルウェアから保護されるのですか。
  • いいえ。アドオンマルウェアの問題を完全に封じ込める解決策は存在しません。マルウェア対策には、オペレーティングシステム、アプリケーション、ユーザー、さらには業界全体といった、さまざまなレベルでの防御が必要です。拡張機能への署名は、不正なアドオンから Firefox を保護する大きな一歩ですが、ユーザーに最良のエクスペリエンスを確保するためには、他にも数々の対策を講じる必要があります。

ディスカッション

このトピックに関する議論は、mozilla.addons.user-experience ニュースグループを中心に行われています。

[これは Mozilla Add-ons Blog の記事 The Future of Developing Firefox Add-ons の翻訳です]

Mozilla は今日、Firefox のアドオンへ今後行われるいくつかの重要な変更について皆さんにお知らせします。Firefox のアドオンエコシステムは長年にわたる漸進的かつ有機的な成長を通じて発展してきましたが、以下のような課題を踏まえ、ある程度の抜本的な変更を伴う Firefox の近代化作業が進んでいます。

• Electrolysis や Servo といった新技術の活用
• スパイウェアやアドウェアからのユーザの保護
• アドオン審査期間の短縮

これらの改善を可能にする方法をアドオン開発コミュニティの皆さんによく理解してもらえるよう、今日、以下 4 つの関連する変更をお伝えします。

• Firefox に WebExtensions と呼ばれる新しい拡張機能 API の実装を進めています。これは Chrome や Opera が採用しているアドオンモデルとほぼ互換性があり、複数のブラウザを対象とした拡張機能の開発を容易にするものです。
• Electrolysis というコードネームで開発されている、より安全で高速なマルチプロセス版 Firefox が近日公開となります。Firefox のアドオンがそれと互換性があるかどうか、開発者の皆さんに 動作確認 してもらう必要があります。
• サードパーティー製拡張機能が、セキュリティやパフォーマンスを犠牲にしたり、ユーザをマルウェアにさらしたりすることなくカスタマイズ機能を提供できるよう、9 月 22 日リリースの Firefox 41 以降、すべての拡張機能に Mozilla による 検証と署名 が必須となります。
• XPCOM や XUL を使ったアドオンについて、おおよその廃止予定スケジュールを決定しました。

Firefox のアドオン開発コミュニティのために、これらの変更は、より広範なクロスブラウザアドオン互換性といった利点をもたらしますが、一方で多くの既存アドオンの再開発が必要となります。Mozilla は大きな投資を行い、アドオンに携わり、アドオン開発者を支援するエンジニアやアドオン審査担当者、エバンジェリストのチーム拡大を図っています。このチームはコミュニティと協力して WebExtensions API を改良、完成させ、アドオン開発者が新 API とマルチプロセスへ対応するのを支援します。

開発者に Mozilla の計画について知ってもらい、皆さんにフィードバックを提供してもらう機会を作るため、これらの変更を今日すべてまとめて発表します。私たちはこの移行を極力スムーズなものにするため、できる限りのことに取り組んでいます。私たちは、Mozilla コミュニティとともに、Firefox アドオンの未来を作っていきます。

WebExtensions API の導入

これまでアドオン開発者からは、API のドキュメントを充実させ、より使いやすくして欲しいという声が聞かれてきました。また、多くの Firefox アドオン開発者が、似たような機能を持った Chrome、Safari あるいは Opera 向けの拡張機能も提供していることに気付きました。私たちはアドオン開発をもっと Web 開発のようにしたいと考えています。単独のコードが標準によって規定された挙動に基づいて複数のブラウザ上で動くべきであり、それに関する包括的なドキュメントが複数のベンダーから公開されることが望ましいと思います。

このような目的を達成するため、Mozilla では、WebExtensions と呼ばれる新しい Blink 互換の API を Firefox に実装しています。Chrome、Opera、あるいはおそらく将来的には Microsoft Edge 向けに書かれた拡張機能は、わずかな変更を加えるだけで Firefox でも WebExtension として動作します。この近代的な JavaScript 主体の API には、当初からマルチプロセスブラウザに対応し、悪さをするアドオンやマルウェアのようなリスクを軽減できるなど、多くの利点があります。

WebExtensions は他の Firefox アドオンと同じように振る舞います。Mozilla によって署名され、addons.mozilla.org (AMO) や開発者のサイトを通じて公開されます。この API により、拡張機能開発者は、各ブラウザ向けに最小限の変更と再パッケージを行うだけで、Firefox と Chrome 向けに同じ拡張機能を提供できるようになるはずです。

WebExtensions のプレビューリリースは、現在 Developer Edition となっている Firefox 42 で利用可能です。WebExtensions のテストを始める方法 に関する情報は Mozilla Wiki にあります。この API の少なくとも一部を標準化しようと、Mozilla は他のブラウザベンダーとの議論を始めました。WebExtensions に関するさらなる情報や詳細はこの Wiki に追加していきます。

マルチプロセス Firefox とアドオン

Web コンテンツの実行に OS の別プロセスが使用される Electrolysis プロジェクト の第 1 弾が Release チャンネルへ向けて進んでいます。後続のフェーズでは複数のコンテンツプロセスと改良されたサンドボックス機能が実装されます。レンダリングに異なるプロセスを使用することで、劇的なパフォーマンスとセキュリティの向上を Firefox にもたらすことのできる基礎が築かれますが、一部のアドオン、特にコンテンツに変更を加える拡張機能との互換性に影響があります。しかし、アドオンを引き続き動かせるようにするため、いくつもの対策が用意されています。

• WebExtensions は Electrolysis と完全に互換性があります。API が成熟し Electrolysis が初期設定で有効になる頃には、これが Firefox 向け拡張機能の移植、開発方法の主流となるでしょう。
• Jetpack SDK ベースのアドオンは、require(‘chrome’) やコンテンツプロセス内オブジェクトに触れる一部の低レベル API を使用していない限り、今後も動作します。
• Electrolysis に未対応のアドオンは、シングルプロセスの Firefox にできる限り似せた特別な互換環境で実行されます。アドオンがコンテンツに触れる場合、そのアクセスは クロスプロセスオブジェクトラッパー (CPOWs) を通じて行われます。ただ、CPOWs はシングルプロセス Firefox における同等の DOM 操作と比べてはるかに遅く、ユーザ体験に悪影響をもたらしかねません。また、互換レイヤーは一部のアクセスに対応しておらず、その場合は例外が投げられます。

今後、アドオン開発者には、マルチプロセス Firefox への対応方針について考えてもらう必要があります。

• Electrolysis とその アドオン開発ガイドライン に詳しくなりましょう。
• Firefox Developer Edition で Electrolysis を有効にして アドオンをテストしましょう。
• 必要に応じてアドオンを更新して CPOWs 依存を廃し、Electrolysis 互換にした上で、マルチプロセス互換フラグを設定し、その拡張機能の互換性を明示しましょう。
• 既存の拡張機能が WebExtensions API をどのように活用できるか検討を始めましょう。

Electrolysis の最終リリーススケジュールは、より多くのユーザによるテストを経て今後数か月以内に決定されます。スケジュールが延期もしくは変更される可能性はまだありますが、以下のような現行のリリース計画に合わせてアドオンを更新すべきだということを開発者の皆さんには理解して欲しいと思います。

• 8 月 11 日 (Firefox 42 が Developer Edition へ移行)、Electrolysis は Developer Edition で初期設定有効となります (Nightly では既に有効となっています)。
• 9 月 22 日 (Firefox 42 が Beta へ移行)、Electrolysis が Beta チャンネルで「オプトイン」機能としてユーザへ提供されます。
• 11 月 3 日 (Firefox 43 が Beta へ移行)、Electrolysis が Beta で初期設定有効となる最初のバージョンです。この時点で、パフォーマンスや安定性に重大な問題を引き起こす Electrolysis 非互換のアドオンをブロックリストへ追加する作業を開始します。
• 11 月 15 日 (Firefox 43 が Release へ移行)、Electrolysis が Release チャンネルで初期設定有効となる最初のバージョンです。これが現在予定されているリリース日となります。
• Electrolysis が Release チャンネルで有効となってから半年後、CPOWs とその他の互換性機能が廃止予定となります。必要に応じてより詳しいスケジュールを公開しますが、Electrolysis の一般公開後半年から 1 年の間にそれらに依存しているアドオンは動作しなくなるということを開発者の皆さんは知っておいてください。

Electrolysis チームが、互換性テストのために人気のアドオン一覧を arewee10syet.com へ投稿しています。開発者の皆さんには、上記の手順に加えて、この一覧を参照し、自作のアドオンが Electrolysis 互換かどうかの情報を提供するよう推奨します。

デジタル署名

Mozilla では既に悪質なアドオンに対抗するためブロックリストの仕組みを採用していますが、一部のアドオンがこのブロックリストを回避する手段を講じていることから、ユーザをより確実に守るための追加措置が必要とされています。ブロックリストはまた対症療法的なものであり、危険なアドオンがインストールされてから、それが Mozilla によって特定、ブロックされるまでにユーザが何らかの被害を被る可能性がないとも限りません。Firefox 42 以降、アドオン開発者は拡張機能を公開する前に、それを一度 Mozilla へ提出して審査と署名を受ける必要があり、未署名のアドオンは Firefox 上でインストールも使用もできなくなります。署名に関する詳細は 別記事 を参照してください。

アドオンの審査過程は開発者にとって時に面倒なものであることは認識しています。審査は今のところほぼ人間による手作業であり、拡張機能が初めて提出されてからガイドラインに沿った完全審査を通過するまで数週間から数か月を要することもあります。WebExtensions の主な利点のひとつは、審査がより短期間で済むということです。一般的に、適切な WebExtension を開発するのはより簡単であり、また許可設定システムによって悪質なアドオンをより容易に判別できるようになります。

私たちの目標は審査過程の自動化を推進することで、それによって addons.mozilla.org (AMO) に登録された新しい WebExtensions の審査待ち時間は 5 日に、既存の WebExtensions の更新待ち時間は 1 日から 2 日に、それぞれ短縮される見込みです。署名のために提出された AMO 非掲載アドオンの待ち時間は今のところ 3 日以内となっています。また、有給スタッフとボランティアで構成されるアドオン審査チームの増強を進めており、自動検証ツールも随時改善しています。これらの取り組みによって、すべての拡張機能の審査待ち時間を近い将来に短縮します。

拡張機能の署名は Firefox 42 までは強制ではありませんが、Firefox 40 で既に関連機能は実装されており、ユーザはインストールされている拡張機能が Mozilla による検証済みかどうかを確認できるようになっています。Firefox Developer Edition のユーザは、8 月 14 日以降未署名のアドオンがブロックされていることに気付いたかもしれません。

アドオンの署名に関する今のところの完全なスケジュールは以下の通りです。

• Firefox 40: 未署名の拡張機能についての警告がアドオンマネージャに表示されるようになりますが、すべての拡張機能は引き続き使用可能です。
• Firefox 41: 未署名の拡張機能は初期設定で無効化されますが、署名の強制を無効化できる設定項目 (xpinstall.signatures.required) が提供されます。
• Firefox 42 以降:
  • バージョン 42 以降の Beta および Release チャンネル (42 Beta は Firefox 41 と同時公開) では上記の設定項目が廃止され、未署名拡張機能のインストールと使用が不可能となります。
  • バージョン 42 以降の Nightly および Developer Edition では、署名の強制を無効化できる設定項目が残され、これにより未署名アドオンの開発や使用が可能となります。Release チャンネルを元にした無印版 Firefox も開発者向けに提供されます。この公開は Firefox 42 の Release チャンネルで (またおそらく Beta チャンネルでも) 予定されています。

XUL、XPCOM と寛容なアドオンモデルの廃止

XPCOM と XUL はいずれも Firefox で最も基礎的な技術です。JavaScript でブラウザの大部分を記述できることは Mozilla にとって大きな利点となってきました。Firefox が他のブラウザよりはるかにカスタマイズしやすいのもこれらのおかげです。しかし、それらの技術から自然発生的にできあがったアドオンモデルは極めて寛容です。既存のアドオンは Firefox の内部実装への完全なアクセスを得ることができますが、このモジュール性の欠如は多くの問題を引き起こしてきました。

寛容なアドオンモデルは、裏を返せば Mozilla が Firefox の基礎に変更を加える柔軟性が制限されるということです。Electrolysis によるアドオンへの影響はこの問題の重要な事例のひとつです。CPOWs のような技術によってアドオンの問題を回避することは可能ですが、CPOWs はこの取り組みの中でも莫大な投資であり、それでもまだ十分なパフォーマンスは得られず、やや信頼性に欠けるものです。

Firefox アドオンの動作を可能にする仕組みへの抜本的な変更なしに、Electrolysis、Servo、browser.html といった新技術を Firefox の一部として採用することは不可能です。

ブラウザとアドオンの密接な関係は、Firefox の開発に短期的な問題ももたらします。実際、Firefox の開発がアドオンとの非互換性によって遅れることも珍しいことではありません。最も極端な例では、Firefox のメソッド初期化方法へ行われた変更が、正規表現によって Firefox のコードを改変しているアドオンによる問題を引き起こしたこともありました。アドオンが API を予期せぬ方法で使っていた場合に Firefox がクラッシュすることもあります。

そのため Mozilla では、XUL や XPCOM、XBL に依存したアドオンの開発手法を将来的に廃止とすることを決定しました。まだ具体的なスケジュールは確定していませんが、おそらく今後 1 年から 1 年半の間に行われるでしょう。開発者が準備を始めフィードバックを提供できるよう、今のうちにこの変更を発表しておきます。新しい WebExtension API を使って作られたアドオンは今後も動作します。また、require(‘chrome’) や XUL 要素へのアクセスを提供する一部の低レベル API を除き、SDK アドオンにも引き続き対応します。

私たちが現在直面している大きな課題は、多くの Firefox アドオンが、現行の WebExtensions API や SDK のみで作り直すのはおそらく不可能だろうということです。今後 1 年かけて開発コミュニティからフィードバックを集め、最も人気のある Firefox 拡張機能が必要とする機能にできるだけ多く対応するため、API の開発と拡張を続ける予定です。

私たちは前進し続けます

ここで発表した方針には必然的に多くの妥協点が関わってきます。既に Chrome 拡張機能を提供している開発者は、同じコードを再利用できるという恩恵を受けられます。Firefox 限定のアドオンを作っている開発者は変更を求められます。その際の作業には相当な時間を割いてもらう必要がありますが、Firefox ユーザと開発者の双方にとって、最終的な結果はその努力に見合うものになると思います。

私たちはアドオン開発コミュニティへの取り組みを繰り返し行い、拡張機能の移植、新 API の設計、Firefox を素晴らしいものにする革新的なアドオンの作成などにおいて開発者の皆さんと協力していきたいと考えています。

今後数週間ないし数か月の間に追加情報の公開を続け、ここで発表したそれぞれの変更点をより詳しくまとめるとともに、Mozilla Developer Network、IRC (#extdev チャンネル)、ニュースグループ といった従来のコミュニケーション窓口を通じてサポートを提供します。

更新: WebExtensions が何をどのようにしてもたらすのか、多くの人から質問が寄せられています。私たちが目指すところや、皆さんが意見を表明してこれらの取り組みに関わる方法について、Bill McCloskey が 追加のブログ記事 を書いています。自分たちが作り、使い、愛するアドオンがどのように Firefox の一部であり続けるのかということについて心配のある人には必読です。

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 41 の翻訳です]

Firefox 41 が 9 月 22 日 [日本時間同日深夜] リリース となります。Firefox 41 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 41 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

拡張機能への署名

• 41 は、新たな 署名要件 が強制される初のバージョンとなります。Firefox 40 では警告が表示されるだけでしたが、41 では未署名の拡張機能は初期設定で無効化されます。AMO に掲載されているアドオンの署名はすべて完了しており、現在は AMO 非掲載アドオンの調査を進めているところです。

一般

• 設定項目 browser.newtab.url が削除されました。
• Date.prototype が Date でない通常のオブジェクトになりました。
• let 式への対応が SpiderMonkey から削除されました。let 式についてよく知らない場合、あなたの拡張機能はおそらく影響を受けないでしょう。念のため、ドキュメントは こちらにあります。
• メソッド定義に中括弧が必須となりました。

XPCOM

• NewChannel の廃止予定警告がアサーションに変わりました。これまでも警告が表示されてきましたが、今後は例外が投げられます。新しいインタフェースのドキュメントは こちらにあります。
• nsIDOMFile が削除されました。
• nsIDebug と nsIDebug2 インタフェースが統合されました。
• nsIHttpChannel が builtinclass になりました。

新機能

• webRequest のような API が Firefox に追加されました。
• 「スピードダイヤル」風の動的なホームパネルレイアウトが開発されました。この新しいレイアウトは Android 版 Firefox 向けのアドオンで使用可能です。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 41 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 は数週間以内に行われますので、AMO に Firefox 40 対応のアドオンを登録している方は後日メールをチェックしてみてください。

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 40 の翻訳です]

Firefox 40 が 8 月 11 日 [日本時間同日深夜] リリース となります。Firefox 40 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 40 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

拡張機能への署名

• Firefox 40 は新たな 署名要件 が適用される初のバージョンとなります。AMO に掲載されているアドオンの署名はすべて完了しており、現在は AMO 非掲載アドオンの調査を進めているところです。このバージョンには署名要件を無効化する設定項目 (xpinstall.signatures.required) がありますが、41 で削除されます。

一般

• SDK から widget モジュールが削除されました。ui モジュール への移行が推奨されます。
• distribution/bundles への対応が廃止されました。
• FUEL の廃止予定を知らせる警告が初回のみコンソールに表示されるようになりました。FUEL ライブラリ は拡張機能の開発を簡単にするためずいぶん前に導入されましたが、SDK と各種 JavaScript モジュール によって取って代わられたため、廃止予定となりました。
• String.prototype.contains が String.prototype.includes へ改名されました。contains メソッドは引き続きエイリアスとして動作しますが、近いうちに削除されます。
• 分割代入型 for-in ループへの対応が廃止されました。
• Dict.jsm が削除されました。Map で代用可能です。
• -moz-text-decoration-* の一時エイリアスが削除されました。

XPCOM

• アプリケーションの一部を除いてバイナリ XPCOM コンポーネント対応が廃止されました。この変更は 41 へ延期される可能性もありますが、バイナリ XPCOM コンポーネントに依存した Firefox アドオンを開発している場合は早急に コードを更新してください。
• nsISSLErrorListener が削除されました。
• 古い keywords API が廃止予定となりました。新しい API は PlacesUtils.keywords です。
• nsINSSCertCache が削除されました。
• DOMClassInfo から GetImplementationLanguage が削除されました。これにより implementationLanguage プロパティも削除されています。
• sessionstore-state-write 通知が削除されました。
• いくつかの使用されていない XPIDL 要素インタフェースが削除されました。次のインタフェースが削除されています: nsIDOMHTMLBRElement、nsIDOMHTMLDivElement、nsIDOMHTMLHeadingElement、nsIDOMHTMLTableCaptionElement、nsIDOMHTMLTitleElement

テーマ

• ファイルのクロームコピーが上書きに置き換えられました。
• アドオンマネージャにコンテンツ内設定画面と同じスタイルが採用されました。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 40 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 は数週間以内に行われますので、AMO に Firefox 39 対応のアドオンを登録している方は後日メールをチェックしてみてください。

[これは Mozilla Add-ons Blog の記事 Compatibility update: Firefox 38 and 38.0.5 の翻訳です]

Firefox 38 アドオン互換性 に関する投稿の補足として、書きそびれた重要な変更について説明したいと思います。それは コンテンツ内設定 です。設定ウィンドウは廃止され、代わりに主要な設定 UI が新しいタブで開かれるようになりました。この変更は設定ウィンドウにオーバーレイしているアドオンにのみ影響しますが、その数は非常に限定的でしょう。

また、6 月 2 日に非定例リリースが予定されていて、そのバージョン番号は 38.0.5 となります。これは リリースノート にあるように 38 にいくつかの機能を加えたものとなります。これによって 38 と互換性のある拡張機能に影響が及ぶことはないはずですが、完全テーマのバージョン不一致を引き起こす可能性があります。38.0.5 は既に ベータチャンネル で公開されていますので、このベータ版を使ってあなたのアドオンをテストすることをお勧めします。

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 39 の翻訳です]

Firefox 39 が 6 月 30 日 [日本時間同日深夜] リリース となります。Firefox 39 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 39 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

一般

• Lightweight Theme Manager のために組み込みテーマのリストを変更する機能が追加されました。バグの コメント #39 に書かれている通り、lightweightThemes.usedThemes、lightweightThemes.isThemeSelected 各設定を使用しているアドオンが影響を受けます。
• String.prototype.{search,match,replace} の非標準 flag 引数について、コンソールに警告が追加されました。これは廃止予定の警告に過ぎませんが、最後の flag 引数はいずれ削除されます。
• -remote オプションが廃止されました。これにより -remote コマンドライン引数が削除されました。より頻繁に使われる -no-remote とは別物です。
• __noSuchMethod__ について警告が表示されるようになりました。このプロパティはまだ使用できますが、廃止予定となっていますので、バグのコメントで提案されている通り代替手段を検討してください。

XPCOM

• XMLHttpRequest の sendAsBinary メソッドが削除されました。
• nsIDocumentLoaderFactory と nsIURIContentListener に変更が行われ、MIME タイプを XPCOM 文字列として取るようになりました。
• nsIClassInfo::getHelperForLanguage が JavaScript 専用になりました。これにより getHelperForLanguage メソッドが削除されています。

新機能

• コンテンツページがクロームと通信するためのシンプルな仕組みが追加されました。Mossop のブログ と MDN に分かりやすい説明があります。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 39 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 は近日中に行われますので、AMO に Firefox 38 対応のアドオンを登録している方は後日メールをチェックしてみてください。

[これは Mozilla Add-ons Blog の記事 Dropping support for binary components in extensions の翻訳です]

今年 8 月リリース 予定の Firefox 40 以降、拡張機能のバイナリ XPCOM 対応が廃止されます。

バイナリ XPCOM は古く相当不安定な技術です。バイナリライブラリを独自のアドオンへ統合し、場合によっては Firefox の内部機構を活用するために (そのためどうしても不安定になります)、少数のアドオン開発者によって使われてきました。より優れた技術が開発され XPCOM を置き換えられるようになったため、Mozilla では開発者に移行を促してきました。以下は 元のニュースグループ記事 からの引用です。

ネイティブバイナリを使う必要のある拡張機能作者には、アドオン SDK の system/child_process パイプメカニズムを使ってそれを実現するよう推奨します。これで物足りない場合、共有ライブラリを使用できる JS-ctypes が代替技術となるでしょう。ただ、この API はなおさら不安定で、安全でないコードをも簡単に書けてしまいます。

バイナリ XPCOM に依存している開発者は、互換性の問題を回避するため、できる限り早くコードを更新してください。この件に関する質問やコメントがある場合は mozilla.dev.extensions ニュースグループへ投稿してください。

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 38 の翻訳です]

Firefox 38 が 5 月 12 日 [日本時間同日深夜] リリース となります。Firefox 38 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 38 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

更新: Firefox 38 と 38.0.5 に関する補足記事 も併せて参照してください。

一般

• NetUtil.jsm API が刷新されました。newChannel2 と asyncFetch2 が廃止予定となり、newChannel と asyncFetch は不要な引数を簡単に除外できるよう options オブジェクトを取るようになりました。詳しくは 更新された newChannel のドキュメント を参照してください。
• promptForSaveToFile が promptForSaveToFileAsync に置き換えられる形で削除されました。

XPCOM

• nsIProtocolProxyFilter.applyFilter() が URI の代わりにチャンネルもしくはリクエストを取るようになりました。これによりネットワークプロキシに関する様々なインタフェースに変更が行われています。
  • asyncResolve と asyncResolve2 が修正され、チャンネルと URI のどちらも受け入れるようになりました。一部アドオンへの影響を回避するため、このような追加修正が行われました。
• SendCompositionEvent() と DispatchEvent() が mIsSynthesizedForTests の設定なしにイベントを発行できるようになりました。これにより、nsICompositionStringSynthesizer に加え、nsIDOMWindowUtils の sendCompositionEvent、createCompositionStringSynthesizer 両メソッドが削除されました。一方で nsITextInputProcessor が導入されました。
• nsIHttpActivityObserver が HTTP アクティビティを適切に監視できていない問題が修正されました。一部の低レベル HTTP イベントが特定の状況で実行されていませんでしたが、今回のバージョンで修正されています。
• mozIndexedDB が再び削除されました。

新機能

• ノードを引数として渡さない nsIContentPolicy の派生版が導入されました。nsIContentPolicy の e10s 対応版 が nsISimpleContentPolicy という名前で実装されました。これはコンテンツノードの代わりにブラウザ要素を渡します。今のところ、この 新しいインタフェースファイル 内の説明が最も詳しいドキュメントとなっています。
• chrome.manifest ファイル内のリソースプロトコルマッピングを動的に読み込めるようになりました. resource: URL をブートストラップ型拡張機能内の chrome.manifest を通じて宣言できるようになりました。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 38 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 はおそらく来月上旬に行われますので、AMO に Firefox 37 対応のアドオンを登録している方は後日メールをチェックしてみてください。

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 37 の翻訳です]

Firefox 37 が 3 月 31 日 [日本時間同日深夜] リリース となります。Firefox 37 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 37 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

一般

• String.prototype.quote が削除されました。
• プラグインリソースを読み込むための nsIContentPolicy.shouldProcess が実装されました。このためコンテンツポリシー実装の関数呼び出しが増加することが見込まれます。不要な呼び出しはなるべく早めに除外すべきでしょう。
• Android 版 Firefox で Downloads.jsm への変換が行われました。

XPCOM

• デスクトップ版 Firefox から nsIDownloadManagerUI が削除されました。
• nsISiteSecurityService.shouldIgnoreHeaders とその実装が削除されました。

新機能

• chrome URI で読み込まれた JavaScript のソースが参照可能となりました。この変更により、about: ページや一部アドオン UI と同様に、chrome: URL 由来のコンテンツ向けスクリプトもデバッガに表示されるようになります。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 37 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 は 3 月中旬に行われますので、AMO に Firefox 36 対応のアドオンを登録している方は後日メールをチェックしてみてください。

[これは Mozilla Add-ons Blog の記事 Introducing Extension Signing: A Safer Add-on Experience の翻訳です]

今年はアドオンの開発に関していくつか大きな変更が予定されています。いずれも安全性やパフォーマンスを向上させるために不可欠であると私たちが考えているものですが、ほとんどのアドオンに対応してもらう作業が必要となります。ここではまず、先行して実装される拡張機能のデジタル署名について説明し、その他の変更については後日別の記事で取り上げます。

Mozilla のアドオンプラットフォームは伝統的に開発者にとって非常にオープンなものとなっています。拡張機能を使えば Firefox の機能を革新的な方法で根本的に変えてしまえるだけでなく、Mozilla のアドオンサイトである AMO への登録も必須ではないため、開発者は自分たちのサイトでも自由にアドオンを配布することができます。これによって開発者は大きな権限と柔軟性を得られていますが、一方で Firefox ユーザに悪さをする人たちにも自由を与えすぎてしまっているのが現実です。

Web ページに広告を挿入したり、ソーシャルメディアサイトに悪質なスクリプトを埋め込んだりするような拡張機能と同じように、ユーザの同意なしにホームページや検索エンジンの設定を変えてしまう拡張機能が広く出回っています。そうした事態を食い止めるため、Mozilla ではすべてのアドオン作者が従うべき一連の アドオンガイドライン を策定するとともに、ブロックリスト機能 (行儀の悪い拡張機能の強制的な無効化) を通じた取り締まりを行っています。しかし、ガイドラインに違反している拡張機能のほとんどは AMO 以外で配布されているため、それらをすべて追跡することはますます困難になってきています。さらに、悪意を持った開発者は拡張機能の検出やブロックを回避する方法を生み出しており、対策は難しくなる一方です。

Mozilla はアドオンのエコシステムに対する責任を負っており、悪さをするアドオンによってユーザが不快な思いをするのを黙って見過ごすわけにはいきません。簡単な解決策は、Google が Chrome 向け拡張機能に課しているのと同じように、すべての開発者に AMO を通じた拡張機能の配布を義務付けることでしょう。しかし、インストールを Mozilla の配布チャンネルに限定することは余計な制約であると私たちは考えます。こうしたバランスを保つため、AMO を唯一のアドオン配布チャンネルとして強要せずにアドオンのエコシステム管理を強化できる、拡張機能の署名という解決策にたどり着きました。

その仕組みは次のようになります。

• AMO に登録され、審査を通った拡張機能は、自動的に署名された上で配布されます。現在公開中の拡張機能についても、審査済みの最新版についてはすべて自動的に署名を行います。
• AMO で配布されていない拡張機能についても、署名を行うために AMO へ登録してもらう必要があります。開発者にはアカウントを作成して拡張機能の情報を提供してもらいますが、その内容が公開されることはありません。それらのファイルは自動審査プロセスに掛けられ、すべてのチェックをパスしたら署名付きパッケージとして出力されます。自動テストをパスしなかった場合、開発者は審査チームによる目視審査を申請することもできます。本審査は、以下で詳しく説明しますが、AMO 非登録のアドオンでも申請可能です。
• 一般には公開されず、組織の内部ネットワークのみで配布される拡張機能に関しては、3 つ目の選択肢があります。これについては近い将来詳しく説明できるかと思います。
• 2 リリースサイクル (計 12 週間) の移行期間を設けます。その間は未署名の拡張機能を Firefox にインストールしようとしても単に警告が表示されるだけです。
• 移行期間後は、未署名の拡張機能を Firefox のリリース版やベータ版にインストールすることは不可能となります。これを無効化する設定やコマンドラインオプションは一切提供されません。
• 未署名拡張機能のインストールは、Nightly と Developer Edition、それに加えて主に開発者が拡張機能をテストできるように公開されるリリース版とベータ版の特別なノーブランド版では引き続き可能となります。

Add-ons SDK でビルドされた拡張機能を含め、すべての Firefox 向け拡張機能がこの変更による影響を受けます。テーマやスペルチェック辞書など その他の種類のアドオン に署名は必要なく、これまで通りインストール、使用できます。署名の検証は Firefox に限られ、現時点でこの機能を Thunderbird や SeaMonkey に実装する予定はありません。

開発者への影響

AMO にアドオンを登録している開発者には今後、Developer Edition、Nightly あるいはいずれかのノーブランド版でテストを行ってもらう必要があります。審査通過時に拡張機能が自動的に署名されることを除けば、登録、審査プロセスの他の部分に変更はありません。

その他の開発者にとって、これはより大きな変更となるでしょう。開発版を使ったテストに関しては、AMO アドオン開発者と同じ選択肢があります。一方でリリース版については、署名のために AMO へ拡張機能ファイルをアップロードするという必須手順が導入されます。多くの場合、この手順は自動化されると思いますが、拡張機能がテストをパスしなかった場合、目視によるコード審査を申請する選択肢が与えられます。

(Web 上の通常のインストール手順ではなくアプリケーションのインストーラを使って) 外部から拡張機能をインストールしている開発者の場合、審査の敷居はより高くなり、(AMO のコンテンツ制限以外は) AMO 上の本審査済みアドオンと同等になるでしょう。こうした手法は、Firefox 向けに独自の拡張機能を提供しているウイルス対策ソフトなど、拡張機能を同梱したアプリケーションによって広く採用されています。

デジタル署名によってもたらされる重要な変更点のひとつは、拡張機能インストール体験の刷新と改善です。本審査基準を満たした拡張機能は、AMO に登録されているかどうかにかかわらず、インストール手順がよりスムーズで分かりやすくなります。この仕組みの初期モックアップを以下に示します。

今のところ、遅くとも今年の第 2 四半期にあたる移行期間中にはこのシステムを実現させる予定です。そのため、拡張機能の未署名警告はおそらく Firefox 39 で実装されます。

ディスカッション

この記事 [原文] へのコメントを歓迎しますが、ここで説明した計画のメリットについて詳しく議論したければ Add-ons User Experience メーリングリスト に参加してください。プロジェクトの関係者は常に目を通していて、何か懸念点について書かれた投稿があれば返信します。