原因が分かった気がする。なんか腐ったDNSに当たって名前解決自体ができなくなっているっぽい。WILLCOM任せで自動で割り当てられたDNSサーバーの中に、おかしな情報を返してくるやつが混ざってない？　試しにDNSサーバーをWILLCOM任せにせずに、別プロバイダのDNSサーバーを使うように設定を変えてみたら、今のところ上記の症状が発生していない。

ちなみにそれに気づいたのは、その状態の時にIEで、かなり昔にサーバーを切り替えたサービスにアクセスしようとしたところ、もうキャッシュ期間もとっくに過ぎているはずなのに、切り替え前の古いサーバーにアクセスしにいったから。

昨日は福岡からオクサンが子供二人連れて帰ってくるのを空港まで迎えに行ったんだけど、地震の影響で飛行機が1時間ほど遅れ、さらに電車（京浜東北線）もぐだぐだになっていて、非常にぐったりと疲れる帰り道になった。行きの場合は飛行機の出発時間に遅れるわけにいかないから電車を使うのもありだろうけど、今度から帰りの迎えには必ず車で行くことを決意。あるいは、うちの近所で乗り捨てOKなレンタカーを空港で借りるってのが一番いい気もするな。今度調べておこう。

Webアプリ（Apacheモジュールで動作するphp＝httpd権限）とバッチ（コマンドラインアプリ）で共通に扱う（書き込み権限が必要な）データファイルがある場合、どのように取り扱うのが一番いいんだろう。

1. ファイルを作成するときに誰でも書き込み可にする
2. ファイルを作成するときにグループ書き込み可にして、httpdユーザーとコマンド実行ユーザーのグループをあわせる
3. コマンド実行ユーザーは、httpdユーザーにsudoしてコマンドを実行する
4. （シェル利用可能な）コマンド実行ユーザー=httpdユーザーにする
5. コマンドはrootで実行しちゃえ！

キャッシュとかは1だったんだけど、キャッシュ以外のファイルを扱う場合は3かなー。2はやったことないけど、うまく設計すれば使いやすいだろうか？　外部ライブラリに依存していて、データファイルの権限を（ライブラリの中をいじらないと）コントロールできない場合も3だろうな。4は危険すぎるんで却下と思いつつも、ユーザー権限を適切に絞れるならばそれもありか？　5は緊急避難用？

PEAR Log_mailが動かないんで、おかしいなーとずっと調べていて、ようやく原因を見つけた。Log 1.9.3ではLog::factoryが生成したオブジェクトのリファレンスを正しく返してくれていないんで、shutdown functionでflushするタイミングでメール送信しているLog_mailでは、shutdown functionがflushするインスタンスと、ログをためているインスタンスが異なるものになってしまって、メールが飛ばないんだった。明示的に$logger->flush();したらメールが飛んだんでようやく気がついた。bug report

不勉強なのでわからないのだけれど、何らかの理由で、はてなでは管理画面のドメイン変更がスクリプト制限に神経を遣うより高コストなのかな?

たいていのblogサービスではいわゆる管理機能のみでユーザー認証（のCookieによる継続）を利用しているけど、はてなの場合は「管理機能」だけではなく、一般ユーザーレベルの閲覧操作でも「ユーザー認証」されていることを活用し、SNS的な機能（閲覧ユーザー権限による分岐。たとえばプライベートモードとかはてなグループとか）を実現している。だからはてなでは、管理機能だけを別扱いにするだけでは、XSS（によるユーザー認証の乗っ取り）対策にはならない。はてなのSNS的な機能をオフにするか、現在とはまったく違った（閲覧ユーザー認証が乗っ取られたときの危険性を許容範囲まで下げるような）システムデザインで実装し直すか、する必要がある。

ちなみに今はクリティカルな部分（ポイントの扱いとか退会処理とか）は別認証になったから、ずいぶん認証が乗っ取られたときの危険性は下がったけど、昔（住所登録騒動が起こる前）はクリティカルな操作も同じ認証で行っていた。逆に言うと、現在は分離されているクリティカルな操作に関する認証以外の部分は、はてなのサービス全体の設計およびユーザービリティ的に分離できない部分なんだと思う。というのは憶測。

しかし、いくつかの仕組みを変更すれば、なりすましの回避とスクリプトの利用許可は両立できるはずなのです。

技術的にどういう問題があるのか理解した上でそういう主張をするのならば、それはそれでありだと思う*1。ただ、はてなはもちろん初めからそういう技術的な知識を元に検討を行った上で、現在のシステムデザインを採用しているわけだろうし、「ユーザビリティを下げたら対応できる」的な話は、デザインの好み（どれもそれなりに妥当な選択肢のうちのどれを選ぶか）の問題だからなー*2。

ちなみにCookieを盗難されたくなければ、別にドメインごと換えなくたって、パスで有効範囲を絞ったっていいんで、たとえばドメイン「d.hatena.ne.jp」＋パス「/ishinao/edit」で範囲を絞ったCookieを発効すれば、http://d.hatena.ne.jp/ishinao/edit以下でしか有効でない（XSSで盗難されない）認証を処理したりもできる。ドメインを換えることは必須ではない*3。

閲覧者の安全はほどほどに守れば十分だの方にもちょっと反応しておこう。

ブラウザの脆弱性を突いて行われる攻撃については、「その通り」と回答します。

一方、ブラウザが仕様通りの動作を行っても、サービスの設計のまずさゆえに可能となってしまう攻撃に関しては、（私の価値観においても）なるほど許容範囲外だと思いました。

念のために書いておくと、あの部分の文章はあくまでも「XSSの攻撃は、はまちやさんの仕掛けるようなすぐに攻撃の存在が発覚するそれほど実害が大きくないものなんだから、攻撃者はすぐ特定できるし、見つけたら攻撃者を排除するだけで十分なのに、なんではてなはあんなに一生懸命XSS対策をしているの？　不要でしょ？　っつーか俺たちにJavaScriptを使わせろや！」という徳保さんのもともとの主張（だと私が読み取ったもの）全体に対して、それは徳保さんが根本的にXSSというものを理解していなかったから、そう思ったんじゃないの？と問いかけているのであって、「対策は十分だと思うか、思わないか」の答えを直接的に聞いているわけではないので。いや別に答えてもいいけど。

ここからはかなり余談。

対策するべきかどうかを考えるときに、原因となる脆弱性が「ブラウザの実装にある」のか「サービスの実装にある」のか、という二つのみを並列させて論じることには、あまり意味がない*1。攻撃は、ブラウザもしくはサーバーの何らかの脆弱性を利用するものが多いが、ブラウザもしくはサーバーの脆弱性（ここでは特にプログラムレベルでの不具合）を利用しない攻撃もある。

まず、基本的にフリーテキストを解釈して処理を行うブラウザにおいては、実装側の自由度はかなり高く、それが脆弱性なのかブラウザの仕様なのか、明確には区別できないので、何らかの怪しげな挙動があったとしても、それが脆弱性であると言い切れない*2。あまり一般的ではないけど、実はこういうこともできるんだよ、というだけの話かもしれない*3。

特にJavaScriptに関して言えば、もともとがただのプログラミング言語なわけだから、そこで実現できることの自由度は非常に大きい。単に「攻撃」というだけならば仕様の範囲内でも非常に多様なことが可能だ。いわゆるJavaScriptによるブラクラなんて少しも脆弱性とは関係ない。信頼できないActiveXコントロールをインストールしたらキーロガーが常駐した、などというのも脆弱性とは関係なく、ブラウザの仕様通りの挙動だ。

また、ブラウザの脆弱性が発見された場合、もちろんその脆弱性を修正できるのはブラウザ制作者であって、サービス提供者がブラウザを修正するなんてことはできない。できるのは、その脆弱性を利用したなんらかの攻撃に対して、対策を取ることだけだ。

そして、ブラウザの脆弱性を利用した攻撃のすべてに、サービス提供者側で対策できるものではない。脆弱性の内容によっては、サービス提供者側では対応できないものもあるだろう。たとえばCSSXSSに関しては、それを利用したいくつかの攻撃に対策することは不可能ではないが、それはあくまでも場当たり的な対処であり、本質的な対策*4は不可能であると考えているので、サービス側での対応はされなくても仕方がないと考える*5。

逆に、ブラウザの脆弱性を利用した攻撃だとしても、それへの対策はサービス側でも容易に実現でき、しかもその脅威が十分に高いのならば、サービス側はブラウザ側の対策を待たずに対応した方がいいだろう。

サービスの実装に原因がある脆弱性を利用した攻撃は、対策しなくていい理由は思いつかないなー。まあ脅威の度合いが低ければ、すぐに対策する必要はないだろうけど、必ずいつかは対策するべきだよね。

ぐだぐだ長文を書いたあとに、まとめをbigpresenで書いておくというスタイルは、結構使えそう。場合によっては、まずbigpresenで概要を書いてから、詳しい話を後に書いた方がいいかもね（本文を読まない人が増えそうだけど）。

CodeBlogを見ていて思ったんだけど、tracにWeb日記インターフェースがついていたらプログラマー系Webサイト構築にすごい便利じゃねー？　バックエンドは標準のWikiシステムでいいんだけど、あれに、

• 日付をキーにしたテキストを手軽に書くためのインターフェース
• そのページ群のインデックスをわかりやすくまとめるインターフェース

を追加して、FrontPage相当がその表示になればそれでいい。tracの拡張機能を書けるようになるために、まずpythonを勉強するべきか……。