May 01, 2006

Mozilla Party JP 7.0いってきた

Mozilla Party JP 7.0行ってきたよ。

も組の歴史とMJの話は、すみません、全然聞いてませんでした。会場で外部のネットワークに繋がらないということを聞いて、ローカルでサンプルが動作するように突貫工事で色々やってたもので……

ダリン・フィッシャー氏の話は概ね今までに各所で出てきていた情報のまとめ的なものだったので、こちらもあんまりまじめに聞いてなかったですごめんなさい。でもXULRunnerの起動プロセスとかは知らない情報だったので面白かったです。

ポータブルOOoの話はちょっと面白かった。でもJavaVMとかフォントとかは使用環境の方にインストールしないといけないというのは仕方がないのか(フォントはLinuxではインストール不要でOOoでだけ使えるようにできるそうなんだけど)。

Gomita氏のScrapBookの紹介と今後の計画は、個人的に一番期待していた発表。スクラップした内容のサムネイル表示というのはなかなか興味深かった。拡張機能コンテストの賞品が届いたら後で関税を請求されたというのが今日一番ウケた話。ちなみに後で聞いてみたところ、賞品の中には僕も欲しくてたまらない例のレッサーパンダのぬいぐるみもあったそうですよ。羨ましい!!

で、最後に僕の発表だったわけですが。

毎回来てくださるような人に同じ話を聞かせてもしょうがない……と考えてしまって、ネタ方向に走りがちな自分の性格は、なんとかしたいところです。くでん氏のおっしゃる通り、もっと堅実にいかないといかんのだろうなあ。内容というかテーマ自体についてもお叱りを受けているし……

プレゼン内容は資料を見ていただくとして、何をやったかというと、VMware上にインストールしたWindowsを仮想の攻撃対象として、攻撃用の拡張機能のサンプルを実行してあれこれという感じです。ウィンドウを震わせるだのタブを無限に開きつづけるだのの古典的ブラクラ……はウォーミングアップとして、Firefoxのカスタマイズ可能なツールバーの中身をグチャグチャにかき回す(しかも一定時間毎に自動で)とかいったイヤすぎる例だとか、システムを壊すようなシャレにならないものもいくつかやってみました。

その後の質疑応答では色々な話が出てきて、僕自身気づいていなかったり見落としていたりといった点を補強してもらえた感じで、嬉しかったです。

  • JLPを同梱した野良拡張機能等の扱いはどうすればよいのか。→普通の拡張機能と違ってフォーク版のような扱いになるだろうし、Mozilla Addonsに登録してよいものかどうか……ただ、普通の拡張機能については、なるべくMozilla Addonsに登録してそちらからのダウンロードを推奨することで、「そこらのアップローダで公開されているものを気軽にインストールするのが当り前」ではなく「信頼できるサイトからインストールするのが当り前」という空気に持っていけるのではないだろうか。
  • 手軽に開発・配布することを禁じられては、開発者のモチベーションがなくなるのではないか(Gomita氏も、もしそんな状況であったらScrapBookを開発しなかったかもしれないとおっしゃっていた)。→安全性の追求と、自由さ・間口の広さというのは、トレードオフにならざるを得ないのではないか。安全性の低い、しかし間口の広い状況であったがゆえに、現在のように多数のユニークな拡張機能が登場したことは事実だろう。皮肉な事だ。
  • コードを精査すれば、危険なコードを事前にはじくことができるのでは?→JavaScriptでは、コード片を文字列として分散させたり連結したりといった事が当り前に行える。単純なチェックでは検出できないのではないか。
  • 拡張機能のシステム自体の改良でどうやって安全性を確保する?→あらかじめ宣言されたXPCOMコンポーネント以外は使用させない、という拡張機能のドメインごとの制限(Javaではそういうことをやってると聞いた)を行うのが一番確実ではないだろうか。
  • 認証や署名付きの配布ファイルというのはできないのか?→署名を付ける仕組みは既にある(Google Toolbarなどはそれを使っている)。しかし個人で署名を作るのは大変。Mozilla AddonsなりMozilla Japanなりがそれを代行してくれるようにならないだろうか、と、拡張機能作者としては期待してしまう。なお、署名は出自を証明するものではあるけれども、内容までは証明しない、という事には気を付けておきたい。
  • NoScriptのホワイトリストを共有する機能があるが、悪意あるユーザがホワイトリストを汚染する可能性があるのでは?→大事な事は人任せにしない、ということしか言えないのではないだろうか。
  • 今回のデモはWindows 98でのものだったが、他の環境ではどうなのか?→マルチユーザ環境のWindows XPやLinuxでは、ここまで簡単には破壊活動はできないと思われる。しかし、常時管理者権限で使っているのならほとんど同じ事が可能だし、プラットフォームや他のアプリケーションにセキュリティホールがあれば、そこを攻撃して連鎖的に切り崩していくこともできるだろう。Firefoxだけ更新していれば安全、というような慢心はくれぐれもしないでほしい。また、XULやXPCOMというのはクロスプラットフォームな技術なので、クロスプラットフォームな脆弱性や、クロスプラットフォームな悪意ある拡張機能、というのも登場し得る。Macだから安全とか、Linuxだから安全とか、そういうことも言えない。
  • 拡張機能の作者として、何かできることはないのか?→例えばLine Markerでデータ保存にテキストファイルの入出力を使っているが、工夫すれば、標準のAPIだけでもやりくりできたはず。仮に拡張機能ごとに権限を設定できても、作者が横着をしてしまうことで、それが無に帰してしまいかねない。ファイルアクセスという危険な権限無しでも実現できるはずの物なのに、危険な権限を無駄に要求してしまうということになる。作者もそこは慎重になる必要があるのではないか。
  • addons.mozilla.orgなどの信頼済みサイト以外では、インストール用のリンクをクリックして、サイトを許可リストに追加して、もう一度リンクをクリックして、数秒待たされて、OKボタンを押して、再起動して……という手間をこれだけかけさせているのだから、普通の人は途中で諦めてくれるのではないか?→一般の事務員等はそれで十分だろうけれども、ネトラン読者に代表されるような挑戦心に溢れている人達は気にしないのではないだろうか、むしろ、それだけのステップを経ることを楽しんだりすらするのではないだろうか? それに、一度そのステップを経ることに慣れてしまえば、その安全策は意味を持たない。Winnyでの個人情報流出の過程などを見ていても、ユーザの側にごく基本的な意識が欠如していたせいで被害が拡大していた。ソフトウェア側の対策を続けると同時に、やはり、コンピュータリテラシ教育の一環として、セキュリティ意識の徹底を早期から行う必要もあるのではないだろうか。

自由と安全性のトレードオフというのが、実に頭の痛い所で……。

エントリを編集します。

wikieditish message: Ready to edit this entry.











拡張機能