2010年も、どうぞ Nyzilla をよろしく。
Nyzilla配布ページの、「あ…あんたが送信してんだからねっ!」のキャラクターは、絵師さんに発注して描いていただいたものです。*1
そこにクレジット表記がなかったのは、メッセージ性の強い形で用いることから、メッセージが絵師さんからのものと誤解する人が出かねないことを心配して、事前に絵師さんと相談のうえ、クレジット表記なしということで描いていただいたためです。
右のイラストは、絵師さんに今度は自由に描いていただいたものです。
絵師さんは、ネットを検索して見つけたイラストレータ仲介サービスで探しました。お手頃な料金で迅速にこうしたデザインを発注できることは、ビジネスでもきっと大いに活用できるのではないかと思いました。
キャラクターの案を思い立ったのは、Nyzillaの趣旨をどうしたらストレートに伝えられるだろうかと悩んでいたときでした。文章でだらだら説明したところで意味が伝わらなさそうです。
伝えたいことは、まさに「あなたが公衆送信しているのですから」という一言に尽きるわけで、このことに気づくと、3年前にNHKニュースで見たシーンを思い出しました。これをAAに言わせてはどうかとも思ったのでした。
いや、嫌ーっ、こんなんじゃない、コレジャナイ。
もちろんこの案は一瞬にして捨て去り、次に思い出したのが、はてな界隈で以前に見かけた「ツンデレサーチ」のサイトでした。これを参考にさせていただいて、絵師さんに発注したというわけです。
もともと、Nyzillaの最初の構想を思い立ったのも、このNHKニュースが放送されたころのことでした。当時、eEye Digital Securityの鵜飼さんが、「Winny問題について意見交換しませんか」という記事を書かれていたことから、私は鵜飼さんとお話しして、誰でも閲覧できるようにするべきだとする意見を伝えたのでした。しかし、最終的に、Winnyの閲覧ツールは一般公開されなかった*3ことから、じゃあ自力で作るか、ということで、同年6月25日に作り始めたのでした。
私があるべきと思ったツールは、鵜飼さんらのツールとは設計理念がいささか異なっていたようでした。私の構想では、Webブラウザと同様に、サイトを指定するとそこにあるものが表示されるという構想でした。そこが重要でした。
その後、「Nyzillaをリリースすべきか迷う」というエントリを書いていたように、リリースに向けた開発をしていなかったわけですが、それは、対象ノードが公衆送信しているファイルを確実に示すことはできないんじゃないかと、その時点では思っていたからでした。
ところが、2009年9月になると、ある実験中に、これは簡単にできるんじゃないか?と確信できる知見が得られたため、リリースする方向で開発を再開したのでした(2009年9月23日の日記)。
もっと早くからやればよかったという気もしますが、まあ、趣味の日曜プログラミングですので、行き当たりばったりです。
*1 ロゴとダウンロードボタンのデザイン、アイコン作成は、別のWebデザイナーの方に発注したもの。
*2 関連ニュース: ACCS久保田事務局長「自分のAA作者を探してます」, ITmedia, 2009年9月29日
*3 Share版はその後「Retina Sharebot」として一般公開されている。
まただ。これで3回目。今回は明らかに報道するメディア側に問題があり、誤報である。
「Winny」のノード数は、2010年1月は2009年12月の平均ノード数より増加傾向が見られ、昨年と同様に15万件から20万件の間で推移。最低を記録したのは、1月1日の15万4400件で、以降増加して13日に調査期間中最高となる18万4610件に達した。
こちらの観測では、下の写真のように、Winnyのノード数は、2010年1月1日を境に約2割減少したことを示している。(1月12日のTwitter発言参照。)
何をもって「ノード数」とするかは複数の定義があり得るわけで、計数方法によって異なった値が出てくるところだが、上の写真の赤のグラフ(一番上)は、ネットエージェントの計数方法とほぼ同じと思われる。
12月5日から数日間、黄色のグラフ(真ん中)や青のグラフ(一番下)がいつも通りの緩やかな減少傾向を示しているときに、赤のグラフが異常な値を示していた(当時のTwitter発言1、2)。この時点で、ノード数を水増しする妨害行為が行われていると思い、ネットエージェント社には知らせておいた。
今回のネットエージェント社の発表には、ちゃんと次にように書かれている。
※ 2009年10月まで、Winnyネットワークに対しランダムなIPアドレス、ポート番号によるキー情報の大規模な拡散行為が行われており、その結果Winnyネットワーク上に実際には存在しないノードの情報が数多く検知されました。2009年11月以降、そのランダムなIPアドレス、ポート番号によるキー情報の大規模な拡散行為は停止しており、検知されたノードの数は減少しています。
Winnyネットワークについては本事例以外にもノード情報を意図的に拡散する行為が確認されており、実際より多くのノード数が集計される場合があります。
Winnyノード数の推移分析, ネットエージェント, 2010年1月17日閲覧
この注意点を伝えたのはRBB TODAYの記事だけだった。それでも記事の見出しは「Winnyは相変わらず」と断定しているし、INTERNET Watchは「増加傾向」とまで言っている。
なぜネット系メディアは取材をしないのか。取材をしていれば誤報は防げただろう。電話して話を聞くくらいのことができないのか。
これまでにも同様の事態は、2回起きていた。
私は10月17日の時点では次のように書いていた。
8月にこの事態について書いた際、偽キー散布について、「Winny利用者が増えているということにしたい何者かが、ネットエージェント社のノード数発表の頃合いを見計らって、ノード数の水増しを謀っているのではないか」といった声が出ていたが、はたしてそれはどうだろうか。
私がそれを疑わずに、大学等での実験ではないかと考えたのは、もし、ノード数の水増しを謀るなら、もっとうまくやるはずだと思うからだ。図1のように断続的に散布したり中止したりを繰り返す意味がわからない。もっとうまく散布されていたら、私も水増しに気づかなかったかもしれない。
今回、10月8日(高裁判決の日)以降連続して偽キー散布が行われており、意図的なものかという感じもしなくもないが、判決によって増加したことを演出したいなら、判決前の10月1日から散布されていたのは何なんだということになる。もしかして、有罪と見越して「高裁でも有罪判決でWinny利用者激減」という演出を予定していたというのだろうか?(それにしては、判決前の8日午前0時から偽キー散布が開始されているわけで、どういう説明がつくのか。)
いずれにせよ、もし今後、この偽キー散布が自然な方法に進化していったなら、実験ではなく意図的な水増しだという可能性を疑う必要が出てくるかもしれない。
その後、23日に「ランダムIPアドレスの発生源を特定」を書いた。ネットエージェントにも知らせたところ、当該ISPに通報したとのことで、その後、10月末にランダムIPアドレスは現れなくなっていた。
そして、12月22日の日記に書いていたように、10月までのものとは異なる新手の水増し手法が現れた。
なお、12月5日から5日ほどの間、異常なピークが赤のグラフにだけ現れた(黄色には現れていない)。ピンクのグラフは、赤のグラフからノイズを除去したものであるが、その方法ではこのノイズを除去できなかったことを示している。新手のノード水増し手法が登場した(か、あるいは新しい実験が始まったのか)と考えられる。今後もこういったことが起きる可能性があるので、注意が必要だ。
これは、水増し能力を確認するテストだったのだろう。そして1月4日から水増しが開始されていた。今回は、以前よりバレにくいように水増しされており、今後さらにバレにくい方法がとられるようになると、私も見分けがつかなくなるおそれがある。
しかし、いずれにせよ言えそうなことは、Winnyノード数は極めて安定的に緩やかに変化しており、短期的に変化が現れることは、ちょっとやそっとのことでは起きない*1ということであり、今後、この手の増加傾向が現れたら、無視するべきだろう。
なお、ノード数の観測は中央大学でも行われているので、そちらにも問い合わせるとよいのではないかと思う。
*1 グラフの青の線(一番下)が示すように、リアルタイムのアクティブノード数は、平日の昼間に少なくなる傾向、土日祝日は昼間も減らない傾向、夜のピークは土日祝日に少し増える傾向があり、年中一貫している。これを24時間分で集計すると、黄色のグラフ(真ん中)のように、土日祝日に増えるという結果になる。年末年始を見ると、年末は祝日に近い傾向が現れ、正月三が日は平日並みに減少し、夜も増えないという傾向が見られる。その結果として、正月三が日はノード数が特に減る。ようするに、単純に、家を留守にしたときにはWinnyを動かさない人が一定割合いるということの現れだろう。そして、今年は特別で、1月1日を境に約2割減少した。なお、Nyzilla使用時はこの数に影響しないようになっている。
NHKが今日になってテレビでこんな誤り情報を流した。まことに遺憾。なぜ私に確認しない。Webでちょっと「winny 利用者」で検索するだけで信用できない情報とわかるじゃないか。
依然として20万台以上に上っており、特にWinnyは、元日に少し減ったあと、利用が増え続けているということです。
観測Winnyノード数は、下の写真のように、1月21日14時ごろ、一気に8万4千ノードが消滅し*1、その後は、先月比で約2割ほど減少した数で従来通りのパターンで推移している。
23日から水増しノードの発生源について調査していたところ、26日にほぼ判明したが、まだ裏付けのための集計処理が終わっていない。NHKがこのような報道を出したので、取り急ぎ、速報として以下の事実関係を示す。
原因となっている水増し分のIPアドレスは、以下の3つであると判明した。
160.193.162.233 160.193.162.234 160.193.163.135
これらは、逆引きできないが、traceroute等でわかるように、大阪市立大学に割り当てられ、接続機器が稼働中のIPアドレスである。ただし、これらのIPアドレスが発生源だったのか、それとも、他の者により偽装されたIPアドレスとして出回っていたのかは、まだ解析できていない。
これら3つのIPアドレスそれぞれに、2万8千個ほどの異なるポート番号を組み合わせたWinnyノード情報が、コマンド4で隣接ノード情報としてWinnyネットワーク全体に出回っていた。
これらのノードを、過去24時間分の合計として計数したのが、図3の茶色のグラフ(下の線)である。
この茶色の水増し分を、赤のグラフ(上の線)から差し引いたのが、紫のグラフ(上から2番目)*2であり、これが本来の値である。グラフの通り、2009年12月31日24時を境に急激に減少し、その後は通常通りのパターン*3で推移していたことがわかる。
何者かの愉快犯が、このような誤報を誘因するためにノード数を水増ししたのか、それとも、大阪市立大学の正当な研究用のWinnyクローラ*4が、異常な設計になっている*5ために引き起こされた、不慮の社会的混乱事故であるのか、あるいは、大阪市立大学の研究の目的自体が、偽ノードを大量に発生させることによる何らかの実験(たとえば、通常のWinny利用を阻害する目的など)だったのか、まだわからない。
今日は時間がないのでここまで。今週末に詳細を改めて書く予定。
大阪市立大学の関係者からの連絡をお待ちしております。
1月30日の日記に続編を書いた。
*1 過去24時間分の集計値なので、実際に発生源が止まったのは1日前の、20日14時ごろと考えられる。1月22日のTwitter発言1、同2。
*2 グラフ中で、下向きにヒゲのように飛び出ているところが4か所ほど見られるが、これは、横軸のサンプル点が異なるデータ(赤と茶色)に対して、引き算によって算出した値であるため。赤のサンプル点は、クローラが一巡するごと(約15分から25分で変動)であるのに対し、茶色のサンプル点は、1時間毎。茶色のグラフが急激に変化した部分で、時刻が整合していないことが原因で、ヒゲのようになる。これは、全体を集計しなおせば解決するが、数日かかる計算量なので、まだやっていない。
*3 平日に少なく、休日に多く、正月三が日には少なくなる。
*4 大阪市立大学から発表された研究で、Winnyクローラを使用しているとされている論文に次のものがある。ただし、これが今回の件と同じ研究室によるものかは、現時点では不明であることに注意。
*5 たとえば、接続するごとに、(自己申告になっている)自ノードポート番号をなぜかランダムにしているとか。
前回の日記の件、大阪市立大学の研究実施責任者より連絡を頂いた。前回、可能性として、
の3つを挙げたが、(B)であるとのこと。大阪市立大学では、P2Pファイル共有ネットワークにおける検索キーワードの流行が時間的にどう変化するかを統計的に分析する研究を進めていて、統計的推定のためには、データの収集頻度を増やす必要があるということで、クローラをマルチスレッド化する改造を年末に行い、年始より稼働させたとのこと。
今回の結果を招いたことについて、「こういった計測活動は慎重にせざるを得ないにもかかわらず、きちんとケアできていなかったのは指導教員である私のミスであり、その結果、高木さまをはじめ多くの方々をお騒がせしてしまったことは大変申し訳なく思っております。」「今回の状況を真摯に受け止め、今後は社会的影響についても慎重に考えながら研究を進めて参りたいと思います。」とのことだった。
クローラの稼働によって大量の架空ノードが発生したのは、そのクローラが、自ノードポート番号(待ち受け接続用に接続相手に申告する自ノードのポート番号)を通知するにあたり、接続先ごとに別々の番号を用いたためであるが、先方の説明によると、「ポート番号をスレッドごとに別々にする必要があり、スレッドごとにポート番号を変化させた」とのことだった。
これらのことは、前回の日記の図3のグラフから推察できることだった。というのは、大阪市立大学のIPアドレスのノードは、ずっと以前から数千個程度で推移していたからだ。こちらの記録がある限りの期間でそれを示すと、以下の図1のようになる。2009年11月までは、全体のノード数としては無視できる程度のものであったのが、12月の改造以降で影響を及ぼすほどになったことがわかる。
しかし、本来、ポート番号を別々にすることは不必要で、1つのポート番号を用いて目的を達成できるはずである*2。おそらく、研究を実施する学生さんが実験用プログラムを開発する初期の段階で、ポート番号を変える必要があると思い込んでしまったのだろう。先方には、ポート番号を固定にしたクローラの作り方を説明して、今後も研究を継続なさるよう、伝えておこうと思う。
以前から一部の関係者の方々にはお話ししていたが、やはり、「Winny等観測者連絡会」のような枠組みが必要だなと思う。これは勤務先の仕事として関係者の方々に声をかけようと思っているところ。
ところで、今回は不慮の事故であったが、今回の副産物として、従来できなかった実験(やりたくても「人体実験」的であるためにできなかった)に近いことが行われたことになる。つまり、冒頭で示した可能性(C)の実験である。
図1のグラフの集計の際に気づいたが、当該ノードが8万個を超えるようになったとき、ノードの数だけでなく、コマンド4で流れてくる隣接ノード情報のうちに当該ノードが占める割合が、かなりの割合を占めている様子だった。
これを、取り急ぎざっくりと簡便な方法で集計してみたところ、図2のようになった。
橙色のグラフ(下の線)(右軸目盛り)が示すように、Winnyノード間でやりとりされる隣接ノード情報のうち、架空ノードが占める割合が、2割にも達するという事態が生じていた。これによって、通常のWinnyがつながりにくくなっていたことが考えられる。どの程度つながりにくくなっていたかは、記録から何らかの方法で計算できるかもしれない。
中央大学の観測では、観測用クローラの「接続できなかったWinnyノードの比率」が、1月6日から上昇したとの報告が出ている。
また、接続できなかったWinnyノードの比率が上がった。このこともダウンロード違法化による影響か、あるいは巷に言われるダミーキーの放流にともなうダミーノードが増加したことに起因するのではないだろうか。
年末年始のP2P, cNotes: Current Status Notes, 中央大学大学院 理工学研究科 土居研究室, 2010年1月27日
これは、上記の件の影響ではないだろうか*3*4。青のグラフ(上の線)の形状が図2と符合している。16日以降にはもっと上昇していたのではないか。
副産物はもうひとつある。以前から気になっていたように、隣接ノード情報は、消滅した過去のノードがかなり長期間に渡って残留して現れるのではないか、そして、それが(隣接ノード情報を含めた)ノード数観測に影響を及ぼしているのではないかという疑問点があった。今回の事態によって、その影響の推定ができるかもしれない。
図3は、大阪市立大学の今回のクローラが隣接ノード情報に残した架空ノード数の、クローラ稼働終了以降(終了から1日半経過後(の24時間経過後)以降)を拡大したものである。
1月20日14時ごろに稼働が終了し、1日半が経過した後も、このように、これらの架空ノードが隣接ノード情報に現れている。これは、Winny利用者に、ときどき断続的にWinnyを起動する人たちがいて、その人たちが、大阪市立大学のクローラから接続を受けている最中に一旦Winnyを停止し、何日かぶりにWinnyを起動したときに、消滅しているはずの大阪市立大学の架空ノードを隣接ノード情報として周囲に撒いたものと考えられる。
図3の結果から、概ね、1日半経過後で約1%の確率で残存ノードとなること、2日半後で約0.5%となることなどが読み取れられる。これを元に計算すれば、全体のノード数への影響を算出できるかもしれない。
中央大学の観測の続報によると、やはり、接続できなかったWinnyノードの比率はさらに上昇していたとのこと。
*1 4月26日以前は旧観測システムによるもの。現在の観測システムに比べて観測密度が低いため、十分な数を捕捉できていない可能性がある点に注意。
*2 Winnyクローラを実現するには、通常、待ち受け接続を必要としない。クローラ側から接続したソケットがあれば、接続先のWinnyノードはこちら向きにコマンドを送ってくる。非Port0接続で接続した場合に相手方から「BadPort0」確認用の接続が折り返し接続されてくるが、これを処理する必要があるならば、接続を受けてすぐに切断すればよく、そのとき待ち受け用のポートは1つでよい。また、仮に何らかの理由で待ち受け接続が必要だとしても、ポート番号は1つでよいはずで、ノードの区別のためには接続元のIPアドレスを用いればよいはず。
*3 架空ノードの占有率に対して「接続できなかったWinnyノードの比率」の上昇がさほど多くはないのは、接続できない率が元々70%あるから。
*4 私のクローラ(2009年5月以降の新型)では、接続先として、キーに書かれたノードアドレスだけを使用して、隣接ノード情報は無視しているため、接続失敗率に今回の影響が及んでいないので、残念ながら同様のデータが私のところにはない。