2009年08月22日
■ 「Winny利用者が増加に転じた」は誤り 5月から異常発生中のため
ネットエージェント社からの発表があったということで、INTERNET Watchに「Winny利用者が再び増加」という記事が出たが、これは正しくない。
- Winny利用者が再び増加、Perfect Darkは「最も警戒が必要」, INTERNET Watch, 2009年8月20日
ネットエージェントは20日、お盆休み期間（8月8日から8月16日まで）におけるファイル共有ソフト「Winny」「Share」「LimeWire/Cabos」「Perfect Dark」のノード数について、独自の検知システムによる調査結果を公表した。減少を続けていたWinnyの利用者が増加に転じたほか、（略）
Winnyの平均ノード数は約30万で、前年同期比約132％と増加。今年のGW期間（4月26日〜5月6日）と較べでも約136％と増加していた。
- Winnyノード数の推移分析, ネットエージェント, （更新日不明）
2007年度の中盤以降緩やかに利用者の減少傾向が続いていましたが、2009年7月以降、Shareの利用者に減少傾向が見え始めた頃と時を同じくして Winnyの利用者が徐々に増加し始めました。しかしながら単純にShareの利用者がWinnyに戻ったことによる結果であるとは数値の上からも考えにくく、ここにきてWinnyの匿名性・機能性が再評価されているのではないかと推測されます。
5月12日の異常なピーク
私のところのWinnyネットワーク観測システム（図1）は、今年5月12日の昼頃から急激に異常な値を示していた*1。
（2009年7月12日撮影）
写真中のミニモニタ上部中央に表示しているグラフは、5月28日の時点では図2のようになっていた。黄色の線（真ん中の線）を見ると、5月12日正午ごろから14日正午ごろにかけて明らかな異常ピークが見られる。
青の線（下の線）は、1回の巡回で観測されたキーから、キーにソースノード（当該ファイルの提供元を意味するIPアドレスとポート番号）として記されたノードの数を計数したもので、1回の巡回は20分〜30分程度である。この値は、おおよその瞬間アクティブノード数を表しているかのようにも思えるが、一巡する時間内に全ノードを巡りきれているとは限らないので、そうとは言えない*2。
この青の線は、毎日深夜にピークがあり、平日の昼間には小さい値となって、土日や祝日には昼間でも値があまり小さくならないという、安定した傾向が見られる。
黄色の線は、青の線が示すノードについて過去24時間以内に存在した数を求めた値であり、1日あたりのアクティブノード数を表す。黄色の値が青の値の2.5〜3倍程度になっているのは、昼間だけ使う人や、夜間だけ使う人がいるためであり、また、1日の間にIPアドレスが変化してしまうノードが重複して計数されてるケースも少なからず含まれるためである。
この黄色の線は、土日と祝日に大きな値となる傾向があり、祝日のない週ではほぼ周期的なパターンを見せている。
赤の線（上の線）は、青の線が示すノード以外に、Winnyがコマンド4（他ノード情報の通知）で送ってくる隣接ノードも含めて計数したもので、24時間あたりの数である。（これが従来方式での「ノード数」に相当するものである。）
新方式でのノード数調査
じつは、5月3日から巡回方法を変更している。従来方式では、キーに含まれるノード情報と隣接ノード情報を合わせてノード数を計数し、それら全部に対して接続を試みる巡回をしていた（その方がすべてのノードを発見できると思った）が、新方式では、キーのソースノードだけに接続を試みるようにした。その結果、巡回時間が大幅に短縮され、20分〜30分で一巡するようになった。これは、到達不能なIPアドレスに対する接続試行が大幅に減少したためである。
このようにしたのは、隣接ノード情報には、既に稼働していないノードがかなり多く含まれているのではないかと気づいた（2月9日の日記の脚注1）ためである。実際に試してみると、従来方式では、接続成功率（Winnyプロトコルでの接続が成功する割合）は25%〜35%程度だったのに対し、新方式では70%〜75%となった。
Winnyのキーは約25分で消滅する*3のに対し、各Winnyノードが保有する隣接ノード（「Noderef.txt」に保存される）には、かなり古いものも含まれていて、古いノードもコマンド4で拡散されているのではないかと考えられる。これが、具体的にどのくらい古いものまで含まれるのかは、まだ調査していない。加えて気になるのは、時々しかWinnyを稼働させない人々の影響であり、たとえば一週間ぶりにWinnyを起動したときに、「Noderef.txt」には一週間前のノードが保存されているわけで、それらがコマンド4で拡散されているのであれば、相当な割合で既に存在しないノードの情報が拡散されていることになる。
つまり、従来方式で計数するノード数は、実際のWinny利用者数よりもかなり多めに出ているのではないかと疑いを持った。図2の赤の線（隣接ノード情報を含むノード数）と黄色の線（アクティブノードだけのノード数）を比べると、倍近い差がある。本当に25万人もの利用者がいるのかというわけである。しかし、黄色の線が実際のWinny利用者数を表しているとも言い難い。なぜなら、（ソースノードを自ノードとした）キーを出さないノードはアクティブノードとして計数されていないからである。「Port0」設定のノード*4は（ソースノードを自ノードとした）キーを出さないので、計数されない。そうすると、Port0ノードの数がどのくらいなのかを調べればよいわけだが、まだ調査していない。
類似の話は、ネットエージェント社のShareのノード数推定方法の説明にも見られる。
Shareのノード数に関して
（略）Shareのノード数は単に発見されたノードを集計するだけでは計測できません。Winnyとは違い、ノード情報の寿命が長いため、発見されたノードを集計すると１日約90万ノード発見できますが、既に多くのノードはIPアドレスが変更されている、または、Shareが起動されていません。そのため、発見されたファイル情報より更新日時（ダウンロードしたファイルブロックの最新の日時）がその日と同じファイルを持つノードを集計、重複を除いたノード数が最もShareネットワークの実態ノード数に近いと考えられ、この値を１日のノード数として発表しています。ダウンロードしたファイルが全く存在しないノードは集計されていません。
というわけで、Winnyのノード数測定方法はまだ確立していないと思う。ネットエージェント社のWinnyノード数測定でも、隣接ノード情報を含めていると思うので、その値は実際より多めに出ている可能性があるように思う。
仮に、図2の黄色の線で表す値をWinnyノード数とすると、現時点で12万ほどであり、ネットエージェント社発表のShareのノード数16万より少ないことになる。実際のところはちょうど同数くらいなのではないかと推測するが、まだ確かなことは言えない。
なお、従来方式で計数したノード数は、ネットエージェント社発表のものより少なく出ていて、原因がわからないままだったが、新方式（図2の赤の線に相当）では、概ね同じ値（平日で20万前後、休日で25万弱）が出るようになった。*5 *6
なお、図2の赤の線を、旧方式によるノード数と一緒にグラフ化すると図3のようになる。
ランダムIPアドレスの偽キー散布
話を戻すと、5月12日の異常なピークは、リアルタイムで見ていて異常が起きているとわかった。黄色の線の上昇が直線的だからだ。もうひとつには、新システムでは、新規出現ノードに対してDNSの逆引きをして、.go.jp や .gov などのドメイン名のものが現れるとリアルタイム表示するようにしていたところ、.nasa.gov などのドメインが現れたため、異常だと気づいた。つまり、Winnyノードとして存在しないIPアドレスのキーがランダムに作成されて、一定の速度で散布されているのだと予想した。
黄色の線の上昇はいつまで続くのだろうかと思いつつ見ていた。もしずっと散布され続けるなら、24時間経過したところで頭打ちになるはず（24時間以内のノード数の計数だから）であったが、ちょうど24時間後に散布が打ち切られたようで、黄色の線は24時間後から急激に（同じ傾きで）減少した。この後の2週間では同様の異常が見られず、何らかのテスト、実験だったことを窺わせるもの（ワーム等によるものではなく）だった。
どこからこの偽キーが散布されたのかを調べようとしたが、それは判明しなかった。かわりに、特定の少数ノードに偽キーが大量に注入された痕跡があるのを見つけた。
観測システムでは、各ノードに接続したときのログとして、抽出したノード数と、そのうち新規に見つかったノードの数を記録し、新規ノード抽出率を記録している（これは元々はデバッグ用途で出力したものだった）。新規ノード抽出率は、クローラの立ち上がり当初は高い割合を示すが、何回か巡回した後は、当然ながら、新規ノード抽出率はごくわずかとなる。ところが、5月12日の異常発生時には、以下のように、新規ノード抽出率が90%を超えるようなノードがいくつも見つかった。
XXX.XXX.XX.XXX:4321 life: 35 con: 3 new: 98.8% ( 168/ 170) 2009-05-12.13:18:56 18禁ゲーム|同人誌|同人ゲーム
XXX.XXX.XX.XXX:7743 life: 33 con: 1 new: 92.8% ( 309/ 333) 2009-05-12.13:50:06 ゲーム||
XXX.XXX.XXX.XXX:7888 life: 35 con: 1 new: 97.6% ( 40/ 41) 2009-05-12.14:59:12 アニメ|ゲーム|18禁
XXX.XXX.XXX.XXX:7000 life: 35 con: 1 new: 98.6% ( 140/ 142) 2009-05-12.21:01:16 18禁ゲーム|アニメ|同人
XX.XXX.XXX.XX:26829 life: 31 con: 1 new: 99.8% ( 471/ 472) 2009-05-12.22:43:12 18禁ゲーム|同人ゲーム|18禁ゲーム
XX.XXX.XXX.XX:26829 life: 26 con: 4 new: 99.6% ( 240/ 241) 2009-05-12.23:02:28 18禁ゲーム|同人ゲーム|18禁ゲーム
XXX.XX.XXX.XXX:1842 life: 35 con: 1 new: 98.9% ( 174/ 176) 2009-05-13.01:39:09 gba|ゲーム|zip
XXX.XXX.XX.XXX:7744 life: 37 con: 2 new: 97.6% ( 166/ 170) 2009-05-13.02:09:26 18禁|ゲーム|同人
XXX.XXX.XXX.XXX:6000 life: 31 con: 1 new: 97.5% ( 39/ 40) 2009-05-13.03:37:38 アプリ|ゲーム|C75
XXX.X.XX.XXX:2009 life: 38 con: 1 new: 90.9% ( 159/ 175) 2009-05-13.04:20:10 .rar|ゲーム|18禁
どうやら、特定のクラスタワードを指定しているノードに接続して、数百個の偽キーをそのノードに注入するということが行われたようだった。
注入されたノードから送られてくる偽キーらしきものを見てみたところ、キーに記載されたソースノードは、IPアドレスが実在しないホストの（あるいはWinnyが稼働していない）もので、ポート番号は、注入されたノードとなぜか同一になっていた。明らかに、何者かにより作為的に生じたものである。キーが示すファイルの内容は、ファイル名を見る限り平凡なもので、これといった特徴はみられなかった。
これを見て、何がしたいのかよくわからなかった。特定のファイルのダウンロードを阻止したいのなら、特定のファイルID（ハッシュ）について集中的に偽キーを出すはずのところ、そうではなかったし、Winnyネットワーク全体に対してダウンロードしにくくする妨害目的にしては、この程度の偽キー注入では影響がない。偽キーを注入したノードの利用者に対して妨害効果があったかもしれない（その効果があったのかどうかは、そのノードの利用者に聞いてみないとわからない）が、そうだとしても、偽キーのソースIPアドレスをランダムにする必然性がない。
Winnyネットワーク等への偽キーの注入（インデックスポイゾニング）は、正当な目的で、いくつかの大学や企業等で何年も前から研究として行われてきた*7し、特定ファイルのダウンロード阻止は、商用のサービスとして実用的に実施されてきた*8わけだが、普通は、実在する問題のないIPアドレスを用いて行うものであって、こんなふうに、ランダムIPアドレスを注入するという乱暴な方法が実施されたことは（少なくとも大規模には）なかったと思う。
ランダムなIPアドレスを散布すれば、そのIPアドレスが実在した場合には、そこにいくらかの迷惑が及ぶことになるのだから、正当な目的のものであっても、倫理的に不適切な行為だと思う。何人かの知り合いに聞いてみたが、「うちじゃない」とのことだった。どこかの研究新規参入者が、教授や上司に相談せずに実施しているものか、あるいは個人によるものなのかもしれない。
その後、5月29日から6月3日まで断続的に繰り返し同様のことが行われ、6月14日と、6月27日から29日、7月3日、そしてそれ以降、断続的にしだいに頻繁に行われるようになった*9。図2のグラフを現在までの範囲で示すと、図4のようになる。黄色の線に着目すると、7月中旬から顕著になり、特に8月の6日から19日にかけては規模が大きくなっていたことが窺える。異常発生期間を灰色で示した。*10
ネットエージェント社が20日に発表したノード数調査の、測定期間「8月8日から8月16日まで」は、ちょうどこの異常発生期間にすっぽり入っている。そのため、偽キーのIPアドレスを拾ってしまい、ノード数が「前年同期比約132％に増加」という結果になってしまったのだろう。平均32%増という値は、図4の赤の線とだいたい一致している。
なお、図4から異常な増分を排除して眺めてみると、ノード数は緩やかな減少傾向を続けていることがわかる。
Winny互換プロトコルで実験を行う人達に提案だが、偽キーを散布するときは、実験とわかるように、キーに特定の値を埋め込むようにしてはどうだろうか*11。「BBSスレッド管理ノードのポート番号」フィールド（ファイルクエリの場合は使用されない）の値を「7743」とする案（通常は「0」が送られているようなので）でどうだろう。そうすれば、「Winny利用者が増加に転じた」といった誤解を避けることができ、それを打ち消すためにこうやって実験の存在を暴露せざるを得なくなることも避けられるので、ウィンウィンじゃないだろうか。（25日訂正： この方法ではうまくいかないことが判明。Winnyは、他ノードから受け取ったキーを別のノードに渡す際、キーの全フィールドをコピーするのではなく、必要なフィールドだけ転載するようで、未使用フィールドにマークを書いても伝播しないことが判明。0x00で始まるトリップの2バイト目以降にマークを書く方法も試したが、伝播しなかった。となると、他の方法としては、「キー消滅判定タイマー」を1600より大きい値にするという方法と、ハッシュ値に特定のパターンを持たせるという方法が考えられるが、前者は、タイマー値はしだいに小さくなっていくので、1600以下になると区別できなくなってしまうし、後者は、通常のWinny利用者にバレてしまうし、ハッシュ値を変更しない目的のときに使えない。あとは「キーバージョン」が使えるのかどうか。）
■ 7月から未曾有の大規模ポイゾニング実施か
上記の件とは別*12に、7月上旬から8月にかけて、通常とは違う事態が生じていた。（おそらく上記の件とは無関係なのではないか。）
前回の日記で示した固定IPアドレスのWinnyノードの挙動について、新システムによる観測データも集計してみたところ、普通でない現象が見られた。以下の図5は、前回の日記の図7の事例の2009年4月26日〜8月21日の期間についてを表示したものである。
全体に疎になっている（薄くなっている）のは、横軸のスケールが前回とは異なるため（前回は32か月分で、今回は4か月分）だが、7月11日前後から始まったように見える密度の高い瘤のような領域が見える。これだけなら、このノードの利用者が利用形態を突然変更しただけかもしれないところだが、他のノードにも同様の現象が見られた。
そういえば、そのころ、無作為にキーダンプに目を通したときに、ファイル名に「ドラゴンクエスト」を含むものがやたら目につくことに気づいていた。「ドラゴンクエストIX」の発売日が7月11日だったらしい。
瘤の部分のキーのファイル名を調べるために、図5のファイル番号8500あたりのファイルについて、ファイル名を抽出してみたところ、次のようになった。同じファイル名でもファイルID（ハッシュ）は別のものである。
8500 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar.lzh 8499 NDS邦画成年コミック伊集院光 深夜のバカ力.vobRom星空の守り人ビデオドラゴンクエストIXおすすめrar3966挿入.exe 8498 [焙煎にんにく][アテナ映像][〓〓〓〓] 〓〓〓〓FUCK 〓〓〓ズボズボ.avi 8497 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8496 (NDS) ドラゴンクエスト9 星空の守り人.rar 8495 NDS邦画成年コミック伊集院光 深夜のバカ力.vobRom星空の守り人ビデオドラゴンクエストIXおすすめrar3966挿入.exe 8494 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8493 【NDS】【パッチ済セーブOK】【supercard one動作OK】3966 ドラゴンクエスト IX DS （ｊｐ）.nds.rar 8492 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8491 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8490 3966 ドラゴンクエストIX 星空の守り人.nds.jpg 8489 (NDS) ドラゴンクエスト9 星空の守り人.rar 8488 (NDS) ドラゴンクエスト9 星空の守り人.rar 8487 【NDS】【パッチ済セーブOK】【supercard one動作OK】3966 ドラゴンクエスト IX DS （ｊｐ）.nds.lzh 8486 【NDS】【パッチ済動作OK】3966 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人.rar 8485 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人.zip 8484 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8483 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar.lzh 8482 [NDS][ROM] ドラゴンクエストⅨ 星空の守り人(J)プロテクト解除済み.rar 8481 (NDS) ドラゴンクエスト9 星空の守り人.rar 8480 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8479 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar.lzh 8478 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8477 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8476 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8475 【PV】[PV] 〓〓 x 〓〓〓〓 - 〓〓〓〓〓〓.avi 8474 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8473 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8472 3966 ドラゴンクエストIX 星空の守り人.nds 8471 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8470 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8469 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar.lzh 8468 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8467 (NDS) 3964 - ドラゴンクエスト ＩＸ 星空の守り人.nds 8466 3966 ドラゴンクエストⅨ星空の守り人.nds 8465 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人.zip 8464 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8463 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8462 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8461 nds(bin+cue).rar同人誌NDSROMドラゴンクエストドラクエナインアナルロックマン妹住所録星空の守り人ドラゴンクエスト9.exe 8460 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8459 [NDS][ROM] ドラゴンクエストⅨ 星空の守り人(J)プロテクト解除済み.rar.lzh 8458 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人(起動確認済).zip 8457 3966 ドラゴンクエストIX 星空の守り人.nds 8456 3966 ドラゴンクエストIX 星空の守り人.nds 8455 3960 ドラゴンクエストIX 星空の守り人 (パッチ済み).nds.jpg 8454 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人 (パッチ済み).zip 8453 127918728 (NDS)(Rom) 3966 ドラゴンクエストIX 星空の守り人.rar 8452 [NDS][ROM] 3960 DRAGON QUEST Ⅸ ドラゴンクエスト9 星空の守り人(起動確認済).zip 8451 NDS邦画成年コミック伊集院光 深夜のバカ力.vobRom星空の守り人ビデオドラゴンクエストIXおすすめrar3966挿入.exe
「ドラゴンクエストIX」で埋め尽くされている。7811番から登場し始め、8995番まで延々続いている。図6についても同様で、9524番から始まって最新の10968番まで続いている。もしかすると現在も続いているのかもしれない*14。
いわゆる捏造ファイルだろう。ダウンロード阻止は成功したのだろうか*15。
これらノードの利用者らが、「ドラクエ」ないし「NDS」等での自動ダウンロードをかけている人達なのか、それとも、そのつもりがないのに入ってきてしまったものなのか、この点が気になる。
この2つのノードについてちょと調べてみたところでは、「ドラクエ」にも「NDS」にも興味がある様子は見えなかった。もしかすると、偽ファイル本体の拡散ではなく、偽キーを散布し続けている*16のかもしれないが、どちらなのかはまだ調べていない。
（25日追記）調べてみたところ、偽キーが散布し続けられていることが判明。7月18日の日記と同じ実験を1時間だけ行った（キーのファイル名は7月18日のときと同じ）ところ、数時間後から、私のWinnyPotのIPアドレスが「ドラゴンクエストIX」を持っていることを意味するキーが、Winnyネットワーク上のあちちのノードで観測されるようになった。つまり、実在するWinnyノードから適当に選んだIPアドレスをソースノードとした偽キーの散布によって、ダウンロード阻止が試みられているようだ。したがって、前述の「『NDS』等で自動ダウンロードをかけている人達なのか」という点については、そうではない（そうとは限らない）ということになる。
*1 このことはTwitterにも書いていた。Twitter発言1、発言2
*2 時間内に全体を巡回しきれないために、実際の瞬間ノード数より少なく出ているかもしれないし、逆に、巡回中に新たに参加したノードを含んでいるという意味で、多めに出ているとも言える。
*3 金子勇著「Winnyの技術」p.120に「キーの寿命の初期値は、現在約1500秒程度に設定しています」とある。しかし、実際には、「キー消滅判定タイマー」の値が1500秒を超えるキーも観測され、（偽キー由来らしきものを除くと）1600秒に境目があるようなので、1600秒の記憶違いではないだろうか。
*4 「NAT内でポート解放していないノード」とは意味が異なる。1月25日の日記で「Port0ノード」という表現を使ったが、それは「NAT内でポート解放していないノード」の意味のつもりで書いたもので、用語の使い方として適切でなかった。ここでは、Winnyの設定で「Port0」モードを設定しているノードのことを指す。
*5 新方式に移行する際に、Windowsを使うのをやめて、Mac OS X上で動かすようにしたところ、大量ネットワーク接続のマルチスレッディングによる処理の性能が大幅に向上（キー取得量で約20倍に向上）しており、Windowsでは相当な取りこぼしが起きていた（接続したものの応答を処理する前に中止するログが大量に残っていた）ことがわかった。
*6 アクティブノードしか巡回しなくなったことが原因で、隣接ノード情報を含むノード数（赤の線）が少なく観測されている可能性も考えられるが、アクティブノードを24時間巡回し続けているのだから、古いノードも、そのどこかで隣接ノード情報として得られているだろうから、それはあまり大きくないと考えられる。
*8 たとえば、1月11日の日記で触れた、流出ファイルの再放流行為に対して、拡散阻止措置が実施されたようだった。
*9 注入対象となったノードのクラスタワードの特徴に変化はなかったので、これらは同じ人達によるものと思われる。
*10 ちなみに、異常発生期間に青の線の値が上昇しないのは、ランダムIPアドレスによる偽ノードは25分で消滅するため、ある巡回で拾ったものを次の巡回でも拾うことがなかったこと、そして、1回の巡回あたりに拾う偽ノード数は千個程度だったため、誤差の範囲となってグラフに現れていない。黄色や赤の線では、1回現れただけのノードも24時間蓄積されるため、値が急増している。
*11 「そんなことをしたらバレてしまって元の木阿弥になる」のかもしれないが、通常のWinny利用者たちには気づかれないのであるし、Winny互換プロトコルで何かやっている人達にバレるのは、元々どうやってもバレるのだから、実際に問題が生ずるまでは、偽キーにはマークを付けておくのでもよいのではないか。
*12 こちらは、実在するノードをソースとしたキーが観測されたものなので。
*13 ちなみに、このノードの前回の期間でのグラフは以下のとおり。
*14 グラフの右端が丸まっているのは、終息したとは限らず、前回の日記に書いた「ソース書き換えキー排除」の結果の可能性もある。「2回以下しか現れなかったキーを除いて」いるので、これから現れるキーの分まで消えた影響があり得る。
*15 よく見ると「.exe」もいくつか含まれている。これは正当とは言えない。正当な措置に便乗したものなのだろうか。それとも両方とも悪意ある者によるものなのか。
*16 キーの散布だけでは25分で消滅してしまう。（25日訂正：キー消滅判定タイマーの値を65535まで増やすことはできる。それでも、18時間ほどで消滅する。）