Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 31/241: « 27 28 29 30 31 32 33 34 35 »

すべて彼女のために - Mar 11, 2010

撃たれると痛い「すべて彼女のために」 - 2010-03-01 - ゾンビ、カンフー、ロックンロールのレビューを見て気になったので、すべて彼女のためにを見てきた。東京だと有楽町、神奈川だと横浜、関西だと大阪で上映してるようです。って3館だけかい! これから増えるのかな? 毎週水曜の安くなる日でも夜の回は結構空いてました。

  • セリフがいきなり英語じゃなくて驚いたんだけど、これフランスの映画だったんですね。
  • 妻が逮捕された冤罪については、真実を解き明かすとかそういう展開は無いです。逃げようのない極限状態に追い込まれた時に、人は愛する人のために一体どこまでできるのか? という事を描くための背景設定でしかないので。
  • ギリギリの綱渡りばかりで、見てて非常にハラハラいたしました。
  • 親も兄弟も友達も仕事も住む所も、今の生活を全部捨ててでも取り戻したいモノ。それのためにどこまでも強くなろうとする、でもなりきれないで挫けそうになる、主人公の葛藤がすごい。妻が電話口で崩れ落ちる時の絶望感がすさまじい。

見終わった後、圧倒されて言葉が出てこなくなる。そんな映画でした。

Windows VistaからWindows 7へアップグレードした - Mar 08, 2010

会社で使ってるWindows Vistaがどういうわけか、ハイバネーションからの復帰にやたら時間がかかるわ復帰後ほっとくとブルースクリーンになるわで死にかけだったので、一縷の望みを託してWindows 7にアップグレードしてみることにした。(もしなんかのファイルが破損してるなら、そのファイルが使われなくなってくれないかなあ?と思ったので。)

  • 「エクスプローラ」改め「エクスプローラー」をファイラ代わりに使うにあたって、左ペインにフォルダのツリーを表示できなくなっていた。
    • フォルダーオプションで「全般」タブの「ナビゲーション ウィンドウ」で「すべてのフォルダーを表示する」と「自動的に現在のフォルダーまで展開する」にチェックを入れてやらないと、今までと同じ使い勝手にできない。
  • フォルダアイコンをデスクトップの端にドロップして作るツールバーが、Windows 7では使えない。これまでは、クイック起動をタスクバーから分離して、個別のツールバーとしてランチャ代わりに利用していたのだけれども、代替手段が無くなってしまった。
    • Windows 7のタスクバーはMac OS XのDockのパクリなので、一回起動してタスクバー上のボタンを右クリック→登録 でタスクバーにショートカットを登録できるんだけど、なにぶん数が多い(Firefox 2、Firefox 3、Firefox 3.5、Firefox 3.6、Minefieldのそれぞれで通常起動とコンソール付きの2通り、同じようなショートカットがThudnerbird用にもある)ので、登録し直すのが面倒でたまらない。
    • 登録し直してみたけど、それぞれのアイコンの横にラベルを表示できないみたいで、判別に苦労する。
    • ショートカットの実体は C:\Users\ユーザ名\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar に置かれるので、ここにショートカットを置けばタスクバーの方に反映されるのかな?と思って試してみたけど駄目だった。タスクバー上でピン留めしないと表示されなかった。
  • Windows 7のインストール時に、互換性のレポートでMicrosoft Virtual PC 2007 SP1がWindows 7での動作を保証されていないという警告が出た。
    • Windows 7になってからVirtual PCを起動すると、VMNetSrv.sysというファイルが見つからないとかなんとかいうエラーが出た。
    • このファイルは C:\Windows\System32\DriverStore\FileRepository\vmnetsrv.inf_x86_neutral_ランダムな文字列? の位置にあった。ファイルの検索で見つかったので、選択してやると、Virtual PCが起動してくれた。
    • 1回正常に起動した後は、それ以後も問題なく動いてるみたい。
    • クライアントOSのWindows XPとの間でドラッグ&ドロップでファイルをコピーする機能もちゃんと動いてる。

これでまだ落ちるようだったら無駄なことに時間を使ってしまったということになるのでとても悲しいです。

四次元ポケットを考えていたら、他のひみつ道具の原理も説明できた - Mar 02, 2010

ドラえもんの4次元ポケットについて真面目に考えてみた。

4次元ポケットの中には、外見から想像される容積より遙かに多くの物を格納することができる。また、内部空間はスペアポケットとの間で共有されているため、スペアポケットから入ってドラえもんのポケットから出てくるということもできる。(実際に、行方不明・回収不能になったドラえもんを発見するためにこの方法を使ったエピソードもある。)

4次元という物を正しく理解すると、どのようにすればこういった仕組みを実現できるのかが見えてくる。

4次元を理解するには、2次元と3次元を対比した場合を考えるのが手っ取り早い。

  • 2次元の住人である2Dドラえもんや2Dのび太達は、床の上に置かれた1枚の巨大な模造紙のようなレイヤである、2次元世界で生活している。
    • この世界は平面なので、X軸とY軸しか無い。
  • ここで、2Dドラえもんがお腹の3次元ポケットに2次元の物体を放り込んだとしよう。するとその物体は、2Dドラえもん達が生活しているレイヤから数mmだけZ軸方向にずれた所に平行に浮かんでいる別のレイヤに移動する。
    • つまり、物体は「3次元ポケットの中に入っている」のではなく、レイヤ同士を繋ぐ3次元ポケットという「ゲート」を通じて別のレイヤへ移動されているのである。
  • これらのレイヤの重なりの方向であるZ軸は、2次元世界のX軸とY軸に対してそれぞれ90度直交している。2次元世界の住人達はZ軸の存在を知らないし、Z軸方向に動くこともできないので、隣のレイヤにある物体を見ることはできないし、ぶつかることもない。
  • 同様のレイヤが、2Dドラえもんの生活する2次元世界や3次元ポケットの先のレイヤの他にも無数に存在していて、ミルフィーユのように積み重なっている。2Dドラえもんの3次元ポケットの出口をどのレイヤに設定するか――出口をどれだけZ軸方向にずらすかは、おそらく任意に決めることができる。
    • よって、スペア3Dポケットは、出口のレイヤの設定が同一である複数の3次元ポケット同士の事を指すのだと考えられる。
  • 2Dドラえもんとスペア3Dポケットが離れた所にある場合はどうなるか。レイヤを何らかの方法で折り曲げると、2Dドラえもん、スペア3Dポケット、そして「3次元ポケットの先のレイヤ」上の点とが重なる。こうして、スペア3Dポケットに入った2Dのび太は、海の底に沈んでいる2Dドラえもんのお腹の3次元ポケットから出てくることができる。
  • 同じ事が、ポケットの中に放り込んだ物を取り出す時にも言える。3次元ポケットの先のレイヤと2Dドラえもんがいるレイヤとの関係を逆にすれば、レイヤ状の好きなところにある物を、別のレイヤの2Dドラえもんがいる位置まで持ってくることができると分かる。

話を我々が暮らす3次元を基準にして考えてみよう。

  • 我々はX・Y・Zの3つの直交する軸が存在する3次元空間で生活している。
  • ここで3Dドラえもんがお腹の4次元ポケットに物体を放り込むと、その物体は、X・Y・Zのすべての軸に直交する第4の軸の分だけ「ずれた」所に移動される。その「ずれた」方向を我々は認識することもできなければ、その方向に我々自身が「ずれる」事もできないので、その物体は目に見えないし、触ることもできない。
  • スペアポケットに入ると、自分自身がその「ずれた」方向に同じだけ「ずれる」事になるので、4次元ポケットの中に放り込まれた物体達に遭遇する事ができる。さらにそこにある「出口」を通ると「ずれ」が元に戻るので、またしずかちゃんやジャイアンやスネ夫と再会する事ができる。4次元ポケットとスペアポケットのある位置が離れていても問題にはならない。

こうして考えてみると、どこでもドアや道路光線や通り抜けフープ、ビッグライトやスモールライトやガリバートンネルも、おそらく同じ基礎技術に基づいて開発されているのだろうと考えることができる。

  • どこでもドアは、途中で「外に出る」事ができないように、4次元ポケットとスペアポケットとを直結した物だと考えられる。なので、スキャン&再構築方式のどこでもドアのようなホラーな事態は起こらない。また、これならドアの出口の先が見えることの説明も付く。
    • そういえば、「宇宙開拓史」ではのび太の部屋の床下と宇宙船との間が繋がった(繋がりが切れそうになっている時には「入り口と出口の間の空間」も描写されてた)のが物語の発端だったなあ。
  • 道路光線や通り抜けフープは、入口を通ると4次元方向に「ずれた」所に移動して、出口を通るとその「ずれ」が元に戻されるのだと考えられる。単に4次元方向に「ずれる」だけなので、3次元的な移動は徒歩なりタケコプターなりで自力で行わないといけない。
  • ビッグライトは、光を当てた物体を4次元方向に強制的に「ずらす」物なのだと考えられる。2次元平面上に置かれた10円玉を持ち上げると、そこにできる影は大きくなる。同様に、物体を4次元方向にずらせば影は大きくなる。
    • ビッグライトとは逆方向に「ずらす」のがスモールライトであり、両方向に対応しているのがガリバートンネルであると考えられる。
    • 影じゃなくて物体そのものの4次元方向の何かを操作するのかも知れない。人間を3次元的に切り刻むともちろん死んでしまうけれど、4次元的に切り刻まれたりこねくり回されたりしても3次元的に問題なければいいということなのかもしれない。
  • のび太を上半身と下半身にぶった切った道具(人体切断機だっけ? 名前忘れた)とか、のび太としずかが首から下を交換したりドラえもんにしずかの脚をくっつけたりした道具とか、任意の動物と合体できる合体のりとか、あの辺の道具も実は4次元的な操作で実現してるのかも知れない。

同じような理屈で、移動する物や大きさを変える物、形を変える物の「原理」を色々と説明することができる。ひょっとしたらタケコプターすらも、同じ基礎技術を使っているのかもしれない。ドラえもんが開発された22世紀というのは、このような4次元を扱う技術が高度に発達した時代なのかもしれない。

この考えの中で一番問題になるのは、「空間を折り曲げる」という所ではないかと思う。

  • 4次元方向の軸に沿った「回転」や「すれる」動作は、多分それほど大きなエネルギーを使わなくても済むはず(位置が大きく変わるわけではないから)。
  • 4次元方向への軸に沿った操作が可能になった時にまず実現されるのは「通り抜けフープ」や「道路光線」の類だろう。これらは単に、4次元方向に「ずれる」だけで実現できるから。
  • しかし空間を曲げるとなると、物凄いエネルギーが必要になるのではないか? ブラックホールはその巨大な質量のせいで周囲の空間を歪めるそうだ。任意の2地点を繋げるように空間を歪めるとなると、ブラックホールと同じくらい、あるいはそれ以上の質量が必要になるのではないか?
  • その点が解決されない限り、4次元ポケットは「物を放り込んだり取り出したりする」事はできても「放り込んだ物を一緒に持ち歩く」事はできない(同じ場所でポケットを使わないと、入れた物を取り出せない)。

ところで4次元ポケットは、ドラえもんに限らず誰でも任意の道具を取り出すことができる。また、ドラえもん自身ですら、混乱している時には望みの道具を一発で見つけることができない。この事から、4次元ポケットは利用者の思考を何らかの方法で読み取ってそれに対応する内容物を返す、汎用的な物体格納・運搬デバイスなのだと考えられる。

  • ドラえもんは「子守用ロボット」であるが、上記のように4次元ポケットを考えた場合には、ドラえもん自体を「4次元ポケットというデバイスを子守という目的に有効活用するために、子供が与える曖昧なインプットに対して適切な道具を検索するデータベースおよび人工知能を備えたロボット」であると言うこともできるだろう。
  • ひょっとしたら、ドラえもんと同一のハードウェア仕様で検索用データベースや人工知能の思考エンジンだけが異なる、介助用ロボットや探査用ロボットというのも存在するのかもしれない。
    • エクステリアまで完全に同一仕様だと耐圧性能だとかそういう点で性能要求を満たせなかったり逆に過剰品質になったりしそうだから、コンピュータ部分だけが共通でそれ以外は別な方がいいかもしれない。

美撮り - Feb 16, 2010

ケータイ世代の女性が企画:男の知らない“きれい”とは――4000枚以上の写真から完成したカシオ端末の「美撮り」 - ITmedia +D モバイル

リンク先の記事にある写真を2つのタブで開いて何度かタブを切り替えてみると、違いがよく分かる。「美撮り」の方は肌をソフトに・目を若干大きめに加工してあった。リアルタイムに自動で行うちょっとしたフォトレタッチだけど、よく考えてみれば今の携帯端末はそれなりの性能のPCみたいなもんなんだから、ソフトウェアさえ載っければこういう事は造作もないんでしょうね。そういえば懐かしい記事で、美人フィルタなんてのもありましたね。

こういうので撮った写真を「偽物だ」と言うのは容易いけど、こういうリアルタイム自動フォトレタッチがあるといいなあと自分も思いますよ。

自分の携帯のカメラとかで彼女の事を撮っても、後で見返してみると、ちょっとションボリする写りで残念になる事がある。肉眼で見てその時感じた「この瞬間の画が欲しい」と思った映像と比べて、蛍光灯の光が青白かったり顔に影が落ちて薄暗くなってたり。一眼レフのカメラを借りて撮った写真は、それに比べるとまだ「思った通り」に近い写真になってたと思う。でもそれでも、肉眼で見た時の通りというわけではない。

人の目というのは、眼球を通して網膜に映った光を視神経で脳に伝えてそこで改めて映像として再構築する物らしいけど、思うに、その過程で周囲の様子とか音とか匂いとか思い入れとかいろんなものが反映されて、物理的な形状とは違う人それぞれの見え方になる物なのではないだろうか。だから、3次元の物理的な形状をレンズを通して2次元に写し取っただけの写真を見た時に、他の情報が欠けているために「あれ、なんでこんなにショボく見えるんだろう……」ってなってしまうんじゃないだろうか。動画の方がまだマシに見えるのは、情報の欠落が写真に比べればまだ少ないからじゃないだろうか。水彩画や油絵なんかの絵が時に写真よりも美しく見えるのは、僕ら凡人が実物を見ても感じることのできない美しさを、画家が敏感に感じ取ってキャンバスに描き付けるからだったりするんじゃないだろうか。

いや、単に、僕のカメラの扱いがなってないだけというのも多分にあるとは思いますけどね。カメラの使い方を心得てる人達なら、同じカメラでもきっと、僕が撮った写真よりずっといい写真を撮れるはず。

ともかくフォトレタッチというのは、写真というメディアの特性や、あるいは撮影者の腕のヘボさによっていくつかの情報が欠落してしまった結果の画像に対して、欠落していた情報を加味した補正を加えて、自分の目でその人や風景を直接見た時に感じていた物に近い情景を再現する作業なのだと僕は思う。「偽物の像を造る」作業ではなく、「自分の記憶に焼き付いた唯一無二の『本物』を復元する、再現する」作業なのだと思う。CGを駆使した映画というのも、偽物を作ってるんじゃなくて、監督の頭の中に思い浮かべられた映像を再現してるんだと思う。(絵を描くという作業だってそもそも、思い浮かべたイメージを画面上に正確にトレースする作業なんですよね。だから、完成図を細部まで思い浮かべる想像力と、それを正確に描写する力とが重要になる。グラデーションがどうとかのテクニックは、思い浮かべた物を画像として再現するための道具でしかない。)

写真を撮るのが下手糞な僕でも、彼女を見て「かわいいなあ」と思った時の感動をそのままフレームに収められたら嬉しいだろうなあと、僕は思うんですよ。そのために何十万円もするカメラやレンズや撮影環境を整えなくとも、いつでも持ち歩けるサイズの携帯電話の組み込みのプログラムで補えるのなら、それはそれで手軽に使えて嬉しい便利な道具だと思うのです。

続きを表示する ...

Some reasons why I say that eval is not absolutely dangerous than other hacks. - Feb 08, 2010

This is an translated version of my another entry, evalが危険でそれ以外の方法が安全だと思ってる人へ . This is an objection for the entry: Five wrong reasons to use eval() in an extension written by Wladimir Palant.


Recently I updated Source Viewer Tab and Tree Style Tab. However, when I uploaded the latest version to AMO, both files were retained in the sandbox, never made public by AMO editors. They said with one mouth: "Your add-on uses the 'eval' function unnecessarily, which is something we normally don't accept. There are many reasons *not* to use 'eval', and also simple alternatives to using it. You can read more about it here: http://adblockplus.org/blog/five-wrong-reasons-to-use-eval-in-an-extension"

I know the point of their blames very well, because I read and translated the entry to Japanese for my understanding. When I got a rejection about another addon, I got just same comment.

Now I have an objection about indiscriminate rejections by "too many eval()s" like this.

Both "wrong" and "right" are infelicitous adjectives about eval.

First of all, there is no "wrong" use of eval in any JavaScript codes (not only my addons). All of evals are "right" if it does its own work correctly.

For example, by the HTML specification, <em> is defined as "means emphasizing", "cannot appear in <title>", and so on. If you write <em> against the definitions, your HTML will be "invalid".

How about eval? 15.1.2.1 eval (x) in the ECMAScript specification describes about the function. It just says: runs the specified string as a script. There is no cautionary statement about the purpose of using eval.

There is no "wrong" use, it is just "dangerous" use. There are many usecases: some is high-risk, some is low-risk. But, they all evals are "right" use if it works as required by the spec. So, I think that it is a suitable subject for the entry: "Five dangerous use of eval() in an extension".

Risks of eval have to be managed, in other words, risk-managed evals are useful tool to extend Firefox. For end users, I think some eval should be allowed if it is safe enough in the case. "Eval? No, no, it is evil function! Don't use it anyway!" - I think that is slapdash work.

When you get 5-minute recipes via HTTP, do you untrust it anyway? Because it is insecure protocol, you cannot trust any information without SSL? Note, VeriSign certifies that the website you are accessing via HTTPS is surely hosted by the author, but he doesn't certify that the author is not evil. If you cannot trust any people via internet, you have to live offline - it's a internet phobia. In many cases you maybe trust them anyway if it is low-risk.

In the entry, he negates any eval without considering about its risk if it is out of the "valid uses". I think it is just a eval phobia.

Can the eval eat codes from the Web, really?

I agree to blame some cases of 5 cases in the entry. The 1st (parsing JSON), the 2nd (accessing to properties dynamically), and the 4th (running event handlers of HTML or XUL elements) - those three cases must be blamed because they possibly run untrusted scripts from the Web as privileged. This is just same to caution about SQL injections for web apps.

I totally agree this topic. I also think any developer must be careful to make eval isolated from the Web. If my addons are rejected because they have this security issue, I totally back the judgment up.

So, how about my cases?

Both addons, Source Viewer Tab and Tree Style Tab, use eval only for injecting codes to functions in Firefox (and other addons). They never get codes from the Web. If editors decided to reject those addons by the reason, like "This is dangerous because it includes eval! Eval can run codes from the Web!", then it means: they reviewed addons without reading codes, and just checks warnings by the "not perfect" validator.

If so, I cannot agree to the decision. We shouldn't overestimate the power of the validator on the AMO system, because it can detect only a few patterns which are defined as "dangerous". It doesn't parse the JavaScript, it only reports the matching result about simple regular expressions, it cannot detect dangerous codes from obfuscated programs.

You have to judge case by case whether the eval is danger or not. Same about XBL hacks, CSS hacks, replacing of functions, and others. "Yes, this doesn't use eval. I accept it." "Oh, this uses eval. This is wrong. I reject it." Such a rash judgment possibly jeopardize people who download addons from AMO. I believe that we should review sources by our eyes to detect dangerous code cleverly obfuscated, even if it take time.

Is injection by eval absolutely dangerous than other hacks?

All of evals in Source Viewer Tab and Tree Style Tab are used to inject codes to functions of Firefox, it is the 5th case described in the entry. In the entry, he blames this use because:

  • When the definition of the target function changed, terrible problem (crashing, data loss, etc.) possibly appear.
  • It possibly invites "already fixed" security issues again.

And, he said that we should use "less dangerous" ways like:

  • Use closure, and wrap up the original function by a new function. In the function, call the original function by func.apply(this, arguments).
  • Watch changes of values of some property by Object.watch().
  • If you cannot do it with those safer ways, you should not do it. Give up.

In other words, in the entry he said that "those ways are safer than eval".

I think it is an unfair suggestion. If you talk about risk of those cases, you should think other risks too, which are not listed in the entry. We also would like to avoid eval if at all possible. However, in our cases eval is the way really better than others.

Risk: possibilities of conflicting to Firefox features and other addons

Methods to extend Firefox can be sorted as:

  1. Using stable APIs provided by Firefox or other addons. (Toolbar buttons, sidebar panels, contents filtering by nsIContentPolicy like AdBlock Plus, Jetpack Features, etc.)
  2. Using other unstable ways.
    1. Using XBL hacks.
      1. Applying new XBLs.
      2. Replacing existing XBLs. (Tab Mix Plus, etc.)
    2. Using JavaScript hacks.
      1. Replacing existing functions. Using closure, wrapping up original functions in new functions.
      2. Hooking operations of existing functions by Object.watch() or other ways.
      3. Injecting codes to existing functions by eval.
    3. Using CSS hacks. (Personas, third-pirtys' themes, etc.)

One addon can use multiple ways above, but we can call it "safe" addon if it uses only "stable APIs". Otherwise they are possibly unstable. Any addon using unstable ways possibly breaks Firefox and other addons. Themes also.

He said that the "less dangerous" way is safer than eval. But, actually it possibly isn't. For example, I tried to watch the toggling of the Sidebar in Firefox 3.6, by document.getElementById("sidebar-box").watch("hidden", ...). Then it breaks the original behavior of XUL element - the Sidebar was never toggled. (So I had to use an event listener for the "DOMAttrModified" generic event.)

Another case, if you wrap the original function by a new function, any other addon which aimed to inject codes to the original function will never work. Hmm, "Because it is evil. Evil addons using eval must die!" Don't say that. It is the fact, you didn't take care about people who use addons with eval.

By the way, there are features which cannot be implemented without injecting codes into existing functions. Dorando told about those addons in the comments to the entry. The conclusion of the entry is "don't do it, you should not do it". However, if you cannot explain how dangerous eval is than others, it is just a tautology: "you should not do it, because it is wrong use of eval." and "it is wrong use of eval, because you should not do it."

Risk: possibilities of causing troubles with updating of Firefox

On this point, both methods (eval and the "less dangerous" way) have same risk. He said that eval will never work if the definition of the function changed. However, the "less dangerous" way will collapse too if the original function is renamed. It is just a bias that functions will be never renamed in security updates. There is no "rule" like this.

Moreover, if you wrapped two functions A and B, expecting they work as "A-mod => B-mod", the hack will break down if only one mate changed by security fix. We cannot imagine how terrible thing caused is. Not only updating of Firefox, but conflicting to other addons too.

Anyway, we addon developers must catch up changes in any update of Firefox. It is the common issue for any addon which uses unstable ways to extend Firefox. I think blaming like "how terrible eval is than wrapping original functions" is nonsense. More importantly, I believe that we should talk about providing failovers for unexpected matters.

To put it bluntly, any addon is just a "dynamic patch". If you use Linux, you possibly download patches from ML or other places, apply it to the source, and build binaries. It is not uncommon sight. And, it is also important note in those cases: Don't apply the patch to any revision different from the base of it. Using addons on unverified versions of Firefox is just same to that.

Risk: possibilities of less maintainability and/or readability

If we use eval hack, only "codes should be replaced" and "codes should be injected" will appear in the source.

Generally reading source codes like this is certainly hard, because we have to refer the codes of the function which is being overwritten. Instead, there are less codes and sources become compact. If it is very simple like replacing from "width" to "height", it will be human readable enough. So know-how to keep maintainability and compatibility is important for this hack.

Even if you choose the way to wrap original functions, only fragmentary codes will appear in the source too. "Pre-operations", "post-operations", "wrapping functions", "watching functions for property changes", and others. Moreover, if you cannot get the result of operations by the original function as its returned value, eventually you have to know well how the function work.

In this case, if you want to implement a feature which require injection of some codes into the logic of an existing function, you need to copy the complete codes of the original function into your addon (of course you have to modify it.) Then, too many codes are possibly duplicated, so:

  • You possibly cannot include the codes of the original function because their licenses conflict.
  • It possibly re-invite security issues fixed by updates of Firefox, as told in the entry.
  • Too many codes simply make themselves hard to be read.

Risk: possibilities of rejection by editors

This is common to the topic about maintainability. AMO editors finally have to review addons with reading of their sources. If there are tricky codes or too many/long lines, then the cost of reading source codes increases. On this point, both eval hacks and wrapping hacks are similarly tricky.

Although if updates of addons are always rejected by the reason: "there is any eval", then, it becomes a new common practice: writing codes without eval anyway, with tricky hacks, even if they become hard to read. Otherwise the update won't be accepted. It is also a tautology: "we should not use eval, because they never accept codes including eval." and "they don't accept eval hacks because we should not use it."

The conclusion

As I described, I think evals in Source Viewer Tab and Tree Style Tab are not unnecessarily. In other words I believe that those evals are the best way to implement the feature with keeping compatibility. I think those evals are not absolutely dangerous than the "less dangerous" ways described in the entry, and I also think there are no alternative ways to do it.

How many people who says "eval is dangerous than others" actually read and reading the source codes of Mozilla products? Trying to extend Firefox even if there is no stable API? Catching up updates of Firefox constantly? Trying to solve compatibility problems with other addons? I'm feeling blue.

Only XPCOM components are really stable APIs, which are marked "FROZEN" in their IDL files. Otherwise they are absolutely unstable. There are only a few "FROZEN" APIs, preferences I/O, W3C DOM, etc. JavaScript functions in the browser window are very unstable. Even the FUEL - which was the component advertised as providing stable APIs independent from Firefox versions - is possibly removed from the next major release of Firefox. Yes, this is the Mozilla. I think it is just a kidding: "eval is dangerous, wrapping original functions by new functions with the name same to originals is safer than it."

In conclusion, I think it is unjust treatment that addons are retained in the sandbox because "they have evals".


To reject spams, you have to answer a quiz to comment to this entry. "今の日本の首相の名字(ひらがなで回答)" means: the family name of the current prime minister of Japan, in "hiragana". You'll see the answer from wikipedia (Japanese version of the page).

VMWare Server Consoleのダウンロードページ - Feb 08, 2010

なんかもう作業環境作る度に同じとこで躓いてるんで……

昔のVMware Serverは、インストールすると「VMware Server Console」というのがセットで付いてきてた。今ダウンロードできる「VMware Server 2.0」は操作のためのUIがWebベースになってて、単体のアプリケーションの「VMware Server Console」が付いてない。しかし古いVMWare Serverが動いてるサーバにある仮想マシンを操作するにはVMware Server Consoleが必要になる。

結論から言うと、これはDownload VMware Serverのページからダウンロードできる。「VMware Server Windows client package」(クライアントがLinuxなら「VMware Server Linux client package」の方)というのをダウンロードするとその中にいくつかのツールのインストーラが入ってるので、そのうちの「VMware-console-1.0.6-91891.exe」を展開して実行する。これでVMware Server Consoleを利用できるようになる。

VirtualPCにゲストOSとしてWindows 7とWindows Vistaを入れてみた - Feb 08, 2010

ホストは以下。

  • Windows Vista
  • 社内の無線LANにUSB接続の無線LANアダプタで接続してる

検証用にWindows 7の環境を手元に作っときたくてチャレンジしたんだけど、ゲストがWindows XPの時は特に何もせず期待通り動いてくれたのに、Windows 7はうまくいかなかった。

  • 「バーチャル マシン追加機能」をインストールできない。
    • インストールすると、再起動後にブルースクリーンになる。
    • FS_Rec.sys というファイルが壊れているというメッセージ。
    • 検索すると海外のフォーラムのスレッドがヒットして、そこから同じ症状がでてる人のブログに辿り着いた。そこのコメント欄に、VirtualPCをアップデートしたらうまくいくようになると書いてあった。
    • しかし、ここに書いてあるVirtualPC 2007のバージョン(SP1、バージョン番号は6.0.192)は手元で動いてる奴と同じ……
    • インストール済みの物はBizSparkでダウンロードした物だったんだけど、ダメ元でVirtualPCのインストーラをダウンロードし直してもっかいインストールしたら、今度はうまくいった。
    • バージョン番号は同じでも、Windows VirtualPC 2007 SP1(BizSparkでダウンロードした物)とMicrosoft VirtualPC 2007 SP1(上記リンク先からダウンロードできる物)とは別物みたい。
    • Windows 7がゲストだと色々不具合あるらしいけど、起動できないのに比べれば全然マシです。
  • Windows 7からインターネットに、というかネットワークに繋がらない。
    • DNSのアドレスを例えばGoogleのDNS(8.8.8.8)に設定しても、全然駄目。そもそもネットワークに繋がってないっぽい。
    • バーチャルマシンのネットワークアダプタの設定で「共有ネットワーク(NAT)」を選択してて、この状態。ブリッジ接続とかどこにも出てきません。
    • 検索して辿り着いたページの記述によると、ホストOS側でネットワークアダプタのプロパティを開いて「Virtual Machine Network Services」にチェックを入れると、そのデバイスがバーチャルマシンのネットワークアダプタの設定で選択できるようになるそうだ。
    • というわけでホストのWindows Vistaで無線LANアダプタのプロパティを開いて上記のチェックボックスをONにして、ゲストのWindows 7を一旦終了(再起動では駄目。仮想マシンの電源をOFFにしないと新しいデバイスは認識されない)。バーチャルマシンの設定でネットワークアダプタのドロップダウンリストを開くと、ホストで使ってる無線LANアダプタの名前が一覧に加わってるので、それを選択。ゲストのWindows 7を起動して、ネットワークアダプタを「有効」にする。これで、インターネットに繋がるようになった。
    • ネットワークの場所が何故か「パブリック」になってたので「社内」に変更した。すると、社内LANの他のマシンが見えるようになった。
    • ホストの無線LANアダプタを別のUSBポートに挿し直したりすると、仮想マシンからアダプタが認識されなくなることがある。この場合、もう一度同じ事をやる必要がある。
  • ゲストがWindows Vistaの場合も同じ注意が必要。
  • ホストがWindows 7の場合も同じやり方でいける。(Windows 7ではVirtualPCはサポート対象外だけど一応動く)

なんで「共有ネットワーク」で繋がらないんでしょうね?

W3C信者だったくせに現実におもねってるというアレ - Feb 08, 2010

eval否定論への反論を書いてて、「以前あんだけ理想論垂れ流してた自分がどの口でこんなことを言うのかね」という事をちょっと思った。でもよく考えてみたら、(ただの自己正当化かもしれないけど)昔から自分の考えは結構一貫してるんじゃないかという風に思えてきた。

僕は元々、自作の絵の公開場所としてWebサイトを作り始めた。当時はNetscape Communicator 4付属のNetscape Composerでページを作ってたけど、凝ったレイアウトをしてたら当のNC4でページ読み込みに死ぬほど時間がかかるようになってしまった。凝ったレイアウトをしつつ逐次レンダリングができるようになるということでCSSの存在を知って、勉強するのにいい本を教えてくれと2chのスレで聞いたらスタイルシートWebデザインを勧められた。その本で「ページの内容と外観の定義情報は分離できる」ということを知って、僕はW3C信者になった。

W3C信者というのは、以下のようなことを言う人間のことだと思ってもらえばだいたい合ってると思う。

  • Another HTML-lintの結果は100点満点で当たり前でしょ?
  • font要素とかbody要素のbgcolor属性とか使うな!! スタイルシートを使え!!!
  • HTML 3.2や HTML 4.0 Transitionalはうんこ!! Strictを使え!!!(もっと過激な人になると「ISO-HTMLを使え!!!」と言う場合も)

で、そういう人の特徴的な行動として、lint等のバリデータでエラーが出るページをあげつらって文句言ったり、「間違ったHTML」を教えてる人がいればそこの掲示板に殴り込んで「あなたの書いている内容は間違っています」と言ってまわったり、日記で名指しで「こいつは何も分かってない」と非難したり、まあそんな感じのことがあって、僕もそういうことをやってたわけですよね。

そういう時に返ってくるお決まりの言葉が「理想論を垂れ流してるんじゃねえ!! 現実はお前の言うような綺麗事じゃ動かねえんだよ!!!」というものだった。うん、自分が今言ってることとソックリだ。

現実を知らなかった当時とは違って今は考えも変わって丸くなりましたから、という自己弁護も可能かもしれないけれども、できれば「考え方が変わってしまったから」だとは思いたくない。昔から一貫して1つのことを言い続けてきたのだと思いたい。そこで、その頃自分が受けた反論と自分が今している反論に違うところはないかということを考えてみた。

自分自身当時から意識していたことなんだけど、「代替案が無いくせに理想論を押しつけるな」という事はずっと考えてた。理想的な手段では現実のニーズに対応できないから「間違った」手段に流れてしまうのであって、ニーズに対応できる答えを示せない限りは「間違った」手段は使われ続ける。理想的な「正しい」やり方を使うことで失われる物は何もなく、今抱えているニーズにもきちんと対応できて、その上新しく色々なメリットを享受できますよ、という風に説得しなければ人は動いてくれない、そう思ってた。「理想のためなら素人受けするようなレイアウトはできなくてもいい」などとW3C信者自身が言うのは、Pure CSSでかっこいいレイアウトを作ることができない自分の視覚的デザイン力の欠如を棚に上げた、怠惰な言い訳でしかないと思った。

だから僕は、「CSSじゃレイアウトとも呼べないようなダサいページしか作れない」という偏見に基づく嘲笑の声に対して、HTML 4.01 Strict(あるいはXHTML 1.1)とCSS2というWeb標準の技術だけでもきちんと「素人が喜びそうな派手なレイアウト」は可能なんだということを、実例を示してアピールしようとしてきた。JavaScriptやPerlで「スタイルシート切り替えスクリプト」を作って、ページの内容と外観を切り分ければこんな事ができるようになるんだというのを示そうともした。

eval恐怖症とも思えるようなeval否定論を見て思うのは、「お前は間違ってる、正しい物を学べ」「理想のためなら何を引き替えにしてもよい、失われる物が多くても何ら構わない」と言うW3C信者によく似てる、僕が目にして「これじゃあ駄目だ」と思ったパターンにそっくりだ、という事だ。また、そういうW3C信者に対して、技術的なことを知らない・CSSでレイアウトはできるという事を知らない人が行っていた「CSSでまともなレイアウトなんかできない」という偏見に基づいた事実に即していない言いがかりを見た時の、「それは違う!」という思いにも似たものをも、同時に思っている。

当時は「非難する側、正義を背に付けた側」の立場から、「技術的な正しさと現実のニーズを満たすことの両立は不可能なのだ」という双方の偏見を取り除き誤解を解こうとしていた。今は「非難される側」の立場から、双方の誤解を解きたいと思っているのではないか。自分ではそう認識しています。

evalが危険でそれ以外の方法が安全だと思ってる人へ - Feb 08, 2010

先日、ソース表示タブのアップデート版をAMOにアップロードしたところ、公開申請が却下されました。「不必要なeval()が多すぎる。拡張機能におけるeval()の5つの間違った使い方(原文:Five wrong reasons to use eval() in an extension)をよく読んで出直してこい。(大意)」という感じのコメントが添えられていました。

また、ツリー型タブのアップデート版も別の人から同じコメント付きで公開申請を蹴られました。

全文+コメントを翻訳するくらいには当該エントリを読んだ僕ですから、今更読み返すこともないのですが、こう何度もこのエントリを引き合いに出して申請を蹴られると正直腹に据えかねる物がありますので、自分の考えをちょっとまとめておきたいと思います。

つたない英語力で頑張って英語に翻訳してみました。

evalの使い方に「正しい」も「間違っている」もない

まず何より明らかにしておきたいのは、言葉尻を捉えて反論するのもどうかと言われそうですけれども、evalの使い方には「正しい」も「間違っている」も無いということです。

例えばHTMLの仕様書には、em要素は強調を意味するとか、この要素はこの要素の中には記述できないとかの、色々な定義が書かれています。その定義から外れた使い方をすれば、確かにそれはinvalidな(間違っている)HTMLと言っていいでしょう。

では、evalはどうか。ECMAScriptの仕様書(リンク先のページには3rd Editionと書いてあるけどPDFは5th Editionです)15.1.2.1 eval (x)の項には、evalの仕様としては「与えられた引数をスクリプトとして実行する」という、挙動についての取り決めだけが書かれています。「何のためになら使ってよい」という風な記述は一切ありません。当たり前といえば当たり前ですが。

そこにあるのはただ、「その仕様の通りに動作した結果、何が起こるのか?」という結果についてのリスクの高低だけです。多大なリスクを伴う使い方、全くリスクを伴わない使い方、色々な使い方が考えられますが、動作する限りはそれらはすべて「仕様通りの正しい使い方」です。なので当該エントリのタイトルも本当は「evalの5つの危険な使い方」などとするのが妥当だと僕は思っています。

こういう場合にこういうデメリットがあること考えられる、だからこのような対策が必要だ、あるいはメリットとデメリットを天秤にかけないといけない、というのがリスク管理の考え方です。「間違っているから駄目だ」と思考停止するのは、天秤にかける事すら否定するということです。

例えばSSLを使っていない普通のHTTP接続で閲覧しているWebページの内容は、「第3者によって改竄されている可能性」を完全には否定できません。だからといって、そのページに書かれている情報は一切全く信用してはいけない、ニュースだろうが料理のレシピだろうが一切アテにしてはいけない、という考え方が健康的と言えるでしょうか? また、SSLは接続している先のWebサイトが本当にその運営者が運営するものであるかどうかということは保証してくれますが、運営者が善人か悪人かということまでは保証してくれません。相手が善人であると保証されないのだからネットで買い物はしたくない、カップラーメンもマンガの本もホッチキスの針も、詐欺に遭うのが怖いからネット経由では絶対何も買わない、という考え方は妥当でしょうか? そこまで行くともはやインターネット恐怖症フォビアでしょう。

前出のエントリで「この使い方は正しい」とされている以外の使い方がされているevalを、個々のケースごとのリスクの高低を無視して一律で否定するのは、僕には単なるeval恐怖症フォビアとしか思えません。

そのevalには本当に、Webからやってきたコードが混入する恐れがあるのか?

前出のエントリで挙げられている5つのケースのうち、1番目(JSON形式のデータのパース)、2番目(プロパティ名が動的に変化する時に、そのオブジェクトのプロパティにアクセスするため)、4番目(HTMLやXULにインラインで記述されたイベントハンドラの実行)の3つのケースでは、Webからやってきた信頼されていないコードを特権付きで実行してしまう可能性があることに触れています。これはWebアプリケーションにおいてのSQLインジェクションに対する注意喚起と同様の物と言えます。

この観点でevalの使い方に神経質になることは大事です。僕も、evalを使うすべての人は、この点に気をつけなくてはならないと思います。この理由で公開申請が却下されたのであれば、その判断は実に妥当だと思いますし、反論の余地は全くありません。

では、今回のケースはどうでしょうか。

ソース表示タブツリー型タブでは、evalはFirefox本体の関数を書き換えるためにだけ利用しており、そこにWebから取得したコードが混入するとは考えにくいです。もしこの理由で申請が却下されたのであれば、それは、レビュアーがきちんとコードを読まずに、単に機械的チェックにおけるevalの警告だけを見て判断を下したという可能性が出てきます。これは言い換えると、「evalが機械的チェックで検出されたからNG、検出されなかったからOK」という風な安直な判断を下すようになっている可能性があるということです。

もしそうなのであれば、そのようなレビュー姿勢は宜しくないものだと自分には思えます。そういう機械的なチェックをくぐり抜けるための抜け道はいくらでもあります。難読化されたコードなどはその典型ですし、難読化されていない「読みやすそうなコード」でも、ぱっと見分からないようにごまかすのは簡単です。もし機械的なチェックの結果だけを見て判断を下しているのであれば、そういうケースによる危険なコードの混入の可能性は否定できないことになります(そういう場合、時間をかけてでも・判断が遅くなってでもきちんと精査するべきでしょう)。そういうケースに対しても対処できるようにというのが、わざわざ人の手でレビューすることになっている理由の1つであると自分は信じています。

evalによる関数の書き換えのリスクは、それ以外の方法のリスクと比べてそんなに高いのか?

ソース表示タブツリー型タブで使われているevalはすべて、前出のエントリで挙げられている5つのケースのうち5番目のケース、「Firefox内で使われている関数の内容を書き換えるため」に該当するものです。前出のエントリでは、この使い方を以下の理由から非難しています。

  • 書き換える対象の関数の内容が変化した時に、ブラウザ自体がまともに動作しなくなってしまう恐れがある。
  • せっかく修正されたセキュリティ上の問題を、再び持ち込んでしまう恐れがある。

そして、代わりに推奨するやり方として以下のような「無理のないやり方」を挙げています。

  • 関数を別の関数で置き換えた上で、置き換え後の関数内で元の関数をfunc.apply(this, arguments)で呼ぶ。
  • Object.watch()を使って、特定の変数やプロパティの値が変化したタイミングで処理を行う。
  • そういう「無理のないやり方」では実現できないことをしようとしているのであれば、もう素直に諦める。

換言すると、前出のエントリの筆者は「このような無理のないやり方の方が、evalによる関数の置き換えに比べて、前述のような事態が発生するリスクが少ない」と述べていると言えます。

僕には、これはアンフェアな言い方と思えます。リスクの多寡で問題を語るのであれば、ここに挙げられていないリスクについても考慮するべきでしょう。そうすることで初めて、僕のような人が「evalによる関数の書き換え」という手法を選択している理由が明らかになります。僕だって、考えなしにevalを使っているわけではありません。メリットとデメリットを天秤にかけた上で、その方がリスクが小さいと考えてevalを使っているのですから。

リスク:Firefox自身の機能や他のアドオンと競合する可能性について

アドオンを「機能を実現する方法」の観点で見ると、以下のように分類できます。

  1. Firefoxや他のアドオンが提供するAPIに則ったアドオン。ツールバーへのボタン追加、サイドバーパネルの追加、nsIContentPolicyによるコンテンツフィルタリング(AdBlock Plus)、Jetpack Featureなど。
  2. Firefoxや他のアドオンがAPIを提供していない箇所に改変を加えるアドオン。
    1. XBLを使って機能を加えるアドオン。
      1. 新規にXBLを適用するアドオン。
      2. 既存のXBLを上書きするアドオン。Tab Mix Plusなど。
    2. JavaScriptの関数のはたらきを変更して機能を加えるアドオン。
      1. 関数を置き換えるアドオン。
      2. Object.watch()等で本来の処理に割り込むアドオン。
      3. 関数をevalで書き換えるアドオン。
    3. CSSでXUL要素の見た目を変えるアドオン。Personas、テーマなど。

1つのアドオンが複数の分類にまたがる場合も多いのですが、このうち「他のアドオンとの競合の可能性」という点で本当に低リスクであると言い切れるのは、1の「APIに則ったアドオン」の枠から外れないものだけです。それ以外はどんなアドオンであっても、Firefox自体の挙動や他のアドオンに何らかの影響を与える可能性があります。テーマですら例外ではありません。

前述の「無理のないやり方」の説明では、さもそのようなやり方を採用することによって競合のリスクが全面的に低減されるかのような書き方がなされていますが、場合によってはこの方が却って競合してしまう場合すらあります。実際、Firefox 3.6上でサイドバーの開閉状態の変化を捕捉するためにIDがsidebar-boxである要素のhiddenプロパティに対してObject.watch()で監視を行おうとしたところ、XUL要素の挙動が破壊されて、サイドバーの開閉自体が行われなくなってしまいました。(これは結局、DOMAttrModifiedイベントを監視してhidden属性の値の変化を見るという方法で回避することにしました。)

別の例として、「無理のないやり方」で関数を丸ごと置き換えられてしまうと、evalで元の関数を書き換えようとしていた他のアドオンが、関数を書き換えられないせいで期待通りに動作しなくなってしまうということも考えられます。……「そんな邪道なやり方をしている方が悪いのだ」という非難は無しですよ? 他のアドオンに与える影響を考えていないのは、お互い様なのですから。

また、これはリスクとは別の話ですが、「evalによって特定の箇所に特定のコードを注入することによって関数の定義内容を変えてしまわなければ実現できない機能」というものもあります(前出のエントリに対するコメントでも、Dorando氏が例を示しています)。そのような「無理なやり方」でやらなければならない事はするべきではない、というのが前出のエントリの著者の結論のようですが、後述する物も含めたリスクの点で明らかな優位性を主張できないのであれば、「無理なやり方はするべきでない、なぜならevalの間違った使い方だからだ」「evalの間違った使い方はするべきでない、なぜならそれは無理なやり方だからだ」というトートロジーに過ぎません。

リスク:Firefoxのバージョンが変わると予期しない結果になる可能性について

この点のリスクは、evalによる関数の書き換えでも、「無理のないやり方」と呼ばれている関数の置き換えでも、同様に存在します。前出のエントリでは「置き換え対象の関数の内容が変わったらどうするんだ」ということを指摘していますが、それを言えば、関数の名前が変われば「無理のないやり方」も破綻します。セキュリティアップデートでは関数の名前やそれぞれの働きが変わることはない、というのはただの思い込みです。そんなルールはどこにもありません。

また、「置き換えた関数A」→「置き換えた関数B」の順で処理が行われることを期待してコードを書いてる場合に、「置き換えた関数A」だけが実際には置き換えられなかったとすると、「置き換えた関数B」が動作する上での前提が崩れますので、その時どんなトラブルが起こるかは予想できません。これはFirefoxのバージョンが変わった時だけでなく、他のアドオンと同時に利用した時の競合についても全く同じ事が言えます。

いずれの場合にせよ、Firefox本体や他のアドオンのバージョンアップに対して、改変を加える箇所のソースコードをその都度調査し直さなければならないという、メンテナンスのコストの問題は、どちらにも共通して存在しています。「evalと関数置き換えのどちらの方が元のコードの変化に強いのか」ということを論じてもあまり意味はなく、どちらの手法を使うにせよ、Firefoxのバージョンアップに際してきちんと動作を検証しているかどうかや、前提が崩れた時のためのフェイルセーフがきちんと考えられているかどうかの方が、リスクに対する備えとしては重要且つ効果的なのではないか? というのが僕の考えです。

Firefoxのアドオンやテーマの正体は「動的に適用されるパッチ」です。ソースコードに対して、そこら辺に転がってる野良パッチをあててビルドする、というのはLinuxを使ってる人にはよくある光景ではないかと思いますが、「パッチが書かれた時のバージョンと違うバージョンのソースにパッチを当てること」がいかに危険かは、言うまでもないでしょう。Firefoxのアドオンを「アドオン作者によって動作確認されたバージョン」以外のバージョンにインストールすることは、それと全く同じ事です。

リスク:メンテナンス性、ソースの可読性が低下する可能性について

evalによる関数書き換えの場合、ソース中には「書き換える対象の関数名」「書き換えたい前のコード片」「書き換え後のコード片」だけが書かれることになります。

このコードを解読するためには「書き換える対象の関数」の内容を参照する必要があるため、その内容が頭に入っていない場合(大抵はそうでしょう)、解読が難しくなりがちです。その代わり、ソースコードの量自体は必要最低限になります。また、書き換える対象がロジックに絡まない「widthをheightに書き換える」という風な部分なのであれば、コードの読みやすさという点でもさほど問題は無いと言えます。このあたりは、「evalで関数を書き換える時の、互換性や後々のメンテナンス性を高く保つためのノウハウ」が重要になってくる所です。

関数の置き換えを行う場合も、ソースコードは結局は断片的な物になります。「前処理の関数」「元の関数をラップする関数」「後処理の関数」「元の関数の中で特定のプロパティに変更が加えられた事を捕捉して処理を割り込ませる関数」などが細切れに定義されますし、また、元の関数の処理結果の受け取り方法として「戻り値」以外の情報を使うのであれば、結局は元の関数の内容が頭に入っていないといけないことになります。

元の関数の中に変更を加えなければどうにもならない機能をどうにかして実現したい場合(前出のエントリのコメントで指摘されているようなケースなど)、こちらの手法にこだわるのであれば、「元の関数に必要な変更を施した後の関数」をアドオンの中で定義しておく以外に手はありません。そうなると、Firefoxや他のアドオンのコードと全く同じコードがそのアドオンの中に大量に含まれるようになってしまいます。これは、以下のような問題に繋がります。

  • それぞれのライセンスが衝突してしまうために、コードを丸ごと引用できないという事態が起こり得る。その機能を実現できない、という苦渋の決断を迫られる。
  • 前出のエントリ内でも指摘されている「せっかくFirefox(や他のアドオン)の側でセキュリティ上の問題が修正されても、関数を古いバージョンのそれに基づいた改変版に丸ごと置き換えてしまうことで、再びセキュリティ上の問題が持ち込まれてしまう」問題が起こり得る。
  • 単純にソースの行数が増加する事それ自体も問題となる。

リスク:公開申請時のレビューが通りにくくなる可能性について

これは「メンテナンス性、ソースの可読性が低下する可能性」にも共通する話です。AMOのエディターは最終的にはコードレビューによってそのアドオンの安全性を精査する必要があり、コードがトリッキーなものであればあるほど、また、コードの行数が増えれば増えるほど、コードレビューは大変な物になります。その意味で、関数の部分的な書き換えも関数全体の置き換えも、コードレビューの手間が増えるという点では一長一短です。

もっとも、今回の事例のように「evalを使っていること」を理由に公開申請が却下されることが相次ぐのであれば、eval無しでトリッキーで可読性の低い分量の多いソースコードの方が、比較的レビューが通りやすいという事になるのかもしれませんけれどもね。その場合、これもやはり「レビューを通してもらうためにはevalを使わない方がいい、なぜなら、evalを使っているとレビューが通らないからだ」という、何の説明にもなっていないトートロジーになる訳ですが。

まとめ

上記のような理由で、僕はソース表示タブツリー型タブの中で使われているevalが不必要な物ばかりであるとは考えていません(むしろどれも必要だからそうしているというのが自分の立場です)し、それらのevalの個々の用法が「これを読んで出直せ」と提示されたエントリの中で書かれている「代替案」に比べて目立ってリスキーであるとも思っていませんし、その「代替案」で代替できるとも思えません。

「evalの方が危険だ」と言っている人のうち何割の人が、本当にMozillaのコードを読んだことがあるのか、読み続けてきたのか、APIが用意されていない箇所でブラウザの機能を拡張する事に取り組んできたのか、継続的にFirefoxのバージョンアップに追従し続けたことがあるのか、他のアドオンとの競合を解消する方法を模索し続けてきたのか、僕には疑問に思えます。

XPCOMコンポーネントのIDL定義で「FROZEN」というフラグが立っている物以外のすべてのAPIは、いくらでも変更される可能性があります。FROZENになっているAPIは、Preferenceの読み書き、W3CのDOM関連など、全体から見れば本当にごく一部だけです。ブラウザ内のJavaScriptのレイヤで定義された関数に至っては、それが変更されない保証などどこにもありません。「Firefoxのバージョンに依存しないAPIが提供される」と思われていたFUELですら廃止される可能性が出てきている、Mozillaはそんな世界なのです。それで「evalの方が危険だ、同じ名前の関数で置き換える方がマシだ」と言うのがどれほど馬鹿げた話か。

ですので僕にとっては、evalの使用を理由として公開申請が却下された今回の出来事に対しては、不当な判断を下されたという思いが強いです。

そろそろFirefoxからChromeへの移行を本気で検討した方がいい気がしてきた - Feb 07, 2010

B.B.S/2628 "タブバーのスクロール後タブバーが正しくリペイントされない" - outsider reflex

Tree Style TabとJetpackを入れるとタブバーをスクロールするとタブの残像が残ったままになる。

[str]
1. Firefox3.6を新しいプロファイルにTree Style Tab-0.9.2010020502とJetpack-0.7をインストールし起動する
2.タブバーがスクロールするように多数のタブを開く
3. スクロールバーまたはホイールスクロールによりタブバーをスクロールする

[actual]
タブバーが正しくリペイントされずタブの残像が残る

[expected]
正しくリペイントされる。

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100206 Namoroka/3.6.2pre ID:20100206050755

B.B.S/2629 "Re: タブバーのスクロール後タブバーが正しくリペイントされない" - outsider reflex

widgetがどうとかのGecko 1.9.2での修正(異常に縦に長いページのレンダリングが壊れる問題に対する修正)の影響だと思われます。JetpackではSlidebarの実装のためにtabbrowserと同じ大きさのbrowser要素をopacity:0の状態でtabbrowserの下に重ねていますが、こいつのせいでレンダリングがおかしくなっています。

タブのcollapsed属性をいじってるTMPの多段タブならともかくTab Kitでも問題が起こらないのはなんでなんだ?と思ってスタイルシートを調べてみた所、scrollboxでスクロールさせてると駄目で、その中のbox.scrollbox-innerboxに対するoverflow:autoでスクロールさせてる場合はこの問題が起こらないようです。

しかしscrollboxをoverflow:autoにした場合はnsIScrollBoxObjectのインターフェース経由でスクロール位置の操作が可能なのに対し、box.scrollbox-innerboxをoverflow:autoにした場合はnsIScrollBoxObjectのインターフェースが取れません。結果、画面の外に新しいタブが開かれた時にその位置まで自動的にスクロールさせるという事ができなくなります。

「Jetpack 0.7と組み合わせても問題が起こらないが、画面外にタブが開かれるとフォーカスを見失う」
「画面外のタブにフォーカスが行くと自動的にそこまでスクロールしてくれるが、Jetpack 0.7とは同時に利用できない」
どっちがいいでしょうか。僕は後者です。(どうせ現状のJetpackはなくなるそうだし、その過程でなんとかしてもらいたいと思ってます)

掲示板の方では「現状のJetpackはRebootで置き換えられるそうだからそっちに期待」的な事を書いたけど、下手したらReboot後でもずっとこのままなのかもなーという風な悲観的な予想も捨てきれずにいます。

norahさん曰く、同じ問題がサードパーティ製のテーマとJetpackとの組み合わせにおいても発生するそうです。既存のアドオン、既存のテーマについては「冷遇」して、JetpackとPersonasへの移行を促したいという事をMozillaの偉い人が言ってたらしいけど、実装レベルで着々と実力行使が進んでる感がありますね。

対するGoogle Chromeでは、タブの縦置きが試験的に実装され始めてるそうです。こんな事を書いたばかりですが、そろそろ本気でGoogle Chromeへのエクソダスを図った方がいいような気がなんとなくしてきました。

今までできていたことが少しずつできなくなっていく、締め付けが強まっていくストレスというのは、いざ自分が締め付けられる立場になるととても辛いものですね。それならいっそ、最初から制限がきつくても将来性のある新天地に移ってしまおう、と考えても変じゃないよなあと思いました。Mozilla SuiteからFirefoxに移行した時以来、レンダリングエンジンの違いで言えばDonutからMozillaに移行した時以来なので、今更それがほんとに可能なのかという不安はありますが。

Page 31/241: « 27 28 29 30 31 32 33 34 35 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき