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

高木浩光@自宅の日記

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

2004年08月14日

キャッシュと嘘とファイル放流

まえおき

Winny作者が著作権侵害の幇助罪に問われている事件について、当人の意図がどうだったかは別として、Winnyというコンピュータプログラムの性質に着目する場合に、Winnyのどの技術要素が他のプログラムにはない特殊性を帯びているかを明らかにしようとするのは、個人的に無罪判決が出ることが望ましいと期待する立場からすれば、不用意にそのようなことはしない方がよいとする考えにたどり着きかねないものである。ようするに、電波系サヨク運動家流に言えば、「どうしておまえはそういうことを言うのか? 黙りなさい! キー!」ということだ。

しかし、もしこの事件が有罪という結果になったときのことを考えてみると、何がその理由で、何が理由でないか、その双方が明確にはなされない(情報技術者や一般の市民たちが理解できるレベルで明確にされない)事態となった場合には、それこそ、技術革新に対する萎縮効果が現れてしまう(特に日本のような法体系・執行制度の国では、自発的に必要以上の自粛ムードが現れることを避けにくい)であろうから、それを避けるための一つの手段として、Winnyのどの技術要素が特殊だったのかを事前にはっきりさせておくことは有益だと考える。

また、特定事件の裁判所判断に関わらず、また、法規制のある・なしにも関わらず、Winnyと同様の性質を持つプログラムは、倫理的に人々に受け入れられるものと言えるかどうか、言えないとしたら、どの技術要素が原因であるかを明らかにしておくことは、いずれにしても重要なことであろう。

すなわち、H_Ogura氏のblog「BENLI」に書かれている、

ですから、「Aという行為は、aという要素がある故に、可罰性がある」という見解(甲)に対し、「同じくaという要素を有しているBという行為は、罰せられるべきでない。従って、見解(甲)は間違っている」という批判(乙)は正しい批判です。

BENLI, 議論の仕方, 2004年8月14日

の表記に従えば、もし(作者の意図とは別に)プログラムの技術要素 aに可罰性の根拠があるのだとしたら、その aは何かを明らかにすることである。

何が aとして該当し得るかは、当然ながら複数のものが可能性として検討に値する。そのそれぞれの候補 aについて、「同じく aという要素を有している B」を満たす Bを検討したとき、Bが少ないほど(究極的には、BがWinny以外に存在しない)、その aはWinnyの特殊性を示すものであり、可罰性があるとする根拠として有力だということになる。

Winnyに類似した新P2P型ファイル放流プログラム「MARIE」

さて、ここで一旦Winny事件から離れて、つい先日新たに登場したP2P型の自称「ファイル共有」プログラムを例にとって、その性質を検討してみる。

信州大学工学部公認サークル kstm.org」が、今月1日、「MARIE」という名の新しいP2P型「ファイル共有」プログラムをリリースした。

このプログラムは、ユーザから見た使用感と、ファイル検索の方式は概ねWinnyと同様で、ファイル転送方式については、「細かい仕様(暫定版) 08/02-23:46」の説明によると、次のように説明されている。

ファイル情報には、ファイル名、サイズ、更新日時、MD5値、ファイルやキャッシュを持っている(可能性の高い)ノードのIPなどが含まれます。ダウンロードをした場合、MD5値をもとに自分の持っているファイル情報リストから検索し、データを保持しているであろうノードにダウロードのためのコネクションを張りダウンロードをします。

ファイル情報には、ファイルやキャッシュを保持している可能性が高いノードのIPが含まれますが、あくまで「可能性が高い」だけです。ダウンロードの接続を受け取ったノードがそのファイルを持っていなかった場合には接続を切りますが、自分以外にそのファイルを持っているノードを知っていた場合には、そのノードに対して、ファイル転送クエリを送信します。

kstm@信州大学, Project MARIE, 細かい仕様(暫定版) 08/02-23:46

このプログラムは、Winnyにない機能として、パスワードと称するクラスタ識別子を用いて「共通のパスワードを持った端末同士でしかファイルを共有する事ができません」という機能を追加しているそうである。(この点は今回の本題ではない。)

ここで確認しておくのが重要となるのは、MARIEの次の特性である。

☆暗号

  • 通信はRC4とRSA(256bit)で暗号化
  • キャッシュファイルはRC4

全てのネットワーク上を流れるデータはRC4で暗号化されます.

(略)

☆キャッシュについて

キャッシュは暗号化されていますが,暗号鍵は固定なので,解析すれば中身は読めます.

kstm@信州大学, Project MARIE, 細かい仕様(暫定版) 08/02-23:46

「キャッシュ」とは、「./Cluster/<クラスタ識別子>/Cache/」のフォルダに保存される、ダウンロード中あるいはダウンロード済みのデータおよび、中継中あるいは中継済みのデータが格納されるファイルのことで、これがRC4で暗号化されると説明している。

通信はさらに別途暗号化されるので、交換するファイルのデータは、二重に暗号化されることになる。また、キャッシュファイルのファイル名は、MD5ハッシュ値か何かが使われており、検索やダウンロード済みファイルで見られるファイル名とは異なる名前が付けられている。

ここで、MARIEの作者らが次のように主張している点に注目する。

著作権について

著作権で保護されたデータを,著作者の承諾なしに,不特定多数の人がアクセス出来る状態で共有しないでください.これ以上,P2Pによるファイル共有に対する違法なイメージを植えつけるのは避けるべきです.

今のところ機能として実装はされていませんが,プロトコル的には強制アップロードが可能なので,自分でダウンロードした覚えの無いファイルがキャッシュに入る可能性があります.もし,違法と思われるファイルがキャッシュに入っているのに気付いた場合,削除してください.知っていて放置していた場合は,損害賠償を請求される恐れがあります(プロバイダ責任法).

共有されたデータを監視したり,一度広まったデータを削除したりすることは,誰にもできませんので,各自で注意して運用してください.

kstm@信州大学, Project MARIE, 細かい仕様(暫定版) 08/02-23:46, 著作権について

これによれば、利用者が適法に利用することを作者として期待していると、作者は主張していることになる。

しかしここで一点、疑問がある。なぜキャッシュファイルを暗号化するのだろうか。

「違法と思われるファイルがキャッシュに入っているのに気付いた場合,削除してください」というのであれば、違法かどうか確認しやすいように、キャッシュファイルを暗号化せずにおけばよいのではないか。

さらに、キャッシュファイルのファイル名も、MD5値にせず、検索結果やダウンロード済みファイルと同じファイル名をそのまま使えばよいのではないか*1

このプログラムの開発は、ファイル交換する人のプライバシーが保護されることを意図していると考えられるが、通信は既に暗号化されているのであるから、その目的において、ファイルをさらに暗号化して流すことには、必然性がないのではないか。

キャッシュファイルは他人から直接に見られるところではないし、通信することで相手が何を持っているかを知られる可能性については、ファイルを暗号化していなくてもリスクは違わないのだから、キャッシュファイルを暗号化された状態で置く目的は、ファイル交換者のプライバシー保護ではないということになる。

また、ファイルを最初に放流したのが誰であるかが隠されるようにしたいという意図もプロジェクトの目的としてあるのだろうが、この方法でファイルを暗号化しても、それがばれるリスクは、暗号化しない場合と違わないのだから、やはり、暗号化する意図を説明できない。

私はひとりのユーザとして作者の方々にMARIEの改善案を述べたい。

  • 違法と思われるファイルがキャッシュに入っていれば削除するようにしたいので、キャッシュファイルを暗号化しない仕様に変更してほしい。
  • 違法と思われるファイルがキャッシュに入っていないか確認しやすいよう、(ダブル)「クリックしても開きませんでしたので」とならないようにしてほしい。
  • 違法と思われるファイルがキャッシュに入っていないか確認しやすいように、キャッシュファイルのファイル名を、ハッシュ値ではなく、本来の名前(+番号)+拡張子という形式にしてほしい。

もし、これらが「改善」にあたらないというのであれば、その理由を説明することはできるだろうか。

「ファイル共有」ではなく「ファイル放流」

WinnyもMARIEと同様に、キャッシュファイルを暗号化して、ファイル名もハッシュ値にしているため、違法ファイルを自分がキャッシュしていないか確認しようにも、(ダブル)「クリックしても開きませんでしたので、普通の状態では見ることも動かすもできない」ということになる。

この性質が可罰性の根拠となるかどうかは別として、この性質を aとしたとき、「同じく aという要素を有している B」を満たす Bのプログラムには、他に何があるだろうか。他にはほとんどなかったのではないか。

私は、この性質が、Winny等の特殊性を示す技術要素の最有力候補(同じ要素を有する Bがあまり存在しない)であると考える。

もちろんこれ以外にも検討すべき性質 aの候補は複数存在する(そしてそのいくつかは、検討に値しないどうでもよいものである)わけであるが、まずは、H_Ogura氏は、この最有力候補を aとした場合について議論を進めてみられてはいかがだろうか。

もし上に書いたMARIEの改善案が改善にあたらないというのであれば、なぜそのような性質を持たせる必然性があるのかについて、H_Ogura氏にも説明を試みて頂くとよいのではないか。

私はWinnyの特性を、6月8日の日記「良心に蓋をさせ、邪な心を解き放つ ―― ファイル放流システム」にて次のように書いた。

違法なファイル交換行為をする人々の心境を指して、「赤信号、皆で渡れば怖くない」が持ち出されることは多そうだが、Winnyの場合は、それだけでは説明しきれていない部分がある。

(略)

一般に、議論中にしばしば見かける「完全に○○することは不可能なのだから」という理屈。こういう主張は意味がない。なぜなら、「完全に」を冠すればあらゆる事象は「不可能」であるのが自明であり、自明のことを主張することには価値がない。つまり、「程度」こそが議論の対象たり得るのであって、それを排除した主張には存在価値がない

Winnyでは、流通の仕組みが受け取る行為と切り離せない構造になっている。受け取る行為によってファイルが拡散するのであり、各ユーザの受け取る行為のひとつひとつが流通の仕組みを支えている。しかし、ユーザはそのことを認識していない。「自分は単に受け取っているだけだ」と勘違いしている。一部の専門的ユーザは認識しているだろうが、大半は理解していない。あるいは、理解することを避けながら使っているだろう。 これはうまく作りこまれた仕掛けである。Winnyでは、5月30日の日記にも書いたように、(日本ではWinMXによる「ファイル共有」としての利用がいまひとつ普及しなかった経緯から、)ファイルを暗号化してキャッシュさせるという仕組みによって、「ダウンロードするとそれが新たな拡散に加担することになる」という事実を、ユーザに認識させにくくする工夫がなされている。

これにより、「これは他の人には見せるべきでない」と良心の働くような真に悪質な映像であっても、「これ以上拡散することは避けられるべきだ」という倫理観を持つ人でさえ、自分だけは見ておきたい(見てみたい、自分だけは見てもよいだろう、見てみないと本当に悪質かどうかわからない、見ておく必要がある)と行動することによって、当人の倫理観とは無関係に侵害規模を拡大させていく。

(略)

そこに見えるのは、自分は侵害行為に加担したくないという倫理観(あるいは安全意識)を持ちながら、自身の欲望は達成しておきたいという考え方だ。Winnyは、まさにそういう人たち向けなシステムだったと言えよう。

良心に蓋をさせ、邪な心を解き放つ ―― ファイル放流システム

また、5月30日の日記「P2Pの価値とは何なのだろうか」では、次のように書いている。

「ファイル放流システム」の誕生

これによって、Winnyは、誰か一人がファイルを一旦uploadフォルダに入れれば(後に削除しても)、あとは、人々に意識されることなくデータが拡散していくという、「ファイル共有」を超えたシステム(共有しているという意識さえ存在しにくいシステム)「ファイル放流」システムを実現してしまった。

(略)

WinMX等で、uploadフォルダとdownloadフォルダを同一にした使い方をする場合であっても、自動的にファイルが拡散していくとはいえ、まがりなりにも自分が何を送信可能化しているかを意識可能だろう。良心の呵責にさいなまれる内容のファイルが流通しているのが目に留まれば、削除するという行動をとるかもしれない。本音と建前を隔てたりせず、宗教的あるいは文化的倫理観ないし強迫観によって削除を自ら迫られる人達であれば、消してくれるかもしれない。

Winnyユーザははたしてどうだろうか。自分が何をキャッシュしているか知っているだろうか。薄々感付いていながら「明確に認知してはいない」と言い訳しつつあえて認知しようとしないとか、「自分だけ削除してもどうせ皆が削除するわけじゃないのだから自分も消さなくてよいのだ」などと正当化して、感心を持つことからさえ逃げていないだろうか。

「ファイル共有」システムではデータの拡散に人の意識が介在する。「ファイル放流」システムでは人が介入する余地がなくデータは完全に機械的に拡散してゆく*2

「どんな方法であれ、いったんネットに公開されてしまった情報は回復できない」「それはP2Pやウィニーに固有の現象でしょうか?」だの、「Winnyが無ければ情報の拡散は阻止できるのか?」だの、「メーリングリストプログラムについても同様である」だの*3と、詭弁を振り回す輩が予想通り現れてきたが、拡散に人の意識が介在する余地があるかないかが肝である。

P2Pの価値とは何なのだろうか

端的に言えば、キャッシュファイルが暗号化されていないならば「ファイル共有」システムであり、暗号化されているならば「ファイル放流」システムであるということだ。

なお、念のため述べておくと、これは、現行法で処罰の対象となるかの議論ではなく、将来の法規制のあり方、あるいは法規制とは別に、人々の倫理はどの位置に収束するだろうかという議論である。

ただ、必要のない機能をわざわざ設けたのはなぜなのか、プログラム作成・提供者の意図を問われる材料にはなるかもしれない。しかし、「たいして意図はなかった。その機能の搭載を避けることもできたであろうが、実装上の細かい都合でたまたまそういう実装を選択してしまっただけだ」という主張はあり得る……と言っておく。

不幸の手紙とチェインメールとコンピュータワーム

不幸の手紙は大昔からあった。「3日以内にこれと同じ手紙を5人に送らないと不幸になるよ」といった内容の手紙を郵送するのが「不幸の手紙」だが、「そういうことはやめなさい」といった話はあまり聞くことがなかった。

インターネットが普及し始めるとすぐに、不幸の手紙の電子メール版が軽く流行した。これは「チェインメール」と呼ばれ、後に、希少な血液型の献血を求めるという、それなりに有益性も理解できなくもないメールが、チェインメール化し、その是非が問われた。さらには、「読んだだけで感染するウイルスメールが存在するので気をつけよ」という噂のメールがチェインメール化したこともあった*2

チェインメールは比較的早い時期から、いわゆる「ネチケット」において、「絶対にやってはいけないこと」とされてきた。たとえ献血が必要であっても、すべて駄目だとされている。これに反対する人はほとんどいない。ネチケットなどという、個人の主観に左右されがちなブレブレの道徳モドキにおいて、これほどまでに全員一致で「絶対やってはいけない」とされているものも珍しい。だが、チェインメールが法律で規制されているわけではない。

そして、コンピュータワームは、次の刑法改正で新設されようとしている「不正指令電磁的記録作成等の罪」によって、その作成、提供、取得、保管が刑法によって罪悪として規定されようとしているが、多くの人はこれを是認していると思われる。(個人的には、作成罪については疑問の余地を感じるが。)

これらの間にこのような違いが生ずるのはなぜなのか、だ。

*1 同一のファイル名で異なる内容のファイルがキャッシュに溜まる場合に配慮するのであれば、通常のファイル名の後に番号を付けて、ハッシュ値との対応表で管理するという方法もある。

*2 当時、それはデマだということでデマの打ち消しに躍起になったものだが、後に、MS01-020の脆弱性の発覚とNimdaワームの登場で、現実のものとなってしまった。

本日のTrackBacks(全100件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20040814]
検索

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

最近のタイトル

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|
<前の日記(2004年08月12日) 次の日記(2004年08月15日)> 最新 編集