この間来た、FBIからの違法ダウンロード警告を装ったウイルスメール。結構いい感じの内容だったんで転載しておこう（本文中のIPアドレスと電話番号だけ念のためマスクしておいた）。

FBIに「Department for "Illegal Internet Downloads", Room 7350」なんて部署、本当にあるのかなー。ちなみに、このメールに「refcode30860.pif」ってファイルが添付されていた。ウイルス種別は「W32.Sober.C@mm」だった。

Subject: Your IP was logged

Ladies and Gentlemen, Downloading of Movies, MP3s and Software is illegal and punishable by law.

We hereby inform you that your computer was scanned under the IP 172.157.***.*** . The contents of your computer were confiscated as an evidence, and you will be indicated. In the next days, you'll get the charge in writing. In the Reference code: #30860, are all files, that we found on your computer.

The sender address of this mail was masked, to fend off mail bombs.

- You get more detailed information by the Federal Bureau of Investigation -FBI- - Department for "Illegal Internet Downloads", Room 7350 - 935 Pennsylvania Avenue - Washington, DC 20535, USA - (202) 324-3***

これを日本風に直すと以下のような感じになるんだろうな。

タイトル: あなたのIPアドレスが記録されました

映画・音楽・コンピュータソフトウェアなどをインターネットからダウンロードすることは法律で禁止されています。

あなたのIPアドレス「172.157.***.***」が、違法ダウンロード監視システムによって検出されました。あなたのPCに保存された違法データは、すでに証拠品として押収されています。あなたには後日釈明の機会が与えられます。 この件の証拠番号は「30860」です。添付のファイルには、あなたのPCから押収されたすべての違法ファイルの一覧が記述されています。

このメールの送信元アドレスは、メールでの攻撃を避けるためにマスクされています。より詳しい情報を知りたい方は、警察庁までお問い合わせください。

---

警察庁インターネット違法ダウンロード対策部第3課 〒100-8974 東京都千代田区霞が関二丁目1番2号 Tel 03-3581-****(代)　

こんなメールが来て、それで「証拠番号30860.xls」とか「証拠番号30860.doc」とか添付されていたら、そのファイルを開いちゃう人ってどれくらいいるだろう？　たとえどんなに説得力があるメールの内容だったとしても、基本的に知らない人からのメールの添付ファイルは開いちゃダメよ（知っている人からのメールでも、開いちゃダメな場合が多いけど）。

なんかAmazonアソシエイトの結果を公表するのが流行っているみたいなんで、うちも公開。去年一杯の結果は以下のような感じ。

確か現在のサーバー＆システムに移行したのが2003Q3のタイミングで、そのときにAmazon Webサービスとの連携を強化した（ASINが含まれる記事のヘッダに、Amazon Webサービス経由で取ってきた商品情報を表示）ところ、ずいぶんアソシエイトの結果が向上した。

うちの場合は、mylog（日記）とblogmapでAmazonアソシエイトリンクを使っているんだけど、どっち経由の購入が多いのかははっきりしない。というのは、どちらでも紹介していない商品の購入に使われているパターンがほとんどだから。うちで紹介している商品自体が購入されるというパターンは、mylogの過去ログページ（書評）経由ってのが比較的多い。

今後も2003Q4くらいの売り上げが計算できると嬉しいんだけど、これってやっぱたまたまなんだろうー。2003Q4の場合は、うちを経由して「全然関係ないシリーズものを全巻購入」みたいなパターンが多かったんで再現性が低そうだ。

でも、これくらいの売り上げが計算できるようならば、AmazonアソシエイトとGoogle AdSenseでの収入を使って維持するようなサービス運営に手を出せるよなー。Webで遊びたい人間にとっては、AmazonアソシエイトとGoogle AdSenseは、「Web上で自給自足するためのシステム」って感じで非常にありがたい。べたべたの広告バナーを貼る気にはなれないけれど、AmazonアソシエイトとかGoogle AdSenseとかみたいな機能性の高い広告ならば、システムに組み込むのもさほど抵抗がないし。

というわけで、うち経由で購入して頂いた方々ありがとうございました。2003年Amazonアソシエイトの結果報告でした。

削除のお知らせ

重要な情報（http://d.hatena.ne.jp/kowagari/20040123#1074827080）より、Amazonアソシエイトのグレードアッププラン用アソシエイト・プログラム運営規約修正契約書に、

乙の販売目標及び取得した金額は甲の秘密情報であり、甲の事前の書面による承認なしで、乙は当該情報を第三者に開示することはできません。

という記述があるとのこと。確認してみたところ、確かにそう書かれていたのでこの部分に書いていた売り上げの詳細情報は削除します。 売り上げ詳細が、「販売目標及び取得した金額」に当てはまるのかどうかはちょっと微妙だけど。なんとなくこれは、人によって契約内容が異なっているという噂の、ボーナス契約の詳細情報のことを言っているような気もする。

関連リンク

• アフィリエイト、理想と現実（あるいは「いかにして余はアフィリエイターになりしか」） - http://kotonoha.main.jp/2004/01/14affiliate.html
• 昨年のAmazonメモ - http://bx.sakura.ne.jp/~kyou/diary/archives/200401/amazon2003.shtml
• Amazonアソシエイツの結果から考察 - http://artifact-jp.com/mt/archives/200401/amazonassociates.html
• アマゾンアフィリエイト収支公開 - http://www.rickdom.com/archives/001109.html

• CocologからのTrackBack対応お時間ください - http://blog.cnetnetworks.jp/archives/yamagishi/000846.html

今回、CNET JapanではSPAM TrackBack対策としてTrackBackで指定されるURLとPingを打ってきたサーバーのアドレスが一致するかどうかを確認し、違う場合はTrackBackを受けない仕様にしました。

という対策をしているんだそうな。なるほど、URLから解決したサーバー名と送信元アドレスを比較してみるってのは、確かにTrackBack SPAMはじきの手段としては、そこそこ有効そうだ。

もちろん今回のようにPing代行サーバーが別途存在する場合（PingProxyなんかもそうだし）とか、あるいはIPベースで複数ドメインを運用しているサーバーなんかからのPingも弾かれてしまう可能性があるけど、そのリスクよりは「あるサーバーから複数サーバーに置かれたURLを大量宣伝するTrackBack SPAMを弾ける」というメリットの方が大きそうだしな。DNSを引くコストで実装できるし。

• サイトの読者を減らす努力と「儀礼的無関心」 - http://artifact-jp.com/mt/archives/200401/sitereaderreduces.html
• 「ホーム」ページという快楽 - http://www.socion.net/soul/index.php?itemid=196

あたりから、アクセス制御の単位を「ケータイのメモリーに登録されているかどうか」に模しているところからインスパイアされたネタ。

いわゆるゲストブックという仕組みとRURIコード（ランダムCookie ID）によるアクセス制御の仕組みを組み合わせれば、かなり妥当なアクセス制御が実装できそうだ。

アクセス制御レベルは4段階。まずは「PUBLIC」＝完全に一般公開。アクセス制御なし。続いて「GUEST」＝ゲストブックに書き込んでくれた人。そして「FRIEND」＝ゲストブックに書き込んでくれた人の中から管理者が選択した人。そして「ADMINISTRATOR」。管理者自身。

サイトにアクセスするとユーザー（ブラウザCookie）には自動的にユニークなRURIコードが割り振られる。ゲストブックに書き込む際には、その書き込みにRURIコードが付随する。ゲストブックに書き込んだ人のRURIコードは、自動的にGUESTグループとして追加される。

ゲストブックを管理者モードで開くと、各書き込みごとに「FRIEND」に昇格させるかどうかのチェックボックスが用意される。FRIENDに登録したい人を選んでPOSTすることによって、その書き込み者のRURIコードは、FRIENDグループに追加される。

管理者のRURIコードは別途「ADMINISTRATOR」グループに登録しておく。管理ツールへのアクセス制御や、下書き（ドラフト）機能、自分専用の非公開メモ機能に活用する。

記事を書くときには、その記事単位に「PUBLIC」「GUEST」「FRIEND」「ADMINISTRATOR」というアクセスレベルを設定しておく。PUBLIC設定の記事は、誰が閲覧したときにでも表示される。それ以外のアクセスレベルの記事は、各グループに所属している人が閲覧したときのみ表示される。

アクセスレベルをもっと細かくしたり（ゲストブックの管理者モードからの選択肢をドロップダウンにするとか）、あるいはアクセスレベルの設定単位を記事単位でなく段落単位にしたり（<FRIEND>〜</FRIEND>みたいな独自タグで囲んだりとか）、いろいろカスタマイズしようはあるけれども、あんまり細かくするよりはシンプルにしておいた方がよさそう。

ゲストブックの公開・非公開は選択できた方がいいかもね。非公開にしておくとケータイのメモリーっぽい感じになるし、公開にする場合はどうせならばFOAFとかの汎用フォーマットで公開するとさらに活用しがいが出そうだ。

とか、仕事が忙しいときって現実逃避の筆が進むよなー。上記みたいなものを作るのは難しくないから、隙を見てちゃらっとプロトタイプを作ってみよう。

• 【特集】Efficeon大研究 〜新しくなったCMSを徹底チェック - http://pcweb.mycom.co.jp/special/2004/efficeon/

今まで見た中では一番詳しいTransmeta系CPU（Crusoe、Efficeon）のソフトウェア的解析記事だ。さまざまなコードを実行するのにかかったクロック数をCPUレベルで計測することによって、CMS（コードモーフィングソフトウェア）がどんなことをやっていて、どういう効果を発揮しているのかを見てみようというもの。

こんなに癖が強いとは思っていなかったなー。これくらい癖が強いとなると、もっさりと評判だったCrusoeですら、あらかじめ最適化したコードを書いたり専用コンパイラでコンパイルすれば、もっといいパフォーマンスが出たのかも。というか、もっとシェアが取れていればそういうのが出せたのかも。ってのはまさしく、卵が先か鶏が先か。

ACCAからNTT工事日確定のメールが到着。工事日は2004年1月22日だそうだ。ADSL初期の頃と比べると対応が早くなったのー。

あと一週間くらいしかないけど、So-net Phoneの解約手続きの方はまだ音沙汰がない。ちゃんと回っているのかな。もともとイレギュラーっぽい処理なんでノートラブルで移行できるかどうかちょっと不安だ。

blogmapの情報収集先にblog系更新情報RSSのデータを追加したところ、予想以上に収集先増加ペースが早く、データ収集処理にかかるコストが増大して、今朝のDBバックアップ負荷と重なったタイミングで、再びDB死亡。

もともと、あまり高負荷になることを考えずに作っていたんで、ここまで規模がでかくなってくると結構きついなー。ひとまず小手先のごまかしで、データ収集プロセスが過度に増えないようにしてみたけど、これだとまたいずれ破綻するだろう。コストを下げる方に設定を変えてしまうか、それとも高負荷に耐えられるような設計で作り直すか、悩むところ。

「本当に訪問者が知りたい20の質問（http://park3.wakwak.com/~madness/test/20q.html）」より。

1.サイト名とそのアドレス、あなたの希望する呼ばれ方（ハンドルネーム）についてお答えください

「ishinao.net」。http://ishinao.net/。「ishinao」。

2.あなたのサイトがどんなところか、一言でご説明ください

個人的にネットで遊ぶところ。“遊び”の範囲は限定しない。

3.このサイトへのリンク、サイト内各ページへの直リンクについてどうお考えかお答えください

もっとも妥当だと思われるURLでリンクしましょう。このサイトに限らず。

4.「サイト上で訪問者にこれだけは絶対にして欲しくない」ということをお答えください

対応が大変なこと。主に犯罪。

5.このサイトを運営していく上であなたが何を一番重視しているかについてお答えください

自分が楽しいこと。あるいは“楽しくない”ようにならないこと。

6.このサイトの更新頻度についてお答えください

常時（更新スクリプトが走っている）。手動更新頻度は不定。

7.1回の更新にかかる時間についてお答えください

不定。殴り書きが多いが、時間をかけているものもある。

8.現在の訪問者数と、今後希望する訪問者数についてお答えください

webalizerの解析結果によれば、2004年1月（15日）時点での1日あたりの平均で、ヒット数24,290、ページ数17,710、訪問者数10,976だそうだ。そのうち5割が日記（mylog）、3割がblogmap。

9.あなたにとって訪問者はどんな存在かお答えください

読者、知り合い、情報探索者、ウォッチャー、通りすがり、など。前の方ほど、意識している度合いが高い。

10.閉鎖の予定についてお答えください

ない。

11.あなたの性別についてお答えください

男。

12.あなたの生まれた年代、できればズバリ何年に生まれたかお答えください

1970年。

13.現在のご職業について差し障りない程度にお答えください

会社員。最近はプログラミングの仕事が多い。

14.出身と現住地について差し障りない程度にお答えください

秋田、岩手、熊本、帯広（北海道）、東京を転々と。現在は埼玉在住、渋谷在勤。

15.振られたときに得意な話題、分野についてお答えください

技術系、ネット系、物欲系のネタ。

16.あなたが一番良く使っているパソコンの性能、接続環境について分かる範囲でお答えください

PCG-SRX7（モバイル系のバイオノート）。IEEE802.11b／ADSL-8M。もうすぐPCも回線も替える予定。

17.毎日あなたが閲覧するサイトの数をお答えください

200〜300くらいかな？

18.Webを閲覧し始めた時期についてお答えください

1996年くらいから。個人アカウントを取ったのが1996年末。

19.初めてサイトを公開した時期についてお答えください

1996年末。

20.影響を受けた or 大好き or ここが閉鎖したら落ち込むかも、というサイトがありましたらお答えください

多数のサイトに影響を受けた。好きなサイトはいろいろあるが、「大好き」とか「ここが閉鎖したら落ち込む」というほどの思い入れのあるサイトはない。

前に「検索エンジン経由の末端ページコミュニティ（http://mylog.ishinao.net/id/1025）」という話を書いたけれども、これだけ検索エンジンが一般化してくると、逆に「検索エンジン経由でのみアクセスできるページ」というアプローチもありかもしれない。

というのは、たとえばblogmapの詳細ページってのは、ランキングに入っているときにはアクセスするためのナビゲーションが存在しているが、ランキングから外れてしまうとそこにたどり着くすべがほとんどない。

しかし、blogmapは検索エンジン（特にMSN系）順位が高いので、一度でもクローリングされた詳細ページは、そのページタイトルなどを検索することで、容易に検索エンジン経由でアクセスすることができる。

以前までは、blogmapシステム自体でもタイトルキーワード検索を用意していたが、その利用者は非常に少なくほとんど使われていなかった。しかし今になって、それとほぼ同等の機能を持つ一般の検索エンジン経由でのアクセスが増え始めている。

こうなってくると、逆に検索エンジンからたどり着いた人をメインのターゲットとして、詳細ページを構成してみるというのも一つの手となるだろう。キーワード検索でやってきた、そのページに関する前知識を持たない人に対して、適切なナビゲーションを用意し、何らかのレスポンスを期待する、とか。

そうなると、そのページはもはや、本来それが構成しているはずのサイト（blogmap）の一部としての意義が薄くなり、広大なインターネットの一部において、「検索キーワード」というメタ情報によりその意義が再定義された存在となる。

サイト側では、ひたすら末端ページを生成し検索エンジンにクロールしてもらうだけで、それぞれのページの定義や評価（ランキング、リスティング、ナビゲーション）は行わない。各ページの定義や評価は、検索エンジン経由で訪れた人たちのレスポンスによって、形作られていく。

Wikiみたいな自由度の高い機能を末端ページに持たせることによって、システムによって制御されずまるで生き物のように自然発生・成長していくページたち。なんて感じになると面白いかも。

• BitChannel / ポリシー決定 - http://i.loveruby.net/d/20040113.html#p04

>>最近はとにかくキャッシュが嫌いなのだ。 tDiary でほとんど唯一気に食わないのもキャッシュだし。家のメインマシンの CPU は P4 2.4GHz なわけで、キャッシュなんかなくても高速に動くのだ。それにも関らず必ずキャッシュしてくれちゃうもので、 tdiary.conf を編集するたびに rm -rf cache/tdiary するのがうざくてたまんない。キャッシュは嫌だ。キャッシュは悪だ。世界の敵だ。ブギーポップが出現しちゃうくらいダメだ。

自作フレームワーク（PHP）ではキャッシュ使いまくりなんだけど、

• 実行されるスクリプトファイル（requireされるものも含む）の更新日時
• データおよび設定ファイルの更新日時
• DBからselectした行の更新日時

の中の一番新しい日時と、使用するキャッシュファイルの更新日時を比較して、キャッシュファイルの方が古かったら自動的にキャッシュを破棄できるようにしている。

あと、データ編集系の処理を行うときには、その編集処理によって古くなるキャッシュをまとめて簡単に削除できる仕組みも用意して、腐ったキャッシュファイルをできる限り自動的に削除できるようにする、なんて感じの一般的なキャッシュ管理の仕組みも併用。

ってのは要は、「キャッシュごとに依存するファイルを登録しておき、依存ファイルの更新日時とキャッシュファイルの更新日時を比較して、キャッシュをコントロールする」という仕組みの応用なんだけど、データレベルの操作に加えて、スクリプトファイル自体の更新もデータの更新と同列に扱っておくのがポイント。

そんな感じにしておくと、キャッシュを使う際に付随する面倒くささが大幅に減少して結構いい感じ。