高木浩光＠自宅の日記

■ やはり「元データは保管していない」は虚偽だった

今日の朝日新聞朝刊「b4」面に、Google Earthについて米Google, Inc.担当副社長がインタビューに答えた記事が出ているが、この中で、日本のストリートビューについての質問にも応じて、次のように答えている。

ストリートビューについても尋ねた。（略）日本では昨夏始まり、塀越しに自宅が撮影されるなどプライバシーを中心に問題になった。

「道幅の狭さ、塀の中の庭、街のつくりなど、日米の違いをよく認識していなかった。例えば米国の家に表札はない。日本の事情に合わせ、変えるべき点は変えていく」

人の顔にぼかしを入れ、ユーザーから削除を申請された写真は表示されない。こうした写真の元データをグーグルはどうしているのか。

「保存しています。地図の間違いやぼかし技術の点検のためで、一定期間後に消去することになるでしょう。問題のないものは原則として残します。何十年か後、ストリートビューの写真は貴重な歴史的資料になるはず。プライバシーと将来の価値のバランスを考えていきたい」

グーグルアースの未来, 朝日新聞2009年8月1日朝刊b4面

「削除を申請された写真」も「保存しています」とのことだ。

6月21日の日記で「グーグル社の東京都への回答「元データは保管していない」は虚偽か」と書いたが、やはりグーグル株式会社の発言は虚偽だった。 東京都情報公開・個人情報保護審議会に対して、グーグル株式会社は発言内容の訂正を伝えているのだろうか。発言した日本のグーグル社が訂正を発表しないで、米Googleの幹部に言わせておけば済まされる話なのだろうか。

元データ保管の有無がどういう意味を持つかについては、日本の個人情報保護法に関係するらしい。私は詳しくないのでいまひとつよくわかっていないが、顔の映った写真は個人情報保護法の「個人情報」に該当するらしい。総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会 第一次提言（案）」（以下「提言案」）にも次の記述がある。*1

個人の容貌が写り込んでいる場合には特定の個人を識別可能といえるが、顔の部分にぼかしをかける等の措置を講じた上で公開している限り、「個人情報」には該当しないと考えられる¹²。ただし、道路周辺映像サービス提供者が、ぼかしをかける等の措置を講じる前の画像を保存している場合には、そちらについては個人識別性があるため「個人情報」に該当すると考えられる。

利用者視点を踏まえたICTサービスに係る諸問題に関する研究会 第一次提言（案）, 総務省

ただ、提言案によると、写真が個人情報に該当するのだとしても、ストリートビュー等は「特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの」とは「言い難い」のだそうで、そうすると、それらの写真は（「個人情報」には該当しても）「個人情報データベース等」を構成する「個人データ」には該当しないのだそうで、ストリートビュー運営者は「個人情報取扱事業者」とはならず、個人情報保護法の義務規定の適用対象とならないのだそうだ。

そうなんだろうか。提言案に対するバブリックコメントとして提出された、武藤糾明弁護士ら（日弁連情報問題対策委員会委員9名の弁護士有志）による意見書では、次のように主張されている。

2 検討内容が妥当性を欠く点について

(2) 個人情報保護法との関係について

ア 「個人情報」該当性について

（略）ところが、提言案においては、冒頭において「道路周辺映像サービスにおいて公開されているものは、」という言葉から唐突に検討が始まっており、公開される前の、画像の収集過程の検討がすっぽりと欠落している。

公開の過程で顔をぼかすとしても、収集の過程においては、解像度の高いレンズで識別可能な顔の情報を収集しているのである。この場合、後で利用の場面においてぼかしを入れるからと言って、最初の収集の場面においてさかのぼって個人情報でなかったことになるはずがない。

そもそも個人情報の収集過程が適正かどうか（個人情報保護法１７条）の検討がなされるべきであるのに、これを無視するのは明らかに相当性を欠く。（略）

イ 「個人情報データベース等」該当性について

提言案は、これを否定しているが、相当ではない。

たとえば、住所について、○○丁目○○番○○号まで入力して検索をし、特定の個人の居宅を検索することが容易になされるサービスが存在する。

このような場合、特定の個人情報である、居宅情報が検索されうるのであるから、「個人情報データベース等」に該当すると言うべきである。

総務省へのパブリック・コメント, 弁護士武藤糾明の日記, 2009年7月28日

たしかに、ストリートビュー（Googleマップ）の機能自身が、住所による検索機能を持っているのであるから、ストリートビューは「住所を入力することでその場に居たことのある人の写真を検索できるサービス」であるわけだが、そのことによって、「特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの」となるのかどうか。

公開されているサービスは顔がぼかし処理されているので（いれば）個人データを扱っていないことになるのだろうが、グーグル社内には、「住所で検索すれば（その場に居たことのある人の）生写真を閲覧できるデータベース」が存在するのだろうから、そちらは「特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの」に違いない*2と思うのだが、どうだろうか。*3

冒頭の朝日新聞のインタビューで、写真について「問題のないものは原則として残します」とのことだったが、たとえば、顔にぼかし処理の施された写真の例として、次の写真があるが、こうしたものも残されるのだろうか。

上の例は、Pathtraqの「2008年11月1日の人気ページ」に掲載されていたのを見つけたものである。おそらく、２ちゃんねる掲示板等で話題になって注目を集めていたのだろう。この事例で、写真の顔の部分に、自動処理とは別の手作業によるぼかし処理が施されていることがわかる。グーグルの人の手を経ても、この写真は「問題のないもの」として「歴史的資料」とされるのであろうか。

ところで、武藤糾明弁護士ら（日弁連情報問題対策委員会委員9名の弁護士有志）による意見書は、「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」の「インターネット地図情報サービスWG」について、次のように批判している。

3 提言を公表するための手続きにおいて、「サービス提供者」及び「利用者」という推進側の意見に偏し、「利用される名もない多くの市民」の意見を聞かないのは偏っていて、公正中立性に反している。

（略）

3 利用される市民の意見が聞かれていないことについて

（略）そもそも、この提言案をまとめたとされる「インターネット地図情報サービスWG」には、地方議会等から批判の的となっている当該サービスを実施している主体であるグーグル株式会社の担当者や、同種サービスを提供している電気通信事業者等が参加している。

仮に、総務省がこれらのサービスに含まれる問題点を指摘する多数の地方議会等の意見に耳を傾け、慎重にこれを検討しようとするのであれば、そもそも当事者をメンバーに加えられるはずがない。このような行為は、問題点の検討を行うに際しての公正中立性に反していることは明らかである。当事者の判断を持って、当事者の行為の適否を決する見解を総務省が対外的に公表することは、行政の公正中立性に反し違法の疑いがある。

このWGで、批判的な見解のものの意見を聴取したり、慎重に検討していないことは明らかであり、少なくともそのように疑われる手続きで結論が出されるべきではない。

総務省へのパブリック・コメント, 弁護士武藤糾明の日記, 2009年7月28日

市民不在との指摘だが、いちおうこのWGには、MIAU（インターネットユーザー協会）の中川譲理事が構成員として参加している。ただ、MIAUがこの問題にどのような立場で臨んだかが公式に発表されていないので、「批判的な見解の者の意見を聴取した」ことになっているのかどうか不明である。ちなみに、その中川譲氏は、先日、自身のTwitterで次のように述べていた。

「テクノフォビア」（テクノロジー恐怖症）とは、技術を怖がったり嫌悪する人のことを指す言葉で、パソコン音痴のことを言うのだろうが、そういう問題なのだろうか。「技術を知れ」とのことだが、中川氏は技術者ではないよね。

非公開のWGだったから何も話せないとのことだが、WGは終わって、第一次提言案が公開され、パブリックコメントにかけられたのだから、（WGでの内容はともかく）MIAUとしてこの問題にどのような立場で取り組んでいるのかは、表明できるはずではないだろうか。

MIAUが衆院選の候補者に情報通信政策に関するスタンスを尋ねるアンケートを作ったとのことで話題になっていた。私も、それの様式を真似て、MIAUに次の質問をしてみたい。

8. 日本のグーグルのストリートビューにはプライバシー上の問題があるとする意見がありますが、一方で技術の発展を阻害してはならないとの意見もあります。プライバシー侵害のリスクと技術発展の自由とのバランスは、どのようにあるべきとお考えですか。

(1) 技術発展の阻害要因よりも、プライバシー侵害のリスクのほうが重要である。

(2) プライバシー侵害のリスクには疑問があり、技術発展を阻害する要因を増大させるべきではない。

もちろん、こんなふうに二者択一で答えてよいような部類の問題ではない。

追記（2日）

脚注にいくつか書き足した。

■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合

一年前、「退化してゆく日本のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。

iPhoneに契約者固有ID送信機能が搭載される日

（略）こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。

（略）iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 （略）契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなければいいのだが……。

無責任なキャリア様に群がるIDクレクレ乞食 —— 退化してゆく日本のWeb開発者, 2008年7月27日の日記

また、10月の越後湯沢での講演で次のスライドを示した。

そして、今年の4月末のこと。「iPhoneにまで進出してくる」との危惧が、現実になっていた。

ニコニコ動画のiPhone OS用アプリが登場したというので、さっそく入手し、アカウント設定の画面に進もうとしたところ、次の画面が現れた。

「端末情報を取得します。よろしいですか？」という。iPod touchなのに？

そこで、ニコニコ動画のサポート窓口に次の質問をした。

すると、すぐに回答があり、

「iPhone版ニコニコ動画」は端末情報（端末製造番号）によってログイン時(毎回)に会員状態を識別しております。そのため、登録時や動画視聴時は端末情報を送信した上でお手続を進めてください。

とのことだった。そこで、続けて、「私は iPod touch 使用しています。iPod touch は携帯電話ではありませんが、「端末製造番号」なるものが、iPod touch にもあるのでしょうか？」と質問したところ、迅速に回答があり、

はい、iPod touchにも端末製造番号が存在しており、ログインアカウントに紐付ける形でユーザーを識別しております。

とのことだった。この間に自力で調べた（自分の無線LAN経由での通信内容を傍受して調べた）ところ、送信しているのは、iPhone OSに搭載されている「UDID」という文字列だとわかった。そこで、「これを送信することは、貴社のプライバシーポリシーに違反しているのではないでしょうか？」と尋ねたところ、すぐに回答があり、

端末製造番号については、その端末を識別する為の番号ですので、仮にお客様がその端末を第三者に譲渡した場合なども、端末製造番号を以って持主を特定することはできないものと存じております。

従いまして、現状のご利用方法が弊社のプライバシーポリシーに反したものであるという認識はございません。

という。ならばなぜ「端末情報を取得します。よろしいですか？」とわざわざ確認するのだろうか。問題があると認識しているからこそ確認を出しているはずなのに、問題はないのだという。携帯電話がそういう流儀になっているので、なんとなく真似て出しているだけなのだろうか。

まあ、その件はいい。それよりも、携帯電話でもないのに「UDID」を使っているということは、セキュリティ上の脆弱性があると推定される。なぜなら、無線LAN経由でも使うのだから、携帯電話のように「IPアドレス帯域」でアクセス元を限定して対処することは不可能だからだ。

自分の通信内容を無線LAN電波を傍受して調べたところ、図3のように、一部でHTTPSが使われていたが、その他はHTTPで通信していた。ニコニコ動画のiPhone OSアプリは、図1の図のように、ニコニコ動画のユーザIDとパスワードを登録して使うようになっているので、このパスワード送信の際にHTTPSが使われているのだろう。

最初のHTTPの通信内容は図4のようになっていた。

「udid=」と「ticket=」という2つのパラメタが渡されている。ticketの値は、ニコニコ動画の会員番号とランダムっぽい値の連結になっており、後者は、おそらく、HTTPSでパスワードを送信して認証成功した際に返されてきた、認証が成功したことを伝える一時的な値であろう。それと共に「UDID」が送信されている。

このHTTPリクエストで、サーバ側でこの「UDID」がニコニコ動画のアカウントと結びつけられるものと考えられる。このときのHTTPレスポンスには、メールアドレスやニックネーム、ニコニコ動画の会員番号等が含まれていて、これらはプライバシー情報にあたるが、このレスポンスはticketがないと得られないものになっているだろう。

しかし、「マイリスト」機能にアクセスしたときは、図5の通信内容となった。

このHTTPリクエストでは、「UDID」だけを送っている。つまり、UDIDだけでログイン状態を維持していることが推定される。HTTPレスポンスには、私の非公開設定の「マイリスト」の内容が含まれている。

これはまずい。では、「UDID」というのは、どのくらい他人に知られ得る値なのだろうか。

日本のケータイWebの場合、契約者固有IDはすべてのWebサイトに送信されるので、誰でも知り得る値であるが、iPhone OSの場合はそうではない。Safariがそのような値を送信するようになっているはずもない。

「UDID」がどのようなものか調べてみたところ、iPhone OSアプリ開発者らの間で広く使われているものだった。「UDID」は通常は目にすることがないが、iTunesの図6の画面で、シリアルナンバーの部分をクリックすると「UDID」が表示されるようになっている。

これがどんな目的で使用されているかというと、ひとつには、開発中のアプリのベータテスト用で、AppleのApp Storeに登録される前の開発中のアプリを、ベータテスト目的で誰かに試用させる際に、試用者に「UDID」を提出させて、特定の「UDID」の機器だけで動作するように限定してベータ版を提供するということが行われているようだ。

• AppStoreに頼らないもう1つのiPhoneアプリ配布法, ZDNet Japan, 2008年9月9日

つまり、「UDID」は他人に知られる場合があることを想定したものである。したがって、「UDID」の送信だけで「マイリスト」を閲覧できてしまうのは、他人にも閲覧できるということであり、「マイリスト」には非公開設定もあるので、これは、ニコニコ動画の脆弱性（Webサイト側のセッション管理上の脆弱性）である。

ただし、上の図4のように、アプリを起動する毎にパスワードによる認証があるので、一定期間だけ「UDID」だけでアクセス可能にするという制御が行われている可能性はある。そこで、翌日まで放置（ニコニコ動画アプリを使わないで）した後に、telnetで直接（自分の）「UDID」を指定してアクセスしてみたところ、「マイリスト」を取得できることが確認できた（図7）。

以上のようにして、実際的な問題のある脆弱性であることがわかったので、「ニコニコ動画お客様サポート」に対し、以下のように脆弱性の報告をした。*1

株式会社ニワンゴ 情報セキュリティ対応係 御中

ニコニコ動画のiPhone OS向けサービスのセキュリティ脆弱性について

iPhone OS向けの「ニコニコ動画」アプリを利用しておりましたところ、その実装手段に技術的な誤りがあり、他人に非公開マイリストを閲覧されてしまうなどの被害の生じ得る、セキュリティ脆弱性があることに気付きましたので、以下の通りお知らせします。

1. ニコニコ動画アプリの挙動

iPhone OS向けの「ニコニコ動画」アプリを、無線LAN経由のインターネット接続で使用し、その際の通信内容を自分で傍受して調べたところ、iPhone OSの「UDID」が送信されていることに気付きました。

「ニコニコ動画」アプリの「アカウント設定」でメールアドレスとパスワードを設定した状態で、たとえば、「マイリスト」のひとつを閲覧しようとすると、i.nicovideo.jp:80 に対し、以下のHTTPリクエストが送信されるようです。

GET /v1/mylistgroup.get?udid=88d0e4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&detail=1 HTTP/1.1
User-Agent: iPod touch
Accept: */*
Accept-Language: ja-jp
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: i.nicovideo.jp

ここで、「udid=」の右の40字の文字列は、私のiPod touchのUDIDです。このHTTPリクエストは、任意のIPアドレスから送信しても受け入れられるようで、携帯電話会社のゲートウェイ等にアクセス元を限定しているわけではないようです。そのため、iPhoneまたはiPod touchを用いずに、通常のパソコン等から上記のHTTPリクエストを送信した場合にも、レスポンスは通常通りに得られ、XML形式で記述された私のマイリストの内容が返信されてくることを確認しました。

2. セキュリティ上の問題点

上記の挙動から、HTTPリクエスト上のいずれのパラメータにも秘密情報が含まれておらず、UDIDだけでユーザ固有の情報にアクセスできることがわかります。このことから、誰かのiPhoneまたはiPod touchのUDIDを知ることができれば、誰でもその人に成り済ましてアクセスできるはずであると推察されます。

iPhone OSにおいてUDIDは秘密情報ではありません。UDIDは、たとえば、iPhone OS用アプリの開発者が、ベータテストのためにテスターを募集する際に、テスターに提出を求める情報として使われており、開発者は他人のUDIDを知る立場にあります。また、他のWebサイトがUDIDを使うようになると、あちこちのWebサイトが人々のUDIDを保有することになります。UDIDは、ユーザIDの代替になることはあっても、パスワードの代替になるものではありません。

Apple Inc. の、Developer Connection の文書「iPhone Reference Library」にも、UDIDについて次のように記載されており、ユーザ認証の目的で使用できないものであることが暗に示唆されています。

http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIDevice_Class/Reference/UIDevice.html

uniqueIdentifier
Discussion
A unique device identifier is a hash value composed from various hardware identifiers such as the device’s serial number. It is guaranteed to be unique for every device but cannot publically be tied to a user account. You can use it, for example, to store high scores for a game in a central server or to control access to registered products. The unique device identifier is sometimes referred to by its abbreviation UDID.

3. 生じ得る被害

私が調べた範囲では、非公開のマイリストが他人に閲覧される点を確認しました。他にも、他人に成り済ましてコメントを書き込まれる可能性、非会員に動画を閲覧される可能性、プレミアム会員に成り済まして利用される危険性などが考えられますが、確認はしていません。

4. 正しい実装方法

現在の「ニコニコ動画」アプリは、「アカウント設定」でメールアドレスとパスワードを設定して使うように設計されており、アプリを起動した際にメールアドレスとパスワードを送信して、アカウントの有効性確認の認証処理を行うよう作られているようですから、本来、UDIDを使う必然性は全くないはずです。

正しい実装方法は、ログイン毎に異なるセッションIDを用いることです。メールアドレスとパスワードでログイン認証した時点で、サーバ側でセッションID（暗号用乱数を用いた十分な長さの予測困難な文字列）を生成して「ニコニコ動画」アプリに渡し、アプリ側はそれをメモリ上に記憶して、アクセス毎にHTTPリクエストに載せて送信するようにすれば、サーバ側で、そのセッションIDを用いたセッション管理を実装できるはずです。

アプリとサーバ間のセッションIDの受け渡しには、HTTPレスポンスのSet-Cookie:ヘッダと、HTTPリクエストのCookie:ヘッダを用いることもできるでしょうから、そうすることで、PHPの既存のセッション管理機構をそのまま使うこともできるのではないかと思います。

5. プライバシーの保護

UDIDはプライバシーに関わる情報であるとも言えます。もし、多くのWebサイトがUDIDを用いるようになれば、UDIDによって、誰が利用しているのかが他のWebサイト運営者にわかってしまう事態が生じます。

ニコニコ動画のiPhone OS向けサービスが上記の通り正しい実装に修正され、ニコニコ動画の運営上UDIDが不必要なものとなれば、これまでに収集されたUDID情報は廃棄されることが望ましいと思います。

以上

そして、7月13日に「ニコニコ動画 for iPhone Ver 1.05」がリリースされ、7月31日をもって旧バージョンの使用が停止となり、この脆弱性は解消された。図8のように、旧バージョンでは動作しないことが告知されている。*2

修正された現在では、「UDID」は送信されなくなり、図4のところでセッションIDが発行されるようになり（図9の「<session_id>」）、図5のところではそのセッションIDが送信されるようになった（図10の「sid=」）。

また、図7と同じことをしても図11のようにエラーとなり（何やらエラーメッセージが見えているが）、脆弱性は解消された。

というわけで、この事例のように、日本のケータイWeb開発者が、普通のWebアプリケーションの構築技法からかけ離れて、蛸壺化していることがうかがえる。

類似の話として、徳丸浩氏の7月14日の日記では、ケータイWeb開発は入門書籍からして蛸壺化しつつあり、その弊害としてCSRF対策もままならなくなっていることが指摘されている。

日本の携帯電話事業者の一部は、「フルブラウザ」にさえ契約者固有ID送信機能を持たせて、蛸壺の維持を謀ろうとしているが、iPhoneのような国際的デファクト標準には通用しないのであって、今後も、他のスマートフォンの普及とともに、蛸壺的手法は通用しなくなっていくであろう。

そのときに、蛸壺の中の開発者らが、このニコニコ動画の事例と同様のミスをする可能性が高い。「IPアドレス帯域」による制限が通用しない機器では、アプリケーションの内容によっては特に危険な脆弱性となるので、関係者はこのことに注意が必要である。

なお、1年前に軽く触れたNAVITIMEのiPhone OS用アプリの件はどういうものだったかというと、NAVITIMEでは「会員登録」時に、図12のように、「http://www.navitime.jp/smartphone/EntryFacade_uid_XXXXXX……」というURLで、何やら固有IDを送信するようになっていた。おそらく、「UDID」を暗号化した（あるいは一方向性関数に通した）もの*3だったのだろう。

NAVITIMEでは、ニコニコ動画と違って、ユーザ名とパスワードの登録機能を持っていなかった。そのため、最初に「会員登録」をするときに、固有IDをSafari経由で送信して、そこで決済用のクレジットカード番号の入力をさせることで、この固有IDに直接クレジットカード番号を紐付ける構成になっていたと思われる。そして、NAVITIMEアプリが有料サービスを実行するときは、この固有IDだけで認証状態を維持していたものと推察する。

このような構造の場合、脆弱性を指摘されてもすぐには直せない。なぜなら、新たにユーザ名とパスワードの機能を用意して、既存のユーザに再登録を促さない限りどうともならないからだ。

NAVITIMEは元々、日本のケータイWebが発祥なので、ケータイ同様に作ればユーザIDとパスワードがなくても認証できると勘違いしてしまったのだろう。蛸壺方式をそのままiPhoneに適用しようとして破綻したのではないか。*4

このことからも、ケータイWebで蛸壺化することのリスクが大きいとわかる。はじめから普通のインターネットでも使うことを想定してサービスを設計しないと、こういう事態になる。

2007年の「モバイルビジネス研究会」が、「ユーザーIDの利活用の推進」としてユーザIDの統一化を謀っていたこと（「日本のインターネットが終了する日」参照）は、このような意味でも日本を駄目にする方向性だったと言える。幸い、2008年の「通信プラットフォーム研究会」では、関係者のご尽力により、この種の問題を指摘する声があがり、SAMLやOpenID（おそらくはOAuthも）を使用することが検討される方向性になった（「通信プラットフォーム研究会 傍聴録」参照）。

ニコニコ動画の事例が解決できたように、「ケータイの契約者固有IDがないと便利なサービスを実現できない」などということはないのであって、特に、Webブラウザではなく個別のアプリでサービスするときには、ニコニコ動画のようにユーザIDとパスワードを設定しておく構造にすればよいわけであるし、初回利用時にユーザIDとパスワードを作成することがケータイユーザにとって煩わしいのが問題であるのなら、SAMLないしOpenIDを活用すればよい*5と考えられるし、Webブラウザの場合であっても同様のはずだ。

■ MIAUについての所感

前々回の日記でMIAUの中川理事のTwitter発言に触れて以来、MIAUについて、はてなブックマークで小さなコメントを書いていたところ、MIAU側で反応があり、MIAUからの公式発表とインタビュー記事が出た。

• 「インターネット地図情報サービスWG」第一次提言（案）作成協力のご報告, MIAU, 2009年8月3日
• インターネット・ユーザーの声を政策の争点にしたい - インタビュー, 日経ITPro, 2009年8月7日

これをベースに、MIAUについての感想を書いてみる。

日経ITProのインタビュー記事の冒頭と終盤で津田大介代表理事が述べているように、審議会が市民参加に配慮しようにも「代表がいないから呼べない」という問題が存在していて、それに応じられる団体としてのMIAUの役割は重要であり、特に、ある時期の著作権関連の審議会において大きな役割を果たしたことには疑いの余地がないと思う。ただ、その後のMIAUの活動を見るにつけ、いくつか疑問を抱くようになった。

一つは、いわゆる「ダウンロード違法化」に反対する活動について。

違法化の検討が始まった当初から懸念された問題点に対し、早い段階から、罰則なし、「情を知って」の要件*1、ストリーミングは対象外とする方針が囁かれる中、MIAUは、徹底抗戦の構えで「ダウンロード違法化」に完全反対の立場をとった。反対にあたってどんな理由を挙げていたかは、MIAUの「ダウンロード違法化に反対するパブコメ素材」で確認できる。無理矢理作り出された理屈も含まれているように見えるかもしれないが、こうしたMIAUの勢力が存在したことも功を奏したのか、最終的に成立した改正法は当初からの懸念に対して手当てされたものになったように思う。

しかし、それでもMIAUは、改正法が成立した後になってからも、「“ダウンロード違法化”等を含む改正著作権法案の可決・成立を受けて」と題して、「なんら具体的な修正は行われぬまま法案が提出され、可決・成立したことに対し、強い遺憾の意を表明致します」と非難した。

MIAUでは設立当初より、ダウンロード違法化がはらむ問題点を訴えるとともに、パブリックコメントの提出や関係者への働きかけ、委員会等での提案等を行って来ました。結果的には「罰則規定なし」「“情を知って”という条件の追加」「ストリーミングは対象外」というところまで引き下げられたものの、約６０００通ものパブリックコメントで指摘された問題点のほとんどに対して、なんら具体的な修正は行われぬまま法案が提出され、可決・成立したことに対し、強い遺憾の意を表明致します。

（略）しかし、今回の法案可決・成立によって、この問題がすべて決着した訳ではありません。ダウンロード違法化が成立したことによる弊害や、インターネットの健全な成長に及ぼす悪影響については、今後も訴え続けていきますし、法案の修正・見直しも視野にいれた活動に取り組んでいかなければならないと考えております。

“ダウンロード違法化”等を含む改正著作権法案の可決・成立を受けて, MIAU, 中川譲, 2009年6月17日

このあたりからよくわからなくなった。「ダウンロード違法化が成立したことによる弊害」というのは具体的に何なのか。それを示して非難すればよいのに、そうした具体性がない。具体的な問題があるのなら、法案が成立する前の段階で、提出法案に対する法文上の問題点の指摘をしたらよいのに、そうした指摘をMIAUがしたという話は聞こえてこない。昨年10月の時点で書かれた津田大介氏による記事「「ダウンロード違法化」ほぼ決定　その背景と問題点」でも、（その標題とは裏腹に）問題点の指摘はされていない。

MIAUの「ダウンロード違法化反対」はそもそも何のための反対なのか。その理念が見えない。たとえば、欧州議会で1議席確保したという「海賊党（Pirate Party）」と比べてみると、彼らは、「文化の共有、知識の無料／自由化、適切なプライバシー」という理念を掲げ、「著作権の適用範囲を縮小し、商用のみ（略）著作権で保護されるべき」といった具体的な方針（その是非はともかく）を明確にしている（CNET Japanによるインタビュー記事）。一方、MIAUの津田代表理事はというと、先週のインタビュー記事で、「アップロードの摘発をもっと効率的に行うべきだ」という考えを示した。

反対のための団体にはなりたくない

MIAUは反対のための団体と思われているふしがあるのですが，僕らは絶対にそうはなりたくないと思っています。「反対するなら対案を示せ」とよく言われますが，僕らはそれなりに対案を出し，対案を議論する場で実際に示しているつもりです。

（略）違法ダウンロード問題の際にも，僕が出ていた審議会では「アップロードの摘発をもっと効率的に行うべきだ」という対案を出したつもりです。実際に現場を取材すると，ネックになっているのはプロバイダ責任法の情報開示手続きの煩雑さにあることが多く，それらを改善する方が実効性がありますから。

僕らもネット上の違法コンテンツは減らしたいと思っています。しかし，ダウンロード違法化は効果も薄く，悪影響も考えられる。もっと効果のある方法をとりましょうと伝えたかった。

インターネット・ユーザーの声を政策の争点にしたい - インタビュー, 日経ITPro, 2009年8月7日

「ネット上の違法コンテンツは減らしたい」という方針をとるのなら、Winny等*2で大量に流通している著作権侵害ファイルについて、MIAUはどのような立場なのか。Winny等を利用する行為について、MIAUが考え方を示したという話は聞かない。*3 *4

Winny等はその仕組み上、ダウンロードすると同時にアップロードする（送信可能な状態におかれる）ようになっており、そのことをよく知らない大量のネット中級者が無差別にファイルを溜め込んで送信可能な状態においていることが、違法コンテンツ流通蔓延の原因になっている。ネット上級者であるMIAUの人達ならよく知っていることだろう。

アップロードを自覚しないWinny利用者らは摘発できない（故意が認められない）のだから、津田代表理事が言うように「アップロードの摘発をもっと効率的に行うべき」であるなら、Winny等の利用者に向けて、「あなたがやっていることはアップロードですよ」という注意喚起をしたらいいのに、MIAUはそういうことをやらないのだろうか。MIAUは、インターネットリテラシ読本作成のプロジェクトも活動の柱の一つとしているのだから、そうした啓発活動をするのも本来、自然なはずではないか。*5 *6

同様の違和感は、児童ポルノ単純所持処罰化に反対する活動においても感じた。

規制推進派が創作物まで規制しようとしてくる中で、それに反対する勢力としてMIAUが存在することの意義はわかる。また、Webのブロッキングという乱暴な手法の導入に対し、批判勢力が必要であることもわかる。7月10日に発表された「児童ポルノ禁止法改正案緊急声明についての解説」はよく書かれていると思ったが、「3.冤罪の可能性がある処罰の新設ではなく確実な法執行で児童を守ること」の内容に違和感を覚えた。

MIAUは、「児童ポルノによる児童の被害は、拡散のみならず所持が続くかぎり継続するという考え方を必ずしも否定するものではありませんが」と、それを被害として認めている。それなのに、所持を違法化しないで「製造・頒布・提供の摘発をより効率的かつ着実に行うことができる法執行体制を整備」せよと主張する。

7月12日の日記に書いたように、Winnyネットワークには大量の真性児童ポルノ（15歳以下のハードコア物等）が流通しており、「児童ポルノによる児童の被害」が無視できない状態にあることは、上級者であるMIAUの人達ならよく知っていることだろう。また、7月18日の日記にに書いたように、それらを摘発することは日本の法実務上、困難になっており、その困難性の原因はWinny等の機能的特殊性にある。このことも、MIAUの人達ならよく知っているはずだ。

それなのに、「提供の摘発を効率的かつ着実に行え」という。どうやって？

こうしたMIAUの立場を見ていると、２ちゃんねる掲示板の「ダウンロードソフト板」の住人たちと重なって見えてしまう。つまり、「マヌケな『情弱』*7どもが違法にアップロードしてくれているおかげで俺たちは安全にダウンロードだけ享受できる*8この状態をいつまでも続けたい。そういった「情報強者」の立場と区別がつかない。

そうでないとすれば、Winny等の利用者達に向けて、違法な利用をしないための啓発活動があってしかるべきであるし、ダウンロード違法化や児童ポルノ取得・所持違法化に反対する理屈を立てるときにも、Winny等における実態にちゃんと触れて、それを踏まえた対案を打ち出してしかるべきではないか。（あるいは逆に、「海賊党」のような理念を打ち出すとか、児童ポルノによる児童の被害を否定するというのなら、話はわかる。）

ぶっちゃけて言うと、MIAUは、それらをわかっていてあえて隠しているように見えてしょうがない。「ネット上の違法コンテンツは減らしたい」というのも、「児童ポルノによる児童の被害は、拡散のみならず所持が続くかぎり継続するという考え方を必ずしも否定するものではありませんが」というのも、心にもないことを言っているように感じられてしょうがない。（そうじゃないというのであれば、今後の活動で見せてくれたらいい。）

次に、ストリートビュー問題について。*9

MIAUは、ストリートビュー問題について検討した総務省のWGに構成員として参加したそうなのだが、その活動内容がようやく明らかにされた。「「インターネット地図情報サービスWG」第一次提言（案）作成協力のご報告」は、MIAUの立場を次のように表明している。

MIAUが総務省から上記WGに招致されたのは、ユーザー側の団体としていち早くこのGSVの問題を公開の場で議論し、諸問題整理の一翼を担えたことを受けてのものと理解しております。

同WGの議論については、総務省から公式な第一次提言（案）が発表されております。これによれば、現状のGSVは、個人情報保護法などに鑑みて適法であるというコンセンサスが取れております。もちろん、例えば東京都の情報公開・個人情報保護審議会におけるグーグル社の発言内容に虚偽があったなどという点については問題があると考えますが、それは「グーグル社はプライバシーという観点から見ておかしい」のではなく、グーグル社のコーポレートガバナンスの問題ではないかと考えます。

GSV問題や今後の「プライバシー」概念の明確化や具体的な政策への反映については、MIAUとは別に、専門的な見地から行動や政策提言ができる団体が必要であると我々は考えています。（略）

「インターネット地図情報サービスWG」第一次提言（案）作成協力のご報告, MIAU, 2009年8月3日

ストリートビュー問題だけならまだしも、それだけでなく、インターネットに係るプライバシー問題全般について、MIAUは取り扱いの対象外なのだそうだ。（たとえば、ちょうど同じ時期に米国のEFFが「日常の便利なシステムがプライバシを脅かす」という趣旨の啓発活動を行ったのと対照的である。）

なぜそこまでプライバシー問題の取り扱いを排除しなければならないのかよくわからないのだが、ストリートビューについて「適法であるというコンセンサスが取れております」という表明はあきらかにおかしい。

総務省の当該研究会 第一次提言（案）の「インターネット地図情報サービスについて」を読むと、「4.我が国において懸念される法的問題」に書かれていることは、次の4点である。

1. 個人情報保護法に照らすと、ストリートビューを運営するグーグル社は、個人情報取扱事業者に該当するとは言い難い。（ぼかし前の写真が保管されているならそれは個人情報に該当し得るが、「特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの」とは言い難いという理由により。）

2. ストリートビューを運営するグーグル社は、総務省の「電気通信事業における個人情報保護に関するガイドライン」における「電気通信事業者」に該当する。したがって、同ガイドラインを遵守することが求められる。ストリートビューに対しては以下が求められる。
   • 個人情報の利用目的をできる限り特定すること（個人情報保護ガイドライン第5条第1項）
   • 利用目的の達成に必要な範囲を超えて個人情報を取り扱わないこと（同第6条第1項）
   • 偽りその他不正の手段により個人情報を取得しないこと（同第7条）
   • 利用目的を本人に通知し、又は公表すること（同第8条第1項）
   • 個人情報保護管理者の設置（同第13条）、プライバシーポリシー（当該電気通信事業者の個人情報の取扱いに関する方針についての宣言）の公表と遵守（同第14条）などが必要
   • 公開することにつき本人の同意を得るか又はオプトアウトの要件（同15条2項）を満たすことが必要

3. プライバシーの関係から、ストリートビューには法的リスクが残る。具体的には以下。
   • 個人の住所とともに当該個人の住居の外観の写真が公表される場合には当該個人の住居の外観の写真はプライバシーとして法的保護の対象になり得ると考えられている。屋内の様子、車両のナンバープレート及び洗濯物その他生活状況を推測できるような私物が写り込んでいる場合にも、内容や写り方によっては、上述の判断基準に照らし、プライバシーとして法的保護の対象となる可能性がある。
   • 人の顔や車両のナンバープレートなどはプライバシーや肖像権との関係で問題を生じやすい情報であり、ぼかしを入れたり、解像度を荒くしたりして判別できなくして公開することが必要。
   • 撮影の態様については、公道からの撮影は不当な態様での撮影とはならないことが多いと考えられる。しかし、私有地にあえて無断で立ち入るなど不当な手段を用いたり、道路交通法等関係法規を遵守しなかったりした場合などには不当な撮影態様とみられる場合があり得る。
   • 我が国の住宅事情にかんがみれば、人の目線を大きく超えるような高さにカメラ位置を設定して撮影すると、結果として塀越しに家屋をのぞき見て撮影しているのと同様となり、やはり不当な撮影態様とみられる可能性があることから、サービスに支障がない限度で、可能な限り人間の目線に近い位置にカメラ位置を設定して撮影するなどの配慮も必要である。
   • 公共の場所にいるという一事によってプライバシーの利益が全く失われると解するのは相当ではなく、もとより当該個人が一切のプライバシーの利益を放棄しているとみなすこともできない。したがって、態様や程度の如何によってはなおプライバシーの利益を侵害するおそれがあると考えられる。
   • プライバシー侵害となるかどうかは、写真の内容や写り方に左右される面が大きく、撮影態様も個別のケースごとに検討する必要があるため、最終的には事例ごとの個別判断とならざるを得ないため、道路周辺映像サービス提供者に一定の法的リスクが残ることは避けられない。

4. 肖像権との関係から、ストリートビューには法的リスクが残る。具体的には以下。
   • 公道上において普通の服装・態度でいる人間の姿を撮影・公開することは受忍限度内として肖像権侵害が否定されることが多いが、常に肖像権侵害が否定されているわけではなく、公共の場における人の姿の撮影・公開につき肖像権侵害が肯定された事例も存在する。
   • ストリートビューでは、目的は地図情報の提供であって人の容貌の公開自体が目的なわけではない。ごく普通の服装で公道上にいる人の姿を撮影したものであって、かつ、容貌が判別できないようにぼかしを入れたり解像度を落として公開したりしている限り、社会的な受忍限度内として肖像権の侵害は否定されると考えられる。
   • ストリートビューでは、風俗店等に出入りする姿、立ち小便をしている姿、職務質問を受ける姿等公道であっても撮影、公開されることを通常許容しないと考えられる写真が入り込むこともあり得るため、肖像権侵害となるかどうかは、プライバシーと同様に最終的には事例ごとの個別判断とならざるを得ず、一定の法的リスクが残る。

この提言案は、「サービスを一律に停止すべき重大な問題があるとまでは言い難い」という結論を出してはいるものの、上記のように、個別の法的リスクは残るので、いろいろと対策をとらないといけないという趣旨になっている。

それを、MIAUは、「個人情報保護法などに鑑みて適法であるというコンセンサスが取れております」と宣言してしまう。

このことについて、はてなブックマークにコメントがいくつか付いたのだが、それに対するMIAUの中川理事のTwitter発言はこうだった。

適法という判断ができたのは個人情報保護法に関してだけである。そもそも、個人情報保護法とプライバシー保護とは別物であり、個人情報保護法に違反しなければプライバシーを保護したことになるわけではない。提言案も、総務省のガイドラインに準拠していると言えるのかという問題を残しているし、プライバシーや肖像権に関して、個別事案毎の問題だからこの種のサービスには法的リスクは残るとしているわけで、「適法です」などという安直な内容ではない。

個別に問題が生じ得るものだからこそ、問題の存在は常に訴えていかないといけない。それなのに、MIAUは、問題自体が存在しないことにしてしまう。*11

たしかに、一部の反対派がストリートビューの中止を求めているわけだから、「サービスを一律に停止すべき重大な問題があるとまでは言い難い」という結論を出したい人達がいるのは理解できる。しかし、だからといって、問題自体が存在しないかのように言う必要性はないわけであって、いったいなぜ、MIAUはそうするのか？

結局のところ、MIAUは、全否定するか、全肯定することしかできないんだなと思った。昭和の野党のようなやり方で、げんなりする。

必要なことは、何を実現したいのかの理念を背景に理想論を展開しつつも、是々非々で落とし所を探し続けていく作業だろう。

ストリートビューの場合でも、その落とし所が「サービスを一律に停止すべき重大な問題があるとまでは言い難い」であるにしても、プライバシーを大切にするという理念と、けして両立し得ないものではないはずなのに、MIAUは、プライバシー全般までも否定してしまった。*12 *13

■ Winnyの利用形態を視覚化してみた

3年前から稼働させているWinnyネットワーク観測システムで、観測したWinnyキーを記録している*1のだが、そのデータから利用者ひとりひとりがどんな行動をしているか、直感的に読み取れるよう視覚化を試みた。

これを行うためには、長期間にわたり同じ人が使っているノードを見つけ出すことが必要で、一般的には、IPアドレスが頻繁に変わってしまうので、単純には追跡できない*2のだが、今年のゴールデンウィークに観測システムを改良して以来、DNSの逆引きを自動化した関係で、固定のIPアドレスで（しかも固有のドメイン名に割り当てられたアドレスで）稼働させているノードが数十個見つかったので、それについて調べてみたところ、長期にわたって稼働し続けているものがいくつかみつかった。

図1は、2006年8月末から2009年4月末までの間に観測されたキーのうち、「〓.〓〓〓〓〓.org」というホストで稼働していたノードがソースとなっていたキー（そのノードがファイルを提供可能ということを表すキー）*3についてプロットしたものである。横軸は時間であり、縦軸は観測された順に0番から番号を振ったファイル番号である。水平に並んだ点の並びは、同じファイルが何度も（そのタイミングで）観測されたことを表している*4。図1のケースでは、この期間に、1万個あまりのファイルのキーが観測されたことを表している。

ここで、直角三角形を成す塊が見て取れる。これは、「キャッシュ」の削除が行われた様子を表していると考えられる。つまり、図中の矢印が削除のタイミングである。

矢印のタイミングで削除がなされても、一部のファイルが再び右側で観測されているケースも散見されるが、これはおそらく、一旦は削除されたが、再び同じファイルをダウンロードしてしまったケース*6を表しているのだろう。

別のノードのケースを図2に示す。（縦軸のスケールは図毎に異なるので注意。）

このケースでは、小さな三角形がいくつか見えることから、比較的早期にキャッシュ消しを行っていたと思われる。しかし、ほとんどの期間で三角形は見えない。ここで、三角形の存在しない連続した線は何を意味するのかだが、これは、（即消ししていた場合も含まれているだろうが、それ以外に）何もダウンロードしていないときに送出されるキーが観測されたものと考えられる。

Winnyでは、何もダウンロードしていないときでも、他のノードから入ってくるキーについて、一定の確率で、ソースIPアドレスを自分のアドレスに書き換え（4%の確率で起きると言われる中継のための書き換え）て他ノードに送信するようになっており、それが観測されているのだと考えられる。そうした、ソース書き換えキーは、ランダムに選ばれたファイルに対して発生するので、図2のように、1回しか現れなかったファイルとして、斜めの連続した線として現れているのだと考えられる。

そこで、そうしたソース書き換えキーを排除してプロットすることを試みた。図3は、図2と同じノードについて、2回以下しか現れなかったキーを除いてプロットしたものである*7。ファイルの個数が3万5千個から、500個に減っている。図2のキーはほとんどが空運転時のキーで、実際にダウンロードした数は500個以下だったと考えられる。

このグラフから、いつごろ多くのダウンロードをしていたかがわかる。2007年の2月から9月にかけてはあまりダウンロードしていなかったらしいことがわかる。それでも、図2では連続した線となっていることから、稼働だけはずっとしていたようだ。

次に、図1のノードについて、同じ処理を施したものを図4に示す。ファイルの個数は、1万個から3千個に減っているが、グラフの形状はほとんど変わっていない。これは、常時まんべんなくダウンロードをしていたということを意味すると思われる。自動ダウンロードをし続けていたのだろう。

次に、別のノード www.〓〓〓〓〓.co.jp（有限会社として登録されたドメイン）の事例を図5に示す。元のプロットと、ソース書き換えキー排除後のプロットを続けて示す。

このケースでは、1年以上キャッシュを消さずに連続稼働させていたが、ダウンロードしない期間もかなりあったと読み取れる。観測開始当初から大量のファイルのキーが一気に出てきていることから、2500個ほどのファイルは、これより以前から集められ、キャッシュに蓄積されて放置されていたものと考えられる。2007年11月中旬に一度、稼働をやめ*8、11月末に再び起動した後、キャッシュをすべて消して、再び何かを500個ほど集めたようである。

他の事例をいくつか示しておく。以下では、ソース書き換えキー排除後のプロットだけを示す。

図6は、一度もキャッシュ削除が行われていない事例である。これだけ思い切りがよいとなると、いわゆる「UP0パッチ」を適用しているのかもしれない*9と考えられるので、今、このノードに転送リンク接続を試みたところ、正常に接続することができ、コマンド32（転送限界切断要求）が返ってこないことから*10、UP0パッチは適用していないようである。大量のファイルの安定供給源となっていると思われる。

図7も、一度もキャッシュ削除が行われていない事例で、今接続してみるとコマンド32（転送限界切断要求）が返ってこないことから、大量のファイルの安定供給源となっていると思われる。ここはコンピュータ関係の（従業員数があまり多くなさそうな）株式会社のドメインで、会社概要にはISO27001取得とある。大丈夫だろうか。

図8は、fw.〓〓〓〓〓.co.jp という有限会社内のノードの事例で、連続稼働はしないで、必要なファイルをダウンロードしたら止めるという利用形態で、キャッシュは消さずに放置しているものと読み取れる。

図9は、個人登録のドメイン（ブログのWebサイトがある）で稼働するノードで、1年近くのブランクがありつつ、キャッシュは数か月消さずに放置するという運用のようである。

図10は、一度もキャッシュを削除せず、2007年6月からはときどきしか稼働させない運用に変化した事例である。今年2月からは再び活発になっていることが窺える。

図11は、1、2か月毎にキャッシュを削除しながら、ずっと使い続けている事例である。（co.jpのドメインであるが、ある小規模マンションで取得したドメインのようなので、居住者によるものと思われる。）

図12は、国立大学での事例で、少しだけしか使っていないが、キャッシュを消さずに、3月の卒業までときどき使っていたことを窺わせる。

図13は、私立大学の事例で、数日から1週間程度でキャッシュを消しつつ、1月の卒業まで使用していたことが窺える。

以上は、今年のゴールデンウィーク前までの旧観測システムでのデータである。ゴールデンウィーク以降の新観測システムでは、キーの観測密度が大幅に向上したため、旧システムと同列には比較できない。図1のケースについて、両システムでの観測データを同じグラフ上にプロットすると、図14のようになり、急激にファイル数が増えて表示されてしまう。

しかし、これに、ソース書き換えキー排除の処理を施すと、図15のようになり、ファイルの増え具合は普通になっている。つまり、ダウンロードの様子は概ね正しく視覚化できているのだと推定できる。

■ 「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。

写真中のミニモニタ上部中央に表示しているグラフは、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』等で自動ダウンロードをかけている人達なのか」という点については、そうではない（そうとは限らない）ということになる。

■ 楽天ad4Uが自粛していた

先週、「楽天 サイト閲覧情報収集し広告配信 無断利用に批判 政府問題視」というニュースが話題になっていたので、Twitterでの反応を調べに行ったところ、次の発言があった。

楽天ad4Uの顧客説明用資料かな？ とりあえず，保存保存 http://bit.ly/X2iDZ

viperbjpn 10:23 PM Aug 20th TweetDeckで

リンク先の公開資料を見に行ったところ、こんなことが書かれていた。

「Firefoxにて現在スタイルシートの仕様上の課題について議論されている状況を鑑み（略）楽天ad4UのFirefoxへの対応を自粛させて頂く」とのこと。

ならば、Internet Explorerについても、こういう使い方をすることの善悪についてのMicrosoftの見解が示されていればよい（ということになる）。

関連：

• 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認, 2008年12月13日の日記

■ エコポイント申請画面が共用SSLサイト上にある件

• 「エコポイント」の情報システムがわずか３週間で完成した理由, 有賀貞一, NIKKEI NET, 2009年8月26日

  こうした問題を解決するために、エコポイント事務局と関係省庁が選択したのが、米セールスフォース・ドットコムの基盤サービス「Force.com」だった。セールスフォースはこのForce.comを「クラウドコンピューティングプラットフォーム」と表現している。利用者はサーバーなどのインフラを持つことなく、この基盤上で独自のシステムを構築できる。

という記事を読んで、「エコポイント」のサイトを初めて訪れたのだが、これはまずい。

「エコポイント」公式サイトの運営者は、「グリーン家電エコポイント事務局」となっていて、プライバシーポリシーでも個人情報取扱責任者が「グリーン家電エコポイント事務局」として書かれている。しかし、国民の視点からすれば、その事務局が法人なのか国の機関なのか、あるいは委託先の企業なのか何なのかわからない。サイトの下部に、環境省と経済産業省、総務省のロゴが貼られているが、それが何を意味するのかはっきりしない。

そういう状況の中で、このサイトのドメイン名が「eco-points.jp」という汎用JPドメイン名になっているところがまずい。内閣官房情報セキュリティセンターの「政府機関の情報セキュリティ対策のための統一基準」の第4版は、「1.5.2.6 ドメイン名の使用についての対策」として、以下の通り遵守事項を規定している*1。

1.5.2.6 ドメイン名の使用についての対策

遵守事項

(1) ドメイン名の使用についての規定の整備

【基本遵守事項】

(a) 統括情報セキュリティ責任者は、ドメインネームシステムによるドメイン名（以下「ドメイン名」と言う。）の使用について、以下の事項を行政事務従事者に求める規定を整備すること。

(ア) 行政事務従事者は、府省庁外の者（国外在住の者を除く。以下、本項において同じ。）に対して、アクセスや送信させることを目的としてドメイン名を告知する場合に、以下の政府機関のドメイン名であることが保証されるドメイン名（以下「政府ドメイン名」という。）を使用すること。

• go.jp で終わるドメイン名 *2
• 日本語ドメイン名の中で行政等に関するものとして予約されたドメイン名

ただし、（略）

(ウ) 行政事務従事者は、府省庁外の者に対して、アクセスさせることを目的として情報を保存するためにサーバを使用する場合には、政府ドメイン名のサーバだけを使用すること。

政府機関の情報セキュリティ対策のための統一基準第4版, 内閣官房情報セキュリティセンター

「エコポイント」のサイトには「インターネット申請」機能があり、住所、氏名、生年月日、電話番号、購入製品等を入力させるようになっているのだから、「政府ドメイン名」のサーバだけを使用しなければならないはずである。

仮に、ドメイン名の周知が他の媒体（家電販売店で配布されるチラシ等）でなされているという理由をもって、これでかまわないのだとするとしても、SSLの使い方に問題がある。

まず、個人情報の入力画面が、図1のように、「https://eco-points.secure.force.com/...」となっていて、ドメイン名が、家電販売店等で周知されるものとは異なるドメイン名となっており、得体の知れないところになっている。EV SSL証明書が使われているわけでもないので、Firefox 3.5で表示すると、SSL接続を表すアドレスバーの青い部分は「force.com」と表示されて、国民にはそれがどこなのかわからない。どこかの共用SSLサイトのようにも見える（追記：見えるじゃなくて、本当に共用SSLサイトだった）。サーバ証明書の内容（発行先組織名）を確認しようとしても、San Franciscoの「Salesforce.com, Inc.」だということしかわからない。

これは単純なPhishing対策の観点からまずいだけではない。SSLによる暗号化通信は、相手先を確認できてはじめて意味を持つ。仮に、利用者が、ドメイン名を手入力して「エコポイント」のサイトにアクセスしたとしても、申請画面にたどり着くまでの間に、通信路上で（たとえば公衆無線LANなどを使用しているときなどに）通信内容を改竄されると、別の正規のSSLサイトに飛ばされてしまうので、盗聴されるのと同じ結果を招く。安全なWebサイト利用の鉄則に示されているように、利用者が重要な情報を入力する画面で（つまり図1の画面で）、運営者を確認できるようにSSLを使わなければ、SSLが意味をなさない。

なによりもまずいのは、こうした真正性の確認できないサイトで入力することに国民を慣れさせてしまうことだ。

クラウドコンピューティングが普及するのはけっこうだけども、入力画面の運営者の確認手段の提供を怠ってはいけない。ドメイン名でわかるようにする（「政府ドメイン」を使用する）か、または、EV SSLで（国民が容易にその真正性を確認できる）組織名を使う必要がある。

なお、この日記は、冒頭の記事を読んでからわずか1時間で書き上げた。（追記：その後40分で少し書き足した。）（追記：1時間後にタイトルを変更した。）

追記（2時間半後）

とりあえず、同じドメイン名とサーバ証明書のSSLサイト（共用SSLサイト）上に、私のページを作成した（図2）。

（追記：その30分後、図2の画像を差し替えた。）

追記（3時間半後）

関連：

• EV SSLを緑色だというだけで信用してはいけない実例, 2009年6月27日の日記

  ところで、そもそも、EV SSLに限らず（通常のSSLを使った）「共用SSL」というサービス自体、どうなんだろうか。以下に4つのケースに分けて検討してみる。（略）

なお、6月27日の日記で例示したサイトは、共用SSLでのEV SSL使用を中止すると発表した。

• フォームメーラー Pro-EV版 サービス終了のお知らせ, フューチャースピリッツ, 2009年8月24日

  この度、『EV SSL証明書』を用いた本サービス『フォームメーラー Pro-EV』におきまして、弊社以外に送信されるフォームについて、弊社名がブラウザに表示されるEV証明書を利用しているのは、不適切であるというご指摘をいただきました。

  弊社にて検討を行いました結果、ご指摘に基づき、本サービスにつきまして2009年10月1日に終了させていただくことになりました。

（ご英断に感謝します。）

追記（12月4日）

その後、エコポイント公式サイトのプライバシーポリシーが改訂され、一応の解決がなされたもよう。「グリーン家電エコポイント事務局」が何者であるかが書き足されていた。しかし、SSLで使用するドメイン名の問題は解決されていない。これについては、その後生じた別の事案も含めて書く予定。

■ 津田大介氏の杜撰な評論 その1

Twitterを「Winny」で検索していたところ、コンテンツ学会企画の津田大介氏の講演（「コンテンツビジネスと著作権-最新動向(仮)」）があったようで、数人の人がそれをTwitter中継しているのを見かけた*1。それらの内容からすると、津田氏はWinnyに対して浅薄な理解しかしていないように見受けられたので、どういう理解をしているのだろうかと、「Winny 津田大介」でWeb検索してみたところ、今年の1月に出鱈目な著作権問題評論を展開していたのを見つけた。

津田大介：著作権っていまモーリーさんが仰ったみたいに、実は著作権ってすごくそういうときに「悪用」って言ったらおかしいけど、利用されやすいんですね。たとえば、明確に日本の法律でコンピューターウイルスを作成したのって、どういう罪に問われるんだろうって時に、結構微妙なんですよ。

モーリー：ふーん。

津田大介：コンピューターウイルスって、作者は明らかに被害を及ぼしているわけじゃないですか。ウイニーを使った情報漏えいウイルスを作ったりコンピューターに破壊活動を行わせるようなウイルスを作ったときに、その作者はどういう罪状でどういう対応をしてどういう署名*2をして起訴までいこうかと考えたときに、逮捕までいくのが結構大変で、そういうときに一番わかりやすかったのがウィニーを使ってるとどうしてもいろんなところにアップロードをしまくるという特性があるので、あれは非常に著作権侵害なりやすいツールなんですね、法律的にも。そこでウイルス作者を著作権侵害で逮捕したりするんですよ。ほんとに結構そういう例っていうのは結構あって、本来それは著作権侵害ではなくてもっと悪いことしてるよねみたいなときに、そういう著作権侵害っていうのが都合よく使われている。

モーリー：別件…

津田大介：別件とまでは言わないですけど、やりやすい方法で著作権が利用されて逮捕されたりとか、逮捕じゃないけれどそうやって一部から脅される口実に使われたりということがあって、本来的な著作権の使い方とは違うんですよね。あれってもともと創作者が経済的利益や人格的利益を守るためのものなのが、方便としてそういうふうに使われてしまっているというのが非常にぼくは歪んだ状況だと思います。

津田大介氏にインタビュー　著作権の現在について(2), Posted by i-morley, 2009年01月16日

ウイルス作者が起訴されたといえば、2008年1月逮捕の事件しかまだない。この件について、津田氏はようするに、「ウイルス作者もWinnyで（アニメ等の）ファイル共有をやっていたので逮捕された」という意味のことを言っている。

もう少し詳しくすると、「警察は、ウイルス作者を逮捕するにあたって、当該ウイルス作者がWinnyで（アニメ作品等の）著作物のファイル共有をしていた（他のWinny利用者らと同様の行為として）ため、それら（アニメ作品等著作物）の公衆送信権侵害（という、ウイルスとは全く無関係の事実）で逮捕したのだ」ということ*3。

それは全くの出鱈目だ。

この事件で罪とされたのは、著作権法113条6項（罰則は119条2項1号）の著作者人格権侵害である。*4

この事件の判決は次のようなものだった。

本件は，被告人がした名誉毀損（判示第1）と，著作物であるアニメーション番組の静止画情報を，自己が作成した感染者のパーソナルコンピュータのハードディスク上の情報を破壊するなどの機能を有するコンピュータウィルスに添付した上，ファイル共有ソフトである「Winny」により自動公衆送信し得るようにして，著作権（公衆送信権）を侵害するとともに，著作権者の名誉又は声望を害する方法により著作者人格権を侵害した（判示第2）という事案である。

被告人は，平成18年1月ころから，
（中略）
アニメーションの画像等が感染者のパーソナルコンピュータのモニター上に表示されれば，感染者が動揺したりその画像に注意を惹かれるなどして対応が遅れ，コンピュータウィルスを機能させることができると考え，平成18年8月ころから，アニメーションの画像にコンピュータウィルスを添付したものを，上記と同様に動画ファイルに偽装した上，Winny等で自動公衆送信するようにもなり，判示第2の犯行に及んだ。

以上のとおり，判示第1の犯行は，（略）。

また，判示第2の犯行は，上記のとおり，被告人が，自己の作成したコンピュータウィルスが思惑通りに機能することを企図したものであって，その経緯や動機にも酌量の余地はない上，その態様も，上記同様動画ファイルに偽装するなど巧妙であるし，この犯行も被告人が繰り返していた同様の犯行の一端であることからすると，この犯行の犯情も悪い。著作権者らは，被告人に勝手にアニメーションの画像を用いられて自動公衆送信され，その著作権が侵害されただけでなく，同画像をコンピュータウィルスに添付されアニメーション番組の名前を冠したウィルス名が付されるなどして悪用されて，同著作物の社会的な評価が傷つけられるなどしており，著作権者らの憤りも強く，同犯行も軽くみることはできない。

以上の諸点に照らすと，被告人の刑事責任は重く，被告人に対し，罰金刑を選択することはできず，懲役刑を選択するのが相当である。

しかし，他方で，被告人が，本件の捜査の過程で，判示第1の被害者やその家族の被った被害や迷惑を知り，今では被害者らに申し訳ないことをしたと反省し，また，判示第2の犯行についても反省の態度を示し，今後はWinnyを利用せず，コンピュータウィルスを放流することもしないと誓っていること，（略）など，被告人のためにしん酌することができる諸事情もあるので，社会内で更生する機会を与えるのが相当であると判断し，刑の執行を猶予することとした。

京都地裁 平成20年5月16日宣告 著作権法違反，名誉毀損被告事件 判決要旨（量刑理由）より

津田氏は冒頭のインタビュー（引用部最後の段落）で、「本来的な著作権の使い方とは違うんですよね。あれってもともと創作者が経済的利益や人格的利益を守るためのものなのが、」と言っているが、この事件はまさに、「創作者の人格的利益」が毀損されたものであって、津田氏はまるっきり事実を取り違えて話していることがわかる。

しかも、この事件のウイルス作者は、公判の被告人質問で次のように述べたと報道されている。つまり、アニメや映画などの著作物をWinny等でダウンロードする人々に対して（怒りを覚えたのか）ダウンロードをやめさせるつもりでやったのだという。

（略）被告は被告人質問で、「ネットの掲示板を見て、ウィニーの利用者は遊び半分で映画やアニメを無断でダウンロードしていると思った」とウィニー利用者への不信感をにじませた。さらに、「映画やアニメがウィニー上で無断でダウンロードされることが続けば、（テレビ局は）映画やアニメを放送しなくなってしまうと思った」と述べた。

（略）被告はテレビで放映されたアニメや映画を録画して観賞する趣味があり、今後もこの趣味を楽しむために「ウイルスを散布して（ウィニーでの違法ダウンロードを）阻止しようと思った」と動機を話した。

（略）「映画などを取り込んでいる人のほうが悪いと思っていた。今は、アニメ画像を（たとえ）１枚でも無断で使ったことを悪く思っている」と反省の弁を述べた。

「ウィニー利用者懲らしめる」 ウイルス作成の（略）被告、身勝手な動機, 産経新聞, 2004年4月17日

「アップロードする人が悪い（ダウンロードする人は悪くない）」という津田氏（やMIAU）の立場と対照的なわけだが、それはともかく、こういう動機でそうしたというのだから、このウイルス作者自身が、鑑賞する目的でアニメや映画をダウンロードしたり、ましてや共有状態にして放置したなどという事実はなかったに違いない。*5

それなのに、津田氏は、「ウィニーを使ってるとどうしてもいろんなところにアップロードをしまくるという特性があるので、あれは非常に著作権侵害なりやすいツールなんですね、法律的にも。そこでウイルス作者を著作権侵害で逮捕したりするんですよ」と、ありもしないことを憶測で言い、被告（現在は判決が確定して執行猶予中）が憎んだであろう人々と同類にしてしまっている。

事件当時、新聞各社が連日たくさんの記事を書き、たくさんの新聞社が社説を出したし、公判中にも上記のように報道が続けられていた。著作者人格権侵害で起訴されたことは、起訴時にスラッシュドットのストーリにすらなっており（「ウイルス頒布の院生、著作者人格権侵害で起訴、名誉毀損容疑で再逮捕」）、「ウイルス 起訴」でWeb検索するだけで見つかる。津田氏は、ジャーナリストなのだから事件の情報ソースに当たる役割もあるはずだろうし、なにより著作権問題を専門とするのだから、非常に珍しい著作者人格権侵害罪での刑事事件が起きたなら注目してしかるべき（この事件における著作者人格権の意義についての論評さえ期待されるところ）であり、それに気づかなかったなどとはあり得ない話だ。

言うまでもないことだが、根拠をろくに確認することなく思い込みで評論することは避けるべきである。たくさんの純真な人々が敬慕して話に耳を傾けてくれる状況ならだ。「政治に文句を言う」のは結構だけども、ありもしない事実を流布して人々に錯誤した不満を募らせるようなことをするべきではない。

（おわり）

ついでに別件について。検索していたところ、「ぐだぐだPodcast 第33回：tsudaさん登場回後編」というポッドキャストがあった。終盤で津田氏が、「tsudacchi（津田大介名言集）」というTwitterアカウントについて、友達が作ったという話の流れで、「で俺最初はそれパスワードも知っていたんで、さすがにそれは名言じゃないなっていうのを自分で消したんだけど、消したら、パスワードを変えられていて、」と述べている*6が、このような発言には気をつけるべきである。「パスワードを知っていた」というのが、仮にアクセス権者から何らかの理由で知らされたものだったとしても、当該パスワードを使用する段階で「利用権者の承諾を得てするもの」であったと言えなければ、不正アクセス禁止法3条（2項1号）違反である。この法律の法益は、目的が「アクセス制御機能により実現される電気通信に関する秩序の維持」とされているように、社会的法益であるので、利用権者に被害感情があるか否かは関係がない。そういった行為が安易に真似されることのないよう、その時点で利用権者の承諾を得て入力したものであったとわかるように話す必要がある。

■ 追記（30日）

上記の点について、津田大介氏が釈明をしている（「Posted at 12時30分」）。

ようするに、発言の方向性が概ね正しければ、その論拠として最大限強烈な題材を持ってくるにあたって、その題材が実は曖昧な記憶に基づく事実でない捏ち上げで、実際にはそこまで酷い話ではないのであっても、発言の方向性が概ね正しければ「事実誤認をしていたとは思えない」という。*7

これが日本のジャーナリストの職業倫理なのか。

ありもしない虚偽事実を吹聴された元被告の名誉はどうなるのか。*8

そもそも、あの事件は、名誉毀損や著作者人格権侵害が甚だしく、それらのみで十分に処罰するに値する犯情があると判決で示されている。判決ではウイルスそのものの被害（ウイルスを誤って実行した人々の被害）については触れられていない。そういう事件が、ウイルス作者であることと関連付けられて大きく報道されたのは、当時、ウイルス罪新設の刑法改正案が国会で店晒しになっていることに対する世間の苛立ちがあり、それをマスコミが汲み取って世論形成を促すのにも（弊害なく）活用できるものだったからで、そうだからといって、当該事件におけるウイルスを用いた名誉毀損や著作者人格権侵害の罪の判断が不当だなどという理屈は、非論理的である。

■ ダウンロード違法化反対家の知られるべき実像

あるきっかけで、あるダウンロード違法化反対家の人の、自宅のものと思われるIPアドレスを知ってしまった。知ることができたのは、2007年と2008年のいくつかのある日におけるIPアドレスである。そのIPアドレスを手元のWinnyノード観測システムの接続ログと突き合わせてみたところ、5回の日時において、WinnyノードのIPアドレスとして観測されていたのを見つけた。

それらのIPアドレスがソースとなっていたキーを抽出し、16日の日記の方法で視覚化したところ、図1のとおりとなった。

他の区間でどうだったかを調べたいところだが、2007年の部分と2008年の部分では、ISPが異なっており、ポート番号も「4857」と「3857」という具合*1に違っていた。

一般的に個人宅に割り当てられるIPアドレスは時々変化しており、それを追跡することは通常、簡単でない。仮にポート番号が一定だとして、ISPとポート番号の組で1つに絞り込めるかというとそうではなく、数人ほどの人々が同じISPで同じポート番号を使用しているようなので、機械的には絞り込めない。

ところが、この人の場合、使用しているのがWinnyではなく、Winnypだった。Winnyネットワークに現れるノードのうちWinnypの割合は 7% ほどであるため、WinnypであることとISPとポート番号によって、機械的に1人に絞ることができてしまった。

図1の既知の区間からその前後のIPアドレスを手繰っていったところ、連続して追跡することができ、途中でポート番号が変えられていたけれども、ポート番号の変更とIPアドレスの変更が同時ではなかったため、続けて追跡することができた。ポート番号は「8356」→「8357」→「3857」→「4857」→「3857」という具合*2に変えられていた。

こうして追跡していくと、最終的に観測開始当初から現在まで辿ることができ、まさに今、当該IPアドレスでWinnypが稼働中であることも判明した。*3

全期間について当該ノードのキーを抽出してみたところ、図2（旧システム観測分）と図3（新システム観測分）のとおりとなった。

このグラフの形状から、同じ人の「Cache」の内容を継続して抽出できていると推定できる。空白の区間が何か所かあるが、ここは該当するIPアドレスを見つけることができなかった*4。Winnypが稼働していなかった期間なのかもしれない。

グラフの最初の立ち上がりを見ると、16日の日記で示した事例に比べて、極端に早く立ち上がっていることがわかる。おそらくこれは、観測を始めた2006年8月末の時点で、既に3000個ほどのファイルが「Cache」フォルダに溜め込まれていたことを意味するのではないかと考えられる。グラフの傾きから推定して、この時点で既に何年も稼働させっぱなしだったのではないだろうか。（もしかして、Winnyが登場したときからずっとなのだろうか。）

図2では、最初の部分を除いて全体的に密度が薄くなっているが、これは、相手がWinnypであるためかもしれない。

じつは、私のクローラはWinnypのプロトコルに対応しておらず、Winnypのノードに接続してもそこからキーを受信することができない。それなのになぜ、Winnypノードのキーを観測できているかというと、当該Winnypノードが他のWinnyノードに接続して拡散させたキーが、そのWinnyノード経由で私のクローラに届いているためである。また、Winnypには、Winnypにしか接続しない動作モード「Ver=0」があるが、当該Winnypが接続した他のWinnypノードが、Winnyへの接続を許す設定（Ver=1〜3）になっていれば、結局、3ホップで私のクローラにそのキーが届く。ホップ数が増えれば、私のクローラまで届く確率が低下するので、グラフで密度が薄く表示されると考えられる。

図2で最初の部分だけ密度が濃いのは、このタイミングで、当該Winnypノードが動作モードを「Ver=0」に変更したためではないかと推測するが、どうだろうか*5。

以下の図3（新システム観測分）では、観測システムの能力が向上したため密度が濃くなっている。なお、図3中の7月13日あたりから8月14日までの区間に見られる瘤状の部分は、22日の日記に書いたのと同じく、「ドラゴンクエストIX」のダウンロードを阻止するためのものと思しき偽キーであった。このノードは、8月14日までIPアドレスを借用されていたようだ。

このように、固定IPアドレスではないインターネット接続であっても、ファイル共有ソフトを使用しているとIPアドレスを追跡されてしまう場合があることは、広く知られてしかるべきである。

ファイル共有ソフト側がクローラに接続されないよう対策するとしても、リバースエンジニアリングされて接続されるのは時間の問題である。これは、不特定多数に利用させるファイル共有システムでは不可避なことである。*6 *7

それにしても、少なくとも3年間（もしかすると5、6年くらい）ずっと「Cache」を消さずに、年中Winnypを動かしっぱなしというのは、いったいどういうつもりなのだろうか。キーの内容にざっと目を通してみたところ、「海外ドラマ」、「成年コミック」、「一般コミック」、そして児童ポルノらしきファイルのキーが目についた。

そこで、それらを視覚化してみた。

図4は、ファイル名に「海外ドラマ」の文字列を含むキーだけ赤で表示したグラフである。2008年5月から「海外ドラマ」のファイルをダウンロードしていたらしいと推察できる。

図5は、Wikipediaのこのエントリで解説されているものに該当するファイルと思しきキーを赤で示したグラフである。2009年6月下旬に連続してダウンロードされたらしき様子が窺える。

おそらく、1週間か2週間ほど地引き（自動ダウンロード）をかけていたのではないか。この部分に該当するファイルは全部で200個ほどあった。ファイル名は以下のようになっていて、シリーズ物をコンプした感じになっている。

(洋ロリータ写真集) 〓-〓〓〓 Issue01 Set-10.rar
(洋ロリータ写真集) 〓-〓〓〓 Issue01 Set-22.zip
(洋ロリータ写真集) 〓-〓〓〓 Issue01 Set-27.zip
(洋ロリータ写真集) 〓-〓〓〓 Issue01 Set-29.rar
(洋ロリータ写真集) 〓-〓〓〓 Issue02 (Sets01-06).zip
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-01.rar
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-02.rar
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-12.zip
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-15.rar
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-21.zip
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-23.zip
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-27.rar
(洋ロリータ写真集) 〓-〓〓〓 Issue02 Set-27.rar
...

もっともこれは、児童ポルノ流通の実態調査のためにダウンロードしたものなのかもしれないので、自己の性的好奇心を満たす目的で繰り返し取得したものなのかどうかはわからない。ただ、調査の目的でシリーズをコンプする必要があるのか疑問に思う。たとえダウンロードが現行法で合法であるとしても、通常のWinny（やWinnyp）でダウンロードすると、いくらかの確率で中継ノードからのダウンロードとなり、そのノードに複製を作ることになる。そのことにいくらか違法性があるかもしれないし、そうでないとしても倫理的によろしくない行為だと思う。*8

ところで、これだけ堂々と長期間「Cache」を削除せず放置してWinnypを運転し続けているということは、さすがに、アップロードゼロの対策はとっているのだろう。ネット上級者ならその必要性を理解しているはずである。（実際にアップロードゼロ対策されているかどうかは、確認していない。）

図6は、「成年コミック」と「一般コミック」を赤で示したものである。

この追跡したIPアドレスが本当にその人のものなのか、念のため、各IPアドレス（とその時刻）をWikipediaの編集履歴と突き合わせてみたところ、ある著作権関連のエントリに自分自身のことを書き加えた履歴があった。

正直、私は、ここ数年、まさかダウンロード違法化反対家の人が未だにこういう状態だというのは、ちょっと思いもよらなかった。

ダウンロード違法化に対して様々な弊害が挙げられたり、児童ポルノ単純所持処罰化に対して冤罪の恐怖が語られたりするけども、実際困るのはこういうことだからじゃないのか。

私が心配なのは、Winnyにも児童ポルノにも興味のない人々まで、一緒になって反対の声を強めていることだ。特に驚いたのは、7月12日の日記「Winnyによる児童ポルノ流通の実態と児童ポルノ法改正の方向性」を書いたときに、ものすごい勢いで、「児童ポルノなんて存在しない」というヒステリックな反応が出てきたことだった。つまり、児童ポルノ所持とは無縁な人達が、児童ポルノ法の冤罪を本気で怖がって、反対派が作ったまとめサイトの記述を鵜呑みにしてか、「日本には児童ポルノなんかほとんど存在しない」と信じ込まされている様子だった。*9

こんなことでよいのだろうか。ダウンロードしたいから反対する、児童ポルノを持ち続けたいから反対するのであれば、正直にそれを明かした上で意見を述べるべきではないだろうか。*10