はじめに結論を書いておきます。
Firefox 3では、「アドオンの更新」を提供しているアドオンのうちで安全な「アドオンの更新」を提供していないものはインストールできなくなりました。それで、Webを見てると、Mozilla Re-MixやFirefox更新情報 WikiなどのWebサイトや、それにやすっち。さん（例1・例2）やGomitaさん[註2]などの人々が危険なことを他の人に薦めているので、面倒ですが[註3]この記事を書いています。
Q1：extensions.checkUpdateSecurityをfalseにする（無効にする）とどうなりますか？
A1：以下のようなことが起こり得ます。
セキュリティホールが開いているわけですから該当のセキュリティホールを突く攻撃をされた場合は基本的に防ぎようがなくされるがままとなります。通信の経路に割りこまれるという攻撃ですから、extensions.checkUpdateSecurityをfalseに設定されていて、extensions.checkUpdateSecurityをfalseにしなくてはならないようなアドオンがインストールされているという2点の条件さえ揃えば攻撃を受ける可能性があります。アドオンの質やアドオンの作者（ベンダ）の信頼性などは関係ありません。
人気のあるアドオンではユーザ数が数十万から百万を超えるものもある（「ユーザが多い拡張」の一例）ので攻撃者にとって標的として悪いものではないでしょう。また、最近ではFirebugやDownThemAll!などのよく知られたアドオンのホームページが攻撃を受けて改変されるということも実際に起こっています。
Q2：「安全な更新方法が用意されていないため、インストールされません」という警告が出てインストールできないアドオンをどうしても使いたいです！
A2：アドオンパッケージの中にあるinstall.rdf内のupdateURLの部分の記述を削除してください。それでインストールできるようになります。自分でできない場合はアドオンの開発者に連絡を取って、下の3つからいずれかの対策をするように依頼してください。
Q3：どのようにアドオン開発者に報告したらいいの？
A3：英語が苦手でも下記をコピー＆ペーストすればとりあえず相手に意図は通じるはずです。
Securing Updates http://developer.mozilla.org/en/docs/Extension_Versioning%2C_Update_and_Compatibility#Securing_Updates McCoy http://developer.mozilla.org/en/docs/McCoy
以下に簡単な経緯。
追記（2008年5月19日6時）：
Amigomrさんがこの記事で云いたいことを一言で表現してくだすっています。
about:config 自体を編集すること自体が危険を伴うことだが、その中でも、セキュリティ関連の設定をむやみに変更することは危険だ。
Amigomrの徒然日記 より引用
追記（2008年5月19日19時30分）：
Piroさんが言及してくだすっています。
註1：というか、標準でabout:configの設定名の一覧になかったり、設定するとアドオンマネージャに警告が表示されたりするわけだから、ちょっとした日本語理解力や警戒心や洞察力があったらこの設定変更はしないと思うんだけど……日本語言語パックのほうでこの警告の文言をもう少し強い表現に変えるというのはありかもしれない。
註2：たぶん技術的なことを理解した上でユーザを危険にさらすようなことを云っているのでこの件では一番タチが悪い一人だと思う。
註3：こんなのMozilla Japanとかもじら組とかlevelさんの領分の記事じゃないですか。私やPiroさんはこの件に関心があるから情報収集をしてるわけだけど、「アドオンを提供する立場」目線でそれを記事にするので（そりゃ当事者だからね）アドオンの一般ユーザには分かりにくい記事になるのはしょうがないです。
註4：ちなみにlevelさんの記事もあるけどコメント欄も含めて非常に誤解を招きやすい記事になっちゃってるので、注意して読む必要があります。
註5：どこかITmediaとかCNET Japanみたいな企業がやってるIT系の情報サイトで日本語の記事としてこの情報を見たんだけどリンクを忘れちゃった……情報ソースのリンクをご存知のかたは教えてください。
以下ちょっと愚痴ですが、公開までの流れを良く理解していなかったり。
- AMO ユーザからのレビュー→公開申請→AMOの中の人の審査→晴れて一般公開
こういう認識でいいのかなぁ。AMOの説明だと、ユーザからの評価もAMOの審査も同じ「レビュー」という言葉が使われているので、どちらの事を指しているのか文面からつかみづらい気がする。公開申請時の文章も何を書けばいいんだろ。こういう環境でテストした、エラー出てないよ、辞書.app が使えると便利だろ！とかでいいんだろうか。そんでそれは日本語で書いてもいいんだろうか。
「サンドボックスのレビューシステム」と「アドオンポリシー」に加えて以下を見たら、そうなんじゃないかなぁ、と。これから空前の引用大会はじまり。
アドオンの一般公開を申請
サンドボックスにあるアドオンは、エディタによるレビューを受けています。承認された場合は、公開ページに掲載され、ユーザが利用できるようになります。レビューをスムーズに進めるため、以下の点にご注意ください。
- テーマを登録する場合、プレビュー画像も併せて登録する必要があります。他の種類のアドオンについても、プレビュー画像の掲載を強くお勧めします。
- 登録されたアドオンは、エディタによるレビューとユーザからのフィードバックが十分に蓄積されるまで、サンドボックスに置かれます。公開にあたってはレビューが必要です。
- 一般に公開するアドオンは、サンドボックスに置かれているアドオンよりも品質が高く、Web の利用価値を高めるものでなくてはなりません。
- 詳細な申請条件は アドオンポリシー でご覧いただけます。
アドオンの公開を申請するには、(エラーや警告が出ないことを含めて) どのようなテストを行ったかや、多くのユーザにとってどこが便利かを記述してください。第三者によるレビューがある場合は、その URL も含めてください。
Mozilla Add-onsの開発者用ツール内のページの吉野さんによる訳 より引用
次にPiroさんによる翻訳記事から。
- そのアドオンは利用者からのレビューが付いているか？
AMOでは、公開を申請されるアドオンには、ユーザからのレビューが付いている事を求めている。レビュー無しでは、私達エディタは私達の仕事を十分に果たすことができない。これはアドオンの公開の申請が却下される場合において私が目にしてきた最も多い例だ。
- アドオンに付いているレビューは簡素なものか、それともより技術的なレビューに近い物か？
「これはすごい拡張機能だ！」とか「このテーマはとてもイイ」という風なレビューは、全く参考にならない。この種のレビューは私に、人々がそのアドオンの事をどれくらい便利と思っているかということを伝えてはくれるが、しかしそれだけでは公開の申請を受け付けるには不十分だ。そのアドオンがごくわずかしかレビューを得ていなくて、そしてそれらが上記の2つの例のような物であった場合、私は大抵そのアドオンをサンドボックスの中に留め置くだろう。
私が実際に見るレビューは、そのアドオンをインストールして、試して、そしてその結果を報告している物だ。プラットフォーム（Windows, OS X, Linux）への依存によって正しく動かない機能や、アプリケーション（Firefox, Thunderbird）もしくはそのバージョン、あるいは拡張機能自身のバージョンに起因する問題についてのレビューは、とても素晴らしい物と言える。レビュアーが何を試して、何を気に入り、何を気に入らなかったのか（詳細も含めて）、を説明したレビューは非常に役に立つ。もし正しく動かない昨日に付いての報告がいくつか見うけられたら、私はその拡張機能をサンドボックスに留め置いて、作者にそのことを知らせるだろう。しかし、技術的に十分に望ましいレビューがあるのなら、私は審査のプロセスを続けるだろう。
あとこの部分かな。
- アドオンが公開されるためにはレビューがいくつ必要なのでしょうか？
必要なレビューの数に基準はありません。最終的な決定は、良いレビューがどれだけ付いているか、アドオンについてきちんと説明されているかどうか、などを基準としてエディタが下します。
- 私のアドオンはサンドボックスの中にあり、ユーザからのレビューを必要としています。外部のレビューも受け付けてもらえるのですか？
はい。もし誰かがあなたのアドオンについて、オンラインマガジンやブログなどで書いているなら、アドオンの公開を申請する際に、そのレビューへのリンクを「レビュー担当者への連絡事項（Notes to Reviewer）」欄に書いてください。
日本語での公開申請申しこみや、日本語で書かれた外部レビューの公開申請時の提示はOKだけど、日本語が分かるMozilla Add-onsのエディタしかそれを審査できないので、英語より審査結果が出るのが遅くなる、ということだったかと。というか、日本語と密接に結びついていたり日本ローカルで役に立つ公開アドオンのレビューでさえ絶望的に遅いという声をちらほら目にする現状では、特に日本語での公開申請申しこみはやめたほうがいいとは思います。
あと、テーマの場合はConsole 2を使うなり下記の設定をするなりして（どちらでもやることは一緒）エラーコンソールにユーザインターフェイス部分のCSSエラーも表示させるようにすれば、typoとかレベルのケアレスミスのチェックはできます。
JavaScriptコンソールは、初期状態ではXULアプリのエラーを表示しません。プロファイルディレクトリのprefs.jsに以下の2行を加えれば、エラーが表示されるようになります。
user_pref("javascript.options.strict", true);
user_pref("javascript.options.showInConsole", true);
個人的には5年間継続して開発されてきて、その期間中の3年間は日々開発が成果が一般に公開されてきたある意味で熟成されきったテーマ（当然テーマ開発者のテーマ開発に関する経験も5年になる）のアイコンだけを変えたテーマへの型式承認って必要なのかなぁ、とちょっぴし思ってみたり。意義はあるし正しいし理解はできるけど、ピケに自動車運転教習を受けさせるようなものというか、「メルカバシリーズの最新型のメルカバ Mk 4は新しいのでコンバットプルーフが取れてない」と云うようなものというか……
あまたの何かしら経由。
たぶんFirefox 3公開に合わせてでしょうけど、またMozilla Addonsがバージョンアップするそうです。とりあえず「Mozilla Addonsバージョン3.2のプレビュー」の記事の詳細は拡張あれこれさんとかに期待しつつ、わたし的にざっくり説明すると、新しい点としては次のようです。<追記 date="2008年02月17日06時40分">拡張あれこれさんさんによるより分かりやすい記事。</追記>
それで特に実際触っての感想を知りたいのは以下だそうです。
で、例によって試してフィードバックくださいとのことです。れっつ・ごー。
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.9b3pre) Gecko/2008020121 SeaMonkey/2.0a1pre
とはいっても、フィードを配信しているWebサイトにアクセスするとFirefoxみたくロケーションバー右側（とメニューバーのブックマークメニューに）にフィードアイコンが表示されるだけですが……手元では、ブックマークへのライブブックマークの登録や、フィードへのスタイル付け、それにフィードを処理方法を選択するユーザインターフェイス（フィードリーダとかに渡したり）とかはまだみたい。Thunderbirdのフィード購読機能もMailに移殖されるそうで、このへんも少しづつ進んでますね。
あとSeaMonkeyでおもしろそうなのは、ナビゲータにFirefoxみたく「ツールバーのカスタマイズ」機能をつける（Bug 394288）というのですねぇ（Classic [bugzilla.mozilla.org]・Modern [bugzilla.mozilla.org]）。Modernのナビゲーションツールバーはボタンを他に動かさないことを前提にしてデザインされているので厳しいと思うんですが、まぁ、テーマレベルでいうとSeaMonkey 2はぐだぐだですし……
追記（2008年02月05日05時40分）：
ライブブックマークについては「ライブブックマークの実装」で、フィードへのスタイル付けについては「フィードへのスタイル付けの実装」で取り扱うみたいです。
まず、すごく素敵だし完成度も高いと思います。後は細かい部分を修正するだけって感じです。
以下簡単に。
