<前の日記(2004年05月15日) 次の日記(2004年05月17日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1203   昨日: 2328

2004年05月16日

市民の安全を深刻に害し得る装置としてのWinny

「Winny」の作者が著作権法違反幇助の容疑で逮捕されたとのことで、いろいろな議論が巻き起こっている。幇助にあたるかどうか、著作権法の将来のあり方、音楽産業の将来などについては専門外であるので、あまり考えはない。

Winnyについては去年の2月2日に、日経デジタルコアの「世界情報通信サミット2003 ネット会議」の場で次のように発言しており、これが私のWinnyに対する考え方だ。

ただ、データ転送に入る前の「ファイル探索」部分まで含めると、純粋に近いP2P構成の動作には、現時点では障害が多いと思っています。(winnyなどの例)

調査のためWinnyを一定期間試用してみたのですが、私の感触では、十分に実用になるほどに検索機能は働いていると感じました。「今すぐ○○が欲しい」という要望には応えられないものの、「2, 3日中に○○に関連したものが欲しい」という要望には応えられるようです。

(略)

そういう状況では、非効率であるはずのP2Pでも十分に人々の要望に応えてしまうため、管理者不在のそのようなシステムが実現し得ることは、著作権を資本としてビジネスを展開したい者としては脅威になると思います。

(略)

マイナーなものは極めて見つかりにくいということですね。しかしその種のものは、1か月かかってでも見つかればいいものかもしれません。また、その種のものは、著作権ビジネス的にはあまり脅威の対象ではないように思えます。

むしろ、名誉毀損やプライバシー侵害にあたるような映像の拡散を止められないといった観点からの懸念があるように思います。

日経デジタルコア ネット会議, 2003年2月2日

前後を読むとわかるが、これは、別の方から、P2Pでは検索が「恐ろしく効率が悪い」ため当面管理行為は同定できるというご発言があったため、「いや十分に脅威になる」という趣旨で反論を試みたものだ。

このとき最後の段落でついでに述べた通り、Winnyのシステム構造には、個人のプライバシーを侵害する行為のために使われた場合に、その原状回復がほぼ不可能という深刻な問題点がある。

業務に使うコンピュータでWinnyを使用したうえ、不用意にトロイの木馬を実行したことによって、個人情報を含むなどの業務上の機密ファイルを誤ってWinnyネットワークに放流してしまったという事例については、操作を誤った者に主な責任がある。

そのケースとは別に、積極的に他人のプライバシーを侵害する目的で、そのような自作のコンテンツを放流するという行為がなされる可能性があり、それが憂慮される。たとえば、そこそこ名を知られた人がトイレで用を足しているところをビデオカメラで撮影し、その映像を放流するといった行為がそれに該当する。そういうことが起こり得ると認識することによって、人々の生活様態事態までもが制約されていくことにさえなり得る。

そうした事態がまだ起きていないかどうかはわからない。いまのところ報道されてはいないと記憶しているが、既に起きているが広く知れ渡っていないだけの可能性もある。少なくとも「善良な」マスメディアは、被害を拡大させるという理由で報道を控えるだろう。

「ブロードバンド社会で次の技術はP2Pしかない」といった、P2Pの技術的価値を主張する意見が多く見られるが、はたしてどうか。

まず、P2Pという言葉が指す意味が人によってバラバラになってきている。サーバ・クライアントモデルに対するものとしての、peer to peerという意味で言うならば、何もそういうアーキテクチャは最近始まったものではなかろう。サーバ・クライアント方式がインターネットの主な通信モデルとなったように思えるのは、単にWWWだけが極端に普及したためではなかろうか。「インターネット = ホームページ」と思っている人にとっては、「インターネット = サーバ・クライアント」なのかもしれない。

SMTPで通信し合う電子メール交換システム全体を見れば、peer to peerとも言える。特定相手とのチャットのための「インスタントメッセンジャー」のような仕組みでは、peer to peer型になるのはアーキテクチャ的にはじめから自然であり、特殊なことではない。

P2Pを狭い意味で使っている場合、それが分散型情報共有システムを指していることがある。しかし、インターネットでははるか昔から、Usenetというバケツリレー方式の分散型メッセージ共有システムがあった。

ここで、Usenetシステムでは削除機能と発信者記録機能がはじめから用意されていたことを思い出す。

分散型情報共有システムを作ることは、一定以上のスキルを持つ情報技術者であれば、誰もが一度は考えたことがあるだろう。その発想は、様々なアプリケーションの開発場面で出てくるものだ。システムをスケーラブルにするために、分散型に設計するのは常道であり、情報系の教育を受けた者であれば常識でなくてはならない。

そうしたシステムを設計する際、一度広がり始めた情報が取り消しできなくなることに恐怖感を覚え、あるいはそこまで考えが及ぶまでもなく、データを削除する機能を取り付けることは、普通の技術者が当然に考えることであろう。

しかしWinnyには削除機能がない。最初の提供者(Upフォルダにファイルを投入した放流者)がファイルを削除しても、既に広くキャッシュされていれば、そのファイルがいくらか参照される限り、いつまでもそのファイルはWinnyネットワークに漂い、残り続けることになる。

もっとも、削除機能をどう実現するかはなかなか難しいところだ。誰でも削除できるシステムであれば、不当に削除を乱発する荒らし屋が現れて使いものにならなくなる可能性がある。Usenetのcancelシステムはまさにそういうものだった。

最初の提供者(放流者)だけが削除権限を持つシステムは作れそうではあるが、それで十分とは言えない。放流者が他人のプライバシーを侵害する目的で意図的に放流している場合は削除してくれないだろうし、放流者が死亡してしまった場合などにも削除できない。特定の人だけが特別に削除権限を持つというシステムが考えられるが、そういうシステムをうまく運用し続けられるかに疑問が残る。政府機関がその権限を持つというキーエスクローのような仕組みは、うまくない発想だと言われて久しい。

多数決で削除を決めるということが考えられる。Winnyには「無視リスト」という機能があるようだ。私のWinnyに関する知識は、「調査のためWinnyを一定期間試用してみた」という2002年のころの知見で止まっているので、その後どうなったかを知らないが、無視リストというのは元々は、捏造ファイルを無視するために用意されたと読んだ記憶がある。たくさんのWinnyユーザが無視リストに登録したファイルは、その人達のノードではキャッシュされなくなり、Winnyネットワークから徐々に消滅していくことになる。だが、全員が無視リストに登録しない限り削除にはならないという点で、多数決削除システムと言えるようなものではないだろう。

削除要求を誰でも出せるようにして、デフォルトはそれに同意とし、異議がある場合だけ拒否を主張できるようにする方式が考えられる。一定割合以上の異議があった場合だけ、削除が中止されるようにする。この場合でも、不当に異議を唱えまくる荒らし屋が現れる可能性があるので、異議を提出する場合はIPアドレスを名乗ることが必須とするという方式はどうだろうか。削除要求についても、IPアドレスの提示を必須とするのもよかろう。

分散型情報共有システムにそうした削除機能を付けることは、Usenet全盛の十数年以上前から技術者は誰もが普通に考えていたことであろう。

Winnyはあえてその機能をつけなかったのだと思われる。Winnyが登場するずっと以前より、普通に技術者は、そうしたシステムが普及してしまうことを、恐ろしいことと直感していただろう。それをとうとうやってしまった。多くの人がそう感じているはずだ。

Usenetにあった発信者記録機能(Path:フィールド)は、メールのヘッダ同様に偽造可能ではあるが、どこからか以降は本物であるから、順々に辿っていって、そこが本当に中継したものかを尋ねて調査していけば、最初の発信をしたサーバまでたどり着くことは不可能ではない。WinnyのようなP2P型ファイル共有システムにそのような機能を付けることは当然ながら可能だ。

では、それほどまでに分散型情報共有システムが普通のものだというのなら、なぜWinny以前にそうしたシステムが普及しなかったかという疑問が出てくるだろう。その答えはこうだ。

放流者を特定できる機能を備えたWinnyのようなシステムを発表したとしても、ほとんどユーザがつかず普及せず、その有効性も確認されなかったと予想される。その理由は次の通りだ。まず、そのようなシステムでは、違法コンテンツが流通することはほとんどなく、合法コンテンツばかりとなる。Winnyがそうであるように、P2P方式の大型ファイルの共有システムでは、検索に時間がかかるうえ、ダウンロードも途切れることもあって、いつダウンロードが完了するかわかったものではない。サーバ・クライアント方式なら即座に目的のファイルを探せ、即座に一定の速度によるダウンロードを開始できるのに比べると、ユーザはイライラするだろう。ましてや、コンテンツが有料だったりすれば、怒りさえ感じて、サービス提供者に苦情を言う人が出てくるに違いない。

つまり、Winnyが検索やダウンロードの効率が比較的悪いにもかかわらず、それでも大量のユーザの確保できたのには、そこに「超」魅力的なコンテンツがあったという事情があるからだ。その魅力とは、言うまでもなく、本来有料のはずのもの、他の方法では入手が困難なもの、そんなものが存在するとは普通知られていないようなものがそこにあったからだ。

人々は、コンテンツの「超法規的な」魅力を原動力としながら、Winnyを体験したことによって、「検索をかけて放置したまま急かされることなくダウンロードし終わるのを適当に待つ」という、情報システムの新しい使い方に覚醒した。Winnyの最大の(今後の展開によっては唯一となるかもしれない)功績はここにあると言えよう。

昨今、P2Pによる分散型ファイル共有(流通)システムの有益性を主張する人が少なくない。ブロードバンド接続が普及したことによって、かつてのUsenetとは違う使い方で、それに有益性が生まれている。

何十年もの昔にUsenetのような分散型情報共有システムが作られたのは、2ちゃんねる掲示板などに見られる集中型のサーバ・クライアント方式でのメッセージ交換システムは、当時のネットワーク性能では到底実用にならないことが明白だったからだ。今のネットワーク性能なら、テキストのような小規模データであれば、そこそこの設備によって集中型システムでも実用的な性能が得られるというわけだ。

そして現時点では、ビデオ映像のような大きなデータを瞬時に多くの人達で共有するには、サーバ・クライアント方式では実用にならないと考えられているため、P2P(というか分散型アーキテクチャ)が再び脚光を浴びているわけだ。

音楽データのように5メガバイト程度のファイルであれば、サーバ・クライアント方式でも十分に提供できるだろう。サーバへの同時接続数が多すぎるとOSが破綻してしまったり、サーバ直近のネットワークが破綻してしまうことがあるが、専用のクライアントアプリケーションを使わせることによって、UDPでゆっくりデータを送出するなどといった方法で、破綻を避けるコントロールができるかもしれない。

「ゆっくりと送出」などというのはイライラして使い物にならないと思われるかもしれないが、Winnyのようなシステムでも、目的のものが即座に得られるわけではなく、急かされることなくデータの到着完了を適当に待つのが普通なのだから、ゆっくりと送出でもかまわないはずだ。

しかし、数百メガバイト以上のデータ(たとえばKNOPPIXのCDイメージデータなど)を提供するとなると、あまりにもゆっくりというわけにもいかず、人気のあるデータならば、サーバにかなりの設備が必要となるだろう。たしか、KNOPPIX日本語版が産総研のWebサーバから提供された際、アクセス集中でWebサイト事態が閲覧できなくなるという事態が起きた記憶がある。(違ったかな?)

そのような場合においてP2Pが有意義だと言われている。DRM(デジタル著作権管理)機構を備えたファイル形式によって、映像コンテンツをどんどんP2P型ファイル共有ネットワークに流通させたうえ、閲覧時にライセンスの購入が必要なようにするといったことが試みられている。

だが、そうした目的の利用においては、最初の提供者に匿名性は不必要だろう。

コンテンツ提供者の匿名性と閲覧者の匿名性は別である。それについては去年の5月29日の日記に書いた。

たしかに、コンテンツの著作者がコンテンツの内容の都合等で、著作者を秘匿したい場合はあるかもしれない。だが、そういう場合は、秘密を一定の条件の下で約束してくれる代理人に放流してもらえばよいことだ。

匿名性にも複数の段階がある。誰にも特定できないレベルの匿名性と、一定の条件がなければ特定されないレベルの匿名性がある。後者の例としては、普通の掲示板書き込みが該当する。掲示板の書き込み者を特定するには、まず掲示板の管理者に書き込み者のIPアドレスの開示を請求し、そのIPアドレスからISPに契約者の連絡先を求めるというステップを踏むことになる。それぞれの場面で開示請求の妥当性がそれなりに判断されるので、つまらないことでなら、匿名性が暴かれる可能性は小さいといったバランスが形成される。

閲覧者の匿名性は確保されるべきものだろうから、Usenetのように中継パスを記録しながらデータを転送する方式はとれない。となると、最初の提供者のIPアドレスは、偽装されたときに追跡できないかもしれない。このあたりは何とかできるか研究の余地がありそうだ。

現在のWinnyでも隣のノードの人のIPアドレスは知ることができる。ISPに開示請求しなくても、たまたまそのIPアドレスの人が、別のアプリケーションでそのアドレスを公開してしまっている事態は有り得る。たとえば、メーリングリストに投稿していて、そのときのReceived: フィールドが参加者に流れていると、発信元のIPアドレスが、Winnyの隣のノードの人と同じだとわかってしまう場合がないとは言えない。

そういうこともあるので、IPアドレスは固定でなくするべきである。このことについては、去年の5月25日の日記などで書いてきた。さらに特定される可能性を避けるためには、2月8日の日記で書いたように、IPv6を使うなどして、ひとつのコンピュータで多数のIPアドレスを保有し、アプリケーションごとに別々のソースアドレスを使用することで解決できる。これが、将来の理想的なプライバシー維持型消費者向けインターネット環境であろう。

とはいえ、コンテンツ発信者の匿名性を完全に確保するための技術が不要だとは言わない。去年の5月29日の日記にも書いたように、万が一何らかの権力構造の変化が起きたときなど、いざというときに完全な表現の自由を確保するため、そうしたアーキテクチャの実現可能性を探求する研究は重要であり、いつでも利用できる準備を整えておくことに意義はあるだろう。

しかし、そうした目的のシステムでは、テキストのみで十分ではなかろうか。映像とテキストにどう違いがあるかといえば、テキストの内容の捏造は容易であるため、皆が信憑性を評価しつつ閲覧する。それに対して、現時点の技術では、映像全体の完全な捏造はそう簡単ではなく、全くありもしない他人のプライバシー侵害映像を、信憑性のある映像で捏造することは不可能であるから、流された映像は本物であると人々は信じ、プライバシーは確実に侵害される。その点で映像は害のほうが大きい。告発のために映像が必要という場合は、まずテキストでその事実の存在を広めた上で、P2Pや完全匿名でないかもしれないどこか別のシステム上に映像を置く。それが削除されたとしても、既に存在事実だけが広まっていて、その行為に妥当性があれば、別の場所でふたたびその映像は提供されるかもしれない。(そうしたことは既に行われている。)

コンピュータワームの蔓延が情報システムのセキュリティ脆弱性のリスクを知らしめたように、Winnyがコントロールの欠如した分散型情報共有システムのプライバシー上の脅威を知らしめた。情報技術者なら当然に予想していたことを、そうでない人達にも実証して見せたのは、ワームに類似している。

「ワームを放てば人々に脆弱性のリスク理解させられる」と頭に浮かぶことはあっても、実際にそれをやってしまうセキュリティ技術者はそういないだろう。そこは倫理的にも、民事的にも、あるいは刑法的にも許されない行為である。ワームでさえ、時限式になっていて、時が来ると終了するようになっているものがある。ワーム作者がなぜそのような機能をつけようと考えたかを想像してみるとよい*1

Winnyの作者は、特製のツールを使うことで、Winnyネットワーク全体の挙動を観察する能力を持っていた可能性がある。実社会で大規模にそれを普及させたうえ、その様子を観察したとなると、クラスタ化がどのように進行していったかなど、シミュレーションでは到底得られない質の観測が得られたに違いない。その知見を論文として発表するなどしてもらえないかなあ。

追記

音楽産業の将来に興味ないと書いたが、少しだけ書いてみる。

産業音楽とは、たばこ産業のようなものである。同じ音楽を何度も何度も繰り返し聞かせるプロモーションによって、人々はその音楽なしにはいられない中毒症状を起こし、なんとしてもその音楽を聴こうとし、あるいは入手しようとし、高めの金額だと感じつつも定価で購入してしまうのだ。音楽の根本は文化などではなく洗脳であり、ある宗教において、子供のころから聖書を朗読して育つことで、自然にその一節が口を突いて出てくるようになるのと似ている。たばこ愛好家が、特定のたばこ品種に強い興味を抱いたり、自分でたばこを巻いて作るなどしたりすると趣味の領域であり、文化のようなものといえるかもしれない。たばこの製造が自由化されていれば、個性的なたばこを作る人達も現れて、そこには製造者側に文化的な要素も出てくるかもしれない。

もともと音楽の本質はそういうところにあるのだから、完成された大量生産工場型の産業は、そういう形態のまま温存すればよいではないか。いっそ、たばこ税同様に音楽税でも課したらどうか。

私はもう新しい音楽はあまり聴かなくなった。若いころに中毒にさせられた音楽を繰り返し聴いてばかりいるし、あとはせいぜいムネヲハウスなどを聴いている程度だ。テレビはニュースしか見なくなったし、有線放送のかかった商店街を歩くこともほとんどない生活なので、新たなマインドコントロールに洗脳されることもほとんどなくなっている。CCCDでリリースされるようになってからはさらに購入頻度が減った。昔のCDをamazonで買ってばかりいる。もちろんWinnyで産業音楽を入手したりはしない。欲しければ買う。ただ、amazonで検索可能なものしか入手できないのが残念だが、幸い、聴いたこともないような音楽には中毒症状がないので関心がない。

音楽と映画は性質が異なる。音楽はたばこと同様に、中毒症状を起こしてあらゆる生活とともに「ながら作業」で味わうものだ。自動車内で運転しながら聴く、メールを書きながら、日記を書きながら聴く、電車で通勤がてら聴く。それに対して映画の場合は、テレビの前に座ってそれに専念して観る。どにみちテレビの前で観るのだから、DVDが他のメディアに私的コピーできなくてもべつにかまわない。だが、音楽CDの場合に私的コピーできないのは許しがたい。自動車内で聴けない、パソコンで聴けない、ポータブル大容量プレイヤーで聴けないとなると、禁断症状が現れてムカムカしてくる。洗脳のための常習性が、販売産業に対する苛立ちを呼ぶことになる。

今やたばこ同様に、音楽を味わう場所もCCCDで規制されるようになった。喫煙コーナーならぬ、傾聴コーナー(昔ながらのCDプレイヤーの前)に行って聴くしかない。歩きながらのおたばこ同様に、音楽もたのしめない。たばこは幸いなことに生まれてこのかた一度も吸ったことがないのだが、音楽も一度も聴かずに育っていれば、苦しまされることもなくどんなによかったことか。

ちなみに、CCCDは挿入しただけで勝手にわけのわからないアプリケーションを問答無用でインストールする。どこにも説明はない。場合によっては既存の特定のファイル名のファイルを問答無用で上書きする。これは、刑法第百六十八条の二 第2項にある、人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録を、人の電子計算機における実行の用に供する行為であり、不正指令電磁的記録作成罪にあたる。と言っておこう。

我々セキュリティ脆弱性を研究する者が、(専門外のオヤジな人にはその社会的意義を理解されないかもしれない)脆弱性情報の公表という行為を、不正指令電磁的記録の提供と決め付けられかねないリスクに怯えつつ、できるだけその意図を適正に説明しようと努力せねばと決意しているというのに、商業活動として提供されているCCCDが、何の説明もなく、人の意図に沿うべき動作をさせず、その意図に反する動作をさせるべき不正な指令を実行の用に供していながら、罪に問われないのではあまりに理不尽である。

*1 じつはWinnyにもタイマーがあったりして?

検索

<前の日記(2004年05月15日) 次の日記(2004年05月17日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2004年05月15日) 次の日記(2004年05月17日)> 最新 編集