雑記

◆ ZDNet

ここのところ，ZDNetのWebバグサイトが良く落ちてますねぇ．今もcgi4.zdnet.co.jpにアクセスしようとすると，TCP_ERRORが返ってきます． 例えば，メールで送られてくる記事のURLが

http://cgi4.zdnet.co.jp/g/01_0309030f10_/enterprise/0309/02/epn16.html

となっている場合，

http://www.zdnet.co.jp/enterprise/0309/02/epn16.html

のように書き換えれば記事を読めることが知っていますが，通常はWanderlust(xemacs)を使っていて，メール内のURLをクリック一発で参照しているので，なかなか面倒です．
そうそう，私は上の方法をmozillaと組み合わせて使っているのですが，(少なくともこのペアだと)起動済みのmozillaがあればそれにリクエストを投げてくれます．この機能を利用してxemacsをリモートホストで起動した際，あらかじめmozillaをローカルホストで起動しておくようにすると，私の自宅─職場間など回線が十分太くはないときには応答速度がけた違いに改善します．xemacsは重くないんかいと突っ込まれそうですが，画像とか無いのでこっちのスピードは十分許容範囲．

◆ と思ったらWebバグ廃止??

上の記述は「ZDNet Wire 03/09/03 朝刊」での挙動を元に書いていたのですが，私の手元に届いた「ZDNet Wire 03/09/03 夕刊」のURLからWebバグと思しき文字列がきれいさっぱり消えていました．(手元に残っているメールによると)去年の5月24日にこれについて，「どういう情報を集めているんですか?」と問い合わせたときには無視されてしまったのですが，今回の措置は時代の流れですかね．

にしても，今回のWebバグの廃止と同時にサーバも停止したのでしょうか? だったらちゃんとその旨ユーザに伝えた上で，しばらくは参照先の記事に自動的に飛ばす機能だけは残しておいてくれれば良いのに．

◆ ZDNet続き

批判を受けてWebバグをやめたのかと思っていたのですが，どうやらそうではないようで，「ZDNet Wire 03/09/04 朝刊」に以下のような説明がありました．

【お知らせ】
　9月3日、メールマガジン掲載URLリダイレクトサーバ （メールマガジンから記事へジャンプする設定を行っているサーバです）を 変更いたしました。
　URLリダイレクトサービスは、問題なく動作しているのですが、 リダイレクトサーバのIPアドレスを準備期間無く変更致しましたため、 ご利用中のネットワークのDNS ・ DNS キャッシュ環境により、 IPアドレス変更が浸透するまで、若干の時間がかかります。 早ければ数時間、遅くとも2、3日と思われますが、長引くケースもございます。
　お手数をおかけしますが、いましばらくお待ちいただけますでしょうか。 なお、対応までは、既配信のメールマガジンは、http://cgi4.zdnet.co.jp/の部分を http://210.166.237.129/と直接IPアドレスを参照していただくことで アクセスしていただけます。

「メールマガジンから記事へジャンプする設定を行っているサーバ」という説明や「URLリダイレクトサービス」というネーミングはいかにも誤魔化していますといった感じです．私の問い合わせに対して，いったんは

メールマガジンのリダイレクトについてですが、弊社でのマーケティングの一環として行っております。

という回答をしているので，情報収集に使っていることは間違いないのですが．．．

ちなみに，「ZDNet Wire 03/09/04 朝刊」でのURLの表記は

http://210.166.237.129/g/01_0409030110_/enterprise/0309/03/epn08.html

といった感じでした．数日間はこの形式でしのいでまたもとの状態に戻すんでしょう．あと，私の記事録からのリンクはWebバグを外した記事本文へのリンクとなっていますのでご安心を．

◆ フラッシュ

upload.rbに対して「フラッシュファイルにも対応してください」という要望が来たので，TODOリスト内の優先順位を大幅に引き上げて勉強．

「インストールだけはしてあった」という状況から初めてこのページを参考にちょこちょこと作業をしたところ，1時間ちょいでこの程度のサンプルは作れるようになった．うーん，けっこう面白い．でもこれで今回の目的はクリアしてしまったので，再びTODOリストの底に沈むことになりそうな予感．

◆ 不振なログ

私が直接管理している職場のホストから毎日届くセキュリティチェックメールを読んでいたら，最近ほとんど使っていなかったホストに，いつも利用しているホストからの私のアカウントでの身に覚えのないsshのログイン失敗の記録が．あちゃあと思ってアクセス元のホストのログを漁ったり，chkrootkitでチェックをかけたりしてみたものの，何も出てこない．よほどうまくやられたのかなと意気消沈しつつ，ログの残っていたホストにおそるおそるログインし，いろいろとチェックするも，やはり何も出てこない．大元のログファイルを見てみると，メールに記録されていたログそのものが見つからない．あー，こっちもやられたのかあ，こりゃ大仕事だぁと覚悟を決めてから，ふと思いついてgrepをかけると該当ログが表示される．おやぁと思ってもう一度よくよく見直すと，なんと去年の記録でした．ログのローテーションをファイルサイズで行っていたため，「最近ほとんど使っていない」上，「私以外の人は全く使わない」ホストだったことが災いして，過去の記録がいつまでも残っていたようです．そうやられてみるとsyslogって確かに年の情報は記録しませんね．

午前いっぱい潰れちゃったよ．はぁ．まぬけ．

◆ 鳥人間コンテスト・人力プロペラ機部門

いやぁ，結果は知っていてふぅんという感じだったのですが，番組を見てちょっと感動してしまいました．日大の不敵なまでのフライト・着水と東工大のトラブルをかかえながらの必死のフライトが見事なまでに対照的で，勝った日大がちょっとヒールっぽく見えてしまったのはかわいそうでしたが．
ここ数年の結果を見ると，今年の結果は破格のようで，日大の選手もまだ体力的に余裕があったようですが，何か技術的なブレイクスルーがあったのでしょうか？ たまたま条件が良かっただけ？？ あとできれば日本記録を先日塗り替えたヤマハのチームエアロセプシーにも同じ条件で飛んで欲しかった．
滑空機部門は番組の存在に気づいたときには終わってました．

◆ いまさらですが

RFID反応リンク集などを読み返していてふと思ったのですが，RFIDって「同一商品内でユニークなID」であれば売り手が管理するには十分で，かつ買い手のプライバシーも守れるんじゃないでしょうか．つまり，よく話題にされる書籍を例にとると，Aというタイトルの本1冊1冊に付けられるIDと，Bというタイトルの本1冊1冊に付けられるIDを，むしろ積極的に重なるように割り当ててしまうのです．もし，ある本が古本屋に売られようとした場合，本のタイトル(もしくはISBN)とRFIDの組み合わせで照合すれば，その本が万引きされたものかどうかは検証可能です．一方で，バッグの中に買った本を入れているときにスキャナで読み取られたとしても，その本がAなのかBなのか，さらに言えばそのIDをもつモノが本なのかどうかすらも，実際にバッグを開けて中を見てみなければわかりません．唯一特定できるケースは海パンいっちょうの時ぐらいでしょうか:-)．同じ仕組みをお金に応用すれば，所持金の額を知られる心配もありませんし，世の中に同一IDがたくさん存在するような状況を作り出してしまえば，いわゆるビッグブラザー問題も起きにくくなるような気がします．
想定される反論として，「同一IDが複数存在することを許すと，万引きされた本が売られようとした場合には発見できるが，万引きそのものの防止に使えなくなる」というのが考えられるので，ちょっと拡張しましょう．といっても手法は単純で，ID内に書き換え可能な管理用の領域を追加するだけです．書店は本を入荷した時にこの管理領域に店舗固有のIDを書き込み，レジを通すときに消します．あとは出入り口のスキャナで管理領域に書き込まれたIDをチェックするだけです．この領域に書き込むIDをちょっと工夫すれば「同一店舗に同一IDをもつ複数の本が存在する」場合の管理も万全です．ちょっと話はそれますが，RFID全体を書き換え／無効化可能にするというのは，万引きされた時点でアウトなのでナンセンスだと思っています．
もう一つ，「RFIDの組み合わせによって個人を識別，追跡できるのではないか」という話にも不完全かもしれませんがある程度の対処はできます．どうやるかというとスキャナに対してランダムなIDを複数返すようなモノを身につけるのです．まあこれでも統計的なアプローチにかかるとばればれかもしれませんが．小銭のような出入りの激しいモノにIDをつけるようにすればだいぶましになるような気がします．
あっ，もちろんお金につけるIDは発行年ごとにリセットします．ようはモノを手にすれば判別できる情報をRFIDで提供するIDに付加する必要はないでしょうということなんですが．

◆ 追記

わざわざ上のような仕組みにしなくても，IDを商品コード(消去可)と個体識別子(消去不可)に分けて，レジで商品コードを消すような仕様にするほうがスマートですね．商品コードのついたままのモノが出口を通過したら万引き．そうすれば店舗までのトレーサビリティは確保できますし，販売後のプライバシーも上に書いた程度には守れます．

◆ 前回のフォロー

第1回に引き続き参加してきました．その時の感想で書いた件については結局なにも言及されませんでした．私が前回会場でお願いした女性の方が上にあげ損なったのか，上層部で「JPCERTがインシデント報告を無視する」なんて評判が立っても別にどうってことないという判断がなされたのかは，こうなってしまっては私には知るすべがありません．そういう感想を持ち，こうして日記に書く人間が一人増えたという事実が残るのみです．行き帰りの電車で「4532107970」という本を読んでいたのですが，クレーム対応と今回の件，さらにはインシデント報告に対する対応って共通点が多いなあと思ったり(というか，この件からの連想で積ん読の山から引っ張り出したんですが)．この本と当時の主催者側の対応を照らし合わせてみるとなかなか面白かったです．面白かったのでもうちょっと脱線．この本では顧客を4つのタイプに分類しています．

	口に出さない	口に出す
満足	サイレントサポーター	ボーカルサポーター
不満足	ウォーカー	トーカー

(p.88 図4より)

私はさしずめ前回トーカー，今回ウォーカーと言ったところでしょうか．こうして日記に書いているのになぜトーカーではないかと言うと，それぞれの説明を読むとわかります．

トーカー

話す人，クレームや苦情をはっきり表明する人です．つい対応を避けたくなる顧客ですが，顧客の話をよく聞き，誠意をもって対応すれば，サポーターになってもらえる可能性があります．

ウォーカー

歩み去って再び顧客とはならない人です．つまり，不愉快な気持ちになったり，納得がいかなくても我慢して，何も言わない顧客です．何も言わないからといって満足しているわけではありません．このタイプの人はあとで，経験を友人や家族に話します．不満が顧客の勘違いやちょっとした行き違いの結果であっても，説明したり，こちらの真意を理解してもらうチャンスがありません．

(p.88より)

つまり自分の不満を直接伝えて対応するチャンスを与える顧客がトーカーであり，私は今回はもうなにも会場では行動しませんでしたので，この分類でいけばウォーカーです．ただし，この本が書かれた1999年とは違い(本当かな?)，2003年現在ではいま私がこうしているように「経験を家族や友人に話す」という行動の延長として「インターネット上で公にする」という対応する側にとってはよりいっそう注意しなければならない状況が現実となっているのです．この本ではさらにこう続きます．

(ウォーカーの)中にはそれでも利用してくれる顧客もいます．「近いので」，「他にないから」という理由かもしれません．そういう顧客はもっと近いところに他の店ができれば，そちらを選びます．顧客の好意や我慢に無関心でいると，新しいライバルに顧客を奪われるだけです．
(p.89より)

JPCERTにライバルが現れるときは来るのでしょうか？

◆ 今回の内容

前半は高木氏の「安全なWebサイト設計の注意点」という講演でした．これが先日受講したチュートリアルとほぼ完全に内容がかぶる結果に．定価$600で丸１日かけてのチュートリアルと比較してはかわいそうなのですが，まあ，そういう感じでした．というか，ご本人も言っていたとおり，あの内容にしては時間短すぎ．
話がそれました．まずはSSLの役割について「通信の暗号化」の他に「改竄防止」と「偽者防止」という面があることを強調していた．この話で半分以上の時間を費やしたのですが，配布資料の印刷後に追加された話のようで，手元にハードコピーがないのは痛かったです．後で配るとは言われたものの，資料のあるなしでメモの量(は発表に集中できる時間を削る)が変わってくるので，ついて行くのが大変でした．途中でSSLの証明書によりman-in-the-middleが防止できるという話がありましたが，チュートリアルの方でそのman-in-the-middle方式を使ってhttpsな通信を中継するproxyについての言及があったので，高木氏が途中でボソッと漏らした○○だがIEにルート証明書が登録されている第３者をだましてごにょごにょすると，httpsなウェブページを気づきにくい格好で改竄できるのではないかと思ったり思わなかったり． 残りの配布資料に載っている部分はかけあしでしたが，私にとって興味深かった話だけいくつか取り上げてみます．完全なリストはご本人のウェブページの近況内で公開されているようですので，そちらをどうぞ(上のほうには今回のスライドが準備中とありますね)．

アドレスバーを隠さない

FRAMEを使わない

ユーザーがそのページの信頼性を確認する術を一つ失ってしまうという論調でしたが，アドレスバーの改竄の可能性について触れなかったのはわざとかな？

認証キーには秘密情報を

電話番号等で認証していると，不正アクセス禁止法で言う「識別符号」には当たらず，取り締まれない可能性がある(警察庁担当者の見解付き)．と言うことだそうです．

パスワードリマインダの鉄則

いろいろと危険だが，これといったうまい方法はまだ思いついていないということだそうです．こういう場面で手軽に使える公開鍵暗号系とかあると便利かもしれません．

注意すべきはURLだけではない

hidden属性付きのinputタグや，cookieも改竄される恐れがあると言う話．以前紹介したIE boosterや，上で少し触れたproxyなどを使うとそういったことがいとも簡単に実現可能だということを見せられたので，「今，そこにある危機」という実感があります．

自前のルート認証局の運営

「きちんとやるにはコストがかかる」とおっしゃっていましたが，前述した○○な第３者機関を利用するのとどっちがましなんでしょうか？個人的には「信頼するべきではない第３者機関のルート証明書」よりは「自前のルート証明書」の方がまだましじゃないかという気がしています．「信頼できる第３者機関のルート証明書」が一番なのは疑いの余地はないのですが，ざっと調べた感じでもホスティングサービスとかの相場と比べるとまだ高すぎて，大企業はともかく中小企業やベンチャーにとっては厳しいと思います．

あと，脆弱性の例の紹介をするときに高木氏が実際に脆弱性が存在したサイトの画面のキャプチャー画像を使っていたのは印象的でした．個人的にはデモを見せてもらったチュートリアルのほうがやはり判りやすかったですが，見るからにお忙しそうですし，参加料から類推される報酬の額を考えると，そこまで望むのは酷ですね．
後半分はまた後ほど

◆ F1イタリアGP

モントーヤ熱い．トゥルーリ残念．アロンソスピード差に対応できず？

ダマッタのタイヤバーストのタイミングがやけに早かったですが，なんか拾っただけかな？

富士スピードウェイ話うざってぇ．

バトン．．．ホンダ．．．

モントーヤ熱い，と思いきや．現場で解説しないからこういうことになるんじゃぁ．

パニス．．．トヨタ．．．

クルサード，ここ数年の成績を象徴するようなリタイヤ．

今回はフェラーリ強かった．ランキングはちょっと差が開きましたがモントーヤ，ライコネンの巻き返しに期待しましょう．

BAR，ランキング5位ですか．ビルヌーブ久々の入賞も扱い低し．

◆ オート・ボルテージュ

鳥人間コンテストで感動したからという訳でもないのですが，最近テレビでドキュメント番組を見たりしてちょっと興味があったのと，タイミングよく上記イベントを発見，値段の安さにも釣られてチケット購入．ワールドグランプリの１戦がFポンより安い料金で見られるんですから，行ってみるしかないでしょう．その３週間前に三重県で開かれる某世界選手権を見に行くのは(ボスには)ないしょ．

購入には「ツインリングもてぎ オンラインショッピング」を利用したのですが，利用規定に不明瞭な点があったので質問したところ，すぐに丁寧な返事が返ってきたのは◎．対応しますと書いてくださったので，そのうち修正されると思いますが，第４条(4)の「ガイドライン」というのは通産省の「民間部門における電子計算機処理に係る個人情報の保護に関するガイドライン」のことだそうです．あと，第４条と第１２条の関係がよくわからないと質問したところ，そこも見直してくれると言うことでした．先日の話でいえば，トーカー(?)からサポーターに変身といったところでしょうか．うーん，我ながら単純．

◆ 第２回 セキュリティセミナーの感想前半分を追加．

◆ 架空請求メール

というものをはじめて受け取った．和解金5万円で事務手数料が1万円だそうだ．とりあえず警察庁の相談窓口にヘッダと本文を転送したり，地元の警察本部の電話番号をメモったりしてみる．

◆ たのしんどい，ふたたび

ふと気づくと今週末から2週間ほどのスケジュールが大変なことに．

9/26 現在進行中のプロジェクトに関するプレゼン．

9/28〜10/2 Blackhat Training受講

10/2〜10/4 ワークショップ参加

10/10 某原稿締め切り

10/10〜10/12 世界選手権観戦

某原稿は手付かず(^^;．

とは言っても9/26の資料を焼き直せばよいので目処はついている．出先で進めるしかないな，こりゃ．

◆ TODO

テントの予約．

もって行くべきものをツッコミ欄に書いといて下さい＞鈴鹿組

◆ プレゼン終了

何とか．さて，これから旅行かばんを買いに行かないと(っておい)．

◆ @成田

出発1時間前なのに，何にもやること無くなってしまいました．おかしいなあ．

いま使っている空港備え付けの端末は，

• スタートメニューに登録されているのはIEと標準のゲーム，リブート・シャットダウンのみ．
• タスクバー上のネットワークアイコンのダブルクリックも制限している．
• IEのメニューが隠されている．
• IEの履歴が使えない．
• ショートカットキーが無効化されている．
• Yahoo! Mailにはアクセス制限している．

と結構気を使っているようです．KとLのキートップがないのと，なにかの拍子にカーソルが勝手に変な位置に飛ぶのはちょっとあれですが…．あと，編集ページへのアクセスの際，「パスワードを記録する」にチェックを入れるとどうなるのかは非常に気になるところですが，怖くてちょっと試せません．

と書いたところで，ちょうど搭乗が始まりました．では，行ってきます．