2011年6月
2011年6月30日(木曜日)
secure.softbank.ne.jpがついに(原則)廃止
公開: 2011年7月10日12時25分頃
ついに、secure.softbank.ne.jpが原則廃止になりました……「ソフトバンクモバイル、携帯サイトの仕様変更で注意喚起 (plusd.itmedia.co.jp)」。実際に切り替わったのは本日未明、午前3時頃のようです。
長かったですが、これでいろいろなことが解決しますね。
実際には、公式サイトはソフトバンクに申請すればsecure.softbank.ne.jpを使い続けられるという仕組みのようで、いくつかのサイトはまだ使い続けているのかもしれません。ですから全てが解決したわけでもないのですが、少なくとも、悪意ある攻撃者が任意のサイトをsecure.softbank.ne.jpドメインで表示できる状態ではなくなりました。危険性はかなり低下したと言えるでしょう。
secure.softbank.ne.jpの話題は過去にも結構書いているのですが、一見するとsecure.softbank.ne.jpと関係なさそうな話も多いかと思います。そのあたりは随時追記していこうと思います。
- 「secure.softbank.ne.jpがついに(原則)廃止」にコメントを書く
関連する話題: セキュリティ / モバイル / secure.softbank.ne.jp
2011年6月29日(水曜日)
ゆるゆり6
公開: 2011年7月10日12時0分頃
購入。
- ゆるゆり6 (www.amazon.co.jp)
表紙から完全にあかり消滅……というか今回の表紙は娯楽部ではないので、あかりだけが虐げられているわけではありません。
あかり目立たないネタも成熟してきた感がありますが、今回は「見切れていたので濡れなかった」という幸運も。他には「ちょっと贅沢なフルーツプリン」の話などが面白かったです。
あとはなんと言っても姉妹編ですね。個性的な姉妹が大勢登場するのですが、あかりの姉があまりにも黒すぎて……。千鶴も大活躍(?)ですが、千歳と直接絡むところをもう少し見たかったかも。
2011年6月28日(火曜日)
ゆるゆり5 天然ボケ vs 計算されたボケ
公開: 2011年7月9日22時55分頃
購入。
- ゆるゆり5 (www.amazon.co.jp)
なんと、ついに表紙からあかりが消滅してしまいました。……と思ったら、帯の裏にいた!! しかも、他の誰よりも大きく描かれているではありませんか。誰よりも大きな扱いなのに、誰よりも目立たないあかり。
京子があかりに飲み物をおごる話には笑わされてしまいました。喉が渇いてスポーツドリンクが飲みたいというあかりに、京子は自動販売機のボタンを同時押し、出たのはおしるこ。自動販売機の同時押しは左側優先というのは知りませんでしたが、普通に実装するとそうなりそうではありますね。
あと、結衣がお茶を一気飲みするエピソードも面白かったです。京子がちなつを恐れるというシチュエーション自体が普段とは逆ですが、さらに、クールなツッコミキャラのはずの結衣が身体を張るという。
それから、私がいちばん興味深いと思ったのは、京子と櫻子を比較して分析するエピソード。作中では知性の差ということで落ち着きましたが、ごはんを食べさせろという台詞を比較しても、全く違う個性があることが分かります。
櫻子 | 京子 |
---|---|
なんでもいいからくわせろー | 炭水化物とたんぱく質をバランス良く私にくわせて!! 繊維質も忘れずに♥ |
すし!! ステーキ!! フランス料理フルコース!! | 阿蘇牛とか池田牛とか赤身のうまいのを!! |
櫻子は欲望のままに言っている天然ボケ風味です。しかし京子はどう見ても狙ってボケています。結衣からツッコミを引き出そうという意図を感じますし、そのツッコミのバリエーションもたくさん考えられそうです。このたった2つの台詞で、天然ボケと計算されたボケの違いを非常にうまく表現していると思います。
二人が組んだらどちらがボケなのかという話もありましたが、おそらく京子はツッコミもできるのに対し、櫻子にツッコミは厳しいのではないかという感じがしますね。
続・徳丸本のあれこれ ストレッチング処理の変更
更新: 2011年7月10日9時20分頃
徳丸本のあれこれを実践してみて気付いたことの続きです。
前回、ストレッチングの回数をどうするのかが難しいと書きました。負荷を心配しつつ1000回で実装してみたのですが、実際に動かしてみると処理が一瞬で終わってしまい、速すぎて心細く感じるほどでした。
アプリケーションの機能は一通り実装し終わり、テスト運用を始めたのですが、しばらく運用してみてもログインが遅いとか、それに伴って負荷が高くなるといったことは起きませんでした。
というわけで、もう少し遅くしてストレッチパワーをためた方が良いのではないかと考え、調整することにしました。
ハッシュアルゴリズムの変更
まず、ハッシュアルゴリズムをSHA512に変更しました。徳丸本 (www.amazon.co.jp)ではSHA256が使われていますが、SHA512の方が遅く、生成されるハッシュ値も長くなります。遅いのは普通はデメリットですが、今回はメリットになります。
※2011-07-10追記: 手元で実測した結果ではSHA512の方が少し遅かったので「遅い」と判断していましたが、春山さんからコメントをいただきました (twitter.com) (ありがとうございます)。64ビットCPUではSHA512の方が速いと言われているそうです。実装に依存する面もあるので、一概にどちらが遅いとは言えないようです。
ハッシュ値の長さは、16進表記で128文字。少し長い感じもしますが、varchar(255)のカラムにすんなり格納できますから問題ありません。
※データベースのサイズを節約したい場合は、Base64にしたり、バイナリで保存することにしても良いと思います。徳丸本のPHPのコードではhexdigestの形になっていて、それで特に問題なかったのでそのまま採用しました。
Rubyには標準でDigest::SHA512 (www.ruby-lang.org)がありますので、Digest::SHA512#hexdigestを呼ぶだけでOKです。ついでに、設定ファイルでDigestの種類を変更できるようにしておきました。
ストレッチ回数の調整
ハッシュアルゴリズムをSHA512に変更しても、速度はそれほど大きくは変わりませんでしたので、処理の回数も調整することにしました。
解析されにくくするためには、できるだけ遅くしたいところです。しかし、遅すぎるとログインのたびに利用者が待たされることになります。どのくらいを遅すぎると判断するのかは難しいところですが、今回は、0.1秒以内に処理できれば良いことにしました。
手元の環境でベンチマークを実行してみました。RubyにはBenchmark (www.ruby-lang.org)というクラスがありますので、rails consoleから以下のようなコードを実行しました。
Benchmark.measure { 1000.times{ User.password_digest('user_id', 'dummy_passphrase') } }
1回だけの測定では一瞬で終わってしまって誤差が大きいので、1000.timesで1000回実行するようにしています。ストレッチ回数の設定を変更しながら試していったところ、ストレッチ5000回が約0.07秒でした。処理速度は環境に依存すると思われますが、まあこのくらいで良いでしょう。
というわけで、ハッシュアルゴリズムをSHA512、ストレッチ回数を5000回に設定しました。本番反映してしばらく様子を見ましたが、特に問題も出ていないようです。もちろん、アルゴリズムや回数を変更すると既存のユーザーはログインできなくなりますので、パスワードの再設定は必要になりましたが。
なお、これはあくまで私が今回実装したシステムでの話です。今回開発しているアプリケーションはCMSで、ログインするのはサイト管理者、編集者、承認者だけ、その頻度も高くありません。そのため、ログイン処理の負荷が問題になることはあまり考えられないでしょう。一般の利用者がユーザー登録するようなシステムの場合、一度に多数のユーザーが頻繁にログインする可能性がありますので、もう少し慎重に検討する必要があるかもしれません。
2011年6月27日(月曜日)
ゆるゆり3,4
公開: 2011年7月9日13時10分頃
購入。
まず表紙が! 3巻ではあかりが見切れかかっている……と思ったら、4巻ではなんと、ちなつの髪で完全に顔が隠れるというひどい扱い。主人公のあかりが目立たないというのはネタなのですが、それで表紙から笑わせに来るという攻撃的な姿勢が感じられます。
3巻で千歳が双子という衝撃の事実、そして4巻でさっそく千鶴が登場。京子がやたら嫌われていますが、千鶴の妄想カップリングは綾乃×千歳なので、京子が邪魔ということなのでしょうね。
あとは、なにげに生徒会長が初登場したり。無口というか全く喋らないキャラですが、どうやって生徒会長になったのだろう……。
銀河ヒッチハイク・ガイド
公開: 2011年7月8日15時50分頃
読み終わったので。
- 銀河ヒッチハイク・ガイド (www.amazon.co.jp)
SFの古典ですね。全体的に軽い感じのナンセンス・ギャグSFなので、気軽に読めて良いと思います。
有名な "the Answer to life, the universe, and everything" は、この版では「生命、宇宙、その他もろもろの回答」と訳されています。スーパーコンピュータ「ディープ・ソート」がこの問いを与えられ、750万年を費やして出した答えがなんと……。その答えを出す機能がGoogle電卓に実装されているというのは有名な話ですね (Google検索「生命、宇宙、その他もろもろの回答」 (www.google.co.jp))。
と、このあたりの話は事前知識として知っていたのですが、話には続きがあって、この答えに対応する究極の問いを計算するためのコンピュータが作られることになります。そして、そのコンピュータは計算が終わる5分前に破壊される……という感じで話が続いていくわけです。もっとも、これらの話は作中では過去の出来事として語られるわけですが。
視点を変えると浮力の正体がわかりやすくなる
公開: 2010年7月8日0時10分頃
あのピンポン球水力発電にまさかの続報が……「記者も感激! さいたま市の80歳男性が発明した「夢のエネルギー製造装置」に迫る」。 (sankei.jp.msn.com)
高校の時は数学や理科が苦手で文系に進んだ私。今回の取材には基礎的な知識が不足しているかもしれないと、以前に取材で知り合った都内の某大学理学部物理学科2年で力学や電磁力などを学ぶA君(20)に同行してもらった。
個人的には、このA君にかなりの感銘を受けました。
A君に計算してもらったところ、この装置で生み出される電力は1ワットにも満たないという。しかし、装置をもっと大きくして球の大きさを変えると、理論上、電力はそれに比例して大きくなるそうだ。
A君は「これ、高校2年生くらいの物理の学力があれば理解できる仕組みですよ。でもそんな簡単な知識でこんなこと思いつくなんて」と感心しきりのようだった。
一見すると、A君はニセ永久機関を絶賛してしまっている……というようにも見えるのですが、注意深く読んでみると、実はA君、永久機関だとかエネルギー問題が解決するといったことは一言も言っていないのですね。この装置が電力を生み出しているのは事実ですし、大きくすれば電力が増えるのも事実です (注入しなければならない水の量が増えるだけですが)。「こんなこと思いつくなんて」と感心してみせる場面でも、「こんなこと」の具体的な内容はコメントしていないという周到ぶり。嘘にならない範囲で、発明者の面子をつぶさないようにうまく立ち回っているように見えました。
……と、A君の世渡りスキルに感心したところで本題です。
物を落とせば確かにエネルギーは生まれる。しかし、落としたものをどうやって持ち上げるか。それに悩む日々だった。ある日、練習用の水に浮くゴルフボールを手にしたとき、ひらめいた。
「これだ。浮力だ。水を張ったパイプの中ならそれが可能だ」
浮力を使えば何も力を加えずに物を持ち上げることができるので、無尽蔵のエネルギーを生み出せる……という素晴らしい「発見」をしてしまったわけですね。確かに、水の中で物が浮かびあがるとき、何の力も加えていないのに、物体が上に向かって動いているというように見えます。しかし、それは誤解です。浮力は何もないところから無尽蔵に生じているわけではないのです。
浮力の正体は、視点を変えてみると分かりやすくなります。というわけで図を用意してみました (インラインSVGで描いているので、最近のブラウザでないと見えないと思います。見えない方はごめんなさい。できるだけ文中でも説明します)。
図の左側は、縦長の容器に水を満たし、ボールを沈めたところです。どうやってこの状態にするのかという問題は、今は考えないことにします (とりあえず、きわめて細い針金のような物で押し込んで手を離した直後の状態だと考えてください)。
この後、ボールは浮かび上がります。ボールが中央まで来たところが真ん中の図で、最初にボールがあった位置を点線で示しています。ボールに注目すると、単にボールが真上に動いたように見えます。
ここで視点を変えて、ボールではなく、水の動きに注目してください。最初、点線の位置にはボールがあり、水はありませんでした。今は点線の位置にはボールがなく、かわりに水で満たされています。単にボールが動いたのではなく、水とボールの位置が入れ替わったと見ることができます。
さらに進み、ボールが水面に浮かび上がったのが図の右側の状態です。ここでも水に注目すると、図の左の最初の状態よりも水面が下がっています。水中にあったボールが水から出ましたので、その体積の分だけ水面が下がります。
と、こうして水の動きに注目すると、ボールが上に向かって動くとき、水が下に向かって移動していることに気付きます。
ボールを水の中に押し込む場合には、逆の動きが生じます。
先の図の右端の状態からボールを取り除き、何らかの方法で底に押し込んだ図です (方法は問いませんが、まあたとえば、外に水は漏らさないが外からボールが入れられる弁のような物があって、底付近に取り付けられていると考えてください)。この状態で、ボールを押し込むと図の右の状態になります。ボールが水中に入り、同時に、水面が上昇しています。
ボールを押し込むことで、水を上に押し上げているわけです。逆に言うと、ボールを押し込むためには、水を持ち上げる力が必要です。力が足りないと水が持ち上がらず、ボールも水の中に入ってくれません。
ここで手を離せば最初の図のようになります。ボールは浮き、持ち上げられていた水は再び下がり、元に戻ります。力を入れてボールを押し込むと水が上がり、手を離すと水が下がってボールが上がるわけです。この動作は、どこかで見たことがあるのではないでしょうか。
そう、シーソーと変わらないのですね。
上図のシーソーでボールが持ち上がるのは、水に働く重力によるものです。そして、もう分かったと思いますが、浮力も水の重力によって生じています。
水に重力がはたらいて水圧が生じます。水深が深ければ深いほど、上にある水の量が増えますから水圧が高くなります。そのため、物体の下面での水圧が上面よりも高くなり、物を押し上げる力が働きます。元を辿れば、これは水が重力で下がろうとする力です。シーソーにおもりを乗せると反対側が上がる、というのと同じことでしかないのです。
ですから、物が浮くときは、必ず同じ体積の水が下がっています。そして、水の方が重いのです (水の方が軽い場合は、物は沈みます) から、水が持っていた位置エネルギーを上回るようなエネルギーを得られることはありません。
それでも浮力を使った永久機関を「発明」をしてしまう人がいたり、それを肯定的に報じてしまう人がいたりするのは、物が浮くという現象が意外に分かりにくいものだからでしょう。普通は浮かび上がる物の方に注目してしまいますし、水中で水が動いてもその動きは見えにいものです。手品師にミスディレクションされているかのように、本質から目を逸らされてしまう要素があるのが面白いですね。
※遠心力を利用した永久機関というのを考え出す人も多いわけですが、それも似たような話なのでしょうね。
2011年6月26日(日曜日)
ゆるゆり2
公開: 2010年7月6日23時55分頃
購入。
- ゆるゆり2 (www.amazon.co.jp)
期末テストに海、花火とイベント盛りだくさんなのですが、何故か印象に残ったのは、あかり主人公なのか疑惑。
第一話の登場の仕方からしてあかりが主人公っぽいという説ですが……第一話では結衣があかりを指して「騒がしいのは京子一人で充分」と言っていたり、あかりがだらだらしていたり、設定があんまり定まっていなかったような。京子は人気がトップ、京子のボケがないと成立しない話が多い (気がする)、という意味で中心的存在ではあるのですが、結衣と2人でワンセットな感じがするので、そういう意味では主人公っぽくない感じもしますね。
2011年6月25日(土曜日)
咲 -saki- 8
公開: 2010年7月4日2時5分頃
出ていたので購入。
- 咲 -saki- 8 (www.amazon.co.jp)
4校合同合宿を経て、ついにインターハイ全国大会へ。合宿で強化された清澄ですが、全国の強豪も次々に登場して、またしても盛り上がってきた感じです。2回戦の先鋒戦で神代小蒔が目を覚ましたところまで。
なにげに小鍛治プロが活躍(?)していて、これがなかなか可愛らしく良い味を出しています。
※あと、妙に露出度が高いキャラが増えてきたような。論理的に言って見えていると思うのですが。
2011年6月24日(金曜日)
究極のエコ? ピンポン球水力発電
公開: 2011年7月3日23時0分頃
産経新聞のこんな記事が話題に……「究極のエコ! 重力と浮力で発電する装置をさいたまの80歳男性が開発 (sankei.jp.msn.com)」。
東日本大震災でエネルギー政策の転換が叫ばれる中、重力と浮力だけを利用して電気を発生させる装置をさいたま市浦和区の会社役員、阿久津一郎さん(80)が発明した。パチンコ玉を内蔵したピンポン球を高い位置から落として歯車を回して発電、水の入ったパイプの中で球を再び浮力で上昇させて循環させるもので、平成22年10月に特許を取得した。実用化されれば、天候や時間に左右されない“究極の自然エネルギー”として注目を集めそうだ。(安岡一成)
産経新聞……。これが「究極のエコ?」という見出しならともかく、「究極のエコ!」という見出しなのですから、フォローのしようがありません。「浮力を使った永久機関 (homepage3.nifty.com)」というアイデアは、既出ですが不可能です。もちろんこの装置も永久機関であるはずがなく、からくりがあります。
装置には水位を保つために、ピンポン球の体積分の水が出し入れされており、1つの球は約3分間隔でこの循環を繰り返す-という仕組みだ。
水を出し入れしているわけです。図を見ると、高い位置に給水タンクが備えられています。ここに水を定期的に補充する必要があるのでしょう。高い位置に水を持っていく必要があるということは、水の位置エネルギーを消費して動くものと思われます。
ちなみにこの特許の内容、特許・実用新案公報DB (www.ipdl.inpit.go.jp)で確認することができます。しかし、frameを駆使した読みづらい構成の上に、特定の特許公報にリンクすることもできない構造のようで、もう心の底から残念な思いをいたしました。
幸いなことに、特許データをもっと読みやすい形で提供しているサービスがありますので、こちらを見るのが良いでしょう。
- 球体循環装置|詳細 - astamuse(アスタミューゼ) (patent.astamuse.com)
細かいところまでは分かりにくいですが、はっきりと読み取れるのは、ピンポン球1個が落下するとき、ピンポン球1個分の体積の水が捨てられるということです。減った水は、装置の上部に設けたタンクから補給する必要があります。つまり、ピンポン球1個を持ち上げるのと引き替えに、ピンポン球1個分の体積の水を下におろしていることになります。
そしてこのピンポン球は水に浮きますから、持ち上がるピンポン球よりも下ろされる水の方が重いことは自明です。羽根を回して発電するなら、ピンポン球ではなく、水を直接当てた方が効率が良いでしょう。水で羽根を回して発電するような仕組みは既に実用化されていて、一般には水力発電と呼ばれています。
というわけで、「エコ」という観点で見ると、この装置は水力発電にかないません。この装置が水力発電と違うのは、ピンポン球が動いたり、音が出たりするのが楽しいという点でしょう。産経新聞は、エコではなく楽しさを打ち出す記事を書いた方が良かったのではないかと思います。
ログ解析で攻撃に気付くのは簡単?
公開: 2011年7月3日20時25分頃
こんなお話が……「ソニーの情報漏洩は起こるべくして起こった」情報通信技術研究会で専門家が総括 (itpro.nikkeibp.co.jp)。
例えば、サーバーが再起動させられるまで不正アクセスに気付けなかった件については、「定期的にログ解析さえしていれば簡単に気付けたはず。そんなごく基本的なことさえしていなかったことは明白」と喝破。
うーむ。「簡単に気付けたはず」と言われていますが、サーバの再起動が起きる前、つまり攻撃が成功する前の段階で気付けということですよね。JSOCの監視サービス (www.lac.co.jp)に匹敵する品質が求められていると思うのですが、そんなに簡単なことなのでしょうか。
そしてPSNはアカウント数が7700万あるサービスですから、ログの量も半端ではないでしょう。そういう量のログをそういう質で監視するというのは、それほど簡単なことではないように思えるのですが……。
あるいは、簡単にできるような標準的なやり方があるものなのでしょうか?
関連する話題: セキュリティ / PlayStation Network
jQueryの落とし穴
公開: 2011年7月3日19時35分頃
「jQueryにおけるXSSを引き起こしやすい問題について (subtech.g.hatena.ne.jp)」。これは非常に興味深いお話ですね。
jQuery (jquery.com)はJavaScriptのライブラリですが、最近ではもうほとんどのサイトで使われていると言っても過言ではないくらい使われています。これは非常に便利で、面倒なDOM操作をとても簡単に書くことができます。たとえばこんな感じです。
$(function(){ $('#main-contents>div').append($('<p>こんにちは</p>')) });
上記のようなコードは良くあるのですが、よく見ると、$() は渡されたものの種類によって全く違う動作をしている事が分かります。
- functionを渡すと、DOM読み込み可能になったタイミング (DOMReady) でそのfunctionを実行
- CSSのセレクタのような文字列を渡すと、既存のノードを選択する動作 (getElementByIdやgetElementsByTagNameのような処理)
- タグのような文字列を渡すと、新たに要素を生成する動作 (createElementのような処理)
この他に、DOMのノードを渡すとjQueryオブジェクトに変換する機能もあります。
ポイントは文字列を渡したときの動作が2種類あることで、しかも、それぞれが全く違う動作になります。そのため、既存のノードを選択しようと思っていたのに要素が作られてしまうということが起こり得ます。
jQuery1.6.1のソースコードを見ると、以下のような正規表現にマッチした場合に要素作成になるようです。
quickExpr = /^(?:[^<]*(<[\w\W]+>)[^>]*$|#([\w\-]*)$)/
先頭のほうに [^<]* があるのがポイントで、開始タグの前に任意の文字列が存在していても良いことになっています。'#foo-bar<tag>' のような文字列はこれにマッチしますので、要素が作成されることになります。
script要素が作られても、それがDOMツリーに挿入されなければ問題ない……と思うかもしれませんが、onerrorイベント付きのimg要素を作らせるような技があり、挿入されなくてもスクリプトを実行させることができてしまいます。これがXSSの原因になり得る、というのが今回のお話です。
$() が万能というのはjQueryの設計思想なのだと思いますが、型が同じ (文字列型の) 引数を渡しているのに挙動が全く違うというのは、予期せぬところで問題を引き起こしやすいだろうとは思います。
関連する話題: Web / セキュリティ / JavaScript
2011年6月23日(木曜日)
Movable Typeまたまたアップデート (詳細不明)
公開: 2011年7月3日10時25分頃
MTにまたまたセキュリティアップデートが登場しているようで。
- [重要] Movable Type 5.12 および、5.06、4.292 セキュリティーアップデートの提供を開始 (www.sixapart.jp)
5月26日、6月9日に引き続いてのセキュリティ修正。ずいぶん立て続けですね。
Movable Type 4.291、4.361 および 5.11、5.051 を含む以前のバージョンでは、アプリケーション上の一部の操作において、ブログの管理者、あるいは投稿権限を持っているユーザーが、ファイルシステム上の既知のファイルへのアクセスが可能になる場合があります。
例によって詳細がよくわからない書き方ですね。「投稿権限を持っているユーザー」というのはブログ記事を投稿できるユーザーなのか、ブログにコメントを投稿できるユーザーなのか……。
りゅうさん (rryu.sakura.ne.jp)が軽く調査したところではXML関係の修正が入っているそうで、ローカルファイルを外部実体として宣言してから実体参照で参照すると読めてしまうという話かもしれない、という説があります。
※公式な情報ではなく、あくまで一説にすぎませんが。
関連する話題: セキュリティ / Movable Type
2011年6月22日(水曜日)
魔法少女まどか☆マギカ ブルーレイディスク 3巻
公開: 2011年7月2日20時25分頃
Amazonで注文していた商品が届いたのですが、カード払いにしたつもりが、何故か代引きになっていたという。デフォルトの状態はカード払いのはずですし、私はそれを変更した記憶がないのですが……注文確認のメールを見ても代引きになっています。何かの操作ミスで代引きになってしまった?
こんなの絶対おかしいよ。わけがわからないよ。
ちなみに届いたのはこれです。
- 魔法少女まどか☆マギカ 3 完全生産限定版 (www.amazon.co.jp)
伝説の名言「こんなの絶対おかしいよ」「わけがわからないよ」が登場するのは6話ですが、それがまさにこの巻に収録されております。このあたりからキュゥべぇがきな臭い感じになってきます。さやか・杏子が活躍する巻でもありますね。
付録のドラマCDは、ちょっと同人ぽい軽いノリのお話でした。
関連する話題: 買い物 / BD / 魔法少女まどか☆マギカ
2011年6月21日(火曜日)
武術「奥義」の科学
公開: 2011年7月2日17時30分頃
読み終わったので。
- 武術「奥義」の科学 (www.amazon.co.jp)
武術の世界では、老人が大男を簡単に吹っ飛ばしたりするような不思議なことが起きたりします。その現象は、時には「気」などというオカルトじみた概念で説明されたりするのですが、実は科学的に説明することができる……というのが本書の主旨。たとえばこんなことです。
- てこの原理など力学的な原理を応用すると、力を効率的に発揮することができる
- 同様に、力学的な原理で相手の力を封じることができる
- 身体を効率的に動かすことで、通常よりも素早く動くことができる
- 相手の錯覚を利用することで、相手が自ら動いて倒れるようにすることができる
説明を聞くと、なるほどと思えることが多く、非常に面白いです。
ただ、少し分かりにくい部分もあります。身体の動かし方の説明が中心になるのですが、肝心の動きが分かりにくいです。図もあるのですが、何度見ても今ひとつピンと来なかったり。
これは動画で説明すると分かりやすいのではないかと思います。電子書籍にして、動画が入ると素晴らしいものになるのではないか……という予感があるのですが、どうでしょう。
bAサイト、いきなりの試練
公開: 2011年7月2日17時0分頃
昨日公開した新しいbAサイト (www.b-architects.com)ですが、今日いきなり高負荷に。
原因はこのニュースリリースと思われます。
- 当社の葵プロモーショングループ入りに関するお知らせ (www.b-architects.com)
既に書いたように、bAサイトは開発中のCMSで管理されています。CMSには大きく分けて動的タイプと静的タイプがありますが、このCMSは動的タイプです。表側サイトもアプリケーション (Rails + Passenger) で出していますので、負荷が高まるとそれなりに厳しかったりします。いちおうAWS (Amazonのクラウド環境) に置いてはあるのですが、まだテスト運用でもあるため、とりあえずスモールインスタンスに乗せただけで、スケールできるような構成にはしていませんでした。
……とはいえ、負荷は高まったものの落ちたりはせずに普通に耐えられました。実はキャッシュの仕組みにいろいろ問題があってギリギリまで調整していたのですが、その調整が間に合っていたのが幸いしたというところでしょうか。
2011年6月20日(月曜日)
bAサイトのリニューアルと新CMSのベータテスト
公開: 2011年7月2日13時40分頃
唐突にbAのサイトがリニューアルしました。
- http://www.b-architects.com/ (www.b-architects.com)
「普通の企業サイトみたいになってしまった」「意図が分からない」などの声もちらほら上がっていたようですが、その秘密はこちら。
- クラウドCMSによるサイト構築を開始しました (www.b-architects.com)
実は、弊社では新しいCMS (コンテンツ管理システム) を開発しています。まだ細かい部分は残っているものの、ひととおりのコンテンツ管理が可能な状態にはなりました。その運用のテストを兼ねて、弊社サイトを開発中のCMSに載せたというのが今回リニューアルの内容です。
このCMSは小規模な企業情報サイトの運用をターゲットとしていて、初期状態で企業サイトに必要なページをおおよそ一通り持っています。そのデフォルトのテンプレートをそのまま使ったのが今の状態です。あえて初期状態を公開し、ここから少しずつ変えていくという方針になっています。
……とはいえ、既に、本来この製品では実現できないような機能が実装されてしまっているのが困ったところ。
このCMSでは、運用者はコンポーネントを選択してデータを入力するだけというコンセプトになっています。HTMLを書くことはできず、WYSWYGエディタを使うこともできないので、個性的なコンテンツを作成することはできません。これはつまり、運用者がどういう操作をしても絶対にvalidなHTMLになるということでもあります。
ところが抜け道があって、実は管理画面でアクセス解析用のJavaScriptを設定できるようになっています (ただしサイト管理者の権限が必要で、一般の編集者、承認者には不可能)。アクセス解析用と銘打ってはいますが、自由にスクリプトが書けますので、他のことに使うこともできます。
しかし……まさか、この機能を使って打ち出しのローテーションまで実装されてしまうとは思っていませんでした……。まあ、べつに問題はないのですが。
※打ち出しを管理する機能は必要だということが分かったので、これは別途正式な機能として実装する予定です。
とまあ、そんなこんなでいろいろ変化していくと思いますので、よろしくおねがいします。
2011年6月19日(日曜日)
ひかり電話ルーターを交換
公開: 2011年6月29日23時55分頃
うちに光回線とひかり電話を導入したのは2005年4月のことです。6年以上も不眠不休で頑張ってきたひかり電話ルーターですが、さすがに古くなったということなのでょうか、NTT東日本から、新型のルーターに交換してほしいという連絡が来ていました。来てもらって設置と設定の作業をしてもらうこともできるという話だったのですが、さすがにbakera.jpをWAN側に公開する設定まではお願いできないだろうと思い、ルーターを送ってもらって自分で交換することに。新しいルーターはRT-S300SE (web116.jp)という機種で、白と黒のカラーバリエーションがあるようですが、届いたのは黒いものでした。
※ひかり電話ルーターはレンタル品で、利用者の所有物ではない扱いなので、好きな色を選んだりはできないようです。いや、あるいはひょっとすると申し出れば好きな色にしてもらえるのかもしれませんが。
というわけで交換。古いものにはACアダプターがついていましたが、新しいものはプラグだけになっていてすっきりしました。
配線が終わって設定。特に問題はなかったのですが、2点ほど気になった点が。
- DHCPで特定のMACアドレスに対して特定のIPアドレスを割り当てる機能がなくなっている気がする (前のルーターにはあって使っていた)。まあ、サーバーのIPアドレスは固定にしておけば良いだけなので、特に必要ないのですが。
- パケットフィルタの設定が分かりにくい気がする。
パケットフィルタの設定は管理画面から行うことができるようになっています。IPアドレスとポートを指定して通過or拒否を設定する、というところまでは良いのですが、「プロトコル」という入力欄があって、これが選択式ではなくフリー入力になっています。とりあえずTCPとUDP両方を拒否してみようとしてanyと書いてみたら、なんと全てのポートがアクセス拒否設定になってしまったという。
ヘルプを見てみると、プロトコルのところには「TCP UDP」と書くのが正解だったようです。anyと書くとTCP/UDPに加えてICMPも拒否するのですが、ICMPにはポートという概念がないので、ポートの指定が無視されて全ポートへのアクセスが拒否される仕様のようで。これはちょっとしたトラップになりそうですね……というか、まあ、私が見事にひっかかったわけですが。
とまあそんなこんなで、しばらくbakera.jpには繋がらなかったりしましたが、今では繋がるようになっているはずです。
関連する話題: ひかり電話
ゆるゆり1
公開: 2011年6月28日1時30分頃
書店で平積みされていたので、なんとなく購入。
- ゆるゆり 1 (www.amazon.co.jp)
女子中学生の日常をゆるく描いた、良くある感じのマンガではあるのですが、方向性が明確に百合方向という特色があります。……といっても、それほど極端なわけでもなく、ギャグテイストなので問題ありません。むしろギャグマンガとしては秀逸で、京子の力強いボケは参考になります。
見た目は妙に厚いですが、大ゴマが多いためか、思ったよりも手早く読める印象があります。気楽に読むのには良いかも。
2011年6月16日(木曜日)
徳丸本のあれこれを実践してみて気付いたこと
更新: 2011年7月9日23時0分頃
とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。
基本的には徳丸本 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。
※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。
ストレッチ回数をどう決めるのか
徳丸本327ページにあるコード例を参考にして実装。アプリケーションごとの固有の値とユーザーIDを連結してソルト値とし、パスワードと連結してハッシュ値を生成。ストレッチングは、回数を設定ファイルに記述できるようにして、1000回に設定。ハッシュ値にソルトを連結してハッシュ、という動作を1000回繰り返します。
処理の負荷を心配していたのですがが、実際に動作させてみると一瞬で終了。むしろ回数はもっと増やしても良いのかもしれません。
回数の設定は設定ファイルに出したので、変えるのは簡単です。しかし、この数字を変えると、既存のユーザーがログインできなくなるという問題があります。運用開始前にしっかり検討して決めておく必要があるのですが、実際に運用してみないと負荷が分からないというパラドックスがあります。
この回数をどう決めるのかは、かなり難しい問題かもしれません。
ユーザーIDを変更するとログインできない問題
いろいろテストしていたら、唐突にログインできなくなるという不具合が発覚。調べてみたところ、ユーザーIDを変更するとログインができなくなることが判明。……って、言われてみればあたりまえの話でした。ユーザーIDをソルトに使っているわけですから、ユーザーIDが変化すると、ハッシュ値も異なるものになります。
対応方法はいくつか考えられます。
- ユーザーIDを変更したときにハッシュ値を作り直す …… ユーザーIDを変更してユーザー情報を保存するときに、ハッシュ値を作り直すという方法。ハッシュ値を作り直すためには元のパスワードが必要なので、ユーザーID変更時に元のパスワードを入力してもらう必要があります。ユーザーが自ら変更する場合には問題ないのですが、管理者がユーザーIDを変更する機能がある場合は採用できません (管理者はユーザーのパスワードを知らないため)。
- ソルトにユーザーIDを使用するのをやめ、DBレコードのIDを使用する …… ユーザーIDではなく、DBのレコードが持っているIDをソルトに使う方法。これは一見良さそうですが、ユーザーを新規作成するときの処理が面倒です。user = User.newとしてUserモデルのインスタンスを作成し、ハッシュ値をセットしてuser.save……としたいのですが、IDが決まるのはuser.saveが完了したときなのです。そのため、save前にはハッシュを作れません。User.new→user.save→ハッシュ値をセット→user.saveという具合にsaveを2回呼ぶ必要があります。これはこれで動くのですが、何らかの理由で2回目のsaveだけが失敗すると、絶対にログインできないユーザーがDBに残ってしまいます。
- ソルトにユーザーIDを使用するのをやめ、専用のソルト値をDBに保存する …… 乱数で専用のソルト値を生成して、DBに保存しておく方法。徳丸本326ページにある「乱数をソルトとして使う」方法です。DBのカラムがひとつ増えますが、特に問題はないと思います。
というわけで最後の方法を採用しようかとも思ったのですが、よく考えると、そもそも、ユーザーIDを変更する機能自体が不要でした。単にユーザー情報変更のフォームがscaffold (Railsによって自動生成されたモノ) のままで、不要な機能が残っていただけだったという。
ユーザーIDが変更できなければ問題ないので、これはこれで解決。ユーザーIDを変更する機能を持つ余地がある場合には、ソルト値をDBに保存するようにするのが良いと思います。
アカウントロックの実装
徳丸本315ページでアカウントロックが推奨されているので、これも実装。
最終ログイン失敗時刻を覚えておき、ログイン失敗をカウントして、10回になったら30分ロックするだけの簡単なお仕事……と思いきや、意外と考えなければならないことが多いです。
単にログイン失敗をカウントすると、アカウントロック後に正しいパスワードでログインしようとした場合にも失敗とカウントしてしまい、正しいパスワードを入れ続けているのにログインできないという問題が起きます (パスワード間違いの場合だけをカウントする必要があります)。また、ログインに成功したら、ログイン失敗カウントをクリアする必要があります。これを忘れると次回のロックが異常に素早くなります。まあ、このようなバグはテストすればすぐに発覚するので、大きな問題になることはないでしょう。
アカウントロックを実装すると、DBへのアクセスの仕方も変わってきます。徳丸本308ページには、以下のようにあります。
ログイン機能は、通常、以下のようなSQL文を用いて、IDとパスワードの両方が一致するユーザを検索し、ユーザが存在すればログインできたと見なします。
SELECT * FROM usermaster WHERE id=? AND password=?
ユーザーIDとパスワード (のハッシュ値) の両方をキーにしてユーザーを取得しているわけですが、何も考えずにアカウントロックの処理を追加すると、こうなってしまいます。
- ユーザーIDとパスワードからハッシュ値を算出
- ユーザーIDとハッシュ値をキーにしてユーザーを取得
- ユーザーが取得できなかった場合、ユーザーIDだけをキーにしてあらためてユーザーを取得
- ユーザーが取得できたらログイン失敗情報を書き込み
この場合、ログインに失敗すると2回のDBアクセスが発生することになります。これは1回にまとめることができます。
- ユーザーIDだけをキーにしてユーザーを取得 (ユーザーが取得できなかったらログイン失敗、ここで終了)
- ユーザーIDとパスワードからハッシュ値を算出
- ハッシュ値が一致しなければログイン失敗、失敗情報を書き込み
ここで気になるのが、ハッシュ値を計算するタイミングです。ストレッチング回数の設定によっては、この計算には時間がかかります。一般的に、ログイン失敗時にユーザーが存在するのかどうかが分かるのは良くないとされています (徳丸本338~339ページ)。最後のような実装を採用した場合、ユーザーが存在した場合だけハッシュ値を計算することになるので、ユーザーの有無で処理にかかる時間に差が出てしまいます。
そこで、処理の順番を入れ替えて、以下のようにしました。
- ユーザーIDとパスワードからハッシュ値を算出
- ユーザーIDだけをキーにしてユーザーを取得 (ユーザーが取得できなかったらログイン失敗、ここで終了)
- ハッシュ値が一致しなければログイン失敗、失敗情報を書き込み
この場合、ユーザーIDが間違っているときにもハッシュ値を計算します。これは無駄ではあるのですが、そうしないとユーザーの存在を推測されてしまう可能性があります。
ちなみに、ユーザーIDが入力されていない場合には、何も処理しないで「ユーザーIDを入力してください」というエラーを出すようにしています。ユーザーIDが空の場合にユーザーが存在しないことは明らかなので、これを隠す必要はありません。
CookieStoreによるセッション管理
ここからは余談になります。
徳丸本46ページ、「クッキーによるセッション管理」の項目には、以下のような記述があります。
クッキーは少量のデータをブラウザ側で覚えておけるものですが、アプリケーションデータを保持する目的でクッキーそのものに値を入れることはあまり行われません。その理由は以下の通りです。
- クッキーが保持できる値の個数や文字列長には制限がある
- クッキーの値は利用者本人が参照・変更できるので、秘密情報の格納には向かない
さらに、206~207ページにもCookieに不用意に情報を格納することの危険性について書かれています。
しかしRails2以降では、"CookieStore" というセッション管理方法がデフォルトになっています。これはCookieにセッションデータを丸ごと格納してしまうという方法で、まさに徳丸本で駄目出しされている方法そのものに見えます。……が、実はHMAC (鍵付きハッシュ) がつけられていて、利用者本人による値の改竄ができないようになっています。
ちなみに、データ本体はMarshal.dumpしたものをBase64エンコードしているだけで、特に暗号化はされていません。セッションデータの内容を閲覧することは可能なので、そこは注意が必要です。もっとも、ユーザー本人に閲覧されて困るものをセッションに格納する機会はほとんどないと思いますが。
※「ログイン済み」という情報をセッションに書き込むと確実にCookieの値が変化するため、セッション固定攻撃ができないという変な副次的作用もあったりして、なかなか面白いようです。
※2011-07-09追記: その後、ストレッチ処理を少し変更してみました:「続・徳丸本のあれこれ ストレッチング処理の変更」
2011年6月15日(水曜日)
なぜ日本人は世界の中で死刑を是とするのか
公開: 2011年6月25日21時40分頃
読み終わったので。
- なぜ日本人は世界の中で死刑を是とするのか (www.amazon.co.jp)
なんと本書の前半、半分以上はひたすら死刑事例を紹介するという、予想の斜め上を行く構成。昭和20年から平成20年まで、時代を追いながら、ただ淡々と死刑判決の事例が紹介されていきます。まあ、それはそれで興味深くはあるのですが……。結局、この膨大な事例から導き出されるのは「死刑の基準は一定不変ではなく、時代や世相に影響されて変化する」という事だと思うのですが、それをこのような形でやってのけるのが凄いと言えば凄い、ある意味、元裁判官らしいと思います。
その大ボリュームの前半に比べ、本論であるはずの後半はあっさり。議論の運びがこれまた淡々としていて、押しつけがましさがないのは好感が持てますが、逆にちょっと拍子抜けな感もあります。中立であろうとすることにこだわりすぎているのかもしれず、これまたある意味、元裁判官らしいと思いました。
タイトルの「なぜ日本人は世界の中で死刑を是とするのか」に対する明確な答えがあるわけではないので、そこに期待して読むと拍子抜けするかもしれません。
EZWebの「IPアドレス帯域」に大きな変更
公開: 2011年6月25日17時0分頃
auのEZWeb、2011年秋冬モデルに合わせて変更が行われるようで。
- KDDI au: EZfactory (www.au.kddi.com)
- EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点 (d.hatena.ne.jp)
- auのEZWebがそろそろ終了しそうな件 (blog.rocaz.net)
変更点として発表されているのは以下の2点です。
<主な変更点>
・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。
・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。
以上、KDDI au: EZfactory より
HDMLが非サポートとなるという話は驚きました。いや、むしろ今までサポートされていた事に驚いたのですが。
まあそれは正直どうでも良い話だと思います。重要なのは、IPアドレス帯域が統一される話のほうですね。PCサイトビューアーは一般のPCサイトを閲覧できるブラウザですから、JavaScriptも動きます。
非公式サイトのいわゆる「かんたんログイン」は、HTTP要求ヘッダを改変できないことを前提としています。今までは、キャリアのゲートウェイからの通信だけを受け入れることで改変を防ぐことが (ある程度) できていましたが、この統合が行われると、それが崩れてしまうことになります。非公式サイトでEZ番号を利用した認証をしている場合は、対応を考える必要があるでしょう。
2011年6月13日(月曜日)
時計を合わせたら録画失敗
公開: 2011年6月19日16時15分頃
録画しておいた番組を観ようと思ったら、録画に失敗していたでござるの巻。
「予約の開始時刻に録画が開始できませんでした。」というエラーメッセージが残されていました。録画を開始するべき時刻に、PS3 (www.amazon.co.jp)が起動していなかったのでしょうか?
トルネで録画予約をしておくと、予約した時間の直前にPS3が起動してトルネが起動し、録画を開始するようになっています。このとき、電源ケーブルが抜けていたり、停電したりしていれば録画の開始ができないということになりますが……そんな気配は全くありませんでした。
……と、ここでふと思い出したのが、PS3本体の時計合わせをしたこと。前回、PS3本体の時計が30分ほどずれているのに気付いたので、トルネを終了してから時刻合わせをしたのでした。PS3にはNTPによる時刻同期の機能があるので、時計を合わせるのは簡単です。
そのときは何の問題も起きなかったのですが、冷静に考えると、こういうことのような気がします。
- トルネで録画予約すると、予約した時間の直前にPS3が自動的に起動するように設定される。
- このとき、PS3が起動する時刻は、トルネの時計ではなくPS3本体の時計によって制御されている。
- トルネは地上デジタル放送の電波から正確な時刻情報を得ているが、PS3本体の時計を勝手に合わせる事まではしていない。
PS3本体の時計が大きく狂っていると、トルネの時計とPS3の時計が大きく食い違うことになります。すると、どうなるでしょうか。今までは、PS3の時計が狂っていたのに、問題なく予約録画できていました。ということは、トルネは本体の時計の狂いを検出して、その狂いをふまえた起動時刻設定をしているのでしょう。
たとえば、PS3本体の時計が30分進んでいるときに、01:00からの番組を録画予約すると……。
- トルネは01:00からの番組を録画予約しようとし、PS3本体を 01:00 少し前に起動するように設定しようとする。
- PS3の時計が30分進んでいるので、01:00のとき、PS3の時計は01:30になっているはずである。
- このことをふまえて、トルネはPS3本体の時計が01:30の時に本体が起動するよう設定する。
と、こうなるものと思われます。このまま何事もなければ、PS3は01:00に起動して、問題なく番組が録画できます。
ところが、トルネを終了した後でPS3本体の時計を合わせると……。
- PS3本体の時計が修正される。
- しかし、トルネは起動していないので、自動起動の設定時刻は修正されない。
- やがて時が来ると、PS3本体は設定された時間である01:30に起動する。
- そしてトルネが起動し、01:00開始の番組を録画しようとする。
と、こうなるはずです。そして、実際にこうなったものと思われます。もちろん、既に放送が終わっていて残念な思いを満喫することになります。
ちなみに、その後は他の番組は正常に録画できていました。PS3本体の時計を合わせたら、そのあとでトルネをもう一度起動すれば問題ないようです。
※なお、録画に失敗していたのが幸いにもチバテレビの「日常」だったため、大きな問題はありませんでした (その後TOKYO MXで録画しました)。
魔法少女おりこ☆マギカ 2
公開: 2011年6月19日13時10分頃
出ていたので購入。
- 魔法少女おりこ☆マギカ 2 (www.amazon.co.jp)
1巻は正直ちょっと微妙な感じでしたが、2巻では魔法少女狩りの目的なども明かされて、良くまとまったと思います。1巻で「これは無いな」と思った方にもオススメ。ただ、1巻であれだけ重要な位置を占めていたゆまが、2巻ではほとんど活躍しないのが残念でした。
ラストは結構衝撃的なバッドエンド……のはずなのですが、「またやり直せばいいだけだよね」と思ってしまうので、そこまでの衝撃にはならないという。時間遡行能力のあるキャラの出てくる話をバッドエンドで終わらせるのはなかなか難しいですね。
関連する話題: マンガ / 買い物 / 魔法少女まどか☆マギカ
2011年6月12日(日曜日)
ワールドエンブリオ8
公開: 2011年6月19日12時10分頃
8巻が出ていたので購入。
- ワールドエンブリオ8 (www.amazon.co.jp)
一冊まるまる過去編。謎が次々と明らかになっていって大盛り上がり。とはいえ、肝心の部分はまだ明らかになっておらず、続きが期待されます。
個人的には、タカオが下の名前ではなく名字だったというのが最大の驚きポイントでした。:-)
2011年6月10日(金曜日)
何が夢で何が現実なのか
公開: 2011年6月19日12時10分頃
村上春樹がカタルーニャ国際賞を受賞した際のスピーチが話題に。
- 村上春樹さん:カタルーニャ国際賞スピーチ原稿全文(上) (mainichi.jp)
- 村上春樹さん:カタルーニャ国際賞スピーチ原稿全文(下) (mainichi.jp)
私が気になったのは、後半のこの部分。
原子力発電を推進する人々の主張した「現実を見なさい」という現実とは、実は現実でもなんでもなく、ただの表面的な「便宜」に過ぎなかった。それを彼らは「現実」という言葉に置き換え、論理をすり替えていたのです。
(~中略~)
我々は夢を見ることを恐れてはなりません。そして我々の足取りを、「効率」や「便宜」という名前を持つ災厄の犬たちに追いつかせてはなりません。我々は力強い足取りで前に進んでいく「非現実的な夢想家」でなくてはならないのです。
この話、「原子力は現実」ということを前提にしているようです。少なくとも、原子力発電を推進する人々はそう主張しているのだと。それはそれで間違いではないと思います。
ただ、私は原子力こそが「夢」だったのではないかと思っています。「原子力を平和利用する」「核分裂連鎖反応を安全に制御する」という思想自体がかつては「夢」だったのでしょうし、核燃料サイクルの中心となるはずの高速増殖炉、高レベル放射性廃棄物の最終処分といった技術は、今でも「夢の技術」だと言って良いでしょう。
原子力を推進してきた人達は、その「夢」を半世紀以上も追い続けてきたわけですが、いまだに実現できていません。日本で実現できていないだけではなく、世界的に見ても実現できた例がありません。そして、その夢を粉々に打ち砕くような大きな事故も起こってしまいました。
にもかかわらず、まだ原子力の推進を諦めていない人達がいる。そういう見方をすると、「夢を見ることを恐れてはなりません」という言葉は、また違った意味に見えてきます。
さらに思ったのは、廃棄物の最終処分の実績が全くない、つまり最後までワークフローが回ったことが一度たりともないというのに、それが現実的だと思われていることの凄さです。この背景には非常に強力な「スピン」が存在するのではないかと感じます。
2011年6月9日(木曜日)
Movable Type5.11/5.051で何かが修正 (詳細不明)
公開: 2011年6月18日15時45分頃
MTにまたセキュリティアップデートが登場しているようで。
- [重要] Movable Type 5.11 および、5.051、4.291 セキュリティーアップデートの提供を開始 (www.movabletype.jp)
ついこの前アップデートが出たばかりなのですが、別件のようですね。
Movable Type 4.29、4.36 および 5.1、5.05 を含む以前のバージョンでは、当該製品で管理している情報を、アプリケーション上の一部の操作において、遠隔の第三者により更新、閲覧、変更される可能性があります。
以上、セキュリティアップデートの概要 より
例によって詳細が良く分かりません。この書き方だと能動的攻撃を受けるように思えますので、「情報を……遠隔の第三者により更新、閲覧、変更される」というのは相当まずいように思います。ただ、その「情報」がいったい何なのかによって深刻さが全く違います。
たとえば、仮にこれが「コメント欄に入力されたコメントを更新、閲覧、変更される」という問題だったなら、コメント欄を使用していないブログは影響を受けないことになります。アップデートが必須なのかどうかを判断するためには、「今の使い方で問題の影響を受けるのかどうか」を知りたいわけです。その判断に必要な情報が出てこないのは厳しいですね。
リリースノート (www.movabletype.jp)を見ても、はっきりとは分かりません。「新たに実装された機能」があったりするようですが……。
DeniedAssetFileExtensions が新しく追加されました。
AssetFileExtensions が、Movable Type 4.291 と 4.361に追加されました。(Movable Type 5.01 以降のバージョンには、すでに実装されています。)
これらの環境変数をmt-config.cgiに記述すると、ユーザーのファイル・アップロード時のチェックに利用されます。コンマ区切りのリストで、ファイルの拡張子を指定します。正規表現を使用することも可能です。
特定の拡張子のファイルをアップロードできないようにする機能のようですが、この機能は今回新たについたのでしょうか、それとも、以前から機能はあって、設定が変更できるようになっただけなのでしょうか。そして、この機能はセキュリティ修正と関係があるのでしょうか、それともないのでしょうか。
まあ、MTはPerlで書かれていますのでソースを読めば分かるのですが、そんな時間を取れるのかが問題です。
関連する話題: セキュリティ / Movable Type
2011年6月8日(水曜日)
虐殺器官
公開: 2011年6月18日12時50分頃
読み終わったので。
- 虐殺器官 (www.amazon.co.jp)
近未来SF作品。主人公米軍の特殊部隊で暗殺任務に携わっていて、現場は凄惨……なのですが、それが翻訳物のような文体で淡々と綴られます。
宿敵のポールは何者なのか、なにをしているのか、という謎が中心になって話は進むのですが、ラスト付近になって明かされる、その動機に驚かされます。そしてラストは衝撃の展開で、非常にインパクトが強いです。
いろいろな事を考えさせられますし、非常に良い作品ですね。
2011年6月6日(月曜日)
賭博堕天録カイジ 和也編 6
公開: 2011年6月10日1時50分頃
出ていたので購入。
- 賭博堕天録カイジ 和也編 6 (www.amazon.co.jp)
相変わらずの友情確認ゲームですが、和也が突然バグバグ言い出したのが面白かったです。
ひどいバグに遭遇したときに使えそうですね。
2011年6月2日(木曜日)
私のおウチはHON屋さん3
公開: 2011年6月8日1時30分頃
出ていたので購入。
- 私のおウチはHON屋さん 3 (www.amazon.co.jp)
相変わらずのプロ店員ぶりに頭が下がります。大切な顧客を「現実と非現実の区別もつかない恥ずかしい人達」と馬鹿にされると……。
澄田さんという方は電車痴漢モノが好きです
けどもちろん痴漢なんてするはずのない
とてもとても真面目な会社員さんです!盗撮モノ好きの井上さんも
緊縛モノが好きな泉さんも非現実 とわかってウチに来てるんです区別のつかない恥ずかしい人達なんかじゃありません!
熱い台詞! でもなんか名前を出された人達がひどい目に遭わされている気がするのはなんでだろう。
新キャラがけっこう出てきているのですが、逆に常連の活躍がまったくないのがちょっと寂しいと思いまた。あと、巻末の読み切りは意外に良かったです。
関連する話題: マンガ / 買い物 / 私のおウチはHON屋さん
2011年6月1日(水曜日)
被害者は誰?
公開: 2011年6月8日0時5分頃
読み終わったので。
- 被害者は誰? (www.amazon.co.jp)
短編4本、そのほとんどが叙述トリックですが、全てが異なるタイプの作品という面白い一冊。
表題作の「被害者は誰?」の仕掛けはすぐに分かってしまいましたが、他3本はなかなか。全体的に軽妙なタッチのスラップスティックで、考え込むより先に読み終わっているような感じですね。
- 前(古い): 2011年5月のえび日記
- 次(新しい): 2011年7月のえび日記