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

高木浩光@自宅の日記

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

2004年08月16日

ソフトウェア科学会大会でP2Pのチュートリアルとパネル討論

日本ソフトウェア科学会第21回大会の併設チュートリアルで、「P2P コンピューティング−基盤技術と社会的側面−」というのがあるもよう。

概要: 日本ソフトウェア科学会では,最近大きな話題を集めているP2P(Peer-to-Peer)コンピューティングについて、チュートリアル「P2Pコンピューティング −基盤技術と社会的側面−」を開催いたします。

本チュートリアルでは、P2P コンピューティングの基礎から最新の技術・研究動向の解説に加えて、P2P技術に関わる社会・法律面の基礎や問題点に関しても解説が行われます。また、講演による解説の後にパネルディスカッションを開催し、今後 P2P 技術をどのように発展させていくべきかを参加者と一緒になって議論することで、P2Pコンピューティングに対してより深く理解することを目指します。

日時: 2004年9月14日 13:00〜17:00

P2P コンピューティング−基盤技術と社会的側面−

フォローアップ1

一昨日の日記「キャッシュと嘘とファイル放流」に対して、トラックバック付きでコメント頂いた点について、まずは簡単なことだけ指摘を。

BENLI」の「キャッシュと暗号と幇助」の中で、事実関係について次の仮定がおかれている。

逆に、Winnyを違法ファイルを「放流」するためのシステムとして位置付けたときは、却って、キャッシュファイルを暗号化しないような仕様にするのではないかという気がします。このような仕様であれば、アップロード用のフォルダに暗号化されていない違法ファイルが蔵置されていた場合に、そのコンピュータの使用者が積極的にその電子ファイルを送信するためにアップロード用のフォルダに蔵置したのか、キャッシュファイルとして知らない間に自動的に生成されてしまったものか区別が付かない方が都合がよいからです。

そう考えると、(略)

BENLI, キャッシュと暗号と幇助

「暗号化しない仕様の方が、Upフォルダに置いているのか、単にキャッシュにあるのかの区別がつかなくてよい」とのことであるが、理由がない。

Winnyの場合、Upフォルダに置かれたファイル(放流用の原本なので暗号化されていない)は、他のノードからの要求によって通信路を流れ出ていくときに、自動的に暗号化されるようになっている*1。(暗号化はそのときに一度行われるのみで、あとはそれがそのままキャッシュファイルとなり、コピーされていく。)

接続された他のWinnyノードのコンピュータから見ると、受信しているデータが、相手ノードのキャッシュから取り出しているものなのか、それとも、相手ノードのUpフォルダから暗号化と同時に取り出しているのかは、区別できない。そのようにプロトコルが設計されている。

よって、外部から見る限りにおいては、キャッシュファイルを暗号化した状態で置くか、暗号化しない状態で置くかは、「区別が付かない方が都合がよい」ということに関係しない。

内部から見た場合についてまで言及されているのか、わからないが、一応検討してみると、内部から見た場合を心配するというのは、捜査員にパソコンを押収されたときのことであろう。Upフォルダにファイルが入っているなら、それは暗号化の有無に関係なく、そこにファイルが入っているのはあきらかである。

それを防ぐためにUpフォルダを廃止するという設計もあり得る。この場合、直接キャッシュに原本ファイルを投げ込むことになる*2が、このとき、キャッシュファイルを暗号化しておくなら、暗号化して投入することになるし、暗号化しないでおくなら、そのまま投入することになるだけであり、暗号化の有無が設計に影響を及ぼさない。

よって、暗号化の有無は「区別が付かない方が都合がよい」ということに関係しない。


次に、「NetWind」の「高木氏が答えていない点。」において、次のように書かれている。

高木氏が求めていることは、(略)他人が「放流」したものであっても、自分の計算機に放置されたもので削除すべきものは削除しなければならないというモラルを持っているように思えるからである。

NetWind, 高木氏が答えていない点。

そのようなことは言っていない。MARIEの作者が、「違法と思われるファイルがキャッシュに入っているのに気付いた場合,削除してください」と言っているので、ならば暗号化しなければよいのではないか? と言っているのであり、逆に、「違法と思われる……場合,削除してください」と注意書きするのを取り止めるという選択肢もある。(その場合は、なぜ当初その注意書きをしていたのかが議論の対象となる。)

私は、できるだけ価値に対して相対的な書き方となるよう心がけているつもりだ。ある背景を前提としたときに、いくつかの事実に基づいた分析を加えて推論すると、こういう結果が導かれる――ということの積み重ねをしているだけだ。積み重ねからどのような方向性を感じ取るかは読者しだいであり、当然ながら他の主張と結合されたうえで判断されるだろう。また、私自身がそうした読者と同じ位置で方向性を模索しているところである。

そういう基本的なことを理解していない人とは議論するに値しない。


次に、「6"(ログ)」の「知財ウォッチ」では次のように書かれている。

誰かがWinnyに簡単な機能追加を施すとします。それは、ファイルを未暗号化状態で放流することもできる、という機能です。(略)

そして、あくまで仮定ですが、もしデータの大部分、あるいはある程度大きな量が暗号化状態で流通すると仮定すると、結果として現れる著作権侵害事態は現行Winnyと基本的に何も変わりません。

(略)

暗号化と中継を別レイヤと考えれば、単なる中継は特殊な機能でも何でもなく、NetNewsやIRCでも可能なことです。実際、暗号化されたファイルをNetNews等で放流されれば、中継ノードの管理者はその中身を見ることはできませんね。もちろん中身を見ずに一律削除することなら可能ですが、それならWinnyでもできます。

6"(ログ), 知財ウォッチ

機械的動作はその通りだが、実際には、そのような利用方法が人々の間に普及しないからWinnyが作られたのだろうから、そんな話をして「何も変わりません」などと主張しても意味がない。

47氏が書いたとされている2ちゃんねるでの書き込みを引用しておく。(5月30日の「P2Pの価値とは何なのだろうか」でも既に引用しているのだが。)

117 名前:47 投稿日:02/04/16 15:18 ID:mPL0z40j
Winnyはぶっちゃけたこと言えば、必ず串経由でMX使って
ファイルは自分で全部暗号化してファイル名を適当なルールつけて
そのままじゃ中身が分かり難くしてやり取りするという文化が広まれば
今のMXそのまま使えばいいんですけど、そうはならんだろうから
それを目指した専用ツールを作ろうってことですね。 

*1 もしくは、Upフォルダに新しいファイルが見つかると、暗号化して自分のキャッシュに投入する――という方式になっている可能性もある。

*2 メニューの「開く」でファイルを選択してキャッシュに投入するというユーザインターフェイスが考えられる。

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

Adderall xr side effects. Adderall xr. Adderall.

検索

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

最近のタイトル

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