スパイダリング技術ここに極まれり−Googleニュース日本語版登場

ついにGoogleニュースの日本語版がリリースされた。

Google ニュース 日本版
ご存知ない方のために、Googleニュースの特徴:
  • Googleのロボットが主要なニュースサイトを自動的に巡回訪問。ニュース記事、写真などの情報を採取。
  • 言語解析などを経て、ページを生成。
  • つまり、Googleニュースの全てのページは、一切の人の手による編集作業というものが無い。全て全自動。
スパイダリング技術、ここに極まれり。

直リンク問題とGoogleニュース日本語版

昨日伝えたばかりのgoogleニュース日本語版スタートの件。 巡回先のニュースサイトから許可をもらってのことと考えているような紹介記事もあったが、 やはりそうではなく、直リンク問題を抱えたままのようだ。

@IT:Googleニュース日本語版、直リンク問題を抱えてスタート
(@IT 2004/9)
Google自体が「(Googleニュースには)ビジネスモデルはない。いいビジネスモデルがあれば教えてほしい」と言っているあたりがちょっと笑える。こういう会社こそがネットをひっぱるのだ。 ちなみにJava言語の推進案が出たとき、「我々はJavaでどうやって儲けるのだ?」というSunの幹部の問いに対し技術者は「さあ。」とだけ答え、幹部は「キミが正しいことを祈るよ」とだけ言ってGOサインが出たという逸話がある。

話がズレたが、マスコミサイトに対する直リンク問題は日本だけではなく世界共通だ。 ちなみに昨年ドイツではこんな判決が出ている。

独最高裁「検索エンジンのニュースソース表示は合法」著作権及ばずと判示
(Internet Watch 2003/7)
マスコミのサイトが直リンクを嫌がる理由については この前書いた筆者の記事のとおりだ。
直リンク禁止とその実現方法(1)
(Webビジネスコンサルタントのネタ帳 2004/8)
@ITの記事によれば、現在、Googleニュース日本語版では読売新聞と産経新聞のサイトが巡回対象に入っていないらしい。 読売新聞については上の記事で筆者が書いたとおりだし、 産経新聞も過去に結構まぬけなトラブルを起こしている

新聞社の比較の話をすると政治的な意味合いにとられかねないので嫌なのだが、 ここはあえて比較してみよう。

  • 産経や読売のように既得権を守ることにしか考えがおよばないままネットの世界で直リンク禁止を叫ぶという無理をしつつ悶々とすごす者
  • 朝日新聞のように自ら記事のRSS配信をするくらいに直リンクWelcomeな態度で貪欲に進化を続けようとする者。 (RSS配信というのは要するに記事の見出しとURLのリストのバラマキなわけだから)

もちろん最終的に生き残るのは、前進することをやめない方だろう。そうであってほしい。

Javaジャバ言ってる間にも(4) − FriendSterはJavaからPHPに乗り換えていた

FriendSterは SNS(ソーシャルネットワーキングシステム)のさきがけ的存在として有名だ。 Googleから買収を持ちかけられたといううわさすらあった。 orkut、mixi、greeなどなど現在人気のSNSも全てこのfriendsterのアイデアを原点としている。

Friendsterの社員が自分のblogに書いた内容がきっかけでクビになってしまったという 記事がCNETにあったのだが、そこに興味深いことが書かれていた。

...同氏は それまでJava J2EEで書かれた同社のウェブサイトをPHPに書き換えるため、 今年1月に同社に採用されたという。新しいサイトは6月から運用が開始された。 同社ではサイトのリニューアルについて大々的に宣伝しなかったが、 外部の人たちのなかには、 ウェブサイトのファイル拡張子が変わっていることに気が付いていた人も多い。
個人ブログが「やぶ蛇」に--ネット企業が社員を解雇 (CNET Japan 2004/9)より

最近やたらめったらJavaジャバ言われていることに筆者がつねづね疑問を抱いていたのは ご存知のとおりだ。

Javaジャバ言ってる間にも (2003/12)
Javaジャバ言ってる間にも(2) (2004/3)
いまおすすめの言語はPHP −Javaジャバ言ってる間にも(3)(2004/5)
ちなみにこれらの記事に関する興味深いコメントとして LightWeight Languages(Passing Wind の日記 2004/5) というのをついでに紹介しておこう。

さて、friendter.comというWebサイトひとつがPHPに乗り換えたという例を挙げたくらいで PHPの優位性を過大に言うつもりは無い。しかし、 Javaやら.NETだけでなくPHPやperlなどのLL(Lightweight Languages)も、 ことWebシステムにおいては非常に有望な選択肢であることが、 特に中規模以上の企業においてあまりにも見過ごされすぎている気がしてならない。

ちなみに8万人のユーザーがいるgree.jpもPHPで書かれている。 mixi.jpはperlだ。

と書いてるそばからこんなニュースが。

@niftyを退社して株式会社はてなに転職しました (伊藤氏のブログ NDO::Weblog 2004/9)
伊藤氏は@niftyの「ココログ」 というブログサービスを立ち上げたチームの一人。Blog Hacksの著者でもある。 @niftyはMovableTypeの開発元であるSixApartと提携し技術導入してココログを 立ち上げたという経緯がある。ちなみにMovableTypeはperlで書かれている。

ちなみに、株式会社はてなは、人力検索はてな、はてなダイアリー、 はてなアンテナの3つのサービス合わせて 12万登録ユーザーで月間1.5億ページビューもある(2004/7現在)が、 そのシステムは全てperlでできている。(詳しくはここ) 一方で、Javaで書かれたWebシステムが月間100万ページビューも無いのに性能が出ないとかいって四苦八苦している例は世の中珍しくない。(笑)

プログラミング言語はあくまで言語であり、言語の選択や言語そのものの進化にかかわらず、 一番重要でシステムの良し悪しを決めるのはちゃんと設計できているかに尽きる、という話はもっともだ。 しかし、現実起きているLL(Lightweight Languages)の潮流に 気づかないふりを続けることもまた非常に危険に思えてならない。 流行に流されるのはよそうよというセリフもJavaジャバ言ってる人にそのままお返ししたい。

だからアドレスバーとか消しちゃだめだってば

ほんと、いままでの(いまも?)銀行のサイトのセキュリティ感覚はどう考えてもおかしかった。

...ログイン画面にアクセスした際に、イーバンクの正規のサイトであることを確認できるよう Webブラウザにアドレスバーを表示するとともに、サイトの証明書を確認できるようステータスバーを表示する。 従来はURLなどを見せないほうが逆にセキュリティ確保につながるとの考えから、 これらの情報をログイン画面では表示しないようになっていたという。
イーバンク、フィッシング詐欺対策でログイン画面に新機能 (Internet Watch 2004/9)
ついでに追加された以下の手法は、確かに有効だ。
次に、ログイン時にキーワードによるログイン方法を追加する。これは、従来からのログインパスワードに加えて、ユーザーがあらかじめ全角10文字以内の“キーワード”を登録しておくことで利用できる。この新しい方法でログインしようとすると、ユーザーが支店番号、口座番号、ログインパスワードの最初の4文字を入力した段階でキーワードが表示される。このキーワードが正しければ、イーバンクの正規のサイトであると確認できる仕組みだ。
ちなみにYahooBBの無線LANサービス(試験サービス中)でも、ほぼ同じ手法がとられている。

関連記事:
フィッシング詐欺に強いデザインとは − 後悔しないためのWebデザイン
ツールバーもアドレスバーも消すな! − 後悔しないためのWebデザイン
安全なWebアプリ開発31箇条の鉄則 (産業技術総合研究所の高木氏のレポート PDFファイル)

2004/10追記:イーバンク銀行のこの機能はほぼ無意味であることが判明!

スパムの標的にされやすいメールアドレス体系

送信元アドレスの詐称がどうだとか、ベイジアンフィルタによる自動識別がどうだとか、 スパム(迷惑メール)の問題には実に様々な側面がある。 だが、技術的に難しい話に至るより以前に、 考え無しに決めたメールアドレス体系そのものが原因かもしれない、という例を紹介しよう。

対策を打つには現状を知ることからだ。まずは迷惑メールを送る側の手口のひとつを解説する。

当然のことだが、大量にメールを送るには大量のメールアドレスが必要だ。 ではメールアドレスのリストをどうやって集めるのか? 単純に考えると、

  • 巷で大流行の、流出した個人情報というものを闇ルートで買う
  • ロボットソフト等でWebをクロールし、 Webページ上に書かれているメールアドレスを自動収集したものを買う
などの方法が考えられるが、 もっと簡単かつローコストで大量のメールアドレスを収集する方法がある。 収集するのではなく、作り出すのだ。 手順は簡単に想像がつく。
  1. 苗字のリストをつくる。 tanaka, suzuki, sato, kondo, shimada...
  2. 名前のリストをつくる。 taro, jiro, saburo, hanako, yoshiko, eriko...
  3. 苗字と名前をピリオドまたはハイフンで片っ端からくっつける。 taro.tanaka, taro-suzuki, taro.sato.....
    名前部分はイニシャルだけでもいいだろう。t.tanaka, t.suzuki, t.sato....
  4. 最後にドメインをくっつける。@docomo.ne.jp とか @nifty.com とか。
苗字と名前をそれぞれ50種類くらいずつ考えて、標的のドメインを5つも選べば、 苗字50種x名前50種xハイフンまたはピリオドで2種x5ドメイン=25000個 のメールアドレスをあっという間に作り出すことができる。 ちょっとしたプログラミング技術がある人なら可能だ。 MS-Excelのマクロ程度でも十分できるだろう。

taro.tanaka@****.comというアドレスが本当に実在するかわからないじゃないか!? なんて話もたいした問題ではない。 スパマーにとっては数打ちゃあたる作戦が全てなのだから。 スパムに対する返信率がわずか0.001%でも採算が取れるほどだ。 名前のスペルリストをつくるというのはまだ気の利いているほうで、 ひどいときはアカウント部分(@の左側)をまったくのアトランダム文字列にして メールアドレスリストを生成していることすらある。

名前のリストいうものも実は既に存在する。欧米人名版はもちろん日本人名のも。 パスワード認証に対する辞書アタック用としてかなり昔からアンダーグラウンドな世界で流通しているのだ。 それがメールアドレス生成用に転用されることは想像に難くない。

さあ、かくしてメールアドレスのリストはできあがった。あとは送るだけだ。 当然ながらこのリストの中には実在しないアドレスが大量にあるはずなので、 標的とされたかわいそうなドメインは次のようなことになる。

....該当する大量迷惑メールは7月22日より断続的に... 海外より発信されており...
その時間帯は通常の数倍の負荷が当社のメールサーバにかかっていました。
...数千万通の該当メールが@nifty会員向けに発信されており、 そのうち99パーセント以上のメールが宛先不明となるものでした。 その結果、@niftyのメールサービスの受信が遅延するという問題が発生し、 一部のお客様に大変なご迷惑をおかけしていました。
@nifty:会員サポート:お知らせ(サポート): 大量スパムメールによるメール遅延、ならびに対策について(2004/8)
@niftyの件の犯人はどうやら海外(≒日本人ではない)のようだが、 手口が輸入されるのも時間の問題だろう。いや、輸入されるまでもなく 日本でも携帯メール向けに昔から同じ手口が使われていると考えてよいだろう。
ドコモによるとその業者は、今年の4〜5月にかけてiモード向けの広告メールを 大量に送信しており、そのうち約400万通は宛先不明の架空アドレス であったため...
...同社では、迷惑メールが大量に送信されることでサーバーに負荷がかかり、 本来のメール配信に遅延などの支障をきたす問題への対策...
NTTドコモ、迷惑メール送信業者に約650万円の損害賠償を請求 (ケータイWatch 2002/6)

どう対抗すればいいのだろうか? という問題の答えは 「なぜ迷惑メールというと巷の記事では@niftyの話ばかりなのだろうか?」 という問いを掘り下げることで簡単に見つかる。 「nifty 迷惑メール」 で検索した結果と 「biglobe 迷惑メール」で検索した結果を比べてみよう。Biglobeのほうでは、 Biglobe宛に送られてくる迷惑メールに関するページではなくむしろ Biglobeから送る迷惑メールに関する記事のほうが多いことがうかがえる。 つまり、niftyでの大量の迷惑メール&架空アドレス処理由来のメールサーバ障害のような問題がBiglobeでは起きていない。 似たような歴史と規模のプロバイダなのに、なぜ?

答えはメールアドレス体系の違いにある。

  • @niftyは (好きな文字列)@nifty.com (nifty.ne.jp)
    例:***@nifty.com
  • Biglobeは (好きな文字列)@(勝手に決まるサブドメイン).biglobe.ne.jp
    例: ***@muj.biglobe.ne.jp
    (ちなみに、Biglobeのメールアドレスのサブドメイン数は50種類をくだらないらしい)
ここで、先ほど話したメールアドレスの大量生成の方法を思い出してほしい。 名前や苗字の組み合わせで自動的にメールアドレスをつくるという手口を使う場合、 最後につけるドメイン名として好都合なのはどちらか? biglobeだと、どんなサブドメインがあるのかといった情報も必要になってしまうし、 あてずっぽうにするにしてもアルファベット26字の3乗 =17576種類のサブドメインになる(数字も含めればもっと)。 つまり17576倍の数のメールアドレスができてしまい、17576倍の送信能力が必要になり、 しかしそのメールアドレスが実在する確率は17576分の1になってしまう。 これはちょっと単純すぎる計算ではあるが、つまりそういうことだ。 サブドメインのことまで考えてメールアドレスを自動生成しだすと、 数うちゃあたる作戦にしたって割に合わなさ過ぎるくらい天文学的に大量のパターンが生まれてしまうのだ。 かくしてスパマーはbiglobeではなくniftyを標的にする。

もちろんniftyでは「abc00001@nifty.com」といった類推しやすいアカウント名を そのまま使っている人が(歴史的事情で)多いというせいもある。 ドコモの携帯電話についても、初期状態では「携帯電話番号@docomo.ne.jp」になるという 仕様が長く続いてしまったことがスパムの標的となった要因のひとつだろう。 しかし今後、メールアドレスの自動生成という手口が日本でも間違いなく広まる(既に広まっている?)だろうし、 その場合やはり標的にしやすいのはniftyやdocomoのようなメールアドレス体系であることに変わりは無いだろう。

標的にされるのはプロバイダなどの通信事業者だけではない。 一般企業のアドレスに対しても同様の手口でスパムが送信され、 メールサーバがパンクしてしまうという事態は欧米では既に日常茶飯事である。 「株式会社example」という日本企業があるとしよう。 社員のメールアドレスが皆 *******@example.co.jp という体系だったら、 残念ながらスパムの標的にされる日は近い。

逆に *******@hoge.example.co.jp のように、社員のメールアドレスを サブドメインにランダムに振り分けてあるだけで、被害にあう確率はぐっと下がる。 サブドメインは2文字以上がいいだろう。i(アイ)、l(エル)、0(ゼロ)、o(オー)などの 紛らわしい文字を排除しても、2文字なら少なくとも400種類以上のサブドメインを作り出せる。 なお、サブドメインを使うようにすると、同姓同名の対処がしやすくなるというメリットがある。 つまり鈴木一郎という社員が二人いたとしても、ichiro.suzuki@hoge.example.co.jp と ichiro.suzuki@fuga.example.co.jp というふうにすれば済む。 Biglobeが沢山のサブドメインを使っているのも、 複数のユーザーが同じアカウント名を第一希望として申し込んできたときに対処しやすくするため、 というのが当初の目的だ。 迷惑メール対策としても機能したのはおそらく結果オーライである。

「うちは100人もいない企業だから標的にはされないだろう」という考えも希望的観測にすぎない。 スパマーが企業規模をリサーチするなんて考えにくい。 標的にしやすいメールアドレス体系(ドメイン)であるかどうかでしか判断しないだろう。

なお、日本では2002年に設けられた「特定電子メールの送信の適正化に関する法律」 のなかで、「数字や文字などをランダムに組み合わせて作成した架空のアドレスに対してメールを送信すること」が明確に禁じられている。 しかしこれは抑止力というよりは、国レベルで禁止を明確化することによって通信事業者が送信停止などの実力行使をする根拠にしやすくするため、という意味合いのほうが強いと思われる。

さて、いつかスパムの標的にされメールサーバがパンクし社員や顧客にブーイングされあわてて対策ソフトを買ったりメールサーバの設定を変更したりし助けてくれはしないだろう警察や関係省庁に届出し・・・つまりあとで後悔するか。 それとも、いまのうちからサブドメインを含むようにメールアドレス体系を変えておくか。 企業の情報システム担当者は、選択しなければならない。あまり猶予は無い。 企業からメールサーバの運用のアウトソーシングを受けている業者さんも頭が痛いことだろう。

♪きっと来る〜 きっと来る〜 (映画「リング」のテーマより)

GREE Night 2.0いってきました。

というわけで行ってきました。 GREE Night 2.0。 なんかよくまとまらないのでとりあえず箇条書きにしてみよう。

  • もともとが本当に単なる衝動買いに始まった筆者のGreeNIGHT行き。単身で乗り込むことも考えていたが、 いやな予感がしたので某サイトをやっているTさんになんとか連絡を取って 現場で会える段取りをつけておく。(Tさん、ご迷惑だったかなあ・・・スイマセン)
  • 嫌な予感は的中。なにがって、人、人、人! 明治神宮の初詣なみとは言わないがとにかく縁日状態いやイモ洗い状態。 あれでは知り合いを探すのは至難だ。 まして筆者だってこの業界にそれほど多くの知り合いがいるわけではない。 旧友くらいにはもしかしたら探せば会えたと思うが、 それにしたってあの状態では・・・。
  • そんななかでもTさん側のお知り合い関係もあって、 貴重な方々とちょっとでもお話することができた。 CNETのEさん、GoogleのKさん、NTTのKさんNさんSさん、、、 (すんません全部書いてらんないんで一部のみです)
  • 学生さんだらけすぎるだろうからと期待していなかった& 単なる名刺交換会も好きじゃない、という考えから あえて仕事用の名刺入れは持っていかなかったが、 これはやや失敗だった。 予備として財布の中にあったわずかな数の名刺でしのいだがあっというまに品切れ。
  • 結局Tさんのお知り合い関係の方と早めにイモ洗い状態を抜け出して 恵比寿の飲み屋(おいしかった^^)で軽く食事とトークをする。 「お友達のお友達とヨロシクねといってちょっと一杯飲む」 こういうのこそGREEの真骨頂なんだろうと思った瞬間。 GREEは出会い系みたいだけど出会い系のつもりでつくったんじゃない、 という開発者の意図ってこういうことなんじゃないだろうか。 (http://www.gree.jp/?mode=doc&act=about参照)
  • 逆に言うと単なるうわべだけの名刺交換会 ≒会っていきなり相手が自分の役にたつかたたないかで一瞬で値踏みするような空気、 つまりいわゆる異業種交流会と呼ばれるものについては、筆者も違和感を覚える。 (すべての交流会がそうだと言うつもりはありません。 気を悪くされる方がいましたらすいません)
  • 無論、名刺交換してほんの少ししかお話できなかった人の中でも 特に人間的(というか単なる筆者の直感的?)に興味を持った方については あとで一本メールを書くようにしようと思う。 うわべだけの名刺交換会がいやだという気持ちは持っていても、 そういう場でなければ会えない人だっているというのもまた真実だ。 キッカケがどうであれ一期一会を大切にという基本も忘れちゃいけないと思う。
筆者としてはとりあえずこんな感じ。

そのサイトを見るとルーターがクラッシュする

ある特定のWebサイトを見るだけでパソコン全体の調子が悪くなる ということは通常ありえない。よほど古いPC=古いブラウザ=HTMLやJavaScriptやVbscriptなどの処理系が古すぎて 最新仕様に対応しきれていないブラウザ=ならばもしかしたらありうるかもしれないが、めったにない。 まして、パソコン(のOS)やブラウザの調子が悪くなるだけでなく ルーターなどの周辺機器にまで影響を及ぼすとは考えにくい。

「あるWebサイトだけ見れない/見るとパソコンの調子が悪くなる」 ということを言うユーザーはたま〜〜にいる。 Webコンテンツ上に寄生しブラウザの脆弱性をついて入り込んでくるタイプの コンピュータウィルスに感染してしまったとか、 ブラウジング中に突然でてくるダイアログボックスで何も考えずに「はい」 ばかり押しているうちによからぬActiveXコントロールでも入れてしまったとか、 単にルーターのコンセントやLANケーブルの接触不良だとか、 ほとんどのケースはそういう原因だろう。

しかし事実は奇なり。

eBayのWebサイトにアクセスした DSLユーザーのシステムがクラッシュしたとの苦情が、 数カ月前から寄せられている。
 問題は、ルータを再起動することで解決できる。 DSLモデム内蔵のルータでは再起動に数分かかるため、 そうしたルータのユーザーは、eBayの利用を不快に感じて苦情を報告するケースが多い。
eBayへのアクセスでDSLルータのシステムに不具合 (ITmedia 2004/9)
※eBayは欧米で超有名なオークションサイト。 日本のヤフオクなんてメじゃないくらい大規模。
アクセスしただけでブラウザじゃなくルーターをクラッシュさせる Webサイトって、ある意味すごい高等テクだ。(笑) しかしそれが、eBayという超有名巨大サイトで起こってしまった。

ネタ元を要約&意訳&補足すると、現象と原因は次のとおり。

  • eBay上に出品されている商品のページを閲覧すると、 その直後から一切のネットワークアクセスができなくなる。
  • PC自体やそのアプリ(ブラウザ等)のせいではないらしい。 ルーターを再起動すると直ることから、ルーター(の内部のファームウェア)がクラッシュするようだ。 しかしなぜ?
  • 実はeBay上の商品ページでは、アクセス解析用のビーコンが埋め込まれている。 eBayオリジナルではなくeBayが提携している解析専門ベンダーによるもののようだ。 日本でも似たようなASP型アクセス解析サービスは珍しくない。
  • ビーコン画像(よくあるタテヨコ1ドットの透明画像と思われる)を送り出す解析サーバのURLは、 13キロバイトにもおよぶJavaScriptによってそのURLが決定されるというものだった。 このURL、長いのだ。何が長いって、なんじゃこりゃ?↓
    http://e-n.y-1shz2prbmdj6wvny-1sez2pra2dj6wjkywkajcboq2dj6x9ny-1seq-2-2.stats.example.com/
    (ここではわざとexample.comに直してあります)
    おそらく、eBay上の各ページ=商品=ごとにアクセス解析するために、 各ページ上のJavaScriptで個別のURLを自動生成しているものと思われる。 それにしたって普通はQUERY STRING=URLの最後のほうに?とか&を使ってくっつける変数=を 使うものだが、このアクセス解析サービスは、 アクセス解析に必要な情報を示す文字列をURLのホスト名部分に埋め込むという、 奇抜な方法を取っていたらしい。 たしかに、DNSのワイルドカード設定を使えばこういう方法も可能だ。 コロンブスの卵的発想(?)。
  • ところが、この長いホスト名こそが、原因だった。 古いタイプのxDSL回線向けルーターのファームウェアのDNS機能にバグがあり、 ドメイン部分の各ラベル(ドットとドットの間の文字)が51文字以上あるホストをDNS検索しようとすると、 ファームウェアがクラッシュしてしまうのだ。 するとルーターの全てのネットワーク機能が停止してしまう(or停止したように見える)。 おそらく、ファームウェアのコードを書いた人間が URLのホストのラベル部分の長さの最大値は50バイトであると、 低く見積もってしまっていたのだろう。 それ以上の値を与えるとバッファがあふれてエラーを起こしダンマリ状態になってしまう。
  • ビーコンのURLはJavaScriptによって生成されるのでソースを見ただけではどんなURLなのかわからないし、 また、ビーコンを埋め込んでいる商品ページはeBay上のプロの法人による出品ページだけで、 個人による出品ページには埋め込まれていない。 そもそも比較的新しいルーターではこういったバグは無いようだ。 そういったことが、問題点の切り分けと原因の発見を遅らせてしまったと考えられる。 だいいち、特定のサイトを見ることとルーターのクラッシュが結びつくなんて、 普通の人は考えも及ばないだろうし。

教訓

RFC1035 ドメイン名−実装と仕様書には、 「ドメインのラベルは63オクテット以下」(つまり63バイトまでならOK)と はっきり定められている。 ファームウェアのコードを書いた人間はこの規定を無視した or 知らなかった or 調べもしなかった可能性が高い。 つまり「とりあえず50バイトとっときゃいいだろ」と安易に決めてしまったのだろう。

そもそもインターネット上で使うアプリケーション仕様や通信プロトコル仕様は、 全てRFCで定められた仕様に準拠していなければならない。 皆がてんでバラバラの仕様でソフトを作ったところで 相互の通信がうまくできるわけがないからだ。 つまり、RFCを読まずにネット関連のソフトを書いてはいけない

実際のところ、最近Webアプリをつくりはじめた人で、 ナマのRFC文書をひとつでも真剣に読んだことのある人はそう多くないと思う。 また、Webアプリに限らずたとえば単にデータベースのテーブル仕様を決めるときに、 「うーん、このフィールドはvarchar(50)くらいでいいかな」と 適当に決めてしまってあとで「しまったぁ・・・」という経験はないだろうか? 筆者にはある。(笑) だがそういうことをしていると、 思わぬところで甚大な規模の迷惑がかかってしまうかもしれないということを、 肝に銘じよう。

しかしだからといって、今回のケースでの責任の所在が、 RFC準拠しているドメイン名を処理できないようなルーターのファームウェア(を書いた人)だけにあり、 アクセス解析サービスを作った側には全く非は無いか、というとそうでもないと思う。 少なくとも1%くらいは責任があるはずだ。

そもそもドメインネームシステム(DNS)とは、IPアドレスという数字の羅列では わかりづらいし、IPが変わったときにそれをあちこちに通知するのも大変だから、 アルファベットも使えるドメインネームというものを定めて、わかりやすくしよう、 というのが本来の目的だ。 アプリケーションで使用する細かい変数を伝達するためにドメイン名を使う というのは全く本来の想定外である。

どんな技術、道具、方法論を使う場合でも、 皆が想定している使い方を逸脱すればどこかで必ずトラブルが起こる。 DNSのワイルドカード設定で思い出したが、 去年のSite Finder事件でベリサイン社が総スカンをくらったときに 「われわれは全てのRFCに準拠している」と開きなおったっけ。 (注:ベリサインのこの言い分はRFC1035の曲解と言える。詳しくは下記参照)

Verisign問題、どこがどう問題なのか?(2003/9)
ICANN、VeriSignの“Site Finder訴訟” を棄却するよう米連邦地裁に請求(2004/4)
「技術的にできること」と 「やっていいこと、つまり世間の人やモノがそれを受け入れる準備があること」 は次元が別である。 ちょっと極端な例だが「できるからと言ってヒトの遺伝子を安易にいじくりまわしてはいけない」 といったことと同じだ。 技術ばかり見ているエンジニアや研究者はえてしてこのワナにはまりやすい。

第9層 モチベーション層、第10層 しがらみ層・・・

OSI12階層モデル。激しく同意。(笑)

第1層 物理層
第3層 データリンク層
第4層 ネットワーク層
第5層 トランスポート層
第6層 セッション層
第7層 プレゼンテーション層

第8層 スキル層
第9層 モチベーション層
第10層 しがらみ層
第11層 経済層
第12層 責任層
詳細は N2 ToolBox:OSI 12階層モデル (2004/9)

コンピュータが勝手に株を売買していいのか?

IBM、野村総研、早稲田大学などの協賛で 株式を市場で自動的に売買する自律プログラムのコンテストが開催される。 もちろん実験用の仮想市場、仮想証券会社を通してのことだが。

1ヶ月間、あなたのロボットがその設定に基づいて株の売買を行います。 さて、あなたのロボットはどれだけ利益をあげられるでしょうか?
カブロボ・コンテストより
面白そうなこの企画、しかし同時に寒気も感じたのは、筆者だけだろうか。

LTCM=ロングタームキャピタルマネジメント=という会社がかつて実在した。 ニューヨーク近郊の従業員170人ほどのその小さな投資運用会社は、 ノーベル経済学賞をとった経済学者、数学者、元凄腕トレーダーなどが考え出した 超高度な数学および理論経済学的テクニックを駆使し、巨額の利益を上げた。 1994年の設立以来ときには十数兆円クラスの資金を運用し、たった4年後、破綻した。 負債額13兆円。資金を託していた世界中の金融機関や投資家は震え上がり、 世界的な金融危機にすらなりうる事態だった。

当時の田中宇氏の記事によると、LTCMがやっていたのは次のようなことだ。

...とはいえ、1回ごとの利回り格差の拡大や縮小はわずかなもので、いわば水面に立つさざなみだ。 それを利益に変えるのは、さざなみを使って波力発電をするようなもの。 膨大な量をこなさないと、十分な利益が出ない。つまり、自動化が必要だ。
 そのため、LTCMは、複雑なコンピュータープログラムを組み、 無数の債券どうしの利回り格差の変化を自動的に判断できるようにした。

神々の崩壊:世界を揺るがすヘッジファンド危機(1998/10)
LTCMのやっていたことにくらべれば、このカブロボコンテストのやることなど まったくお遊びにすぎないのかもしれない。しかし本質は同じだ。

ロボットにやらせたところで、ロボットのとる行動はそのロボットの持ち主の責任だ。 人間のとる行動はその人間の責任だ。責任の所在が一緒なら、 ロボットが勝手にやろうと人間の指が売買ボタンを押そうとどっちでもいいじゃないか。 それもそうだ。 しかし、最後の最後に「人間」が「判断」を下すというプロセスがなされない株式取引が、 はたして人間による市場経済の場で行われるべき商取引と言えるのだろうか? 意見の分かれるところだろう。

自律判断するプログラム、その研究自体に問題は感じない。筆者だって技術者として大いに興味がある。 しかし、以前の記事でも書いたが、 技術的にできることと、実際やっていいこととは、次元が違う。 その部分の啓蒙がすっぽりと抜け落ちたままの技術研究には危険を感じずにはいられない。

ボトルメールが届きました

最近ふえてきた、偶然や間違いを装うようなアダルト系スパムメール(過去記事を参照)。 今度はボトルメールを偽装してます(笑)。

Subject: ボトルメールが届きました
From: ○○はるか <****@yahoo.co.jp >
X-Mailer: MailDistributor

はじめまして!
○○はるかっていいます。
夏の終わりの記念にボトルメールっていつ誰に届くかわからないけど、送ってみました。
素敵でチョットくらいはえっちな男の人に届くといいなぁ〜なんてね♪
意外と近くの人だったらあってみたいしぃ。。。
もしメール届いたらお返事して欲しいのっ!女の子でも平気だよぅ!
(*^ヮ^*)待ってま〜す!
☆22歳はるか☆
「なつかしいものを持ち出すなあ」と思うなかれ。 本物のボトルメールはいまもちゃんとサービス稼動している。
公式サイト:ボトルメール : 予期せぬ出会いを創出する不思議なツール
新生「ボトルメール」が正式スタート(InternetWatch 2002/9)
なお、
ボトルメールはボトルメールユーザにしか届きません。ボトルメールを利用していない一般のインターネットユーザさんのメールソフト(Outlook Expressとかポストペットなど)にいきなりボトルメールが届くということはありません。
(ボトルメール:システムの説明より)
です。

トラックバックスパムはじまる

SEOをねらっているのであろう、ブログサイトに対する(特に海外からの)コメントスパムはご存知のとおり。当サイトでもそう激しい数ではないけどいくつかあった。 んでまあ、同じ流れですぐでてくるだろうと思われてたトラックバックスパムだが、 やはり出始めたようだ。

SPAMは許さん!「悪質サイトBlog Map」
絵文録ことのは 2004/9
たとえばMovableType3.0以降においてはコメント上のリンクはMTのCGIを通してリダイレクトするようになっており、これによってSEO効果がほぼ失われるため、事実上コメントスパムの歯止めとなるようになっている。同じようなことをトラックバックにおいても実装することはそう難しくないし、そうすることになるだろう。

ただ、そうやってコメントやトラックバックによる相互リンク関係が変なふうに複雑化することは、 ロボット型検索エンジンに頼るところの大きい現在のWeb自体を停滞(?)させてしまうような気がする。 残念だ。

関連記事: 新手のスパム−RSS配信の功罪?(2004/1)

楽天とライブドアが喉から手が出るほど欲しいもの=知名度

スポーツにはそれほど興味が無いのだが、 意外と大騒ぎ(?)になってきたので一応書いてみる。 そう、楽天とライブドアとプロ野球の話。 先に断っておくが、筆者はほんとにそれほど興味ない。 したがって、どっちかを持ち上げてどっちかをおとしめるようなことを書くつもりはないし、 でも万が一そう見えてしまったらごめんなさい他意はないんです本当にということで。

まず、両者共通の目的はもちろん知名度だろう。 業種にもよるが、いつの時代も変わらず新興の企業が喉から手が出るほど欲しいもの、それが知名度だ。 このブログを読んでるような人には一瞬信じられないかもしれないが、 よく考えれば「ところで楽天ってなに?」な状態な人のほうが世の中断然多いのだ。 いわんやライブドアをや。

マスコミですら、楽天のことはかろうじて「インターネット商店街大手の・・・」と紹介するところも少なくないが、 ライブドアについては「IT関連の・・・」としか語られない。 「インターネットポータルサイト運営の・・・」とか「企業向けWebサイト構築の・・・」 なんていう紹介のされ方を聞いたためしがない。 サイバーエージェントの藤田社長が奥菜恵と結婚したときも「IT関連社長と・・・」であって 「インターネット広告大手の・・・」といった紹介はまれだった気がする。 要するに一般ピープルにとってはその程度の認識でしかない企業群なのだ。残念。

一般消費者相手の事業者が手っ取り早く知名度を上げる方法はテレビCMだ。 武富士やらプロミスやらアイフルやらの消費者金融のテレビCM合戦がその代表だろう。 ちょっと古い例だが、昔、東京総合信用というクレジット会社がこんなテレビCMを打っていた。

(お父さんが娘を叱る) 「カレシ(彼氏)じゃない!レシだ! アクセントは頭につけるんだ!」
(ナレーション)「トゥソウシン」
ちなみにこのCMのお父さん役の役者は、 今アイフルのCMでチワワ犬の飼い主のおじさん役をやってる役者だったりする。 とにかく当時かなりウケたCMだったが、そのCMがヒットしている最中、 突然「クォーク」に社名変更し、その後はクォーク君の誕生にはじまるCMに切り替わった。 それまでのCMはなんのためだったのだ!? でもいいのだ。 おそらく社名変更は最初から計算づくで、 それでもあえて「トゥソウシン」のCMで印象を植えつけることで、 それに続く「クォーク」に対する印象づけのジャンプ台にするつもりだったのだろう。 相当な投資額を大胆に使った見事な作戦だった。 そこまでしてでも知名度が欲しかったというわけだ。

そう、テレビCMでの知名度アップにはものすごい金がかかる。 楽天も数年前にテレビCMを打ったことがあるし、ライブドアは最近打ち始めた。 だが両者ともあまり見た覚えが無い(笑)。そんなに露出させるには金がかかりすぎるということだろう。 テレビCMの相場なんてよく知らないが、ン億円を使い切るのに2,3週間もかからないのではないだろうか。

だとすれば、最初の保証金(?)30億(しかも大半が数年で返還されることになったらしい) +選手年俸20億くらい?+年間諸経費−テレビ放映権料やチケットや関連グッズ収入 で消費者向けの定常的なCM媒体として機能するプロ野球が手に入るとなれば、 知名度が欲しい新興企業にとって決しておかしな選択肢ではない。

さてところで、なんだかんだで仙台の件は結局楽天に落ち着いてしまうのだろう、 ということはみな薄々感づいているのではないだろうか。

「100億稼ぐなんとか」という本で「女は金についてくる」と やや紙一重すぎることを書いて話題になったり、鼻持ちならない奴と叩かれたり、 「老害=ナベツネ」と誰もが思っている(笑)けど口に出さないことを堂々と口に出し(ているらしい)、 しかもそれらの行動はライブドアの知名度アップのためのマーケティングの一環としての 意味もあると感じさせるライブドア(の堀江社長)と、 トヨタの会長とかANAの社長とかそうそうたるおエラ方を諮問委員会とかいうものにすえてお伺いをたてつつ静かに前進する楽天。

プロ野球機構の石頭のおエラ方のお気にめすのがどちらなのかは明白だ。 なんかやな感じだがそれが現実である。 筆者としては6:4くらいでライブドアがんばれなのだが・・・。

では楽天は勝者なのだろうか? そうでもない。 楽天はJリーグのヴィッセル神戸に出資したものの数億かけて獲得したイルハンは故障で役立たず、 といった苦い経験をすでに味わっている。野球でも似たようなことは起こる。 「ああ(球団なんて)やるんじゃなかった」「やらなくてよかった」というケースだってありうるし、 「やってよかった」「やればよかった」もありうる。どっちに転ぶかは誰にもわからない。 ビジネスとしての勝負は果てしなく長い。

「インターネット?あれは学術目的のシロモノだよ。 28.8Kbps以上のモデムを持っている人なんてまだ一握りだ。 ネット上でビジネスやろうなんて無茶だよアハハ」 なんて言われていた頃からまだ10年たっていない。 それがプロ野球の球団をやるやらないで騒ぎになるところまで来たのだ。 それだけでもたいしたもんだというのはちょっと的外れだろうか。

see also:
ライブドアがアダルト?楽天もやってるよ (2004/10)

wikiやxoopsが微妙に流行らない理由

wiki(ウィキ)やxoops(ズープス)をご存知だろうか。 Webサイト構築ソフトの一種だ。 とはいってもホームページビルダーだとかそういうのとはぜんぜん違う。 両者をごく簡単に紹介すると次のとおり。

  • wiki(ウィキ)
    • 普通のWebサイトは管理者が書き読者は見るだけ(掲示板に書き込める程度のことはできる場合も)。 しかしwikiは「そのWebサイトの内容を誰でも編集できる」のがコンセプト
    • つまりネットワーク上に置かれたホワイトボードであり、 誰でも参照できるメモ帳であり、ネットワーク上の連絡板であり、 みんなが共同で文書をまとめる作業場である。
    • 「wiki」そのものはソフトというより概念や仕様を意味する単語であり、 それの実装(動くようにプログラミングすること)はperl版wiki、 PHP版wikiなどいろいろな種類がある。
    以上、一部説明は結城浩のWiki入門より。
  • xoops(ズープス)
    • XOOPS日本公式サイトによると 「PHP言語で書かれた、コミュニティサイト構築用ソフトウェア
    • PHP言語+MySQLデータベースを用いたCMS(コンテンツマネジメントシステム)。 PostgreSQLなど他のDBMSエンジンも将来的には使えるようになる予定。
    • IDとパスワードを発行してログインさせる、といったユーザー管理機能があり、 閲覧権限、編集権限などをコンテンツ毎、ユーザー毎に割り当てるCMS的機能が充実。 管理画面のスクリーンショットはこちら もちろん未登録ユーザーなら閲覧だけ可能といった感じになる。
    • 日付、見出し、本文といった形での「ニュース」(blog的とも言える)や、 それに対するコメント投稿機能、 FAQページの作成機能、投票機能、ユーザー間のインスタントメッセージ機能、などなど 種々の機能が「モジュール」として提供されている。 詳しくはこちら
    • 有名どころ(?)では中央三井キャピタル株式会社の一部のページが xoopsでできていたりする。 他にも中小企業のホームページが実はxoopsでできているなんて例は多数。 XOOPS模擬的企業内イントラ風サイトなんてのもある。

wikiもxoopsもそれ自体はCMS(コンテンツマネジメントシステム)なので、 コンテンツそれ自体はユーザーが書かなければならない。 そりゃあたりまえなのだが、その部分に唯一にして最大の欠点がある。 独特のフォーマットでコンテンツを書かなければならないのだ。 たとえば通常のHTMLであれば

<font color=#ff0000>あいうえお</font>
と書くところを、wikiやxoopsの記事作成フォーム画面においては
[color=FF0000]あいうえお[/color] (xoopsの場合)
&color(#ffff00){あいうえお} (pukiwikiの場合)
と書かなければならない。 おいおいその程度のことが欠点か?と思われるかもしれないが非常に重要なことだ。

追記:xoopsでは[b][color]などの簡易タグだけを使うか普通のHTMLタグも許可するかどうかは 設定次第のようです。ご指摘くださった方ありがとう。実装によるでしょうがwikiもそうかも。以下はそのつもりで読んでください。

製作会社のWebデザイナーも一般企業のWeb担当者も、 HTMLとCSSを覚えるだけですでにもういっぱいいっぱいだ。 ましてJavaScriptやらperlやらPHPやら果てはJavaすら勉強しなきゃならない状況下では、 もう一文字だって他のことを覚えたくないというのが正直なところではないだろうか。 Java言語を考えたSunの技術者もそれはよく心得ていて、まず念頭に置かれたのが 既存のC/C++言語のプログラマーに受け入れてもらうにはどうすればよいかということだったと言う。 だからこそ、条件文は()でくくり、命令は{}で、命令の最後はセミコロン、 といったC/C++言語での基本はJavaでもそのまま使われた。perlやPHPもしかり。

[b]とか[color]とかいう特殊タグを書くための簡単なツール(JavaScript)が xoopsの記事編集画面に搭載されている。 それを使えばいいのかもしれない。 が、いちいちそのツールにマウスでフォーカスを移し、「あいうえお」と書いて ボタンを押して色を選択し追加ボタンを押してはじめて [b][color=FF0000]あいうえお[/color][/b] が入力される。 コンテンツを書く人にとってそれは苦痛だ。書き始めたらもうキーボードから手を離したくない! だからといって[color=#ff0000]と手で直接書こうとしても、 <font color=... とついつい書いてしまうだろう。苦痛だ。

< >か[ ]かなんて大した違いじゃない、慣れの問題だ、 という話もあるが、第一印象は重要である。 HTMLをやっと覚えたユーザーが「えっ、違う書き方しなきゃならないの?」と ネガティブ印象を持ってしまったが最後、それを取り返すのは難しいのだ。

と思っていたらこんな記事を見つけた。

...ドリコムブログ(Drecom Blog)ですが、 使ってみて特に気になった点をまとめてみました。
<記事投稿>
最近のブログの流行は、HTMLを知らなくても予め用意してある簡易タグ(例:<赤>〜</赤>) で記事を編集できる点にあります。この方式は、ヤプログ、アメーバブログなどにも採用されていて、 初心者には入りやすいという長所の反面で、タグ使いにはイライラの原因。 この点でヤプログやドリコムブログでは、 HTML(タグ)と簡易タグ使用の切り替えができるので便利です。
Purple Aquarius:ドリコムブログ(Drecom Blog)開店休業!?(2004/9)より
ほう、最近のブログはそんなふうになっているのか(8へぇ)。 簡易タグを用意しつつもHTMLタグ知っている人はそれでもいいようになっているというのは やはりユーザーの心理というものをよく心得ている証拠だろう。

たとえばblogソフトのデファクトスタンダードであるMT(MovableType)では、記事を書くのに特殊なフォーマットを要求されない。 ココログやブログ人などのMT系統のソフトを採用してるブログツール提供サイトでも同様だろう。 必要ならHTMLタグをそのまま書けばいいし、書かなくてもいい。 Convert Line Break(改行を<br>タグに置き換える)をオンにしておけば メールを書くような感覚で記事を書けるし、 自分で<br>とか<p>とかを書くのならオフにしておけばいい。

もちろん、wikiでもxoopsでも設定次第でHTMLタグを直接書けるのかもしれないが、 基本的な設計思想がそうなっている以上、どこかで必ず無理が生じるはずだ。

wikiもxoopsもすぐれたアイデアのこもったいいソフトだと思う。 でも実際使うのは技術者ばかりで、MTのように、非技術者の一般ピープルになかなか浸透しないのは、 肝心かなめのコンテンツを実際書く人の心理に微妙にマッチしない文書フォーマットにある。

疲れてますよ(本日のスパム)

本日のスパム。

Date:     Tue, 28 Sep 2004 20:20:34 +0900 (JST)
Subject:  疲れてますよ
From:     "send@hongen.com.cn" <aa@excite.co.jp>
To:       
X-mailer: Supmailer 9 [cn][maro]

確かに疲れてます。
ここのサイトで元気を出して下さいよ。
http://***.tk/
題名の書き方がナイス(笑)。 「○○サービスニュースレター第x号」とだけ機械的につけてるだけの企業メールマガジンの編集者もみならっていただきたいものだ。(See also: メールの題名とFromは既に戦場

このURLをうっかりクリックしてしまうまえに注意。 実はこのメールHTML形式で送信されているので、 リンク先のURLの実体は

http://xxx.xxx.xxx.66/wt.asp?CID=Zhongqiu&AT=1&CT=1&URL=http://***.tk/&FN =AAAAA&D=2004-9-28&T=19:21:30&Em=筆者の@別なメールアドレス
となっている。送信先のメールアドレスをURL埋め込むことで、 それにアクセスすると少なくとも相手のWebサーバのアクセスログにはメールアドレスが記録される = 誰がクリックしたのか追跡できるようになっている。 まぁ普通のメールマガジンでもたまに行われているよくある手法。

で、うっかりクリックしてみる(笑)。

あなたは18歳以上で規約に同意していますか?
さらに素直に(笑)「はい」のリンクを押すとこうなる↓
メンバー入会処理いたしました。

あなたの企業名(筆者が契約してるプロバイダ名)
あたなのアクセス場所-
あなたのネットワークアドレスxxx.xx.xx.xxx
あなたの接続業者(IPアドレスを逆引きしただけのホスト名)
あなたのアクセス日時 2004/09/28 23:58:12 (Tue)
あなたのマシン識別ID 1095040757(←単なるアトランダムな数字または固定な数字だろう)
(以降面倒なのでかいつまんで引用) お支払い期限は3日後で振込先は○○銀行○○で・・・ お支払いが無い場合はお客様管理者であるinfo@(筆者のプロバイダのドメイン).ne.jp へ 登録詳細を御連絡させて頂く場合も・・・。
だそうです。

思うところをつらつらと。

  • 最近のスパムもちょっとずつ手が込んできてるが、それでもこんなんでお金振り込んじゃうひとっているんだろうか?(いるんだろうなあ)
  • 前述のとおり、アクセスすると、その人のメールアドレスが相手にわかるように細工されているため、 数日後に「あなたは振込みがないよ!」と脅しめいたメールが来ることになるのだろう。 で、「ほんとに自分の情報がわかってしまうんだぁ!?どぉしよぉ〜〜??(涙)」となってしまう罠。
  • これであわててプロバイダに問い合わせてしまう人もいるのだろう。 プロバイダのサポートセンターもいい迷惑である。業務妨害にすらあたりそうなもんだが。
  • じつはちょっと前に携帯のメール相手で非常に似たような手法が使われている。(詳しくはこちら) 今回のはURLにメールアドレスを埋め込んであとで督促メールを送る材料にできるようになっているあたりが進化しているようだ。