_ ダメだ、とまらん……。ねむい……

2chの「家は宿でも合宿所でもねぇぞ!!!」スレッドは、肉般若のあとしばらくあたりまで見ていたんだけど、ネタ疑惑推理合戦とかが始まってだるくなったあたりから見ていなかった。それがもう70なんて数になるまで続いていたんだねー。

ちなみにこのスレッドの主旨はというと、オタクな趣味を持っている人たちの中には、かなりキテいる厨房（精神年齢が正常な社会生活を営めないくらい低い人たち。実際の年齢も低い人も多い）含有率が高く、しかもそういう人たちは趣味を同じくする人たちに対して、普通の脳みその持ち主には予想もつかない方向から、迷惑をかけることが多々ある（特にコミケとかアイドルやバンドのライブとかみたいな、その手の趣味の人たちが集まるイベントが存在するようなカテゴリの場合に、危険度が高いらしい）。

彼らの行動は普通の脳みその持ち主には予想もつかないのだが、どうやら同じような迷惑をかけられた人たちの話を総合すると、彼らには彼らなりの法則性（パターン）があるようだ。たとえば、「趣味が同じ＝親友も同然＝一緒に住む／泊まりに行くのは無許可でOK」とか、「前世／異世界信者（今ここにいる自分は本当の自分ではない、という逃走系妄想）率が高い」とか、「私はあなたのことが好き＝あなたも私のことが好きなはず＝あなたのものは私のもの」とか。

で、このスレッドではそういう迷惑をかけられた体験談を各自が語って情報を集積しつつ、その手の危険に対する現実的な対抗策を構築していったりもしてみよう、なんてことになっている。「(=゜ω゜)ノぃょぅ好き」ってところは、2chの関連スレッド上で同時進行的に語られる複数の話題を、読みやすく編集してまとめて掲載しているところ。

で、2、3日前にここを読み始めたところ、もうとまらなくなってしまった。12時過ぎに家に帰って1時過ぎにベッドに入って、眠くなるまでここを読んでいるかと思っていると、いつも気がつくと3時4時になってしまう。ムスコを保育園に送るために8時には起きなければならないのに……。

ここの話は、下手なサスペンスドラマ／小説を見るよりも絶対面白いな。被害者には創作系同人者が多いから、エンターテインメントってものを心得ているためかもしれない。その分ネタ疑惑も強くなるわけだろうけど、ネタだろうとネタじゃなかろうと面白ければいいのだ。ネタの中にも幾分かの真実は含まれているものだし。

_ 掲示板にベイジアンフィルター (13:49)

2chみたいな掲示板システムに、ベイジアンフィルターはとてもマッチすると思うのだけれども、導入しないのかな。フィルターの調整とフィルタリングの判断は結構難しそうだから、on/offをユーザーが選択できるようにして。ひとまず2chブラウザーとかで実験してフィルターの設定を調整していけばいいんだろうな。でもまあ自分で作ろうとは思わないけど。

_ 2003F1オーストリアGP (13:49)

予選1日目

久しぶりに録画を忘れなかった。金曜日に放送されると見忘れるから、土曜日の2日目の頭にもダイジェストを放送して欲しいなー。ってのはスカパーの話ね。地上波放送は全然見てないからどうなっているのか知らない。

で、ここ数戦予選1日目を見ていなかったせいで、その意味をどう判断すればいいのか非常に難しくなってしまった。最初の頃は「本気でタイムアタックしたら速い車がどれなのかわかるセッション」だと認識していたんだけど、結局予選1日目のグリッドはレースの最終結果にとってはあまりにも意味がないということで、各チーム各ドライバーの予選1日目に対する本気度がとても読みにくい。

従来の予選だったら、後からアタックする人間が前にアタックした人のタイムを見ながら、どこまで無理をするかの調整が出来ただろうけれど、今年のレギュレーションみたいに1回しかアタックできない場合は、自分の中で「1回しかタイムアタックできない（ミスが出来ない）中でのベストアタックをする」という走り方しかできないだろうし、その中で状況に応じて（現在の他車のタイムを見て）変えることができる幅というのは、各ドライバーそれほど大きくなさそうだ。あるいは変えることによるメリット・デメリットを比べるとメリットが大きくないのかな。というわけで、予選1日目に上位にきても、予選2日目のメリットがあまりないと考えているドライバーが多そうだ。

でまあ結局今回の予選1日目で分かったことと言えば、相変わらずフェラーリ（の新車）は速そうで、中でもミハエルは速そうで、マクラーレンはそこそこだけれどもフェラーリには勝てそうに見えなくて、ウィリアムズは速いけれども落ち目という感じで、ルノーはやっぱりテクニカルサーキットじゃなきゃすごくはなさそうで、BARは予選だけはそこそこ速いけれども本戦には全然つながらなさそうで、ジャガーもBARっぽくて、ファーマンは相変わらずダメだったって感じか。

予選2日目

セッション最後の方になって、前にアタックした車たちがセッションストップにならない程度に路面を汚して、その結果予選1日目に上位タイムを出したドライバーほど不利になるという展開は、（端から見た）話を面白くするという意味ではいいけれども、走っているドライバーにしてみれば納得いかないよなー。それでもポールのミハエルはすごいなー、という感想。

決勝

最後尾スタートのドライバーがスタートできなくなっても、再スタートにする必要はない気がするぞ。勝手に止まっていてくれればほかのドライバーのスタートの邪魔にならないし。

で、微妙に雨が降ったり、オイルをまく車がいたり、ミハエルの車の給油口が火を噴いたりしつつも、最終的にはミハエルの楽勝レース。トラブルがあってもまだ楽勝とは、本当に地力に差があるなー。あとバリチェロは、相変わらず速いんだけれども強さが足りない。ライコネンを育てるいいライバル（しかも将来倒されること前提。っつーかもう倒されてる？）になりつつあるぞ。ライコネンはミハエルがいなくなった頃に天下を取れそうだなー。となると、フィジケラ、トゥルーリあたりは、タイミングが良ければ（ミハエルがいなければ）天下を取れたのに、ってポジションになってしまうのかな。

それにしても、今年のウィリアムズは運もなさそうだ。FW14の貯金が尽きたときの悪い状態を思い起こさせるよ。FW16だっけ？（検索したところ、そういえばあれはセナが死んだ車だったよ）　もともとすごく良かった車が少しずつ（相対的に）悪くなっていって、速いタイムを出せなくもないけれども運転しづらいし結果も出にくい、みたいな。ただ今回はピーク時にもチャンピオンシップを取れなかったってのは痛いね（って、もう終わったように言うなよ）。

そういやBARは今回決勝も速かったね。でもまあこのコースで速かったところで、次戦以降にさほど期待出来るわけではないけれど。トヨタもなかなかいい結果が出ないなー。ところでトヨタってまだダラーラ・ジャッドヤマハな感じなのかな？　それとももう完全にトヨタチームって感じになっているんだろうか？

_ また警報機が壊れた (2) (13:51)

結局店では再現しなかった、とのこと。ただあんまりちゃんと（長時間）テストをしたわけではなさそうだ（営業時間もしくは作業員がいる間だけ警報をオンにしていたらしい）。どうも向こうではセンサー過敏だったってことで話を終わらせたいんだろうなー。まあ再現性が今のところないし、そう処理したい気持ちはわかるけれども。一応、また起こるようだったら別の機種と交換するという話だったんだけど、これから日々夜中とか早朝とかに誤警報が鳴ることを気にしながら生活するのはいやだなー。ふつうの（センサー過敏の）誤警報みたいに、30秒だけ鳴って止まるならばまだいいんだけど、今回の症状は人間が止めるまで延々と（最初に鳴ったときには数分間鳴りっぱなしだった）鳴り続けるから、近所迷惑度がしゃれにならないほど高いんだよなー。自費で別の警報機に載せ替えることも考える必要があるだろうなー。

_ 認証の維持とセッション管理の違い (09:11)

「認証の維持」といわゆる「セッション管理」とはちょっと違う。

一般的なユーザー認証では、サーバー側にIDとパスワード（のハッシュ）という情報を持ち、ユーザーがフォームから入力したIDとパスワードの組み合わせを、サーバーの持つ情報と照合することによって認証処理を行う。

ただし、毎回フォームでIDとパスワードを入力するのは面倒なんで、一度入力したIDとパスワードは、2回目以降いちいち入力せずに認証処理を行いたい。要するに一度入力されたIDとパスワードを覚えておいて使い回したい。

BASIC認証とかのブラウザが対応している認証方式の場合は、ブラウザの機能として覚えてくれる。そして、アクセスのたびにIDとパスワード（のBASE64エンコード）が送られ、毎回認証処理が行われる。ちなみにBASIC認証で送られるパスワードのBASE64エンコードは可逆なので、パスワードを平文で送っているのと大して変わらない。

ブラウザの標準機能を使わず認証を行う場合は、Webの標準的な機能を使ってIDとパスワードを覚えておかないといけない。そこでCookieが使われることになる。IDとパスワード（平文あるいはBASE64のような可逆エンコード）を覚えておくというのが一番単純なやり方（初回にフォームからIDとパスワードが送られたときと同じ照合コードが使える）だけど、ちょっと安全性を高めたければ、IDとパスワードのハッシュ（非可逆）を覚えておく。

サーバーサイドには、IDとパスワード（のハッシュ）の組み合わせしか認証チェック用の情報を持たないことが前提なんで、ブラウザから送られる情報は、サーバーに保存されているIDとパスワード（のハッシュ）を使って照合可能なデータである必要がある。

一方（いわゆる）セッション管理というのは、基本的には認証とは関係なく、単にあるブラウザからの連続したアクセスを同定し、複数回のアクセスにおいて状態（データ）をサーバー上で保持（認識）したい、という話だ。

そのためには、あるブラウザからのアクセスを特定するために、ブラウザごとにユニークな識別IDを割り振り、それを使用する。それがセッションID。そのセッションIDも基本的にはCookieに保存することになる。

セッションIDはユニークであれば連番とかで生成してもいいけど、連番で生成したセッションIDの場合、他の人のセッションIDが類推できてしまう。たとえば自分のセッションIDが100だったら、「きっと99とか101とかの人もいるに違いない」とか。だから、セッションIDはできるだけ類推の効かない（ランダム性の高い）ものを使うことで、安全性を高める必要がある。

セッション管理を使えばあらゆる状態を維持することができるんで、もちろん認証の維持にも使うことができる。セッション管理の仕組みを認証の維持に使うことによって、IDやパスワードと直接結びつくデータを毎回送信する必要がなくなり、安全性が高まる。

またいわゆるセッション管理機能を使わない場合でも、直接IDやパスワードと結びつかないランダムでユニークな認証キーをサーバー側で生成し、サーバー上でIDと結びつけておくと同時に、ブラウザにその認証キーを覚えてもらう。そして、その認証キーを利用して認証処理を行うことによって、直接IDやパスワードに結びつく情報のやりとりを最小限に抑えることにより、安全性を高めることができる（他にも方法はいろいろある）。

ただし、セッションIDやランダムな認証キーを利用する場合でも、直接IDやパスワードと結びつくデータが流れないというだけで、セッションIDやランダムな認証キー自体が直接認証機能と結びつき、それを悪用されることで認証処理を乗っ取られることに代わりはない。

また、せっかくセッションIDやランダムな認証キーを利用していても、その有効期間が必要以上に長い場合は、結局その文字列自体をパスワードのように利用することができ、セッションIDやランダムな認証キーを使っているからより安全だ、とは言い切れない。もちろんCookieが漏れるような設計だったら、セッションIDやランダムな認証キーを利用していても意味がない。

って俺は毎日なんでこんな文章を書いているんだろうなー。

ところで、JavaScript必須でチャレンジ＆レスポンスとかやっている例ってあるのかな？とふと思った。

_ IPAから返事が来た (16:05)

昨日の問い合わせの返事が来た。なかなか早いなー。すげー時間がかかるかと思ったのに。ちなみに内容は以下の通り（公開許可取得済み）。

IPA セキュリティセンターです。

お問合せいただきました件ですが、脆弱性関連情報の個々の取扱いの詳細に関するご質問につきましては、回答を控えさせていただいておりますので、ご了承下さい。

本件が脆弱性であるかどうかの判断は、2004年7月7日に経済産業省より公示された「ソフトウエア等脆弱性関連情報取扱基準」（平成16年経済産業省告示第235 号）および、「情報セキュリティ早期警戒パートナーシップガイドライン」に基づき行ないました。

詳しくは IPA ウェブサイトの「脆弱性関連情報の取扱い」より、それぞれの資料をご覧下さい。

http://www.ipa.go.jp/security/vuln/

以上、よろしくお願いいたします。

ということで、個々の取り扱いの詳細については答えてもらえないそうだ。まあ確かに細かい問い合わせにいちいち答えてられないだろうしなー。詳細に答えてもらいたければ、聞く方もそれなりの手続きをふまなきゃだめなんだろう。

で、返答のメールに書かれていた「ソフトウエア等脆弱性関連情報取扱基準（PDF）」および「情報セキュリティ早期警戒パートナーシップガイドライン（PDF）」を読んでみる。

「脆弱性」の定義は、前者では、

ソフトウエア等において、コンピュータウイルス、コンピュータ不正アクセス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者がアクセス制御機能により保護すべき情報等に誰もがアクセスできるような、安全性が欠如している状態を含む。

後者では、

脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。

なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適切な運用によって、個人情報等が適切なアクセス制御の下に管理されておらずセキュリティが維持できなくなっている状態も含みます。（ウェブサイトの不適切な運用に関しては付録４に示します。）

となっていた。

「攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所」の解釈がポイントなんだろうな。俺は「具体的な攻撃手段」が存在した上での「安全性上の問題箇所」が「脆弱性である」と考えるんだけど、ポイントを「安全性上の問題箇所」にある（具体的な攻撃手段はどうでもいい）と読む人もいるんだろうな。

個人的にはすごく納得がいかないんだけど、これ以上追求するのは大変そうなんで、ここまで調べた段階でしばらく様子を見ることにしよう。

様子を見るといいながら

やっぱり気になったんで、もう1回だけIPAに聞いてみることにした。内容は

「具体的な攻撃手段」が存在しない場合でも、「セキュリティ上の問題箇所」が存在すれば、「脆弱性」であると解釈されるのでしょうか？

といった感じ。

粘着ですまんのー＞IPAの担当者の方。でも今後の開発指針とかにいろいろ影響が出るんで、つっこんで聞いておきたいところなんだよなー。

っつーかぶっちゃけ、HTTPで認証をやっているありとあらゆるものは、すべて脆弱性だっていう判断だって、全然おかしくないわけよ。というか、現状のインターネットははっきり言ってゆるゆるのがばがばなわけだよ。だから、ヒジョーにキビシク脆弱性認定を行うことで、「痛みを伴う改革を断行しよう」とか言われたら、それはそれで納得できるわけよ。で、その辺どうなの？