最新 RSS Twilog 掲示板

くでんな日々や公開どう?

<前の5件 次の5件>

2008/05/18

[Mozilla] 塞がれたセキュリティホールを開けろという人々

はじめに結論を書いておきます。

  • extensions.checkUpdateSecurityをfalseにする(安全な「アドオンの更新」が提供されているか確認する設定を無効にする)ということは、一度塞がれたセキュリティホールを自らの手で開けるということである。
  • この設定項目はMozilla製品やアドオンの開発者がテストなどに用いるために存在するものと思われる。一般ユーザはこの設定を初期設定から変えるべきではない[註1]。

Firefox 3では、「アドオンの更新」を提供しているアドオンのうちで安全な「アドオンの更新」を提供していないものはインストールできなくなりました。それで、Webを見てると、Mozilla Re-MixFirefox更新情報 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つからいずれかの対策をするように依頼してください。

  1. 「アドオンの更新」を提供したいアドオンはMozilla Add-onsで配布する。
  2. Mozilla Add-ons以外でのアドオンの「アドオンの更新」の提供をやめる。
  3. McCoyを使うなり、「updateURLにSSL接続のURIを使う+updateHashを記載」するなりして安全な「アドオンの更新」を提供する

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

以下に簡単な経緯。

  1. Firefoxの「アドオンの更新」機能に中間者攻撃が可能であるというセキュリティホールが発見[註4]される。
  2. アドオン開発者に向けて、「アドオンの更新」を提供したい場合はMozilla Add-onsで拡張を配布するか、install.rdf内のupdateURLをSSL接続のURIに変更するよう勧告がされる。
  3. 実際にこのセキュリティーホールが攻撃に利用された例が報告される[註5]。
  4. Firefox 3で対策が取られてセキュリティホールが塞がれる。これによってinstall.rdf内にupdateURLの記述がないか、install.rdf内にupdateURLがある場合は一定の条件を満たさないとアドオンがインストールできなくなった。
  5. install.rdf内のupdateURLがSSL接続のURIではない場合でも安全に「アドオンの更新」を提供することを可能にする、アドオン開発者向けツールの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系の情報サイトで日本語の記事としてこの情報を見たんだけどリンクを忘れちゃった……情報ソースのリンクをご存知のかたは教えてください。

2008/05/17

[Mozilla] サンドボックスのアドオンを公開の方法ってこうかい?

以下ちょっと愚痴ですが、公開までの流れを良く理解していなかったり。

 

- AMO ユーザからのレビュー→公開申請→AMOの中の人の審査→晴れて一般公開

 

こういう認識でいいのかなぁ。AMOの説明だと、ユーザからの評価もAMOの審査も同じ「レビュー」という言葉が使われているので、どちらの事を指しているのか文面からつかみづらい気がする。公開申請時の文章も何を書けばいいんだろ。こういう環境でテストした、エラー出てないよ、辞書.app が使えると便利だろ!とかでいいんだろうか。そんでそれは日本語で書いてもいいんだろうか。

 

Firefox から辞書.appで検索する拡張「Look Up in Dictionary」 より引用

サンドボックスのレビューシステム」と「アドオンポリシー」に加えて以下を見たら、そうなんじゃないかなぁ、と。これから空前の引用大会はじまり

アドオンの一般公開を申請

 

サンドボックスにあるアドオンは、エディタによるレビューを受けています。承認された場合は、公開ページに掲載され、ユーザが利用できるようになります。レビューをスムーズに進めるため、以下の点にご注意ください。

 

- テーマを登録する場合、プレビュー画像も併せて登録する必要があります。他の種類のアドオンについても、プレビュー画像の掲載を強くお勧めします。

- 登録されたアドオンは、エディタによるレビューとユーザからのフィードバックが十分に蓄積されるまで、サンドボックスに置かれます。公開にあたってはレビューが必要です。

- 一般に公開するアドオンは、サンドボックスに置かれているアドオンよりも品質が高く、Web の利用価値を高めるものでなくてはなりません。

- 詳細な申請条件は アドオンポリシー でご覧いただけます。

 

アドオンの公開を申請するには、(エラーや警告が出ないことを含めて) どのようなテストを行ったかや、多くのユーザにとってどこが便利かを記述してください。第三者によるレビューがある場合は、その URL も含めてください。

 

Mozilla Add-onsの開発者用ツール内のページの吉野さんによる訳 より引用

次にPiroさんによる翻訳記事から。

- そのアドオンは利用者からのレビューが付いているか?

AMOでは、公開を申請されるアドオンには、ユーザからのレビューが付いている事を求めている。レビュー無しでは、私達エディタは私達の仕事を十分に果たすことができない。これはアドオンの公開の申請が却下される場合において私が目にしてきた最も多い例だ。

 

- アドオンに付いているレビューは簡素なものか、それともより技術的なレビューに近い物か?

「これはすごい拡張機能だ!」とか「このテーマはとてもイイ」という風なレビューは、全く参考にならない。この種のレビューは私に、人々がそのアドオンの事をどれくらい便利と思っているかということを伝えてはくれるが、しかしそれだけでは公開の申請を受け付けるには不十分だ。そのアドオンがごくわずかしかレビューを得ていなくて、そしてそれらが上記の2つの例のような物であった場合、私は大抵そのアドオンをサンドボックスの中に留め置くだろう。

私が実際に見るレビューは、そのアドオンをインストールして、試して、そしてその結果を報告している物だ。プラットフォーム(Windows, OS X, Linux)への依存によって正しく動かない機能や、アプリケーション(Firefox, Thunderbird)もしくはそのバージョン、あるいは拡張機能自身のバージョンに起因する問題についてのレビューは、とても素晴らしい物と言える。レビュアーが何を試して、何を気に入り、何を気に入らなかったのか(詳細も含めて)、を説明したレビューは非常に役に立つ。もし正しく動かない昨日に付いての報告がいくつか見うけられたら、私はその拡張機能をサンドボックスに留め置いて、作者にそのことを知らせるだろう。しかし、技術的に十分に望ましいレビューがあるのなら、私は審査のプロセスを続けるだろう。

 

Mozilla Add-onsのエディタの人がどういう風に審査してるのか、についての詳細 より引用

あとこの部分かな。

- アドオンが公開されるためにはレビューがいくつ必要なのでしょうか?

必要なレビューの数に基準はありません。最終的な決定は、良いレビューがどれだけ付いているか、アドオンについてきちんと説明されているかどうか、などを基準としてエディタが下します。

 

- 私のアドオンはサンドボックスの中にあり、ユーザからのレビューを必要としています。外部のレビューも受け付けてもらえるのですか?

はい。もし誰かがあなたのアドオンについて、オンラインマガジンやブログなどで書いているなら、アドオンの公開を申請する際に、そのレビューへのリンクを「レビュー担当者への連絡事項(Notes to Reviewer)」欄に書いてください。

 

Mozilla Add-onsでのレビューの仕方 より引用

日本語での公開申請申しこみや、日本語で書かれた外部レビューの公開申請時の提示は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);

 

JavaScriptコンソールのエラーメッセージ より引用

個人的には5年間継続して開発されてきて、その期間中の3年間は日々開発が成果が一般に公開されてきたある意味で熟成されきったテーマ(当然テーマ開発者のテーマ開発に関する経験も5年になる)のアイコンだけを変えたテーマへの型式承認って必要なのかなぁ、とちょっぴし思ってみたり。意義はあるし正しいし理解はできるけど、ピケに自動車運転教習を受けさせるようなものというか、「メルカバシリーズの最新型のメルカバ Mk 4は新しいのでコンバットプルーフが取れてない」と云うようなものというか……

2008/02/16

[Mozilla] 俗・くでんMozilla Addons探検隊

あまたの何かしら経由。

たぶんFirefox 3公開に合わせてでしょうけど、またMozilla Addonsがバージョンアップするそうです。とりあえず「Mozilla Addonsバージョン3.2のプレビュー」の記事の詳細は拡張あれこれさんとかに期待しつつ、わたし的にざっくり説明すると、新しい点としては次のようです。<追記 date="2008年02月17日06時40分">拡張あれこれさんさんによるより分かりやすい記事</追記>

  • 開発者向けコントロールパネルの統計情報表示を改良
  • サンドボックスとのより良い統合
  • アドオンのカテゴリ分けとナビゲーションをよりシンプルに

それで特に実際触っての感想を知りたいのは以下だそうです。

  • このインターフェイスの改良はあなたがアドオンを捜すのをより早くより簡単にしますか?
  • アドオンの種類分け(拡張機能・テーマ・検索エンジン・プラグインとか)をなくして、ぜんぶまとめて機能別に分けてみたけどこれは混乱する?

で、例によって試してフィードバックくださいとのことです。れっつ・ごー

トップページ
日本語だとまだ表示が少し崩れるので英語ページに切り替えてあります。
Firefox以外のXULアプリケーションのアドオンページへの切り替え
トップページ右上の「Other Applications」をクリックすると表示されます。
検索語句入力部分
ドロップダウンメニューからカテゴリを絞り込んでの検索もできます。
カテゴリ
左側の「Categories」の「Download Management」をクリックした先のページ。
テーマはどこに?
同じく左側の「Categories」の「Interface Customizations」にユーザインターフェイスを変更する拡張と一緒にまとめてあるみたいです。正直云って分かりにくいと思います……
検索してみる
トップページに戻って検索文字列入力欄に「modern」と入力してEnterを押すと一覧が表示されます。Phoenity Modernがありました。
アドオンのページ
たしかにすっきりした感じ。感想を書く欄が分かりやすくなっています。一番下の「Advanced Details」の「expand」を押してみると...
Advanced Details
開発者のコメント・開発者のWebサイト・最新バージョンについてのコメント、が表示されます。えっと、開発者のコメント・最新バージョンについてのコメントがユーザに分かりにくい(ユーザの目につきにくい)のはすごく困るんですが……
ログイン
トップページに戻って、ページの右上の「Log in」からログインしてみます...
開発者ツールへのリンク
ログインすると「Log out(Log in)」の横にアカウントの編集ページへのリンクが、そして「Log out」の少し下に開発者ツールへのリンクが表示されます。
開発者ツールのページ
開発者ツールの個々のページやできることは現行とあんまり変わらないので省略します。個人的ポイントとしては、Bug 401105で拡張と同じようにテーマもある時点でインストールされているテーマが実際に使用中か使用中じゃないか分かるようになったので、将来的にはその情報が「Active Daily Users」に反映されるようになると思われることでしょうか。アドオンの更新確認が有効になっている場合は、Mozilla Addonsに自動的にインストールされているアドオンの新しいバージョンがあるかないかの照会が行きますけど、そのときに統計資料としてその時点でインストールされているテーマが実際に使用中か使用中じゃないかの情報も統計資料として確認するようにしたいようです。<追記 date="2008年02月17日06時40分">現時点では「Active Daily Users」は(少なくともテーマに関しては)実際に使われている使われていないに関係なくとりあえずインストールされていてアドオンの更新の確認が有効になっている状態で、その日のうちにMozilla Addonsにそのアドオンの新しいバージョンがあるか問い合わせがあった数、なんだと思います。</追記>
サンドボックスとの統合
ログインしてサンドボックスのページに切り替える必要はなくなって、例えば「Qute」の文字列で検索すると公開されているアドオンもサンドボックスにあるアドオンもすべて表示されるようになりました。背景が薄い水色なのが公開されているアドオンで、背景が薄いピンクで「EXPERIMENTAL(実験的な)」と書いてあるのがサンドボックスにあるアドオンです。っていうか、非公式にFirefox 3に対応したQuteがサンドボックスにあったんだ……<追記 date="2008年02月17日06時40分">のりさんの記事</追記>って、いけないいけない、話を戻すと、サンドボックスにあるアドオンへのリンクをクリックするとログインしている場合はそのままアドオンのページが表示されて、ログインしていない場合はログインページへ移動します。

2008/02/02

[Mozilla] SeaMonkeyへのライブブックマークの移殖

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分):

ライブブックマークについては「ライブブックマークの実装」で、フィードへのスタイル付けについては「フィードへのスタイル付けの実装」で取り扱うみたいです。

2007/12/26

[Mozilla] Mac OS X Leopard Mail

まず、すごく素敵だし完成度も高いと思います。後は細かい部分を修正するだけって感じです。

以下簡単に。

  • install.rdfのem:minVersionを2.0にem:maxVersionを2.0.0.*に。
  • 「進む」「戻る」「タグ」ボタンのアイコンがない?
  • 読み込み中アイコン(スロバー)が大きい。アイコンサイズ、アイコンのみ・アイコンとテキスト・テキストと切り替えても同じ。
  • 設定ウィンドウの文字や要素が切れる。使いたくなるのはよく分かりますけど、「ウィンドウやダイアログその他各部の幅や高さへの固定サイズの指定」「ユーザインターフェイス部分のフォントのフォント名やフォントサイズの決め打ち」は諸刃の剣なので慎重に。多環境に対応できませんから。このあたりを総決め打ちにすればどの環境でもだいたい同じにはなりますけど、原則的にユーザインターフェイス部分のフォントは個々人が自分でデスクトップの表示に使っているフォントやフォントサイズが一番使いやすいはずです。
  • 個人的にはテーマ名は「Leopard Mail」くらいにしたほうがいいと思います。「Leopard」も「Mail」も一般名詞でその組み合わせで作った造語だと云えないこともないですし。商標面を考えると「Mac」とか「Apple」とか「OS X」はテーマ名に入れるのは避けるべきだと思います(もちろん本当は「Leopard」もですけどね)。
  • 自分が完全に新規作成した画像、コードについては、再配布などを考慮してできれば使用条件(ある場合)やライセンスを自分で決めてそれを文書に明記してアドオンパッケージ内に含めてください(他者による再利用を想定して。添付しない場合、再利用したい人から毎回毎回問い合わせがくる)。
  • 他者が作成した画像、コードについては原則再利用(そのまま流用や加工して流用)はできません。ただし、作成した人から許可を得ている場合、もしくは他者が作成した画像、コードに使用条件やライセンスが示されていてそれに従っている場合は別です。どちらの場合も再配布などを考慮してその旨を文書に明記してアドオンパッケージ内に含めてください。
  • Thunderbird 2の標準テーマに含まれる画像以外のファイルはMPL 1.1/GPL 2.0/LGPL 2.1のトリプルライセンスで配布されています。
  • Thunderbird 2の標準テーマに含まれる画像でこのページで配布されているZIPファイルに含まれる画像およびそれと同等の画像はArvid Axelssonさんによってクリエイティブ・コモンズライセンスで配布されています。それ以外の画像はMPL 1.1/GPL 2.0/LGPL 2.1のトリプルライセンスで配布されています(これであってると思う。できれば問い合わせを)。
  • 「他のアドオンと組み合わせて〜」はマルチアイテムパッケージとかem:requires拡張機能の依存関係)とか技術的には手がないわけじゃないですけど、いろんな意味で話がややこしくなるので、これらのアドオンと一緒に使うといいですよ、と配布ページでカスタマイズとして提示するのがいいと思います。
  • 日本人からフィードバックが欲しい場合は、一番簡単なのは適当なレンタルblogを借りて適当に記事を書いてその記事内にdeviantARTのページへのリンクをはって、コメント欄でフィードバックを受けつける方式(例1例2)でしょうね。英語でコミュニケーションできる人からのフィードバックだけでいいや、という場合はdeviantARTだけでやってみるとか、MozillaZineフォーラムのExtension/Theme Releasesフォーラム(人は多い。逆にいえばあんまりリプライがなかったら埋もれちゃうんだけど)かTheme Developmentフォーラム(人は少ない。ただしテーマ開発者やコアなテーマユーザがいる)にLeopard Mailのトピックを立てちゃうとか?
  • 最近の例だと、FoxdieなんかはdeviantARTで開発を続けてある程度の完成度になったところでMozilla Add-onsに登録して、比較的すぐにレビューがついてサンドボックスでテストの状態から公開のアドオンになりました。
  • あとは、ご自身でがんばってください、としか。まずは、大事なのはフィードバックしてくれるユーザを得ることでしょうね。それか、PremierさんがおっしゃるようにmozillaZine日本語版のテーマフォーラムにこのテーマの開発についてのトピックをつくって皆さんに協力を願うとか。とりあえず、書けることと書きたいことは簡単に書きました。次に私が関与するとしたらどうしてもサンドボックスでレビューがつかないときくらいかな?