2011年5月
2011年5月31日(火曜日)
.NETでお手軽XSLT
公開: 2011年6月5日17時55分頃
とあるCSVからXMLを経由してXSLTでHTMLを生成するプログラムを作成して披露したら、「XSLTの良い処理系ってありませんか?」みたいな話に。実は.NET FrameworkにはSystem.Xml.Xsl.XslCompiledTransformというクラスがあってXSLT1.0の変換ができますので、それをそのまま使うという手があります。
Visual Studioが必要そうに思えるかもしれませんが、そんなことはなくて、以下のような手順でコンパイルすることができます。
- .NET Framework デベロッパー センター (msdn.microsoft.com)から、最新の.NET Frameworkをダウンロードしてインストールする。
- .NET Frameworkについているcse.exeを探す。おそらく C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe のような場所にあります。
- 以下のような C# のコードを用意して xslt.cs というファイル名で保存する。
- コマンドプロンプトから C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe xslt.cs のようにしてコンパイルする。
コードはたとえばこんな感じ。
using System; using System.Xml; using System.Xml.Xsl; public class Xslt{ public static int Main(string[] args){ try{ if(args.Length < 2){ Console.WriteLine("Usage: xslt XMLfile XSLTfile"); return 1; } XslCompiledTransform xct = new XslCompiledTransform(); xct.Load(args[1]); XmlWriter xw = XmlWriter.Create(Console.Out, xct.OutputSettings); xct.Transform(args[0], xw); return 0; } catch (Exception e){ Console.WriteLine(e); return 1; } } }
エラー処理を除くと実質4行です。これをコンパイルすると xslt.exe というファイルができます。あとはコマンドラインから xslt XMLfileXSLT file > result.html のようにすれば動きます。
- 「.NETでお手軽XSLT」にコメントを書く
第1回アクセシビリティBAR~初夏のパンくず祭
公開: 2011年6月5日17時55分頃
以前からやろうといっていた「パンくず祭」、ついに実現!
- 第1回「アクセシビリティBAR(仮称)」初夏のパンくず祭 (atnd.org)
- Togetter - 「第1回「アクセシビリティBAR(仮称)」初夏のパンくず祭」 (togetter.com)
- 第1回アクセシビリティBAR『初夏のパンくず祭』に行ってきた (sho.tdiary.net)
- 覚え書き@kazuhi.to: 第1回「アクセシビリティBAR(仮称)」初夏のパンくず祭 (kidachi.kazuhi.to)
参加者はウェブアクセシビリティ基盤委員会ワーキンググループ2 (waic.jp)のメンバー7人とを中心に、3人を加えた合計10人。そういう構成だったこともあり、ちょっと内輪ネタが多かったような感じもなきにしもあらずですが、全体としてはとても面白い話ができたと思います。
議論の中心になったのは以下のような点でしょうか。
- そもそも、パンくずリストは必要なのか
- パンくずリストをどのようにマークアップするべきか
- 「>」を画像にして alt="の中の" とするパンくずリストは是か非か
そもそも結論を出そうとして議論していたわけではありませんので、結論は特に出ていませんが、出た議論の中で印象に残ったものを書いておきます。実際の発言とは違う可能性があります。
そもそも、パンくずリストは必要なのか
パンくずリストには現在位置を把握させる機能と上の階層に戻る機能がありますが、これがそもそも必要なのかどうか。
- ディレクトリ型の階層構造を持つコンテンツであれば、ある程度有効なのではないか。
- 最近はディレクトリ型でないコンテンツも増えてきている。有効性がないケースもありそう。
- アクセス解析をすると、実際に数パーセントの人は確実にパンくずをクリックしている。それなりに使われているのではないか。
- ここに来ているのはリテラシの高い人だから「あまり使わない」と思うかもしれないが、リテラシが高くない人は使うのではないか。
- 高齢者のユーザーテストをすると、とにかくホームに戻りたがる傾向がある。
「パンくず要らない」という強硬派の意見があるかと思いきや、意外とそうでもなかった印象です。
パンくずリストをどのようにマークアップするべきか
パンくずリストのマークアップについて。
- 富士通のサーバのコンテンツ (primeserver.fujitsu.com)では、JSで左のナビを読んでパンくずを表示する実装を行っている。パンくずのマークアップはol。
- ulはあるがolはちょっと無いのではないか。
- 日本郵政のサイト (www.japanpost.jp)ではdlが使われている。dtには「現在位置」と入っている。
- これはdlの濫用なのではないか。
- 「現在位置」を見出しにすると強すぎる気がするのでdtにしている。
- リストの入れ子を使うケースもある (各階層ごとにulを入れ子にする)
- そもそもリストではないのではないか。自分はpやdivでマークアップしている。
- そもそもコンテンツの内容に入れることが適切なのかどうか。本来はhead要素内に入るような性質のものではないのか。ブラウザが対応していないので仕方なくbodyに入れている、ということかもしれない。
ここは割と持論がばらけたところです。様々なサイトのパンくずを見ていったところ、区切りを画像にしてaltをつけているサイトに遭遇。そして、その話が盛り上がって行くことに……。
「>」を画像にして alt="の中の" とするパンくずリストは是か非か
パンくずリストの区切りには「>」が使用されることが多いですが、それを画像にして alt="の中の" と設定しているケースがあり、この是非が議論になりました。インフォアクシア (www.infoaxia.com)のサイトがそうなっているのですが、代表の植木さんがこの場にいらっしゃっていたため、たいへん素晴らしい盛り上がりを見せることに。
- そういえば昔CSS Nite LP2 (cssnite.jp)で紹介されていた記憶がある。植木さんとは別の誰かが紹介していたような気も。
- 推奨したつもりはない。スクリーンリーダーでパンくずリストが自然に読まれる方法の一つとして紹介。
- いちおうユーザーテストもやっていて、それなりに良い結果が得られている。
- これはスクリーンリーダーのユーザーを甘やかしすぎている感じがする。
- 今ではこれがベストとは思っていない。
植木さんも含め、わりあい批判的な意見が多かったように思います。
私がこのやり方に違和感を覚えるのは、スクリーンリーダーの利用者が、そうでない人よりも多くの情報を得ているという点です。区切りを「の中の」と読むと分かりやすくなるというなら、スクリーンリーダーだけでなく、全ての人に「の中の」を見せれば良いのではないでしょうか。それが鬱陶しいと思われるのであれば、スクリーンリーダーの利用者にとっても鬱陶しいものになっている可能性があります。
※余談ですが、summary属性にもこの手の違和感があります。表のサマリーは、スクリーンリーダーの利用者だけでなく、他の利用者にも役立つものになるでしょう。HTML5ではsummary属性を使わない方法が考えられています (4.9.1.1 Techniques for describing tables (www.w3.org))。
とまあ、そんなこんなで非常に有意義なお話ができました。
全体を通して思ったのは、アクセシビリティに対するアプローチの仕方がいくつもあるということ、そのアプローチの仕方は大きく2つに分けられるのではないか、ということ。その辺りはまた別の機会に書くかもしれません。
関連する話題: Web / アクセシビリティ / アクセシビリティBAR
2011年5月30日(月曜日)
魔法少女まどか☆マギカ3
公開: 2011年6月4日22時15分頃
コミック最終巻。
- まどか☆マギカ3巻 (www.amazon.co.jp)
基本は原作と同じ展開なので、最終話を見終わっていると特に新鮮みはないかもしれません。ただ、ラストには原作とはちょっと違うシーンがありますね。
関連する話題: マンガ / 買い物 / 魔法少女まどか☆マギカ
2011年5月28日(土曜日)
魔法少女まどか☆マギカ ブルーレイディスク 2巻
公開: 2011年6月2日0時5分頃
注文していたブルーレイ2巻が届きました。
- 魔法少女まどか☆マギカ 2 完全生産限定版 (www.amazon.co.jp)
1巻と同様にブックレットとCDつきなのですが、このブックレットの文字がやたらと読みにくい……。特に監督インタビューの部分は読むのにかなり難儀するレベルでした。おそらくマミさんのカラーリングを意識してでしょう、文字がオレンジ色になっているのですが、この色が実に読みにくいです。
ブルーレイ本編はふつう……かな? 1巻で修正されていたマミさん部屋や屋上は、2巻でも同じように修正されています。ただ、結構微妙なままのところも残っていて、お菓子の魔女との戦闘前のまどかとマミさんの会話シーンあたり、作画がかなり厳しいように感じました。
そのぶん(?)、オーディオコメンタリーは結構興味深い話が。1巻のオーディオコメンタリーの髪の色の話についてもフォローが入ったりしていましたね。
まあ、マミさんもちゃんとマミっていますし (あたりまえ)、買う価値はあると思います。
関連する話題: 買い物 / BD / 魔法少女まどか☆マギカ
PlayStation Networkのパスワードを短くした話
公開: 2011年6月1日23時45分頃
PlayStation Networkが復旧したという噂を聞いたので、アクセスしてみることに。
PS3 (www.amazon.co.jp)に記憶させていたパスワードでログインすると、「お客様のパスワードはご利用いただけなくなりました。パスワードを変更する必要があります」と言われて、新パスワード入力画面に。パスワード入力とパスワード確認入力の欄はあるものの、旧パスワードの同時入力がないのが気になりました……が、機器認証済みのPS3からのパスワード変更ならCSRFも関係ないはずです。そこは気にせずにパスワードを入力することにしました。
パスワードの要件は、「英数字を含む8文字以上」と表示されています。8文字あれば良いとはいえ、PlayStation Networkはまだ攻撃者から注目を浴びている状態です。新しいパスワードは、できるだけ長くて強力なものが良いでしょう。
というわけで、ちょっと工夫して約20文字のパスワードをつくりました。PS3のコントローラを使ってソフトウェアキーボードから文字を入れるのは結構面倒なのですが、それでも頑張って2回入力。そして「決定」を選択してみると……。
入力された内容は無効です。パスワードの入力には以下の点にご注意ください。
- 8文字以上で入力してください。
- 1文字以上の英字および数字を含めてください。
- 同じ文字は3文字以上連続させないでください。
- サインインIDまたはオンラインIDと同じものはご使用になれません。
- パスワードは2箇所に正しく入力してください。
- 英字の大文字と小文字は区別されます。
- 前回のものと違うパスワードにしてください。
「同じ文字は3文字以上連続させないでください。」という部分だけが赤文字で表示されています。つまり、そういうことなのでしょう。
しかしこれ、なんで駄目なのでしょうか。パスワード全部が同じ文字だけというならともかく、しっかりと英字、数字、記号を混ぜたパスワードです。それなりのパスワードを作ってから一部の文字を連続させると、簡単にパスワードを長くできる上に、覚える手間も大差ありません。個人的にはかなりオススメできる方法だと思っていたのですが……PlayStation Networkのポリシーとしては駄目ということのようですね。
仕方ないので、連続部分を削ってパスワードを短くしました。文字の連続を禁止されれば当然こういう対応になるわけで、何を意図してこのような制限をつけたのかが理解できません……。
関連する話題: セキュリティ / PlayStation Network / ユーザビリティ
2011年5月26日(木曜日)
PSNとログの転送
公開: 2011年5月29日23時10分頃
こんな記事が……「ソニー、“想定内”の攻撃を防げず 一部再開も、専門家は対策不足を疑問視 (itpro.nikkeibp.co.jp)」。
焦点の一つは「ログの有無」だ。PSNなどがサイバー攻撃を受けたのは米国時間の4月17日から19日。ソニーは同4月20日に問題を認識してサービスを停止したが、公表までに1週間を要した。セキュリティ対策に詳しいS&Jコンサルティングの三輪信雄社長は、時間がかかった理由を「サーバーのログを二重化しておらず、攻撃手法や被害実態が把握できなかったのではないか」とみる。
(~中略~)
このような場合、後からアプリケーションサーバーの動作を確認するには、別の場所にログを保管しておく必要がある。不正プログラムがログを消去するのを防ぐためだ。「ログを二重化していなかったとすると、セキュリティ対策が稚拙だったと言わざるを得ない。思いつきで通販サイトを営むのと同じレベルだ」とS&Jの三輪社長は語る。
「ログを二重化」という言い方は分かりにくいと思いました。
サーバが不正アクセスを受けた場合、攻撃者は、自らの攻撃の痕跡を消すために、ログを消去したり改竄したりする可能性があります。改竄の痕跡が見あたらなかったとしても、分からないように巧妙に改竄されている可能性が否定できません。ですから、侵入を受けたサーバに蓄積されていたログは信用できないということになります。
そういった問題を防ぐために、専用のログサーバを立てておき、ログはそこに転送してしまうという方法をとる場合があります。こうしておくと、ログサーバが攻略されない限り、ログが改竄される心配はありません。
※ついでに、複数サーバのログを一箇所に集められるので、管理しやすくなるというメリットもあります。
というわけで、「ログは専用のログサーバに転送しておくべき」という話であれば、それはある程度正しいと思います。ただ、重要なのはログを別のサーバに転送することであって、「二重化」することではありません。二重化していても、その両方が侵入を受けたサーバ上に置いてあっては意味がないはずです。
また、ログサーバが万能かと言うと、そうでもありません。ログを送るのにはサーバ間の通信が必要ですから、通信のトラブルが起きればログの取りこぼしもありえます。また、ログサーバが攻略されてしまえば無意味です。そもそも、ログは侵入されたあとの調査 (フォレンジック) のためのものであって、侵入を防ぐ施策ではありません。それはそれで意味はありますが、順序としては、脆弱性対策のほうを優先してほしいところです。
そして、ログサーバを運用するのにもコストがかかります。それなりの規模のサービスでも、ログの転送はしていないところが結構多いのではないでしょうか。「セキュリティ対策が稚拙」「思いつきで通販サイトを営むのと同じレベル」というのはちょっと叩きすぎのように思うのですが、どうなのでしょうね。
関連する話題: セキュリティ / サーバ / PlayStation Network
Movable TypeのCSRF修正 (詳細不明)
公開: 2011年5月29日22時25分頃
MTにセキュリティアップデートが登場しているようで。
- [重要] Movable Type 5.1 および、5.05、4.29 セキュリティーアップデートの提供を開始 (www.movabletype.jp)
Movable Type 5.04 および 4.28 を含む以前のバージョンでは、アプリケーション上の入力項目の一部において、適切に入力エスケープ処理されないため、クロスサイトスクリプティング(XSS)および クロスサイトリクエストフォージェリ(CSRF)が発生する可能性があります。Movable Type 4 および Movable Type 5 のすべてのバージョンの、修正版へのアップグレードを強く推奨します。
以上、セキュリティアップデートの概要 より
例によって詳細が良く分かりませんが、CSRFは結構まずい可能性がありますね。このCSRFで何ができるのかが分からないのですが、内容によっては最優先で対応する必要があるかもしれません。
しかし、例によって詳細が良く分かりません。利用の方法も様々ですから、場合によってはコストをかけてまでアップデートする必要はない可能性もありますが、詳しいことが分からないと影響もよく分からないですね。
関連する話題: セキュリティ / Movable Type
原発労働記
公開: 2011年5月29日22時5分頃
読み終わったので。
- 原発労働記 (www.amazon.co.jp)
1979年に単行本、1984年に文庫で出版された「原発ジプシー」を復刊したもの。1978年9月から翌4月までにかけて美浜原発、福島第一原発、敦賀原発で日雇いの下請労働者として働いた、その経験を手記のような形で記したドキュメンタリーです。
下請労働者の現場目線で書かれているので、内容は非常に興味深いです。記憶に残った部分を順不同にメモ。
- 「ネッコー」こと熱交換機のピンホール検査が実に原始的な方法で、被曝しなくても粉塵がひどい。
- 「高圧給水加熱器」のピンホール検査を実施しているとき、これはどういう働きをするものなのか、という質問に現場の人は誰も答えられない。
- 黒煙が上がるのはNGだが透明な煙ならOK。安全のために必要だから対応するのではなく、反対されると面倒だから仕方なく対応するという発想。
- マスクが息苦しいため、作業員はあっさりマスクを外してしまう。
- 放射線管理教育の内容は原発ごとにまちまち。原発の安全性については教えられるが、マスクの付け方などの本当に重要なことは教えてもらえない。
- 管理区域から工具を持ち出すのにも検査があり、汚染されたものは持ち出せない……ので、検査をスルーしてこっそり持ち出す。
- 健康診断で駄目な数値が出ても、頼むと結構何とかしてくれる (改竄してもらえる) 場合がある。
- アラームメーターの故障で大量に被曝してしまっても、基準内の数字を報告する。
- 敦賀原発では定期検査のたびに電源敷設作業が必要になる (設計上、定期検査用の電源が考慮されていない)。
- 東電社員専用の放射線測定器がある (下請は使用禁止)。
特に印象深かったのは、きっちり定められているはずのルールが、現場では無視される状況です。全面マスクをつけなさいと言われても、全面マスクは苦しく、作業が続くと「とてもやっていられない」と外してしまうような状況。JCO臨界事故では裏マニュアルが作られ、その裏マニュアルさえ無視されるという実態が明らかになりましたが、そのような体質はずっと昔からだったのでしょう。
しかも、これはあくまで定期検査時の話なのであって、事故時の話ではないのですよね。このお話で出てくる最大の線量は、毎時100ミリレム程度。シーベルト単位に直すと1mSv/hです。それに対して、現在の福島第一原発1号機で観測されている数字は2000mSv/h。桁が全く違います。定期検査でもこれだけ壮絶なのに、今回の事故ではどんな環境になっているのでしょうか。
2011年5月25日(水曜日)
ストレッチング採用の理由
更新: 2011年5月30日10時50分頃
徳丸さんに誘われ、徳丸本 (www.amazon.co.jp)レビュアー中心に6名ほどで飲み食いしながら四方山話をしたり。
翌日に徳丸さんはこんなつぶやきをしておられますが、
同じく昨日の一言。「パスワードのストレッチングについては効果を疑問視する声もあったが、『教科書』にベストプラクティスとして載っている以上、最低限そこまではやるべきと主張して、徳丸本の通りに実装することにした」<こういう声は嬉しいですね
これは私の発言ですね。せっかくなので、もう少し流れを補足しておきます。
サーバ側でパスワードを保存する際、パスワードそのものではなく、ハッシュ関数を通したハッシュ値を保存することが良く行われます。これによって、たとえDBの値が漏洩しても、生のパスワードが漏れることがなくなります。とはいえ、攻撃者はハッシュ値を作りながら総当たりをすることも可能ですし、事前にハッシュ値のデータベースを作っておいて攻撃するような手法もあります。
そこで考えられたのが、ハッシュ関数を何度も使った結果を保存するという手法です。こうすると、攻撃者がハッシュ値をつくりながら攻撃をするのに時間がかかるようになり、総当たりに必要な時間を増加させることができるようになります。この、ハッシュ関数を何度も使うことによって時間を稼ぐ方法を「ストレッチング」と呼んでいます。
※時間を稼ぐほかに、ハッシュ値生成のアルゴリズムが分かりにくくなるという効果も無くはないのですが、DBの値が漏れているような状況ではソースコードが漏れている可能性もありますし、攻撃者は自らアカウントを取得してハッシュ値がどうなるかを調べることもできます。アルゴリズムはばれている前提で考えるべきです。
さて、実は今、社内であるシステムを開発しているのですが、パスワードを保存する際の仕様ががっちりと決まっていなかったので、どうするのか議論になりました。ソルトをつけてハッシュ値を保存するところまでは良いとして、ストレッチングのような処理が本当に必要なのかどうか、というのが議論のポイントです。
セキュアプログラミングの要素の多くは、議論の余地無く採用されるものです。XSSやSQLインジェクションは単なるバグで、その対応はアプリケーションの正常動作ために必要です。CSRFへの対策も、その必要性は明らかです。
しかし、このストレッチングはアプリケーションの動作に必須のものではありません。DBの中身が漏洩する事故が起きて初めて意味を持ちますが、それにしても必要性がどの程度あるのか疑問です。長めのソルトをつけてハッシュしてやれば、それだけで十分なのではないかとも思えます。メリットがいまいち分かりにくい上に、平時はCPUパワーを浪費したり動作が遅くなったりするデメリットもあります。
※動作を遅くすることが目的なので、プログラミングの工夫で速くすることもできません。
というわけで、技術的にはメリットとデメリットの両方があって何ともいえず、採用するかどうか決められませんでした。にもかかわらず採用することに決めたのは、技術的な必要性というよりも、政治的な必要性があったからです。何かセキュリティ事故が起きて、「十分な対策を行っていたか?」と問われたときに、「よく知られた手法があるのに、それを採用していなかったではないか」と責められると厳しいでしょう。つまり、「有名書籍に肯定的に書かれている」ということ自体が採用の理由になっています。
※2011-05-30追記: ちょっと語弊があった気がするので補足しておきます。「技術的に不要だと判断したのに政治的な理由で無理矢理実装させられた」というネガティブな話ではなくて、単に「技術的には要・不要の決断ができなかったので、政治的な理由で決定に至った」ということです。本文も少し修正しました。
2011年5月22日(日曜日)
JUGEM管理画面、セッションID漏洩の問題を修正
公開: 2011年5月22日22時15分頃
こんなリリースが出ていますね……「【重要】管理者ページセキュリティの修正と強化に関しまして (info.jugem.jp)」。
この度、PHPSESSIDが付与された管理者ページURLから外部サイトにアクセスした場合、外部サイトのアクセス解析に残ったログから、お客様のブログ管理者ページに他の方がログイン出来た可能性が判明いたしました。
(~中略~)
【弊社で確認した発生する条件】
(1)ご利用のブラウザのプライバシー設定が規定値より高く設定されていた場合
(2)セキュリティソフト等でCookieがブロックされてしまった場合【第三者がログイン出来た条件】
上記(1)(2)のいずれかの条件を満たしたお客様が、JUGEM管理者ページ内から外部サイトへ遷移した場合に、その外部サイトのアクセス解析等にお客様の管理者ページにログイン出来るURLが表示されてしまう
Cookie無効環境でURLにセッションIDがついて、Refererから漏れるというシンプルなお話ですね。
PHPにはsession.use_trans_sid (www.php.net)とかsession.use_only_cookies (www.php.net)といった設定項目があって、これらの設定によっては、Cookie無効時にセッションIDをURLに埋め込むという「親切な」動作になります。
PCサイトの場合、Cookie有効を前提にしてしまってもほとんど問題ありませんので、単に設定を変えて、URLにセッションIDがつかないようにすれば良い話です。JUGEMではそのような対応をしたようですね。
※ただ、ドコモのフィーチャーフォン (いわゆるガラケー) でもアクセスしてほしいような場合、Cookie有効を前提にすることはできませんから、セッションIDつきのRefererが外に出ないような (やや面倒な) 対処が必要になってきます。
関連する話題: セキュリティ
2011年5月21日(土曜日)
So-netで不正アクセス
更新: 2011年5月22日20時30分頃
So-netで不正アクセスの被害が発生しているそうで。
- “なりすまし”による「ソネットポイント」の不正利用への対応について (www.so-net.ne.jp)
- So-net、ポイントサービスで不正利用発覚 第三者が会員なりすまし (www.itmedia.co.jp)
- ソニー系接続会社に不正アクセス ポイント10万円被害 (www.asahi.com)
「ソニー系接続会社」という表現は斬新……というか、そう言われてはじめてSo-netがソニー系だったということを思い出したような次第です。
ともあれSo-netの発表によると、不正アクセスの具合はこのような感じになっています。
- 特定 IPアドレスからの不正アクセス試行回数 : 約 10,000回
- 「ソネットポイント」の不正な交換に使用された ID数 : 128
- 「ソネットポイント」の不正な閲覧に使用された ID数 : 73
- 「ソネットポイント」にて不正な交換が行われたポイント数 : 105,500ポイント (約 10万円相当)
- 「Webメール」の不正な閲覧に使用された ID数 : 90
閲覧+交換のようなケースが重複してカウントされているのかどうかが良く分かりませんが、約1万回の試行が行われて、突破されたアカウントが128~291。パスワードを固定してアカウントの方を回していく、リバースブルートフォース攻撃でしょうか?
リバースブルートフォースだとすると、サービス側で対処するのはそれほど簡単ではありません。同一IPアドレスからの連続試行をブロックすることはできますが、踏み台を使われてIPアドレスを変えられると突破されてしまいます。
サービス側でできることは、パスワードに複雑性を求める (あまり単純なパスワードは使用できないようにする) というところです。このあたりの要件がどうなっていたのかが気になりますね。
※ただ、突破率がちょっと高いような気もするので、単なるブルートフォースではない可能性も考えられますが。
※追記: 春山さんから「so-netへの攻撃は, so-netには関係ないサービスでid/passのリストが漏れて, そのリストを利用したものじゃないかと推測しています
」というコメントをいただきました。十分にあり得ると思いますし、よりすっきり説明できますね。そして、仮にそうであれば、サービス側でできる対応は「パスワードを使い回さないでください」とアナウンスすることくらいしかないと思います……。
関連する話題: セキュリティ
2011年5月20日(金曜日)
屋上屋を架すJR大阪駅
公開: 2011年5月22日19時5分頃
こんな記事が……「JR大阪駅、古い屋根外せず 新装大屋根、雨吹き込む (www.asahi.com)」。
古い屋根の上に新しく大きな屋根を作って古い屋根を撤去、のはずが、雨が吹き込むため古い屋根が撤去できず。「屋上屋を架す」という言葉がありますが、それを地で行く状態になっていて面白いですね。
関連する話題: 思ったこと
雨の匂い
公開: 2011年5月22日15時20分頃
読み終わったので。
- 雨の匂い (www.amazon.co.jp)
雰囲気が独特で、暗いというか、退廃的というか、クールというか、全てが淡々と進みます。淡々と話が進んで、淡々と人が死んで、淡々と終わる感じ。
人が殺されたりしていても淡々とスルーされてしまうのが凄いと言えば凄いです。
2011年5月19日(木曜日)
ウェブ健康診断仕様アップデート
公開: 2011年5月22日14時20分頃
LASDECの「ウェブ健康診断仕様」がアップデートされたようです……「ウェブ健康診断仕様(改版)を一般公開しました(平成22年度実施事業) (www.lasdec.or.jp)」。大きく変わったのは以下の2点ですね。
- OSコマンドインジェクションの検査パターンが変更された
- クローラへの耐性試験が追加された
OSコマンドインジェクションは、以前は「ifconfig/ipconfigの結果が表示される」というものでしたが、「sleep/pingでレスポンスが遅くなる」というものに変更されました。サーバ内でコマンドが実行されていても結果が画面に表示されない場合があるため、このような形になったのでしょう。厳密に言うなら、サーバ内で別スレッドが作られて実行されているようなケースや、レスポンスを送り終わってハンドラをクローズしてから実行されているようなケースは確認できません。が、もともとそこまで厳密なものを意図していないでしょうから、これで十分でしょう。
クローラへの耐性試験は、レスポンスが返ってから0.5秒待って次のアクセスをするというシリアルアクセスを実行してみて、障害が起きないかを見るものです。これは明らかに岡崎市立中央図書館事件 (librahack事件) を受けたものでしょう。ステータスコード400番台/500番台のレスポンスが5回以上連続するとNGなので、連続アクセスに意図的に503を返すような実装だと報告されてしまいますね。まあ、もともとそこまで厳密なものを意図していないでしょうから、これで十分でしょう。
関連する話題: セキュリティ / 岡崎市立中央図書館事件 / librahack
2011年5月18日(水曜日)
シャットダウン事件と発見者の責任
公開: 2011年5月22日13時50分頃
こんなお話が。
- 巫女SE、脆弱性のあるサービスを独断で停止し、あわや警察沙汰に (slashdot.jp)」。
- 巫女テスター(17歳)、システムの致命的な欠陥を発見しサーバーごとシステムをシャットダウンした一部始終 (togetter.com)
- 巫女テスター(17歳)、欠陥システムをサーバーごとシャットダウンするに至った顛末とその後のお話 (togetter.com)
とあるシステムを見ていたら「パスワード再発行フォームのメールアドレス入力画面にSQLを仕込むと全ユーザーの情報を引き出したり
」といった致命的な脆弱性を発見してしまい、そして……本番環境を動かないようにしてシャットダウン。その後は警察を呼ばれそうになりつつも、クライアントの理解が得られて最悪の結果は回避できたようで。まとめには出ていませんが、「課長と部長に報告したし、埒があかないから更に上に話させてくれと再三掛け合って駄目だった結果がアレ
」という事情もあったようですね。
一歩間違えば大変な事件になっていた可能性がありますが、結果的には丸く収まって良かった、運が良かった、というところでしょうか。
脆弱性にもいろいろありますが、これは簡単に能動的に攻撃でき、かつ被害も大きいタイプのものでしょう。そういうタイプの脆弱性を発見したら、「今にも攻撃されて被害が出るかもしれない」「とにかく早く対応しなければ」と思ってしまうわけで、報告しても対応してもらえないと分かったら……そういう状況で冷静でいるのは、それほど簡単なことではないと思います。発見者が責任感の強い人であれば、なおさらです。
しかし、サービスの安全性や情報の管理の責任を負うのは、あくまでサービス運営者です。事故が起きたときに賠償の責任を負うのも、サービス運営者です。そのサービス運営者が「情報が漏洩するかもしれないが、それでも良い」と判断したならば――発見者はその判断はまずいと意見するでしょうが、それでもその判断を固持したなら――その判断は尊重すべきだと、私は考えます。
あえて語弊のある言い方をすれば、「サービス利用者が被害を受けても、それは運営者の責任で、私は知らない」ということでもありますが、私はそれで良いと考えています。世の中には「脆弱性を知った者はサービス利用者を守る責任がある」などと考える人もいるようですが、私はそうは思いません。
脆弱性に関わる立場の人は、強すぎる正義感や責任感が不幸を生むこともある、ということを頭の片隅に置いておくようにした方が良いと思います。
※追記: 「発見者はサービス利用者の立場を代弁するべきではない」という記述がありましたが、高木さんのからご指摘 (twitter.com)をいただきました。確かにこの部分は妥当でないと思いましたので、その部分は撤回します。
2011年5月13日(金曜日)
魔法少女かずみ☆マギカ 1
公開: 2011年5月21日11時40分頃
読み終わったので。
- 魔法少女かずみ☆マギカ 1 (www.amazon.co.jp)
まどか☆マギカ (www.amazon.co.jp)関連作品。ソウルジェム、魔女などの設定は共通していますが、登場人物は (今のところ) 共通していないので、同じ世界の全く別の場所の物語という感じですね。話はどたばたコメディータッチで、魔法少女ものの王道に近い感じになっています (今のところは)。
※ただ、無意味に露出度が高かったり、いきなり全裸だったりするので、その辺りはちょっと注意。
面白くないわけではないのですが、まだいろいろ良く分からない感じです。今のところ記憶喪失の設定も生かされていませんし。今後に期待したいところです。
関連する話題: マンガ / 買い物 / 魔法少女まどか☆マギカ
Web&モバイルマーケティングEXPO 3日目 / WebARENA CLOUD9 のお話
公開: 2011年5月15日2時10分頃
NTTPCコミュニケーションズのWebARENA CLOUD9 (web.arena.ne.jp)というサービスで5月8日から障害が続いていて、復旧予定が未定になっているという話が出ています。セキュリティホールmemoを見ていたら、こんなお話が。
NTTPC コミュニケーションズは、5/13 まで開催されている第2回クラウド コンピューティングEXPO春に出展しているから、そこで状況を聞いてみるのも一興かと。
以上、セキュリティホールmemo より
都合の良いことに、私は今日もEXPOに行くお仕事があり、NTTPCコミュニケーションズのブースで話を聞いておきたい別件もありました。というわけで、仕事の隙を見て行ってみることに。
ブースには共用レンタルサーバやVPSのパンフレットはあったものの、問題の「CLOUD9」については何も展示されていませんでした。メインの展示は中小企業向けのBCP (事業継続計画) を支援するソリューションで、VPCで在宅勤務が可能になったりする話のようです。
その話や、聞きたかった別件を一通り聞いた後、「クラウド系のサービスはないんですか?」と質問してみると、「CLOUD9というサービスがあり、それは別のブースで説明している」という旨のことを教えていただきました。
※このタイミングでは障害のことには何ら言及されず。CLOUD9とはあまり関係ない部署の方だったのかもしれません。
教えていただいたブースへ行って、CLOUD9の事を聞いてみると、「このたびは大変ご迷惑をおかけしており申し訳ありません」と、いきなり謝罪のお言葉が。べつにユーザじゃないので謝っていただかなくても……と思いつつ、いろいろ話を聞かせていただきました。
私が教えていただいたのは、だいたい以下のような感じです。
- WebARENA CLOUD9は、VerioのサービスがOEM提供されているもの。NTTPCコミュニケーションズは、OEM供給を受けて販売する立場。
- サーバは日本国内に置いてあり、サービス提供者であるVerioが海外からリモートアクセスでメンテナンスしている。
- 障害の内容は、ディスクアクセスの大幅な遅延が起きるというもの。シェルのプロンプトが出ている状態で、何も入力せずにEnterを押すと、次のプロンプトが出るまで5秒待たされる。
海外からのOEM提供というのはなかなか興味深いです。いろいろと大変そうですね。
※Verioのことは「コンセプト - WebARENA CLOUD9 (web.arena.ne.jp)」に書かれていますし、ディスクアクセスの遅延が起きていることは「新規お申し込み受付の一時停止について (web.arena.ne.jp)」に書かれていますので、内緒の話というわけでもないようです。
関連する話題: Web / Web&モバイルマーケティングEXPO / クラウド
2011年5月12日(木曜日)
魔法少女おりこ☆マギカ 1
公開: 2011年5月14日23時30分頃
今日もEXPOで立ちっぱなしのお仕事ですが、出動前にひっそりと購入。
- 魔法少女おりこ☆マギカ 1 (www.amazon.co.jp)
まどか☆マギカ (www.amazon.co.jp)のスピンオフ作品。表紙には3人の人物が描かれていますが、そのうち2人は杏子とマミさんです。見ての通り、ひだまり風味はカケラもないので、本編とはかなり印象が違います。
話は……1巻の時点では、ストーリーの流れはまだ良く分からないですね。そもそも、誰が主人公なのか良く分からない感じ。
マミさんがお菓子の魔女に勝っていて、ほむらがマミに「私達に接触しないで」と言っているので、本編4周目の出来事のように思えますが。
関連する話題: マンガ / 買い物 / 魔法少女まどか☆マギカ
2011年5月11日(水曜日)
Web&モバイルマーケティングEXPO 1日目
公開: 2011年5月14日23時10分頃
「Web&モバイルマーケティングEXPO (www.web-mo.jp)」のため、朝から東京ビッグサイトへ。ブースの裏でずっと控えているというひたすら地味なお仕事だったのですが、そのついでにいろいろ回ってみました。
以下、話を聞いたりしたところ。他にもあったと思いますが、印象に残ったところだけ。
- ジャストシステム / GDMS (www.justsystems.com)
- シフト (www.shiftinc.jp)
- B.CORE / colorbit (www.colorbit.jp)
- ブログウォッチャー (www.blogwatcher.co.jp)
- インテル (www.intel.com)
あとは気付いたことなど。
- 節電のソリューションが多数。インテルブースでも「CPUを高速にすると結果的に省電力になる」という形でデモを行っていました。また、LED電球が当たるなど、省電力グッズも人気でした。
- IPA/SEC (sec.ipa.go.jp)とIPA/ISEC (www.ipa.go.jp)は両方ともブースを出していましたが、規模が全く違っていて切なくなりました。
- 巫女さんがいたので何事かと思ったら、占いのASPサービスらしいです。
- IIJブースの赤ずきんが可愛いです。
関連する話題: Web / Web&モバイルマーケティングEXPO
2011年5月10日(火曜日)
有限責任と巨大事故リスク
公開: 2011年5月14日18時40分頃
こんな記事が……「お金は正直、反原発運動家は嘘つき (news.livedoor.com)」。
本当に反原発運動家がいうほど浜岡原発が危険ならば、事故の確率が減るのだから株価が上がってもいいようなものです。東京電力の株価は5分の1になり、福島原発の賠償問題は未だに先が見えないのに。そういった東京電力の窮状を見れば、中部電力が抱える唯一の原発サイトが全面停止されるのだから、株主にとってそれほど悪い話ではないじゃないですか。
これにはハッとさせられました。
株式会社では、株主は出資額以上のリスクを負うことはないというルールがあります。最悪の場合には出資したお金が全く戻らなくなりますが、それ以上の賠償や補償の責任を取らされることはありません。責任の範囲が限られているという意味で、これを「有限責任」と言います。
※会社によっては社名の英語表記に "Co., Ltd." とつくことがありますが、これは "Company, Limited" の略で、有限責任の会社という意味です。
会社の資産では賄いきれないような事故が起きても、株主は有限責任です。事故の規模が一定以上になれば、どんなにひどい事故であってもリスクは同じです。株主が利潤を最大化しようとするなら、「希に起きる巨大事故を回避するためにコストをかける」という施策にはメリットがありません。中部電力の株主が原発の停止に反対するのは、合理的な行動です。
別の見方をすると、有限責任のルール自体が巨大事故リスクの軽視につながる、とも言えます。このことがあまり問題視されていなかったのは、そもそも、民間の会社がそこまで巨大な事故を起こすということが考えられなかったからでしょう。
あるいは、原子力のような事業を民間で行うこと自体を制限して行く必要があるのかもしれません。本来それは原子力安全・保安院の「指導」で達成されるべきものなのかもしれませんが……。
原発停止のリスク
公開: 2011年5月14日17時5分頃
「電力不足、全国的な問題に 浜岡原発停止で融通厳しく (www.asahi.com)」。
定期検査に入った原発は東日本大震災後、まだ全国で1基も運転を再開していない。福井県内に11基の原発を持つ関電は、3基が定期検査で停止中。さらに3基が定検に入る。幹部は「再稼働できないと関電も厳しい」と打ち明ける。
これはまずいですね。電力が不足するとまずいのは当然ですが、「原発が停止すると電力が不足する」という状態そのものに問題があると思います。ある程度の地震が来ると原発は停止するようになっていますし、一度停止すると、すぐには運転再開できません。
たとえば、2009年8月11日の静岡沖地震では、御前崎市で震度6弱の揺れがあり、浜岡原発は全機停止しています。その後の流れは以下のとおりです。
- 2009年8月11日 午前5時7分頃に地震が発生、浜岡原発4号機、5号機が自動停止 (3号機は点検中、1,2号機は廃炉に向けて停止していた)。冷温停止に向けた運転操作を開始。「地震発生後の浜岡原子力発電所の状況について(午前7時00分現在) (www.chuden.co.jp)」
- 2009年8月11日 午後6時10分、4号機が冷温停止。2009年8月12日午前2時17分、5号機が冷温停止。「地震発生後の浜岡原子力発電所の状況について(続報) (午後3時00分現在) (www.chuden.co.jp)」
- 2009年9月15日 4号機の点検と調整が完了。 「浜岡原子力発電所4号機の調整運転の再開について (www.chuden.co.jp)」
- 2009年9月17日 4号機の調整運転開始。 「浜岡原子力発電所4号機の発電再開について (www.chuden.co.jp)」
- 2009年10月16日 4号機の営業運転開始。 「浜岡原子力発電所4号機の営業運転再開について (www.chuden.co.jp)」
- 2009年12月15日 5号機の停止期間延長を発表。 「浜岡原子力発電所5号機の停止期間の延長および定期検査の実施について (www.chuden.co.jp)」
- 2010年3月12日 5号機はそのまま定期検査に突入。浜岡原子力発電所5号機の定期検査について (www.chuden.co.jp)
- 2011年1月25日 5号機は調整運転を開始。浜岡原子力発電所5号機の原子炉起動について (www.chuden.co.jp)
- 2011年2月23日 5号機は営業運転を開始。浜岡原子力発電所5号機の営業運転再開について (www.chuden.co.jp)
4号機は比較的早く復旧しましたが、それでも調整運転まで1ヶ月、営業運転まで2ヶ月かかっています。5号機のほうは1年以上止まっていたことになります (2006年に壊れたタービンの交換もしていたようで、地震の影響だけではないようですが)。
地震で原発が停止し、それがしばらく続くという状況は過去に何度も起きています。これは予想外でもなんでもありませんから、個々の電力会社では、管内の原発が全て止まっても問題ないようにしてあるはずです。しかし今回は、震災による「融通」の分が厳しいということなのでしょう。節電を頑張って行くしかないでしょうね。
2011年5月7日(土曜日)
かけ算、割り算、係数の優先順位
公開: 2011年5月8日17時20分頃
こんな記事が……「「6÷2(1+2)=?」という小学生レベルの問題? 大勢の人が「1」と答え半分以上が不正解 (getnews.jp)」。ふつうに1で正解だと思ったのですが、正解はこうらしいです。
<正解>
6÷2(1+2)=
6÷2(3)=
3(3)=
3×3=9
つまり (6÷2)(1+2) とみなすらしいのですが、本当にそうなのでしょうか。
括弧の前の2は単なるかけ算ではなく、後ろの括弧全体にかかる係数として書かれているように見えます。問題では括弧の中身が数字だけなので違和感がありますが、a = 1 と置くと、これは 6÷2(a+2) という式になります。これはやっぱり 6÷(2a+4) と計算するのではないでしょうか。a=1 を代入すると答えは 1 になります。
答えが9となるような計算順位を意図するなら、式を (6÷2)(a+2) と書くのが普通であるようにも思います。この書き方は自然です。逆に、答えが1になる事を意図した場合に 6÷(2(a+2)) という書き方をしなければならないとなると、この書き方はかなり不自然であるように感じます。
ということで、問題のような式の書き方をするのであれば、答えは 1 として良いのではないかと思うのですが、どうなのでしょうね。
2011年5月6日(金曜日)
浜岡原発停止要求までの流れ
公開: 2011年5月8日16時25分頃
浜岡原発停止の話で盛り上がっていますね。ここに至るまでの流れを確認してみると、以下のようになります。
- 2011年3月30日: 原子力安全・保安院から各電力会社に対し、「平成23年福島第一・第二原子力発電所事故を踏まえた他の発電所の緊急安全対策の実施について(指示) (www.meti.go.jp)」という文書が出される。
- 2011年3月30日: 同日、中部電力はそれを受領。「福島第一、第二原子力発電所事故を踏まえた緊急安全対策の実施について (www.chuden.co.jp)」というプレスリリースで、
「当社は、この指示文書を真摯に受け止めるとともに、今後、適切に対応してまいります。また、この対応内容につきましても地域のみなさまにしっかりとご説明してまいります。」
と発表。 - 2011年4月20日: 中部電力から安全対策の報告。「浜岡原子力発電所における緊急安全対策について(経済産業大臣からの指示に対する報告) (www.chuden.co.jp)」
- 2011年4月20日: 原子力安全・保安院は報告を受け取る。「緊急安全対策に係る報告書(中部電力株式会社浜岡原子力発電所、日本原子力研究開発機構高速増殖原型炉もんじゅ)の受理について (www.nisa.meti.go.jp)」
- 2011年5月6日: 原子力安全・保安院から浜岡原発の運転停止を求める旨の発表。「浜岡原子力発電所の津波に対する防護対策の確実な実施とそれまでの間の運転の停止について (www.meti.go.jp)」
5月6日には首相が記者会見をしているようですが、中部電力への文書は経済産業大臣の名前で出されていて、原子力安全・保安院からの要求という形になっています。内容は以下の通りです。
平成23年3月30日に貴社に対し緊急安全対策の実施を指示し、その実施状況に関する報告を受け、その内容を確認した結果、適切に措置されているものと評価します。
しかしながら、浜岡原子力発電所については、想定東海地震の震源域に近接して立地しており、文部科学省の地震調査研究推進本部の評価によれば、30年以内にマグニチュード8程度の想定東海地震が発生する可能性が87%と極めて切迫しているとされており、大規模な津波の襲来の可能性が高いことが懸念されることから、貴社の報告にある津波に対する防護対策及び海水ポンプの予備品の確保と空冷式非常用発電機等の設置についても確実に講ずることを求めます。
また、これらの対策が完了し、原子力安全・保安院の評価・確認を得るまでの間は浜岡原子力発電所の全ての号機について、運転を停止するよう求めます。
流れとしては、3月30日の指示に対して4月20日に中部電力からの対策案を受けとり、5月6日に、その対策案に対する返答として「対策は適切だが対策が終わるまで運転を止めるように」という要求を出したという形です。法的拘束力はないのかもしれませんが、中部電力としては「真摯に受け止める」とした指示への対応に駄目出しされた形になりますので、これはスルーしづらいでしょうね。
関連する話題: 原子力
端末の耐タンパ性とネットワークセキュリティ
更新: 2011年5月8日17時25分頃
「サーバーとの通信を2重暗号化するなどの対策が急務 (pc.nikkeibp.co.jp)」。
SSLは盗聴では解読は困難ですが、MIM(Man In the Middle:中間者攻撃)を行えば、通信の内容は平文で取り出すことが可能です。
(~中略~)
これまでネット家電やゲーム機では「外部からの攻撃」に対して対策が取られていました。また、ネット家電やゲーム機が直接侵入されたり踏み台にされたりしないような対策ということが論じられてきました。しかし、サーバーとの通信を密に行うようなケースでは、サーバーとの通信の2重の暗号化などの総合的な対策が必要とされます。
これはちょっとわかりにくい記事だと思いました。
まず、普通の利用者が普通に利用する際に中間者攻撃が問題になることはないはずです。サーバ証明書を検証することによって中間者攻撃を防ぐ仕組みがありますので、普通の利用者は中間者攻撃を恐れる必要はありません (PS3 (www.amazon.co.jp)自体に脆弱性がなければの話ですが)。
利用者が意図的に自身のPS3を改造して証明書を入れ替えたり、証明書検証を無効にしたりすれば、中間者攻撃が可能になります。これは、攻撃者が自身のPS3を解析するための手法として利用できます。
普通のPCの場合、そんなことをしなくても自由にプログラムを動かして解析できますが、ゲーム機の場合は解析が難しくされていることがあります。これはいわゆる「ハック」であったり、不正コピーしたゲームソフトを動かしたり、といった行為への対策です。このような、解析や改造をされにくい性質のことを「耐タンパ性」(tamper registance) と言ったりします。
端末の耐タンパ性とネットワークのセキュリティには、直接の関係はありません。もとより、ネットワーク機器の側では、端末の耐タンパ性をあてにしてはなりません。解析で攻撃のヒントが得られることはありえますが、今回の情報漏洩事件は、「機器を解析されて……」というような高度な攻撃ではなく、単にアプリケーションサーバの既知の脆弱性が突かれたという話になっています。
※PSNの通信先のサーバが解析で割り出された可能性はあるのかもしれませんが、SSL/TLSでもパケットの送り先やポートは普通に見えます。通信先を割り出すだけなら、中間者攻撃をするまでもありません。
「2重の暗号化」というのも、機器の耐タンパ性を高めるための施策でしょう。漏洩事件と直接の関係はないでしょうし、急務というほどでもないと思います。
関連する話題: セキュリティ / PlayStation Network / 情報漏洩
2011年5月5日(木曜日)
魔法少女まどか☆マギカ スペシャルCD
公開: 2011年5月5日22時40分頃
魔法少女まどか☆マギカ 1 完全生産限定版 (www.amazon.co.jp)には、特典のスペシャルCDがついてきます。せっかくなので聴いてみたいと思ったのですが、なんと恐ろしいことに手元にCDが読めるドライブが無く、PCに取り込めないのでした。
※厳密に言うとIDE接続のDVDドライブはあるのですが、つなげるの面倒すぎで。
というわけで、PS3 (www.amazon.co.jp)PS3でリッピングを試みてみました。CDを入れると「ミュージック」の中に出現するので、選択すると「取り込み」というメニューがあって普通にリッピングできます。リッピングしたデータを選択すると「コピー」というメニューが選択できるので、USBメモリを挿してコピーしてやればOK。
……なのですが、PCに移してみたら拡張子.3gpのデータになっていて、Windows Media Playerでは再生できずに残念な思いをする羽目に。Quick Timeをインストールすれば良いのでしょうが、インストールするソフトウェアはできるだけ少なくしておきたいところです。
というわけでPS3に戻り、「設定」メニューでコーデックをAACからmp3に変更。この状態でリッピングしてみたところ、問題なく.mp3のデータを取り込むことができました。
特典CDの中身は、まどかキャラクターソング「また あした」とカラオケバージョン、それとドラマCDです。「また あした」は本編エンディングと違って2番まで収録されているフルバージョンなのですが、2番の後半がブックレット記載の歌詞とだいぶ違っています。これがブックレットが交換対象になっている理由ですね。
ドラマCDのほうは10話の冒頭部分の話で、放送を見ていない人には激しくネタバレ、というか意味不明な可能性がある諸刃の剣。しかしまどかの契約の内容が明らかになったりするので、10話を見ていれば聴く価値は高いですね。
関連する話題: 買い物 / 魔法少女まどか☆マギカ
2011年5月2日(月曜日)
コンテント・ネゴシエーションのわかりにくさ
公開: 2011年5月5日22時40分頃
本日、bAサイト (www.b-architects.com)を更新しました。コンテンツは全く変わっていないのですが、Accept-Languageによるコンテント・ネゴシエーションが行われなくなっています。
bAサイトは昔からコンテント・ネゴシエーションを実装していて、ブラウザのAccept-Languageがjaならば日本語のコンテンツを、enなら英語のコンテンツを、どちらでもなければ406 Not Acceptableを返すようになっていました。
その状態で10年ほど運用されてきたわけですが、しばしば以下のようなお問い合わせが。
- 日本語を使う人が海外からbAサイトを見ようとすると英語になってしまい、日本語のコンテンツを見る方法が分からない
- 英語を使う人が国内からbAサイトを見ようとすると日本語になってしまい、英語のコンテンツを見る方法が分からない
- 中国やその他の国からアクセスしようとすると、エラーになって見られない
いずれも、ブラウザの言語設定を変更すれば見られるようになるのですが、ブラウザの言語設定の変更方法自体がマイナーなのでしょう。特に悲しいのは最後の話で、406 Not Acceptableの画面にはブラウザの設定方法なども載せていたのに、読んでもらえなかったようなのですね。何かエラーっぽい画面が出ると「エラーが出た」とだけ認識して思考停止してしまうというのは良くある話です。
コンテント・ネゴシエーションによる言語切り替えは技術的には問題ないのですが、使う人の側、特にブラウザのインターフェイスの対応が今ひとつなので、あまり使いやすいものではないという結論に至りました。問題は「切り替え方が分かりにくい」という点なので、コンテント・ネゴシエーションを使いつつ切り替え機能を提供するという選択肢もあるのですが、それはそれで複雑だったりURLが分かりにくくなったりしますし、なかなか難しいところです。
関連する話題: Web
PSNへの攻撃、既知の脆弱性を利用
公開: 2011年5月4日21時5分頃
PSNの件、記者会見でいろいろ発表されたようですね。
- 「正常な動作として侵入、検知できなかった」──ソニー・平井副社長会見 (www.itmedia.co.jp)
気になるのは攻撃の方法ですが、それについては以下のように述べられています。
──4月19日に問題を把握したというが、数日間なぜ気がつかなかった
長谷島業務執行役員「検知できなかったのは、脆弱性をつかれたためだ。データセンターそのものの堅牢性を確保しないといけない」
(~中略~)
──今回、アプリケーションサーバーの脆弱性を狙われたということだが、セキュリティソフトをどうすり抜けたのか
平井副社長「正常な動作として入ってきて、出て行ったので検知できなかった。従来の仕組みでは追跡もできなかった。さらに、強固なセキュリティシステムを導入を検討し、すでに一部導入している」
最近では、複数の手法も組み合わせて組織の内側から崩してくるというような、高度な攻撃手法も見られます。たとえばStuxnetなどがそうで、2011年版10大脅威 (www.ipa.go.jp)でも第5位に挙げて注意を促しています。
しかし、ソニーのこれはそういう高度な話ではなくて、単に既知の脆弱性を突かれたということのようです。ミドルウェアの脆弱性が放置されていた、というようなところでしょうか。ちょっと拍子抜けではありますが、それなりに大きな組織でも脆弱性を放置してしまっているケースはかなりあるので、他人事だと思わずに注意することが必要なのではないかと思います。
関連する話題: セキュリティ / PlayStation Network / 情報漏洩
魔法少女まどか☆マギカ ブルーレイディスク 1巻
公開: 2011年5月4日13時15分頃
ちょっと仕事で、とある機器でブルーレイを再生した際のユーザーインターフェイスを見たかったのですが、ブルーレイディスクを持っていなかったので購入してみました。
- 魔法少女まどか☆マギカ 1 完全生産限定版 (www.amazon.co.jp)
会社でいろいろ検証しつつ視聴してみましたが、あらためて1話を見直すと大きな感慨がありますね。特に、10話を見てからほむらの登場シーンを見ると、非常に新鮮な印象があります。
実は本当に内容が変わっている部分もありますね。オープニングの絵が描き直されていたり、エンディングがオリジナルだったりする他、マミさんの部屋や学校の屋上なんかは大幅に変わっています。他にも描き直されている部分が結構あるようです。全体的にクオリティが上がっているのですが、とはいえ全部描き直されたわけでもないようで、逆に作画が荒いところが気になったりもします。私が気になったのは以下の2点。
- 1話のほむらの自己紹介時、よく見るとまどかの後ろの生徒が入れ替わるという現象が発生しています。
- 1話の喫茶店のシーンで、さやかは飲み物を飲んでいるのに最後まで全く減っていません (むしろちょっと増えているように見える)。
あと、2話の音声は噂の残念バージョンで、魔法少女の説明の際にマミさんが同じ事を2回言うのを確認できます。これは公式に認められている不具合で、製品交換の案内が出ています (4/27新譜BD・DVD『魔法少女まどか☆マギカ 1』本編ディスクおよびブックレットの一部内容に関するお詫び (www.madoka-magica.com))。
おそらく映像だけでなく音声も再編集していて、その際にミスが起きたということなのでしょう。ただ、編集しているわりには音声が映像と合っていない部分があったりして気になりました。音声で私が気になったのは以下の2点。
- 2話でさやかが屋上のフェンスを掴むシーン。BD版ではフェンスは太く頑丈そうな質感なのに、まるで金網を掴んだときのような音がして違和感があります。放送時の映像では金網だったのでしょう。
- 2話の上条の入院シーン。オーディオコメンタリーでは「上条君って白髪でしたっけ?」というような話が出るのですが、BD版の映像ではシルエットになっていて髪の色が分かりません。これは放送時は白髪に描かれていて、その映像を見ながら収録していたのでしょう。
まあ、オーディオコメンタリーはどうしようもない感じがしますし、仕様だと言われれば仕様として受け入れられる範囲ではあります。マミさんの台詞の編集ミスは致命的ですが、そこを除けば全体的なクオリティは悪くないと思いました。繰り返し視聴に向いている作品でもあると思いますので、買って損はないかなと。
※あと、2話のオーディオコメンタリーではキャラクターデザインの蒼樹うめ氏がゲストになっていて、興味深い話が聞けたりします。
関連する話題: 買い物 / BD / 魔法少女まどか☆マギカ
- 前(古い): 2011年4月のえび日記
- 次(新しい): 2011年6月のえび日記