最近一週間ほどのえび日記
2010年2月28日(日曜日)
美味しんぼ 104
公開: 2010年3月7日13時15分頃
出ていたので。
- 美味しんぼ 104 (www.amazon.co.jp)
海原雄山は、激怒すると大声を上げたり杖で殴ったり小鉢を投げつけたりする人だったはずなのですが、ずいぶん大人しくなったものですね。
環境問題特集ということですが、議論されているのはだいたいこんな感じ。
至高のメニュー: ダムの問題
- ダムを造ると上流に砂が貯まる。上流では川底が上がって洪水が起きやすくなる、岩がシルトに覆われて苔が生えなくなる。海に砂が流れて行かないので砂浜が痩せ、消波ブロックを設置せざるを得なくなる。
- ダムによって、川を遡上するような魚が大ダメージ。魚道を利用できる魚はごくわずか。
- 洪水対策としては、ダムより堤防のほうが良いのではないか。
ダムより堤防を……という提案なのですが、ダムをやめて堤防にした場合のデメリットについては何の議論もなく、海原雄山の主張が妥当なのかどうか良く分かりません。
至高のメニュー: 築地市場移転問題
- 土壌と地下水が汚染されている?
……正直なところ、築地については環境問題としての論点が良く分かりませんでした。そもそも、市場では地下水を使用しない想定ですし、土壌汚染・地下水汚染が食品にどう影響してくるかについては論じられていません。「都が情報を隠していたりして信用できない」「そもそも取引量が減っているので移転自体不要であり、お金の無駄」という議論も出ていますが、それは環境問題とは別の論点であるように思います。
結局、「汚染された場所に建てるのは心理的な抵抗感がある」という話のようにしか思えませんでした。海原雄山は怒りもあらわに「あれほど甚だしく汚染された土壌の上に……建設するべきではない、という意見は学者の良心から出てこなかったのか」と言っていますが、むしろ学者に同情したくなります。
究極のメニュー: 河口堰の問題
- シジミがほぼ全滅。
- 大型のアユやサツキマスが川を下れなくなって大ダメージ。
- ゲート上げ下げの運用が適切に行われていないのではないか。
せめてゲートの上げ下げをもう少しきちんと、という提案ですね。
究極のメニュー: 核燃料再処理場の問題
- 通常運用時の排気・廃液などによる放射線量は0.022Sv程度であり、日本での自然環境の放射線量1.48Svと比較すると、ほとんど影響がないと言える。事故さえなければ問題はなく、むしろ心配なのは風評被害。
- それよりも、高レベル放射性廃棄物の処分をどうするかが問題。地質が悪く地下水の多い日本で最終処分場が作れるのか。
通常運用時の放射線は問題ないと明言。むしろ問題なのは高レベル放射性廃棄物をどうするかで、これは再処理云々ではなく原発自体の問題ということですね。
……こうして見ると、海原雄山は糾弾の論調は強いものの背景の議論がボロボロで、なんか明らかにダメなような気がするのですが、気のせいでしょうか……。
※あと、汚染の話をした直後に食べ物が出てきても、心理的にあんまりおいしそうに感じないという問題がありますね……。
- 「美味しんぼ 104」にコメントを書く
2010年2月27日(土曜日)
うぃずりず 4
公開: 2010年3月7日11時10分頃
4巻が出ていたので購入。
- うぃずりず 4 (www.amazon.co.jp)
そろそろ大詰め……なんですかね。A/Bパート進行の表現はちょっと面白かったです。
ゆゆ式2
公開: 2010年3月7日0時40分頃
2巻出ました!
- ゆゆ式 2 (www.amazon.co.jp)
ズヴョズドチュカ! ズヴョズドチュカ! ズヴョズドチュカが頭にこびりついて離れませんよ。
あと、「ピストルの握るところがタオル」というネタが面白かったですね。他にも、ゆずこのシュノーケルとか、縁の虫とかいろいろ。左右の柱の小ネタも味があって良いです。
428 ～封鎖された渋谷で～
公開: 2010年3月6日21時25分頃
購入。
- みんなのおすすめセレクション 428 ～封鎖された渋谷で～ (www.amazon.co.jp)
New スーパーマリオWii (www.amazon.co.jp)
※なんとなくファミスタ'87の「87年度版」というシールを思い出してしまいましたが。
ただ、しばらくの間ははみ出るほど忙しいので、プレイ時間が取れないかも。
2010年2月25日(木曜日)
脆弱性報告者の心構え
公開: 2010年3月6日21時5分頃
「正しい脆弱性報告のあり方 (d.hatena.ne.jp)」。
それでも修正対応のスピードを求めるのだとしたら、例えば世の中的にそういうの放置すればするほどヤバイじゃん、という思いがあるのかな？
この思いはありますね。中には攻撃に複雑な条件が必要な場合もありますが、ほとんどの場合、脆弱性は誰でもすぐに気付けて、誰でもすぐに攻撃可能なものです。どうしても「他の人が気付いて悪用するのではないか」という心配をしてしまうわけで、できるだけ早く対応して欲しいと思ってしまいます。
……ただ、「運営者に圧力をかけてまで素早い対応を求めるべき」とまで思うかどうかは、分かれるところでしょう。私は、脆弱性の修正はあくまで運営者が自身の判断で行うべき事で、外から圧力をかけてやらせるようなことではないと思っています。運営者が脆弱性の影響を正しく理解した上で「修正しない」と判断したのであれば、それはそれで尊重するべきでしょう (私がそのサイトを使い続けるかどうかは、また別の話ですが)。
以前も「脆弱性に関わる人の立場と目的」という話を少し書いたのですけれど、個人的には、脆弱性報告の際には以下の3点に気をつけるようにしています。
- 脆弱性を作った開発者や脆弱なサイトの運営者に対して、罰を与えようとしないこと。
- 野次馬を気にしないこと。野次馬の期待に応えようとしない。
- あくまで運営者の意思で修正が行われるようにすること。強迫や脅迫によって修正させることはしない。
これはあくまで私のポリシーなので、人によってはまた違うでしょう。そもそも「野次馬の期待に応えることだけが目的」という人がいても良いわけですし、その場合は私とは全く違う行動パターンになるはずです。
2010年2月24日(水曜日)
ガラパゴスに支えられる携帯サイトのセキュリティ
公開: 2010年3月6日14時20分頃
モバツイ (www.movatwi.jp)作者のえふしんさんが、こんなつぶやきを。
もろもろセキュリティのことまで考えると、携帯サイトはガラパゴス（国内で閉じてる）の方が良いんじゃないかなぁ。
携帯サイトは、閉じられた環境であることを前提として作られている場合があります。すなわち、以下のような前提です。
- 利用者が自由にHTTPリクエストをしたり、リクエストパラメータを改変することはできない
これはPCサイトでは全く通用しない話です。通常のインターネットからの接続では、telnetなどで好きなデータを送信できますので、通信内容はいくらでも改変できてしまいます。
PCサイトの場合は、それでも問題ありません。攻撃者はリクエストを改竄できますが、ターゲットになりすますためには、ターゲットの識別情報を入手する必要があります。PCサイトで標準的に使われる識別方法は、Cookieを発行することで端末(ブラウザ)を識別するという方法です。Cookieは発行したサイトにしか送出されないため、何らかの理由でCookieが漏れない限り、攻撃者はターゲットの識別情報を知ることができません。
※漏れる原因の一つがクロスサイトスクリプティング脆弱性です。
つまりPCサイトは、「リクエストは改竄され得るが、識別情報が漏れない」ということを前提とした設計になっています。
しかし、携帯サイトは違います。特に顕著なのは、勝手サイトにおける「かんたんログイン」の仕組みです。「かんたんログイン」はiモードIDなどの契約者固有IDを使用することで、ノーパスワードでのログインを実現するものです。
PCサイトのCookieが発行ドメインにしか送られないのに対し、契約者固有IDは全てのサイトに同一の値が送られます。つまり、最初から漏れているわけで、漏れないことを前提にした設計はできません。そのため通常、かんたんログインを使用する携帯サイトは、3キャリアのゲートウェイからのアクセスだけを通すようにしています。キャリアの提供する端末ではリクエストを改竄することが難しいため、リクエストが改竄されていないことが期待されます。
つまり携帯サイトは、「識別情報は漏れるが、リクエストは改竄されない」ということを前提とした設計になっているのです。携帯サイトは、リクエストが改竄されない世界でのみ生存することができる希少種で、そう考えると、ガラパゴスという言葉はピッタリなのかもれしません。
ところが最近、このガラパゴスの世界に、今までとは異なる「種」が発生しました。それがJavaScript対応端末です。JavaScript対応の端末は、XmlHttpRequestで任意のリクエストを送出したり、iframeを使って別サイトのコンテンツを読み取ったりする機能を持ちます。これが、docomo端末のDNS Rebindingなどの新たな問題につながっています。今のところ問題が公表されているのはdocomoだけですが、他社の端末にもJavaScriptやXmlHttpRequestに対応したものがあり、それらもやはり問題に直面しています。
これからも、そういった問題は表面化してくるでしょう。また、将来的には、JavaScript以外の新機能が出てくる可能性もあります。すぐには難しいでしょうが、将来的には、ガラパゴスでなくても生き残れるような方向に転換して行かざるを得ないのかもしれません。
……ちなみに別の話ですが、携帯サイトの場合、パスワードを入力するのが非常に面倒だという問題もあります。パスワード入力を頻繁に求めれば求めるほど、ユーザーは簡素で入力しやすいパスワードを設定しようとします。パスワードに頼る認証もなかなか難しく、悩みの種が尽きないところです。
2010年2月23日(火曜日)
管理画面を別ドメインに分ける
公開: 2010年3月6日13時0分頃
「XSSとセキュリティリスクと正しい脆弱性報告のあり方 (d.hatena.ne.jp)」という話が。
ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。
これは意外に理解されていない場合が多いような気がしています。「JVN#81490697 Movable Type におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」という問題がありましたが、製品開発者からは「管理画面にアクセスできる人はそもそも任意のスクリプトを書けるのだから、そういうもの」というような反論がありました。
これは、ある意味正しいと言えます。以下の条件のいずれかを満たす場合は問題にならないはずです。
- 管理画面と同じドメインにコンテンツがパプリッシュされている
- ユーザーが一人しかいない、もしくは管理者ユーザーしかいない (権限を制限していない)
個人が一人で使っているような場合は上記に該当するので、問題になりません。
しかし、Movable Typeは、PowerCMSとセットにしてCMSのように使うこともできます。社外のユーザーに直接コンテンツを編集してもらうため、権限を絞ったユーザーを作成することもあります。この場合、管理画面のドメインで任意のスクリプトが実行できてはまずいことになります。ですから、管理画面を別ドメインにしておくことが必須になるのですね。
というわけで、ある事象が個人ユーザーと企業ユーザーとで異なる評価になる場合は良くあります。Movable Typeは企業で使われていることもある、という認識をきちんと持って欲しいところです。
……あと後半ですが、こういう主張ですかね。
- 運営者に知り合いがいる場合、直接伝えると対応が早い
- 運営者に知り合いがいる場合、「ゼロデイを公開する」と言って強迫すると対応が早い
賛同できるかどうかはともかく、間違ってはいないと思います。ただし、運営者が知り合いでない場合については述べられていないので、その点は注意しましょう。
デバイスに依存するFlashコンテンツは新デバイスに対応できない
「iPadにFlashは来ない？ タッチスクリーンとFlashの根本的問題 (slashdot.jp)」。アクセシビリティやユーザビリティを専門としない人には、ちょっと分かりにくそうな話ですね。
既存のFlashサイトをそのまま設計通りに動作させるのは難しく、また表示することだけを実現してもユーザーにとっては満足度の高い実装とはならないとのことだ。
要するに、iPadでは既存のFlashコンテンツがロクに動かない可能性がある、という話です。……と、こう言われても、ぴんと来ない人が多いかもしれません。Flash Playerやオーサリング環境をどうにかすれば解決するのではないか、と疑問に思われる方もいそうですね。
たとえば、こんな感じのFlashコンテンツを見たことがないでしょうか。
- Flashコンテンツの中に、商品写真が横一列に並んでいる。商品をクリックするとリンク先に飛ぶ。
- 商品写真のリストはコンテンツの幅に収まりきらず、スクロールする。
- スクロールバーやスクロールのためのボタンはなく、マウスポインタを右の方に動かすと右のほうにスクロール、左の方に動かすと左にスクロールする。
仮にこれをiPadで再生できたとして……どうやってスクロールさせれば良いのでしょうね。
このケースは、キーボードでもスクロール操作できません。WCAG 2.0 Guideline 2.1 (www.w3.org)では、全ての機能がキーボードで操作できることを求めています。Webサイトのアクセシビリティ調査をしていると、残念なことに、キーボード操作できないFlashコンテンツがかなり多いということに気付かされます。
これはFlash自体の問題ではなく、Flashコンテンツを作る側のデザインの問題です。たとえば上記のケースでは、スクロールするためのボタンをつけるだけでキーボード操作可能になります。そうすれば自然と、iPadやそのほかの新しいデバイスでも操作可能になるでしょう。
世界中のFlashデザイナーがもう少しだけアクセシビリティを意識してくれれば、世界は違うものになるかもしれませんね。
※10年ほど前に書かれた「Flash: 99％有害 (www.usability.gr.jp)」という文章が思い起こされます。あるFlash作者は憤慨して、ヤコブを車で轢き殺すFlashゲームを作ったり……。
2010年2月22日(月曜日)
長く遊べすぎるゲームの功罪
「やり込み要素の危険性 (allabout.co.jp)」。ここで言う「やりこみ要素」は、クリア後などもずっと長く遊べるということを指しています。長く遊べるソフトは良いけれど、むやみに長くするとメーカー自身の首を絞めるのではないか、という指摘です。
これを読んで気がついたのですが、私、ドラクエ9 (www.amazon.co.jp)
欲しいソフトがなかったわけではないのです。スクウェア・エニックスのソフトだとサガ2 秘宝伝説 (www.amazon.co.jp)
ドラクエ9おそるべし。
攻撃者に脅迫されたら
こんな記事が: 突然の大規模DDoS攻撃! その時オンラインゲーム運営はどうする? とっても厳しいiPhoneアプリ、ソーシャルゲームの現実と、将来の展望 (game.watch.impress.co.jp)。オンライン麻雀ゲームの運営者が、「DDoS攻撃を行なう。止めて欲しければ、100万円支払え」と脅迫された……というお話ですが、興味深いと思ったのは顧客への対応。
そして顧客に対してはどうか。栢氏は、このような事由でサービスが提供できない場合、公開できることはできるだけユーザーに伝えることが重要だと語っている。攻撃を受けた経緯、現状、復旧の見込み、そして従業員がいかにその脅威に対抗しようとしているのか。洗いざらいユーザーに伝えることで、「当初はサーバーダウンについての批判メールがあったが、すぐに応援のメールが大量に届くようになった」という流れになった。
「洗いざらいユーザーに伝える」ことによって、ユーザーを味方にすることができたと。単に公開したのが良かったというよりく、コミュニケーションがうまかったという話だろうと思いますが、姿勢を明確にしてユーザーと向き合うことが大事なのではないかと思いますね。
関連する話題: セキュリティ
- 前(古い): 2010年2月19日(金曜日)のえび日記
![Dreamweaver プロフェッショナル・スタイル [CS3対応]](http://ecx.images-amazon.com/images/I/31YE7dzwWXL._SL75_.jpg)
