_ はてなの住所登録 (16:59)

俺はほとんどはてなダイアリーは使ってないし、はてなアンテナも常々自分でアンテナ立てた（り作ったりした）方がメンテナンス性が高くて良さそうだなーと思っていたところなんで、ひとまずぎりぎりまでは住所登録せずに様子をみるだろう。で、結局住所登録しなきゃサービスが使えないようになったら、どうしてもはてなアカウントが必要な理由が思いつかない限りはそのままフェードアウトだな。

はてなが信頼できないとかいうのではなく、はてなというネットサービスに住所を登録するメリット・デメリットを考えたときに、メリットはほとんど思いつかないけれども、デメリットはいくつか思いつくから。

デメリットは大して大きいものではないけど、メリットが思いつかない以上そっちが主な検討材料になってしまう。はてな自身にとっても（表面上見えている理由だけしかないなら）デメリットの方が大きいと思うんだけどなー。数万人の住所を含めた個人情報を責任を持って管理しなければならないというコストは、しゃれにならないくらいでかいと思うんだけど。

俺みたいな、比較的はてなに好意を持っている＆個人情報だだもれ野郎がそう考えるくらいだから、そうでない人はもっと登録する気にならないだろうな。

法的問題が起きたときに利用者の個人情報が必要になる可能性があるというだけなら、最終アクセスIPアドレスとかを記録しておいて、いざというときはそこからプロバイダなどに対して（司法機関経由で）情報開示を求める、とかいうレベルでだめな理由がよくわからない。

_ strtotime、dateのサポート範囲 (21:36)

ある日付文字列を、$ndate = strtotime($sdate)でUNIXタイムスタンプに変換して内部で取り扱い、出力する際には$sdate = date('Y-m-d', $ndate)なんて感じで処理していたところ、1970-1-1より前の日付が軒並み1970-1-1になってしまった。

調べてみたところ、srttotime関数について手元（というか日本語版）のマニュアルの注意書きには、

注意: タイムスタンプの有効な範囲は、通常、Fri, 13 Dec 1901 20:45:54 GMTからTue, 19 Jan 2038 03:14:07 GMTまでです。(これらは、32ビッ ト符号付整数の最大及び最小に一致します。)

とだけしか書かれていなかったけど、英語版を見たら、

Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.) Additionally, not all platforms support negative timestamps, therefore your date range may be limited to no earlier than the Unix epoch. This means that e.g. dates prior to Jan 1, 1970 will not work on Windows, some Linux distributions, and a few other operating systems.

と書かれていたよ。試してみたら、strtotime関数の段階ではきちんと（負の）UNIXタイムスタンプ値として変換されていた（RedHat/Fedora系Linux）。ただそれをdate関数で文字列に変換するときに、負の数値は0扱いされてしまい、1970-1-1になっちゃってるんだね。なんでstrtotimeできちんと負のタイムスタンプ値になっているのに、dateではそれを扱えないのか謎だ。っつーかこれどうやって解決しておくのがきれいなんだろうなー。今回はハイフン区切りの日付部のみだったから「-」でexplodeしちゃったけど、もっと汎用的な解決策を持っておきたいなー。

_ ブッシュ勝ちますか (01:35)

ブッシュ再選はないかと期待していたんだけど、ほぼ確定っぽいなー。日本の現状を考えると、アメリカ協調路線にはそれなりに利があるとは思っていたんだけど、これからまた4年もブッシュが大統領を続けるとなると、アメリカ協調路線を捨てることによるさまざまなデメリットを考えても、いい加減アメリカと距離を置く方を選びたい。軍事方面は、国連＋自衛隊で何とかならんかな。

自民党がそういう方向になってくれればいいけど、多分そうはならないだろうから（ここまでアメリカべったりでやってきて、ブッシュが再選したのにアメリカと距離を置く路線に変わるようなら、その方が信用できない）、しょうがないから民主党に何とかしてもらうしかないんだろうな。その場合は実務能力に欠けるであろう民主党が政権党になるというリスクまで背負わなければならないけど、それでもブッシュが二期連続で大統領を務めるアメリカべったり路線の日本にはもううんざりだ。

まあだからといって、俺がやるのは欠かさず投票に行って、民主党に入れることくらいだけどね。ひとまず中途半端に他の政党に票を分散させるのは（現状が変わるまでは）しばらくやめておこう。

_ 風邪が治らん (14:22)

月曜日は休んだし、火曜日も早めに帰った（けど仕事はしていた）し、昨日も休んだ（けど仕事はしていた）のにもかかわらず、まだ風邪が治らない。一番いやだった頭痛と関節痛は消えたんだけど、立ち上がるとやたらとふらふらするし、鼻水は相変わらずな感じだし、新しい症状としてやたらと喉が痛い。

もしかしたら、家族で複数の風邪菌を交互に感染しあっている状態なのかなー。症状から見て、この間までの風邪は下の子供の風邪で、今ひいているのは上の子供の風邪っぽい気もする。というか「（けど仕事はしていた）」が良くないんだろうな。なんでこんなアホな仕事に四六時中つきあわされてるんだろう。

_ センスオブワンダー(14:42)

「弥生の会計ソフト、複製はやってよくない」。なんか不自然なタイトルだなーと思いつつも、本文を読んでも特にその意味がわからなかった。けど、単に「やよい」と「やってよくない」をかけているだけ？　ちょっとセンスオブワンダーを感じた。

_ 紳助ネタ via 偉愚庵亭憮録: 抗議 (18:02)

俺にはどうしても、紳助擁護意見がよくわからん。紳助は芸能人として好きだし、内輪での訴訟沙汰を選んだ被害者の行動は（日本人的に）いまいち好きになれない（けど、状況的にしょうがないかなーとも思う）けど、それでも今回はどう考えても弁解の余地なく紳助がアホだっただけだと思う。

紳助はアホやったツケを払った上で、ちゃんとまた芸能界に復帰してねとは思うけど、紳助は好きで被害者の行動は嫌いだからといって、紳助がやったこと自体も擁護するってのはむちゃくちゃすぎる。

紳助自身も「無礼」の理由として「吉本の偉い人を呼び捨てにしたこと」を挙げているし、その辺は状況的に首尾一貫しているんだよね。だったら、結局「紳助の常識知らずの勘違い」が原因で「暴力をふるった」という話でFAってことになって、やったことに対する擁護の余地は全然ないと思うんだけど。

_ プライバシーポリシーの見直し、住所登録スケジュールの延期について (20:20)

・住所をご登録頂いていないユーザー様は、はてなをご利用頂けなくなります。

（質問の登録や日記の編集、アンテナの編集などの操作が、住所登録後に可能となりますが、これまでにご登録頂いた情報が突然削除されたり、閲覧不能になることはありません）

うへー、編集権限はなくなるけど公開はされ続けるのか。ってことは、もしも住所登録をする気がない場合は、放置しておいたんじゃだめで、期限前にきっちりデータを消しておかなきゃならないんだな。まだ住所登録しないと決めたわけじゃないけど、追加の説明を読んでも、俺の中での判断には変化がないんで、住所登録しない可能性の方が高い。ということは、フェードアウトするだけではなく、期限前にちゃんとアンテナとダイアリーの削除作業を行わなければならないことになるな。忘れないようにしないと。

あとこういう場合は住所登録フォームだけでなく、オンラインでの退会フォームも一応用意しておいた方が、選択肢としては妥当な気がする。選択肢の片方（運営側が選んでほしい方）は簡単にできて、もう片方（選んでほしくない方）は面倒くさいというのは、オンラインサービスでは良くあることだけど。

_ データは消しちゃった (13:15)

退会はMyはてなから簡単にできるんだね。今まではてなはダイアリーとアンテナ以外使ってなかったんで、はてなのトップページってほとんど行かなかったから、あれが会員メニューに相当するものだと気づいていなかった。

でも、後でばたばたするのも面倒だから、ダイアリーとアンテナのデータはいったん削除してしまった。やっぱりちゃんと使い続けたいと思ったらまたゼロから始めてもいいし。やっぱり俺的には、自分の文章（Webサイト）が管理権限が失われた状態で、公開され続けるってのはかなり気持ち悪いことだから、それだけは避けておきたい。

それに、俺の場合ははてなダイアリーは（仕組みとかコミュニティとかが）面白いから使っていたけど、実際のところは自分のサイト以外に文章を分散することの（管理の手間の）面倒くささも結構大きくて、困っている面もあったんだよな。今回はちょうどいいきっかけになった。やっぱり情報は自分のサイトにまとめた方がいいよな。

あとはMM/本のメモを拡張して、他人のサイトにコメントした情報も自サイトに（メモ→RSS→サイドバーという形式で）取り込めるようにすれば完璧だ。っつーか、自分のところでやりたいことはたくさんあるんだけど、やっている暇がないなー。

_ 最近読んだ本 (02:10)

最近全然感想を書いてないんで、MM/本のメモから読了一覧（RSS）だけ貼り付けておこう。

• [了](4) 講談社 ひぐち アサ 『おおきく振りかぶって (2)』
• [了](4) 小学館 浦沢 直樹,手塚 治虫,手塚 真 『PLUTO (1)』
• [了](4) 20世紀フォックス・ホーム・エンターテイメント・ジャパン 『スター・ウォーズ トリロジー DVD-BOX』
• [了](4) 講談社 山下 和美 『天才柳沢教授の生活 (10)』
• [了](4) 講談社 佐藤 秀峰 『ブラックジャックによろしく (10)』
• [了](4) 早川書房 オースン・スコット カード,Orson Scott Card,田中 一江 『シャドウ・パペッツ』
• [了](4) 早川書房 小川 一水 『復活の地〈3〉』
• [了](4) 早川書房 栗本 薫 『ノスフェラスへの道―グイン・サーガ〈97〉』
• [了](4) メディアワークス 成田 良悟 『バッカーノ!1932―Drug & The Dominos』
• [了](4) メディアワークス 秋山 瑞人,よしみる 『E.G.コンバット〈3rd〉』
• [了](4) 小学館 島本 和彦 『吼えろペン 7 (7)』
• [了](4) 小学館 島本 和彦 『吼えろペン 8 (8)』
• [了](4) 集英社 奥泉 光 『鳥類学者のファンタジア』
• [了](3) 毎日コミュニケーションズ 山本 容子 『A Better Design Webページ リ・デザインブックII』
• [了](3) アスミック 『ぼくが地球を救う DVD-BOX』
• [了](3) ユニバーサル・シグマ 岡村靖幸 『Me-imi(初回)(DVD付)』
• [了](3) 小学館 島本 和彦 『吼えろペン 11 (11)』
• [了](3) 小学館 島本 和彦 『吼えろペン 9 (9)』
• [了](3) 小学館 島本 和彦 『吼えろペン 10 (10)』
• [了](3) メディアワークス 谷川 流,蒼魚 真青 『学校を出よう! (6) VAMPIRE SYNDROME 電撃文庫 (0996)』
• [了](3) メディアワークス 谷川 流,蒼魚 真青 『学校を出よう!〈5〉NOT DEAD OR NOT ALIVE』
• [了](3) 小学館 島本 和彦 『吼えろペン 5 (5)』
• [了](3) 小学館 島本 和彦 『吼えろペン 4 (4)』
• [了](3) 小学館 島本 和彦 『吼えろペン 3 (3)』
• [了](3) 小学館 島本 和彦 『吼えろペン 2 (2)』
• [了](3) 竹書房 福本 伸行 『アカギ―闇に降り立った天才 (第16巻)』
• [了](3) パラマウント・ホーム・エンタテインメント・ジャパン 『スクール・オブ・ロック スペシャル・コレクターズ・エディション』
• [了](3) メディアワークス 成田 良悟 『ヴぁんぷ!』
• [了](3) メディアワークス 成田 良悟 『デュラララ!!』
• [了](3) メディアワークス 成田 良悟 『Mew mew!―Crazy cat’s night』
• [了](3) メディアワークス 成田 良悟 『バウワウ!―Two Dog Night』
• [了](3) 講談社 川原 正敏 『海皇紀 22 (22)』
• [了](3) 新潮社 池波 正太郎 『待ち伏せ』
• [了](3) 新潮社 池波 正太郎 『剣客商売〈8〉狂乱』
• [了](3) 松下電器産業 『Panasonic DMW-CZS20 FZ20用ソフトケース』
• [了](3) 新潮社 池波 正太郎 『剣客商売〈7〉隠れ蓑』
• [了](3) メディアワークス 時雨沢 恵一 『キノの旅〈8〉the Beautiful World』
• [了](3) 角川書店 谷川 流,いとう のいぢ 『涼宮ハルヒの暴走』
• [了](3) 新潮社 池波 正太郎 『池波正太郎の銀座日記』
• [了](3) メディアワークス 谷川 流,蒼魚 真青 『学校を出よう!〈4〉Final Destination』
• [了](3) 小学館 島本 和彦 『吼えろペン 1 (1)』
• [了](3) メディアワークス 秋山 瑞人,よしみる 『E.G.コンバット (2nd)』
• [了](3) メディアワークス よしみる,秋山 瑞人 『E.G.コンバット』
• [了](3) メディアファクトリー 小栗 左多里 『ダーリンは外国人(2)』
• [了](3) 小学館 島本 和彦 『吼えろペン 6 (6)』
• [了](3) 新潮社 恩田 陸 『六番目の小夜子』
• [了](3) 草思社 保坂 和志 『書きあぐねている人のための小説入門』
• [了](2) 朝日新聞社 村上 春樹 『「そうだ、村上さんに聞いてみよう」と世間の人々が村上春樹にとりあえずぶっつける282の大疑問に果たして村上さんはちゃんと答えられるのか?』
• [了] 東芝EMI 高野寛 『相変わらずさ-ベストアルバム』

_ 個体識別番号ですらないんじゃん？ (22:56)

「携帯の個体番号悪用　個人情報特定装い料金を不当請求」より、

　携帯電話サイトの広告にアクセスした利用者に、電話番号や氏名を把握したと思い込ませて利用料を迫る不当請求が、仙台市などで急増している。実際は携帯電話の個体識別番号が分かられただけなのだが、個人情報も知られたのでは、という不安をあおり、請求に応じざるを得ない心境に追い込む手口。市消費生活センターは「引っ掛けサイト」と名付け、注意を促している。

　「ご入会ありがとう。あなたの個体識別番号　ＤｏＣｏＭｏ／１．０／メーカー記号９００ｉ×××　を登録させていただき、入会手続きが完了しました」

それは単なるユーザーエージェントなのでは？　DoCoMoの場合は端末のスペック情報もユーザーエージェントにつけてくるから、機種情報まではそこからわかるけど、個体識別番号まではわからないはず。UTN付きリンクを踏まされたってわけでもなさそうだし（それならもう一段注意書が出るから、こういう話にはならないと思う）。まあUTN付きリンクを踏まされたところで、それこそ単なる個体識別番号がわかるだけで、個人情報が知られたわけではないけど。

_ 警察の任意での捜査に協力するかどうか (23:31)

ARTIFACT「はてなの住所登録問題―個人情報の開示基準編　悪徳商法マニアックスとウェディング社の件について―」の、

　警察の任意照会に対して、プロバイダーが個人情報を開示することについては、問題がないと考えます。

オオツネさんはテレコムサービス協会に完全準拠するという案を考えていますが、上で書いたように現状では大変難しいと思われます。それを実行しているのはニフティぐらいではないかという話もありますし、それをはてなのような企業規模ののところに求めるのは酷かと。

とotsuneさんのコメント、

>それをはてなのような企業規模ののところに求めるのは酷かと。

それは何故だろう？ @niftyがそれを実現しているのは、はてなでは無理なリソース（金銭・時間や、警察との関係構築……ぶっちゃけ天下り顧問受け入れetc.）を負担していると予想できるから？

はてなでも現状のリソースでやれば出来るような気がするけどなぁ。根拠無いけど。

照会書だけで断ることが出来ないという公式な理由が出ていないから。

あたりを読んで、結局警察というものをどのくらい信用しているかがポイントになるんじゃないかと思った。

• 警察の通常の捜査活動に協力できないほど、警察は信用できないかどうか
• 警察の捜査活動に非協力的な行動に出ることによって、警察に目をつけられる（怪しいところだと思われ、今後何かと捜査対象となり、業務に支障が出る）ことのデメリット（の可能性）

あたりを鑑みた上で、どういう選択をするか。

「警察を信用しない」という場合は、たとえ目をつけられる可能性があったとしても「法的な根拠がなければ要求には応じない」と突っぱねることもできるでしょうし、それで不利益があった場合はさらに「警察を信用しない」ことになるでしょう。「警察を信用する」場合は、「警察の任意の照会だとしても、捜査活動に協力するために（もちろん警察はそれ以外の用途では情報を利用しないと信じた上で）、ユーザーの個人情報を渡してもいい」と判断するのでは。

私だったら多分（規約等に、法的根拠がなければ個人情報は渡さないと明記していない限りは）警察に協力すると思います。もしその情報を警察が悪用したりしたら、それはそれで別問題として警察を追求するでしょうけど。

悪マニとウェディング社と京都府警の話の時は、「はてなの人たちは2chなんかで流れていた、ウェディング関係者と京都府警との間の過去のニュース記事なんかに関する情報をすべて知っていたのかどうか」、「はてなの人がその当時持っていた情報から、京都府警は信用できないから協力できないという結論を出し得たか」あたりがポイントになりそうだけど、まあその辺ははてなの中の人以外は知らないこと。

でも、結局はてなも悪マニのBIG-NETじゃない方のプロバイダー（PROXだっけ？）も警察の任意の照会に応じたってことは、どちらかというと「警察を信用する」という判断を下したってことじゃないかな。「警察を信用しない」という判断を下して、警察と敵対する（非協力的な行動を選ぶ）のは、よほどそういう信念を持っていない限りは難しいと思うし。

_ うーん、まだ治らない (01:03)

この週末も飯を食いに出かけた以外はほとんど寝ていたんだけど、未だに風邪が治らない。先週後半から喉に来ていたのがひどくなって声が出なくなったのに加えて、再び頭痛と関節痛が戻ってきたよ。なんじゃこりゃ。なんかもう完全に治るまで一週間くらい休みたくなってきたなー。

_ 私の体は覚えていてね (14:37)

マジかジョークか微妙だなー。でもまだ女性名だけの連名で良かったじゃん。

_ 技術的な話 (02:26)

• はてなの Cookie が洩れると個人情報も洩れる
• はてなの Cookie

sheepmanさんがいろいろ書いているんで、俺も裏（mixi）でぐだぐだ言うのはやめて、表に出せる部分は出してしまおう。sheepmanさんの指摘の繰り返しにすぎない部分が多いけど。

• どんなに「技術的に安全」に管理していても情報漏洩の可能性はある。セキュリティホールは現場の技術者の過失だけが原因で発生するわけではない。
• ソーシャルハッキングのレベルまで考えると、「人間的に信頼できる」というのはほとんど意味がない。関係者全員が高度なセキュリティ意識を持っていない限り、たとえ「人間的に信頼できる」人でもセキュリティ的には信頼できないことになる。
• はてなのサイトの作り自体があまりセキュアさを重視していない。現在のはてなのサービス内容を考えると十分なレベルのセキュアさは持っていると思うが、これだけの個人情報を収集するのに十分であると私には思えない。
  • 認証管理を永続（ブラウザを閉じても消えない）Cookieでやっている。その内容もランダムではあるが半固定。試してみた限りでは、2回ログアウト→ログイン操作を行うと値が変わるが、その操作をしない限りは固定値となっている。つまり、（おそらく）多くのユーザーにとっては固定値である。その分危険性（漏れた場合に悪用される可能性）が高い。はてなが集める個人情報ならば、せめて以下のレベルでのセキュアさがほしい。
    • ランダム非永続認証Cookie＋HTTPS＋secure
    • ランダム非永続認証Cookie（＋HTTPS）
    • ランダム永続認証Cookie＋比較的頻繁に（n回アクセスするごとに、など）認証キーが変化
  • セキュアさが必要なコンテンツとそうでないコンテンツで、認証管理のレベルを切り替えていない。たとえば個人情報にアクセスするところで、SSLに切り替えると同時にsecureな新しい認証セッション（もう一度ID・パスワードを入力させた上でsecureなCookieを発行する）に切り替えたりとか。
  • はてなダイアリーの、ユーザーが自由に入力したHTMLやCSSをロジックで洗浄するというアプローチには、潜在的な危険が大きい。そのアプローチはあくまでも「危険を発見したら対処する」の繰り返しであり、実用上十分な安全性は確保できるが、確実な安全性を狙ったアプローチではない。

ちなみに上に書いている内容はあくまでも俺個人の評価であり、「俺基準では、現状のはてなのシステム的なセキュリティに関する態度は、今から集めようとしている個人情報の質・量を考えると物足りない」という話にすぎない。はてな的にはこれで十分と考えているのかもしれないし、あるいは他のWeb技術者もこれで十分と考える人もいるかもしれない。

その辺の一般的な評価が見えなくて表で書きづらかったんだけど、少なくともsheepmanさんも俺と同じような認識を持っていることがわかったから、俺も表で書いておこう。

うわ

またTrackBackが全文送られちゃったよorz..

はてなダイアリー日記にも

TrackBackを送ったつもりだったが送れていない……。と思ったら、そういやはてなはURLをGETしたドキュメント中にリンクがない場合は受け付けないんだっけ。ということで、リンクしてからもう一度チャレンジ。

_ 万物理論(グレッグ・イーガン) (20:50)

決して面白くなかったわけじゃないし、話自体もグレッグ・イーガン的な大仰な論理科学SF系で期待通りではあったんだけど、ちょっとストーリーにも（論理）ガジェットにもパワーがなく、一気に読んでしまうような勢いがなかった。で、だらだらと通勤電車で一週間くらいかけて読んでいって、ようやく読み終わったんだけど、いまいちカタルシスが足りない。ちゃんときれいに話は終わっているんだけどなー。大ネタの万物理論を巡る攻防自体はそれなりに面白かったけど、その周辺のネタがいまいち（俺の中で）消化不良だった感じかな。特にオチの『』というテーマあたりが特に。細切れに読んでいったからその辺の重要な文章を読み飛ばしちゃったのかなー。本当はあそこでカタルシスを感じるべきだと文脈上はわかるんだけど、そこで「ふーん、そういうオチですか」程度しか感じなかった。元々Hワードに関する話題は読み飛ばし気味だったから、その辺をもっとちゃんと読み込んでおくべきだったってことかなー。

_ 久しぶりに激しい背筋痛 (12:46)

なんかもうふつうに歩いていてもいやな感じですよ。痛む部分が結石の時と似ているけど、痛みの質が全然違うから、これはもっと昔にやった背部挫傷の後遺症の方だろうなー。一度整体にでもいって診てもらった方がいいかなー。

_ 休み (13:46)

昨日は最低の体調だったにもかかわらず、きんきんに冷房を効かしたサーバールームで立ったまま4時間作業というろくでもない仕事をさせられたので、やる気をなくして今日はお休み。といってもどうせ家で仕事をしているんだけどな。っつーか、どうせ裁量労働制なんだから、もう会社に行こうが行くまいがどうでもいいじゃんよ。打ち合わせと社内作業と出先作業があるときだけ出社義務にしてくれればいいのに。ちなみに昨日は作業後とっとと帰って寝たんで、体調自体はずいぶん良くなってきた。まだ咳と鼻水は完治には遠そうだけど。

_ はてな住所登録パブリックコメント (21:17)

もうちょい寝かせておこうかと思ったけど、そんなに時間をかけてもいられないからもう出しちゃおう。ちょっとはてなに対しては厳しすぎる意見が多いんで、そのあたりもうちょっと柔らかく書きたかったんだけど、そこに時間をかけている余力がない。特にはてなのセキュリティ対策に対していろいろ不満を述べているけれども、実際問題として現在のネット系サービス会社の中では、はてなはセキュリティ関連の技術的に悪い方ではないと思う。ただそれでも、私基準では（特に住所を含めた個人情報を収集しようと言う動きを見せたことと絡めると）まだまだ物足りないと思っている。もう一度繰り返すけど、「特にはてなが悪い」と言いたいわけではない。

住所確認方法の実効性への疑問

無作為抽出した150人に郵送で確認する方法では不十分だと思う。

はてな側としては、多くの割合のユーザーが正しい住所登録をしてくれることを期待し、郵送確認の結果によってその期待が（数学的に）証明されるという展開を望んでいるのだろう。確かに150人に郵送した結果、たとえば9割の人が正しい情報を登録しているという結果が出るのならば、この方法は確かに有効である。

しかし、もしかしたら郵送確認したうちの1割のユーザーしか正しい住所を登録していないという結果が出るかもしれない。そのような結果が出た場合でも、「150人のユーザーに郵送で住所確認を行うという、十分な本人確認の努力を行っているから、問題なく従来通りの運営を続けられる」という結論が出せるのだろうか？　おそらくそうはならないだろう。それではいったい何割以上という結果が出れば、問題ないと言えるのか？

つまり、無作為抽出した150人に対して、郵送で住所確認をするという方法は、現状では博打（その方法が有効なのかどうかは、調査の結果が出るまでわからない）の要素が大きすぎるのだ。

また、せっかく住所確認作業を行っても、新規登録ユーザーの住所確認が行われないのならば、さらに意味は薄くなる。現状では、無作為郵送チェックで弾かれたユーザーが再び不正な住所を使って新規登録することが可能であり、そうなるとせっかくコストをかけて住所確認をしても不正住所登録者の数が減らないことになってしまう。

上記二つの点から、現在予定されている住所確認方法は不十分であると考える。

セキュリティ対策が十分であるという信頼感がほしい

実名、実住所、性別、生年月日、メールアドレスという個人情報を数万人分収集するに当たっては、それに見合っただけのセキュリティ対策が必要になる。以前指摘したとおり、私は現在のはてなのシステムは上記情報を収集管理するシステムとして、十分なセキュアさを持っていると考えていない。

少なくとも、HTTP経由でやりとりされる半固定10年期限Cookieによる認証だけで、個人情報が表示される設計は問題がある。Cookie漏洩の可能性が十分にあり得ることは、今までのはてなダイアリーにおけるXSS対策の経緯から、はてな側でも十分に認識されているだろう。また、住所登録導入時のSSLの使い方の失敗（フォーム投稿はHTTPSだったのに、結果はHTTPで返した）はあまりにも基本的なミスすぎた。

それらの問題を、実際に住所情報を収集し始める前の社内チェックの段階で発見できなかったという状況に、とても不安を感じる。その不安を払拭できるような対策および情報を示してほしい。もし、はてなに数万人分の正しい住所を含む個人情報があるということになったら、今までよりもはてなの会員DBは狙われやすくなるのだから。

FAQの「情報へのアクセスは社内からのみ可能となっており、誰が、どのような操作を行ったかが記録されています。また、現在はてなには7名の社員がいますが、全て正社員および経営者です。はてなのサイト運営に関して外部の事業者等は利用しておらず、この7名以外がはてなユーザーの登録情報に接することはありません。」からも、セキュリティに対する知識が十分であるとは読み取れない。

「情報へのアクセス」は、少なくともインターネット上からすべてのユーザーが（正規の手段では）自分の情報に対して可能である。社内ネットワークからしかDBへのネイティブアクセスができないと言いたいのだろうが、それならそう明確に書くべきだろう。一般的に「情報へのアクセスは社内からのみ可能」という表現は、すべてのクライアント（アプリケーション）が社内ネットワーク上にしか存在しないような設計の場合に使うべきものだ。

また、個人情報DBへ直接アクセスできる者が「正社員」や「経営者」のみだとしても、その全員が十分なセキュリティ知識を持っていない限り、「だから安全だ」とは言えない。逆に言うと、各人のセキュリティ知識（教育状況）が十分でないままに、「正社員ならばユーザーの個人情報にアクセスできる」のならばそれは問題だ。

「セキュリティ知識の必要性」の具体例を挙げておく。たとえば社員の誰かが「社長に頼まれたんだけど、社長のメールアドレスに○○（個人情報を含むデータ）を送ってね」みたいな、一見安全そうな個人情報操作を依頼された場合に、疑問に思わずに送ってしまわないだろうか。もちろん上記がハッキングの手法だとしたら、攻撃者は社長がメール受信をするネットワーク経路で盗聴を仕掛けていることになるだろう（現在のはてなの運用体制で上記のような攻撃が有効なのかどうかはわからないが）。

「個人情報にアクセスできる権限を持つ人間に必要なセキュリティ知識」というのは、上記のようなシチュエーションにおけるリスク等をきちんと計算できるレベルだと私は考える。そのような知識がない場合は、たとえ正社員だといえども個人情報へのアクセス権限は持たない方がいい。そして、現状の「全員が社員だから大丈夫」的な説明からは、そういう認識が欠けているように見える。

「プライバシーマークを取得する」という案があったようだが、そういう外部団体のお墨付きを得ることもひとつの方法だろう。また、十分に妥当なセキュリティポリシーを掲げ、それに則った運用を行っていることを態度で示すだけでも、私的には安心できる。ともかく現在のポリシーおよび運用状況は「安心できる」には物足りなく感じる。

プライバシーポリシーなど

これは別に現状のままでもかまわないし、よりユーザーが利用しやすい内容に変更するならばそれでもいい。集めた個人情報をどのような用途に利用するかは、（法律に反しない範囲で）はてな側が決めることだし、それを正しく表記してさえくれれば、ユーザー側がそれを読んで利用するかどうかを決めるだけだろう。

「住所登録」の代替案

もともとこの「住所登録」案が出てきた背景には、

「はてな関連サービスにおいて、（カジュアルな）違法行為が原因であるトラブルが増えている。それによるサポートコスト（お金＋労力＋法的リスク）の増大や、ネットコミュニティとしてのはてなの価値減少の可能性が、はてな社内での大きな問題となった。そこで、トラブルサポートコストの削減・ネットコミュニティとしての価値の維持もしくは増大のための対策を考え出す必要があった」

という事情があるのだと考えている。

だとすると、別にその対策は「住所登録」以外にもあり得る。実際はてな側も今回、「情報削除ガイドラインの見直しや、削除フローの見直し」という対策ですませられる可能性を示唆しているし、私も実効性や運営コスト的な問題が大きい「住所登録」という対策を選ぶ前に、上記のようなはてな内部のみで対応可能な対策を進めてみるべきだと考える。

ただ、今までのはてな社内での試行錯誤の過程で、すでに上記のような対策では十分ではないという結論が出たのだとしたら、「住所登録」のような、ユーザーにもある程度リスク/コストを受け持ってもらうような対策をとるという選択もやむを得ない。しかし、だからといって「住所登録」という結論に飛びつくのはまだ早い。「住所登録」よりもより良い選択肢が他にもないか検討してほしい。

たとえば私は、「本人確認性が高いメールアドレス登録を必須にすることによる、間接的な信頼性の担保」という手段がいいのではないかと考える。はてなが直接具体的な個人情報（住所）を管理するのではなく、すでにユーザーが個人情報を提供しているインターネットプロバイダ等の第三者機関を介して（ワンクッションおいて）ユーザーの個人情報にアクセスできる環境を整えるのだ。

はてなが今回「はてなが負わされる法的なリスクの可能性」を重視しているのだとしたら、法的な要請の元で十分な本人確認性を確保できれば、それで十分なのではないだろうか。プロバイダ等の第三者機関というワンクッションを置いたとしても、それを介すことで確実に本人確認が可能な体制を準備できるなら、法的な要請の元での本人確認性は十分にあることにならないだろうか（このあたりは法的な見地からの意見を聞いてみたいところ）。

またユーザーにとっては、いざというときにすでに個人情報を預けてあるプロバイダ経由で身元確認をとってもらう方が、新たにはてなに個人情報を登録するよりも安心だろう（情報漏洩する可能性がある口は少なければ少ないほどいい）。

一応、メールアドレス確認をベースにしたシステムの概要も挙げておく。

まず「許可メールアドレス（ドメイン）」「拒否メールアドレス（ドメイン）」のデータベースを作成する。国内大手プロバイダなど、個人情報をユーザーが預けていることが確実なメールアドレスについては、あらかじめ許可しておく。また主要なフリーメールアドレスなどの、本人確認が甘く、重複登録が簡単なものについてはあらかじめ拒否しておく。

続いて、許可でも拒否でもないグレーなメールアドレスについては、順次手動でのチェックをかけていき（たとえば、一般の企業アドレスや学校アドレスなどは、本人確認性が十分高いと考えられるだろう。また独自ドメインアドレスなども、その利用状況を簡単に確認することで、ある程度は本人確認性の高さを見積もることができるだろう）、その結果を許可・拒否データベースにも反映させていく。それにより、かなりのメールアドレスは自動的に許可・拒否の判断ができるようになるだろう。

手動チェックでも許可・拒否が定まらなかったグレーなアドレスを最終的にどう判断するかについては、単にポリシーを決めればいい。メールアドレスのみでは判断がつかなかった場合のみ「住所による本人確認を併用する」のもいいだろう。あるいは単純に「このメールアドレスは登録できません。許可アドレスリストを参考に、登録可能なメールアドレスを用意してください」ですませてしまってもいい。

そして、グレーおよび拒否メールアドレスに該当するユーザーに対して、メールアドレス登録の変更を呼びかける。住所登録の変更と同様に、準備期間を設けて期限までの変更を促す方法でいいだろう。メールアドレス確認の仕組みについてはすでにはてなも持っているし、システム構築にかかるコストもグレーなアドレスの手動判別にかける工数で調整すれば、それほど莫大なものにはならないはずだ。

_ 喉の奥の異物 (14:08)

昨日あたりから喉の奥に腫れ物ができて、咳き込むとしゃれにならないくらい痛む。そういや5年くらい前に、同じ場所にひどい腫れ物ができて、呼吸をするだけでも激痛が走って、しょうがないんで耳鼻咽喉科に行ったら、腫れ物を針でつついて皮膚を破って膿を吸引するという恐ろしい治療を受けたことがあった。喉の奥に対してそういう破壊的物理治療をするのはやめてほしいのう。歯医者とかで喉にたまったつばを吸引する状況を100倍ひどくしたと思いねえ。あんな目には二度とあいたくない。

ということで、昨日の夜から喉の湿気を保つためにマスクをつけっぱなしにしているんだけど、これはずいぶんいい感じだな。それまではずっとのど飴をなめ続けていたんだけど、のど飴なんかなめなくてもマスクだけで十分喉の痛みが和らぐ。っつーか、そういや今はほとんど喉の奥の異物感がなくなっているな。ラッキー。

そういや今日からオクサンが仕事に復帰した。っつーことで、朝から子供2人に飯を食わせて保育園に連れて行くという作業を1人でやらなきゃならなくなった。ムスコの方はもうずいぶん人間らしくなったんで、口で指示するだけで何とかなるんだけど、オトウトの方はちょっと目を離すと逃亡してひどいことを始めるんで、そっち対策がつらい。まあでも慣れればなんとかなりそうか。

_ 松下ドライブ (20:13)

http://hobby7.2ch.net/test/read.cgi/av/1100181669/378より、

DVDドライブはパナOEMでしたYO！

ようやく信頼できそうな情報が出てきたよ。よかつたよかつた。で、Amazonからはいつ届くんでせうか？

_ うわー (23:59)

ムスコが久しぶりにゲロゲロになりやがったよ。先週鼻水の風邪が治ったと思ったら、またおニューの風邪をもらってきましたか。オトウトの方の風邪もようやく治ったと思ったところなのにまたうつりそうだな。こいつら二つの保育園で別種の菌をかわりばんこに持ち寄るつもりだな。俺も負けずに会社から別の風邪をもらってこないと。

_ もしかして (16:37)

TSUTAYAネタが発表された今でも、基本的にはてな（というか近藤さん）はふつうにユーザーにとっていい方法を考えているつもりなだけで、それがユーザーにこんなに反発を食らうことなんて考えてもいなかった、ある種天然さんだという説の方を有力視しているのは、もしかして俺だけですか？

_ 「ログイン画面の変更について」 (22:16)

「ログイン状態を保存する」をチェックした場合のみ、ブラウザを閉じてもログイン状態が保存されます。（チェックを行わない場合は、ブラウザを再度起動した際にログインが必要となります）

また、「ログイン状態を保存する」をチェックした際に、ログイン状態が保存される期間を1ヶ月としました。

というわけで、はてな全体の認証維持の方法として、デフォルトで非永続認証Cookie、ユーザーの意志で永続を選んだ場合も有効期間一ヶ月と、通常利用の範囲におけるはてなのセキュリティレベルは向上したようです。

ただ個人情報管理という観点からは、「よりセキュアさが必要とされるコンテンツ（主にmyはてな内）にアクセスする際には、認証レベルを変える（SSL＋secureクッキーによる通常とは別の認証を行う）」といった対処の方が重要なので、そちらの方も対応してもらえると、個人情報管理を行うWebシステムとしての安心感は大幅に向上するでしょう。

_ 住基ネットセキュリティ調査結果もみ消し (19:58)

まずはセキュリティホール memo MLに流された、「Ejovi Nuwere 氏発表中止関連」（BASIC認証がかかっているけど、ダイアログにID/PWDが書かれているので誰でも閲覧可能）。そして、調査にあたった人のblogの記事「My JUKI net presentation」と発表されるはずだったプレゼンテーションのPPTファイル（英語、日本語）。/.-Jの該当トピック「住基ネット侵入実験に関する専門家の発表に総務省が「待った」 」。毎日新聞の関連記事「住基ネット侵入実験者の発表が中止に　総務省が難色」。

なんかもう具体的につっこむのもあほらしいけど、総務省ごときが、わざわざ調査を依頼したセキュリティ専門家の調査結果に対して、『「住基ネットと庁内ＬＡＮを混同している。脆弱（ぜいじゃく）性を具体的に示すおそれがある」などと修正を求めた』ってのがちゃんちゃらおかしいよな。なんのために専門家に調査を頼んだんだ？　問題が発見されることなんて予想もしていなかったってのか？

_ 北戸田ジャストと新都心Cocoon (22:29)

プレオープン期間中の北戸田ジャスコを見物しようかと、15時頃に車で向かってみたら、ずいぶん手前から駐車場渋滞になっていた。2時間待ちだそうだ。こりゃまたすごいな。確か以前よりも駐車場台数とかずいぶん増やしたはずなのに。というか、かなり手前のアンダーパスの途中から渋滞するのはやめてけろ。この辺で詰まってしまうと、行くのをあきらめても回避することさえ難しい。

というわけで、何とか中央分離帯が切れたところでUターンして、代わりにさいたま新都心にできたCocoonとかいうところに行ってみた。新都心は昔ヨーカドーによく行っていたんだけど、ここ1年ほどは全然行っていなかった間に、いつのまにか映画館まで入ったでかい建物が新しくできていたらしい。

で、駐車場も結構余裕がありそうだし、建物や入っているお店もそこそこ良さそうではあったんだけど、今家族中体調不良状態なんで、ろくに店を回ることもできなかった。というか、なんだかやけに面積を広々と使った感じの建物で、ほとんど店に入らずに一周回っただけでものすごく疲れた気が。もうちょっと家の近くにできたんだったら、結構行く気になりそうな感じだったんだけどな。新都心もこれができたおかげで、ずいぶん人が集まるようになったっぽい。去年作りかけていた背の高いビル群も一通り完成していたみたいだし。

_ 誰も気にしない (10:50)

さっき通りかかった、旧東急文化会館裏の山下書店の並びにある商工中金の、裏口っぽい階段に、車がきれいにはまるように落っこちていた。「おえぇっ！」と驚いて立ち止まって眺めていたんだけど、他の人は誰も気にもとめずに通り過ぎていくのが不思議だった。あれって駐車場入り口と間違えて落っこちたのかな。写真撮ってくれば良かったな。後で飯を食いに行くときにでもまだあのままだったら、写真撮ってこよう。

_ 引っ張りあげ中 (14:05)

狭い道に微妙な角度（水平垂直とも）ではまっているんで、引き上げ作業は難航している模様。ひとまず今あの辺の裏道は全部通行止めです。あの道って狭い割にはよく使われている道だし、回避ルートも少ないから大変そう。

_ ずっぽり (14:07)

ほぼジャストサイズの横幅なのに、ぱっと見、車の左右に傷が見えないから、不慮の事故で落ちたとかじゃなくて、きちんとあそこに入ろうとした結果落ちたんだろうな。ただ、あの道ってあの階段とはちょっと逆向きに一方通行のところなんで、ふつうに車が走っていたら入ろうとしないはず。一方通行逆走した車が駐車場と勘違いして入っていったのか、それとも商工中金が怖い人たちとトラブって盗難車とかをつっこまされたとか？　でも落ちた先にあるガラス扉が壊れていなかったから、どかんと落ちたというよりは、そぉっと落ちたって感じに見えた。

_ 広く浅く化？ (10:06)

ちょっと前までは、同じURLを何度も（129回だっけ？）ばらまくREFERER SPAMが多くて、その場合はrefeditプラグインで簡単に削除できたんだけど、今日は1アクセスずつ大量のURLをばらまくタイプがやってきてしまい、これだとSPAM URLを識別して削除するのがとっても大変なのでした。

複数のIPから

同時にアクセスしてきているみたいだな。しかも全然違うアドレス領域を使って。ちなみにHEADリクエストみたいだけど、tDiaryってHEADリクエストの場合でもREFERERを記録するのか。

_ 1回休み (10:59)

下の子がゲリピー状態で保育園に預けられずに一回休み。ゲリ以外は元気なんだけどなー。っつーか、どうせ家で仕事しているんだけどなー。

_ 漏れ (13:56)

いまだに下の調子が良くない下の子は、朝から漏れうんち1回、漏れないけどほぼ水なうんち1回と復調せず。だけど、今日はどっちも休めなかったんで、しょうがないから事情を話して保育園に預けつつ「ダメだったらすぐに呼び出し」覚悟で出社。今のところまだ連絡はないけど、明日はまたダメかもなー。

_ 浮気亭主を見つけろ! の問題 (15:19)

ある国に何人かの浮気亭主がいた。あるとき、その国の女王様がこう言われた。「この国には少なくともひとりの浮気亭主がいる。妻は自分の夫が浮気をしていると確信できたら、その日の夜にすぐさま夫を殺すべし」。ただし、妻たちは自分の夫が浮気をしているかどうかは知ることができない。そのかわり、国じゅうのそれ以外の浮気している夫はすべて知っている。そして昼間のあいだに「昨日の夜は何人殺されたか」を知ることができる。 1日目の夜が過ぎたとき、誰も自分の亭主を殺していなかった。 2日目の夜が過ぎても、誰も殺されなかった。しかし 13日目の夜に、それなりの数の亭主が一斉に殺された。このとき殺された浮気亭主の数は全部で何人か? そしてそれはなぜか? なお、国民はすべて女王が嘘をつかないことを知っており、他の国民がそのこと (女王が嘘をつかない) を知っているということも知っている。

過程省略。ということでいいのかな。ひとまず最初にこの問題をみた瞬間、どうやったら人狼BBS的にアレンジできるか考えてしまった人はたくさんいるに違いない。あと、最近のデスノートの展開を見たときも同様。

_ 不具合？ (18:11)

東芝HDD＆DVDレコ【RD-X5/XS53/XS46/XS36/XS24】130より、

家の場合R2でM2音声で録画した場合ビットレートにかかわらず起こる事が 確認できました。L-PCMでは確認できません。 ところで前スレでも書いたのですが家の場合音とびの数秒後、音ずれ補正のためかコマ落ちが発生しています。

うちの検証結果と同じだね。 やはり発生条件はR2チューナーでの音声M1/M2録画のようだ。

うーん、Amazonからの発送メールがこない今のうちにキャンセルしておくべきか、迷うなー。片方のチャンネルでのみときどき音飛びが発生する程度だったら、意識して回避すればすむような気もするし、やっぱり使っているうちに我慢できなくなりそうな気もするし。

_ やられた (12:53)

下の子の風邪をまんまとうつされたぜ。上からも下からも状態。最近家族全員別の場所（会社・保育園）に通っているから、風邪菌のバラエティも豊富になって、治った頃にまた新しい風邪をひく状態が続いているなー。もうこれで何週間風邪をひき続けているんだろう。

_ 転送量とか (14:42)

「論壇系ブログのために今できることは何だろうか？」の、

また、送り手のコストの問題として、転送量増加というのも意外な障害である。具体的に、私が現在使っているTypepadで、現在のPlusプランでは１か月3GBの制限があるのだが、拙ブログの現状では2000Hit/日くらいで、このキャップの80%くらいになってしまう。Proレベルにアップグレードすれば5GBまでキャップが増えるが、それもこのまま成長していけばすぐだろう。

あたりを読んで。

MovableTypeって、自動的にgzファイルも作ってコンテントネゴシエーションを利用するような設定にできないのかな？　ほとんどがテキストベースのblogサイトの転送量問題なんて、それでほとんど解決するんじゃないか？

ちなみにblogmapは1ページあたりのデータサイズは結構あるけど、ほとんど圧縮かけているから、1日10万ヒット（8万ページ）でも月間転送量は20Gバイトくらいですんでいる。あ、下りだけの話ね。上りはその3倍くらい。

ただ、ブラウザでHTMLを表示する帯域よりも、RSSの帯域の方が多いようだったら、ちょっと微妙。RSSリーダーで、Accept-Encoding: gzip, deflateしてるやつとかあるのかな？

ちなみに

現在のblogmapのトップページだと、無圧縮で51kバイト、圧縮して10kバイト。ほぼ1/5になっている。

_ バックアップの方法 (17:00)

「Sleipnir作者、開発マシンが盗難に遭う」を読んで。

Windows系の開発者っていまだにバージョン管理ツールとか使っていない人、結構いそうだよなー。いや、Sleipnirの作者さんは、もしかしたらローカルでCVSとか使っていたかもしれないけど。

現状バックアップ環境ってものがいまいち整っていない原因のひとつは、やっぱり手軽なサーバー環境が少ないからだと思う。ふつうのプロバイダが提供するサービスに、WebDAVとかSubversionとか（SSL＋認証設定可能）があれば、結構気軽にサーバーにバックアップを取ったりできるだろうに。

現在一番手軽なのは、さくらの専用サーバーかなー。月6800円という値段は、Web＋メール＋20Gディスクスペース＋安定したネットワーク環境＋電気代等考えれば十分その価値があると思うけど、それを値段分だけ使いこなすスキルが必要ってところが難。Webmin経由でしか設定をいじらないとしても「誰でもできる」というわけにはいかないからなー。

デスクトップLinux関係はいろいろ頑張っているところがあるみたいだけど、個人用サーバーLinuxというターゲットも今後は需要が増えるんじゃないかな。コントロールパネルの発展系なんだろうけど、もっとデスクトップLinux並にターゲットユーザーを低くする感じで。

ちなみに俺は、ここ最近はSubversionをバックアップ環境のメインとして使っている。cron＋pdumpfs＋rsyncとかも試してみたけど、その手の自動バックアップの仕掛けは、ディレクトリ丸ごとバックアップとかになっちゃって、長い間使っているうちに不要なデータがたまりすぎて、たまりすぎたバックアップデータの管理（人間ガベージコレクション）が面倒くさい。

Subversion＋TortoiseSVNだと、自分の好きなタイミングで好きな部分（ディレクトリ、ファイル）だけバックアップできるし、差分も必要最低限しか残らないので、検索性も高い（cron＋pdumpfsだと不要でも定期的にバックアップが取られてしまうけど、個人用バックアップの場合はそこまで完璧なバックアップは逆にじゃまくさい）。あと「ここはテンポラリだから、バックアップ不要」みたいな設定も柔軟に（そのディレクトリだけignoreすればいい）できる。あと、CVSと違ってバイナリのコミットとかファイルの移動とかも気楽にできるし。

ただ、バージョン管理システムというものの概念と、それにまつわる操作のコツがわからないと、ちゃんと使いこなせないだろうな、とも思う（TortoiseSVNを使っていると、普段の操作はExplorerから手軽にできるけど、ディレクトリの移動・削除とか、ファイルの移動とかは、Subversionの仕組みを意識しながらやらないといけなかったりする）。あと、ソースコードのバージョン管理に使うならばSubversionのフル機能（差分管理とか）が必要だけど、単なる履歴付きバックアップストレージとして使うならば、そこまでの機能はいらない。というか、ない方が使いやすい。

ちなみに今まで自分が試してきたバックアップ環境の歴史は、

1. 手動でメディア（フロッピーディスク、MO、CD-R、別ハードディスク）に気が向いたときにフルコピー
2. 半自動で別ハードディスクに差分コピー。ときどき気が向いたときに外部メディアにフルコピー。
3. 半自動で別ネットワークドライブに差分コピー。
4. JUST SYSTEMのInternetDiskサービスと専用クライアントツールを使って、気が向いたときに外部サーバーに差分コピー。
5. pdumpfsで別ハードディスクに履歴付きコピー＋手動rsyncで最新データを別サーバーにコピー。
6. バックアップしたいデータは必ずEclipseのプロジェクトにして、EclipseのCVSプラグインでCVSサーバーに手動コミット（履歴付きバックアップ）。
7. Subversion＋TorutoiseSVNで、バックアップを取りたいディレクトリをExplorer上でプロジェクト化し、必要なときに必要な分だけ手動コミット。

なんて感じかな。順番はだいたいあっているけど、必ずしもまっすぐ下に下りてきたわけではなく、途中で行ったり戻ったりも結構ある。そういや昔々のデータって、家のどこかにふるーいHDDという形式で埋まっているんだよなー。DOS/VとかWindows 3.1とかの頃のIDEとかSCSIのハードディスクからデータを吸い出すのは、今となっては大変そうだ。

あとちなみに、ここに書いたのはあくまでも個人的なデータのバックアップ方法であって、サーバーのデータとか仕事関係のデータのバックアップについてはまた別の話。

_ mylistのRSS出力 (04:45)

ずっと放置中のtextmania。最近巡回手段をBloglinesベースに移行しつつあるんで、自分でもほとんど使っていない。というか、textmaniaのmylistからBloglinesに移行できたものは削除していったところ、7割くらいは移行できたんで、何となくそれで満足してしまってBloglinesに移行できたサイトだけをチェックしてしまい、mylistに残されたサイトはほとんど見てなかったりする。とかいいつつも、いくつかのサイトはi-knowとかlivedoorチェッカーズ（これ、名前がイクナイと思います）とかを経由してBloglinesに登録していたりするんだけど、どうせならtextmaniaのmylistをそのままRSSで出力してBloglinesに取り込めるようにした方が便利だろうなー。自分の分だけだったら30分くらいあればできるんだけど、汎用的に改造するとなると、根本的なところから作り直したくなるんで困る。

_ いったんキャンセル (06:38)

Amazonから発送メールはこないし、不具合関連の情報もずいぶん信憑性があるっぽいし、通販だとその後の展開がややこしくなりそうだから、Amazonでの注文はいったんキャンセル。近所のケーズデンキで138000円くらいの値札が付いていたから、交渉すれば13万円くらいまでは下がりそうだし、買うならそっちで買うことにしよう。その方がいざ交換とかなったときが楽そうだ。

_ コメント削除＆MM/本のメモとの連携強化 (13:17)

最近しょうもない投稿（宣伝とか死体画像求むとか子供の喧嘩とか）が多くて、メンテナンスが面倒なんで、blogmapからコメント投稿機能を削除した。あと、MM/本のメモとの連動を強化というか、今までよりも目立つように表示するようにした。あと、MySQL 4.1にアップデートしたときに文字化けしまくっていたTrackBackのデータを、ようやく古いDBバックアップから復元した。

_ 買った (19:32)

昨日帰りがけに近所のケーズデンキに寄ったら、168000円の値札に取消線が引かれていたんで、いくらになるか聞いたら、消費税込み5年保証付きで138000円と言われて、130000円にならないか聞いてみたらあっさりOKが出たんで、そのまま買って持って帰ってきた。ネット上での最安値は125000円くらいまで下がっているみたいだけど（Amazonも還元を入れればそのくらいか）、音飛び不具合の話とかも出ているし、多少割高でも近所で買った方が安心かと思って。

で、ひとまず最初にはまったのはLANケーブル。付属のケーブルはクロスケーブルなのね。使えねー。っつーか最初LAN端子自体が壊れているのか疑っちゃったよ。最寄りのハブからはそこそこ離れているんで、収納をあさって昔部屋と部屋の間を結んでいた15mもののケーブルを見つけ出して接続。でも10mくらい余ってるけどなー。

次にはまったのは、スカパー！のチャンネル設定。最初スカパー！のチャンネル番号はC0000-XXXというのにあわせるのだと勘違いしていて一通り設定したところ、スカパー！連動の対象にほとんどのチャンネルが出てこない。ただ、いくつかのチャンネルは出てきているあたり、混乱は深まった。けど結局正解は、スカパー！のチャンネル設定はC1000-XXXなのね。で、ときどき（条件不明）ごく少数C0000-XXXじゃなきゃ動かないものも混ざっている模様。C1000-XXXに修正し、それで通らなかったものだけC0000-XXXに直したらちゃんと動くようになった。ちなみにうちのスカパー！チューナーはソニーDST-SD5だけど、チャンネルも電源もちゃんと連動した。ただしチャンネル連動はやたらと遅いなー。昔ソニースタイルのお試しコクーンで連動は使ったことがあるけど、あれよりもさらに遅い感じがした。

ちなみにRD-X2からの乗り換え者としては、基本性能にはものすごく満足。タイトルの削除とか、RD-X2では1タイトル消すのに30秒以上（1分以上かな？）かかってたからなー。X5ではふつうに1秒くらいで消えるのにものすごくほっとした。あと当たり前だけどiEPGは偉いなー。毎回情報を取得しにいくみたいで最初に番組ナビを開くときがちょっと重いけど、ふつうに地上波もスカパー！もまとめて番組表から予約でき、それがそのまま録画したデータのタイトルとか番組詳細に付加されるのはとても便利だ。

ただ、PCとの連携は思ったよりも不便だなー。っつーか、iEPG周りの仕様はものすごく変な実装になっているんだね。インターネット上の一般向けiEPGサイトに対するプロキシーとしてRD-X5が働き、もしもユーザーがiEPGリクエスト系のデータを開こうとしたら、それを強引にフックしてRD-X5への予約に変換をかけているのか。そんな妙な挙動のせいで、別ドメイン名のSSLを使ってリダイレクトをかけるようなiEPGサービスだとうまく動かない（回避策もありそうだけど、まだその辺真面目にやってない）。しかも東芝標準で提供しているiEPGサイトはスカパー！非対応だし、基本的なできも良くないみたいだし。

インターネットテレビガイドとかテレビ王国とかONTVとか使ってみた結果、結局ONTVを使ってみているんだけど、ONTVもログインするとSSLページのドメインが違うんで、パーソナライズされた番組表がRD-X5のプロキシー経由で使えてないんだよなー。あとONTVってスカパー！チャンネルはどっちにしろパーソナライズできないっぽいし。

っつーか、RD-X5本体が持っている番組表機能をそのままPCで使えるようにはできないのか？　俺的には番組ナビの機能で十分なんだけど、テレビの画面の解像度じゃ物足りないから、それをPCの解像度で使いたい。それだったらスカパー！のチャンネル設定とかもちゃんと反映させてくれるし。

ああ、そういやVirtualRDとVideoLAN Clientを使って、無線LAN（g）ごしのノートPCで録画データの再生もできた。けど、再生を開始する作業はテレビ側の画面を見ながらじゃないとできないし、再生中は本体で他のこともできなくなるみたいだし、あんまり使えないかもね。

とかまあ書き始めるといろいろあるけど、まだちょっとさわり始めた程度でわかっていないところもたくさんあるんで、もうちょっと使い込んでからちゃんとした感想を書こう。

_ RandomeNote/PHP with TypeKey Authenticationテスト中 (15:15)

RandomNoteをPHPにポーティングしたバージョンに、PHP版TypeKeyライブラリを使ってTypeKeyによる読み書き認証とmixiライクな足跡機能を取り込んだバージョン。現在、

• http://rntk.ishinao.net/

にて実働テスト中。

現在の設定では、閲覧は誰でもOK、編集はTypeKeyログイン必須だけどログインしたら誰でもOK、にしてある。設定によって、完全オープンから読み書き（特定ユーザーのみ）クローズドまで自由に変更できる。あと、個人的な趣味でWiki記法をtDiary Wikiスタイル互換（というか、Wiki Wayを参考にもっとも標準的と思われるWiki記法に近いもの）にしてある。

基本的な機能は一通りできているんだけど、設定周りとかまだ煮詰め中＆TypeKeyのverifyにときどき失敗する原因もできれば調査しておきたい＆ドキュメントとか著作権表示周りとかもちゃんとしないとな状態なんで、配布版はまだできていない。一応xreaのs57サーバーでも動いた。

ひとまずこれで、TypeKeyを使った認証が単なるSPAM対策だけでなく、一般的なWebアプリでも十分有効に使えることが十分テストできたならば、次は同じ仕組みを使った日記（あるいはblog）ツールを作るつもり。これとTypeKey SNSを使った、認証情報の複数Webアプリでの共有の仕組みを用意すれば、はてなダイアリーというかmixi日記というか、的なシステムをオープンなインターネット上に構築することができるはず。

Rubyのお勉強が間にあえば、この仕組みをtDiaryにも組み込んでみたいところだけど、Rubyのお勉強をしているくらいだったら、PHPとかPerlでスクラッチから組んだ方が早そうなんだよな。というわけで、そっち系は後回し。というかもし本当に有用そうならば、tDiary系の人たちが勝手にそういうのを作ってくれそうだし。

でもまあ、ひとまずこのネタで遊べるのは今日でいったんおしまいで、次に手をかけれるのは来年になってからかもしれない。となると、不完全でも現状バージョンを公開しておいた方がいいのかな。

一応アーカイブにまとめた

• http://rntk.ishinao.net/archives/rntk_041122.tar.gz

ドキュメント類は適当。いろいろ足りない部分とか修正し切れていない部分とかあるかもしれないけど、その辺はおいおい直そう。というか、ちゃんと直している暇がしばらく取れないっぽいんで、自助努力推奨。

ライセンスに関しては、本体をいじったものについては、オリジナルのRandomNoteおよびRandomNote/PHPに準じてフリーソフトウェア。平田さんのAuth_TypeKeyの修正版も同梱してあるけど、それについてはPHPライセンス。あとさらに独自のTypeKey認証コードが別ファイルで追加されているけど、その部分はLGPL扱い（というか、別ソフト用にLGPLとして組み込んでいたコードを改変流用しているんで）。

どういう風に使うものか？

いろいろ利用例はあるけど、ひとまず思いついた例を以下に。

自分用メモ帳

アクセス権限を閲覧private、編集privateに設定して、管理者として自分を登録しておけば、自分専用のメモ帳になる。他の人は閲覧も編集もできない。

身内用メモ帳

上記設定で、閲覧許可ユーザー、編集許可ユーザーを設定すると、あらかじめ登録したユーザーのみ閲覧・編集可能な共有メモ帳になる。許可・拒否ユーザーは、管理者権限があればWeb上から追加可能。

誰が編集したのかがわかる

編集権限をprotectedもしくはprivateにして、足跡設定をedit => TRUEにしておくと、編集した人が誰なのかが足跡に記録されるようになる。もしもいたずら等された場合は、そのユーザー名をアクセス拒否リストに追加することで、以降そのアカウントからの編集は拒否することができる。

誰が見に来たのかわかる

閲覧権限をprotectedもしくはprivateにしておいて、一覧表示時にReadMoreが表示されるようにしておき、足跡設定をshow_leaf => TRUEにしておけば、そのドキュメント（の詳細）を閲覧した人がわかる。

編集のみ自分/身内専用

閲覧権限public、編集権限をprivateにしておくと、単に閲覧するユーザーにはTypeKeyアカウントはいらない。編集は登録ユーザーのみが可能。

_ 今日は麻雀大会 (08:33)

今年はやる気でねーな。っつーか、帰って寝たい。体調悪すぎ。

_ 半荘一回目＋57トップ (10:02)

_ 結果 (22:01)

結局半荘6回で、最初から5連続トップ、最後の1回だけ2着という結果で、今年の大王様になりましたよ。勝因は、とても体調が悪かったんで、ほとんど無理をせずに同じペースで打ち続けていたことでしょうか。具合の悪い中半荘6回も打つともうふらふらで、打ち上げでもろくに酒を飲めず、帰りの電車では半分気を失いながら、なんとか家までたどり着いたのでした。

_ 本文読まずにコメント (13:26)

mixiネタを書いた日付の日記に、（「mixi」で検索してやってきたらしい、本文をろくに読んでいないっぽい）見知らぬ人が「mixiに誘ってください」とメルアド付きのコメントをつけるケースが最近増えているというネタをあちらこちらで見かけたけど、俺はそれよりもうちの日記に「トリビアの泉」で検索をかけてやってきて、オリジナルのトリビアらしきものを書き込んで、あまつさえ「よろしく！」とか書くのはやめて欲しいの心。俺は番組への応募代行なんかしないぞ。あと、自分が最近知ったからといって、それが世間でも珍しい知識だと考えるのはやめた方がいいと思う。

あ、ちなみに

その手の投稿は見つけ次第削除（非表示）にしているんで、検索しても見られないです。っつーか、そこのコメント欄はオリジナルトリビアの投稿だけでなく、いたずら投稿もやたらと多くてうんざり気味。

_ いつもより多く回しています (15:24)

blogmapのバックエンドでリストラ中に付き、いつもより多めにbotが回ってます。ちょっとご迷惑をかけることもあるかもしれませんが、再帰とかリトライとかはしていないので、あんまりひどい挙動はしないはずです。巡回先の方、ちょっとの間ご辛抱ください。

_ Windowsで「&」を含むファイル名が扱えない (19:39)

具体的には、「&」以降のファイル名がExplorerなどから見えなくなる（んで、アクセスしようとするとエラーになる）。WebDAV Resources JP Download Pageにある015_escape_amp.gzを当てると直る。なんかWebDAV周りの情報って古い情報が多すぎて、今現在有効な情報がどれなのか探すのが辛い。

_ 信頼性データベース付きシングルサインオンサービス (10:13)

「小倉秀夫の「IT法のTop Front」：残念！！」より、

これで、BLOG事業者は発言者のトレーサビリティを確保するためのシステム作りを行うことは自主的には行い得ないということになってしまいました。

って、そこまで言い切りますか。せいぜい「blog事業者が発言者のトレーサビリティを自主的に確保したいのならば、もっとちゃんと準備してからやらなきゃダメだよ」程度じゃないかと思うんだけど。

俺ははてなが、今回のようないまいち練れていないやり方ではなく、実効性と安全性をきちんと確保した上で、住所なりなんなりを担保にした方がよりよいサービスを提供することができるというのなら、住所を登録してもいいよ。っつーか、俺の身元なんて元々隠してないしさ。

まあでも、はてなが単体でやるよりも、

BLOG事業者団体で共同出資した利用者情報管理会社が発行するＩＤ、パスワードを使用する等、トレーサビリティを確保するための仕組み

みたいな方法がいいかもなー。っつーか、シックスアパート日本法人あたりとTypeKeyをそういう用途で使えるようにできないか話し合うとか、あるいは日本のblog事業者が協力して身元保証付きのTypeKeyっつーかシングルサインオンサービスを作ったらいいんじゃないか？　いやまあもちろん、Microsoft PassportとかLiberty Allianceとかと協力してもいいんだけどさ。

個人的には、ドメインベースの信頼性格付けデータベースなんかを民間有志で作成・運用して、みんな自己責任でその格付けを使うってのも悪くないかなーとか思ったりする。要は、どのドメインを名乗るメールアドレスやホスト名は、どのくらい信頼できるのかというデータベースね。

メールアカウントで認証するようなサービスを構築しようとした場合に、フリーメールアドレスとかは信用できない＆多重アカウント防止のために弾きたいってことはよくある。

けど、網羅されたデータベースってないから、自前で一生懸命フリーメール／転送メールドメインデータベースを作ったり（海外サービスまで含めると、悪意のある相手に対応するのはものすごく難しい）、あるいは逆に信頼できるドメインデータベースを作って（国内プロバイダ一覧とかから作れるんで、こっちの方が安全に作りやすい。要望があったら追加していけばいいだけだし）それ以外を弾いたり、といったことになる。

こういうことをやりたい事業者はたくさんいるだろうから、そういうところで金を出し合ってデータベースをメンテして、できれば一般に無料でデータベースを配布してくれるとうれしいな。もし資金に余裕があるなら、認証API（Web Service）とか、信頼性データベースと連動したシングルサインオンシステムなんかも載せてもいいかもしれない。そこまで行ったら、そのデータベース上で直接ユーザーの個人情報を預かって、ドメインベースではなく個人ベースの信頼性情報を返せるようにできるかな。

_ 「泣き言」だよね (14:27)

「三浦淳、ヴェルディ“癒着”に三下り半」の、

ところが、アルディレス監督が「どうしても、東京Ｖに残りたい」と態度を一変させたから、話はややこしくなった。結果の出ない指揮官の泣き寝入りをあっさり聞いてしまうのが、かつて黄金時代を築きながら一気に衰退の道を歩んだ東京Ｖの悪癖の一つ。

「泣き寝入り」だったら、あっさり契約破棄させてくれるんじゃん？