Freenet のプラグインを作ろう: HelloWorld プラグインの作成

はじめに

最近 Freenetプラグインを書く必要に迫られ情報収集をしている。しかし開発に当たって必要な情報が英語でも日本語でも纏まっていない印象なのでここに記しておく。

Freenet はインターネット検閲に対抗するため匿名でのコミュニケーションを実現する P2P 型システムである。ユーザーからは分散型のストレージのような感じで使える。そしてそのストレージ機能を利用して匿名メールや匿名掲示板のようなものを実現するプラグインが開発されている。

今回は公式 Wikiチュートリアル に則って簡単な HelloWorld プラグインを作成する。

ソースコード

HelloWorld.java

/**
 * 参考: https://wiki.freenetproject.org/Plugin_API
 */

import freenet.pluginmanager.*;
import java.util.Date;

public class HelloWorld implements FredPlugin {
    private volatile boolean goon = true;

    /* Freenet の API にアクセスするためのオブジェクト */
    PluginRespirator pr;

    /* プラグインがアンロードされた時に呼ばれる */
    public void terminate() {
        goon = false;
    }

    /* プラグインがロードされた時に呼ばれる */
    public void runPlugin(PluginRespirator pr) {
        this.pr = pr;

        while (goon) {
            /* 標準エラーへの出力は wrapper.log ファイルに吐かれる */
            System.err.println("Heartbeat from HelloWorld-plugin: " + (new Date()));
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                // Who cares ?
            }
        }
    }
}

manifest.mf

※ jar を作るときに生成されるマニフェストファイルへ追記する設定。Freenetプラグインのエントリーポイントを知らせる。

Plugin-Main-Class: HelloWorld

ビルド

Freenet のインストールフォルダー (Windows でのデフォルトは AppData\Local\Freenet) に freenet.jar があるはずなので、クラスパスとして指定しつつビルドする。また jar 作成時にマニフェストファイルも指定する。

javac -cp path\to\freenet.jar HelloWorld.java
jar -cvmf manifest.mf HelloWorld.jar HelloWorld.class

実行

Freenet の Web インターフェースにアクセス (localhost:8888 あたり) し、上部の「設定」タブから「プラグイン」に移動、下部の「非公式プラグインを追加」で作成した HelloWorld.jar を指定してロードする。

AppData\Local\Freenet\wrapper 付近にある wrapper.log というファイルを見ると以下のような出力が確認されるはず。

INFO   | jvm 1    | 2014/12/14 02:31:56 | Downloading plugin path\to\HelloWorld.jar
INFO   | jvm 1    | 2014/12/14 02:31:56 | Heartbeat from HelloWorld-plugin: Sun Dec 14 02:31:56 JST 2014
INFO   | jvm 1    | 2014/12/14 02:31:57 | Heartbeat from HelloWorld-plugin: Sun Dec 14 02:31:57 JST 2014

プラグインのアンロードは「Plugins currently loaded」から HelloWorld プラグインを見つけて「アンロード」ボタンを押す。

まとめ

WebRTC を使った P2P ファイル共有ソフトは違法か

概要

WebRTC を使った P2P ファイル共有アプリケーションを公開することは果たして著作権的に違法なのかどうかというお話です。

※ 私は法律全般に関して素人です。本記事はそれを踏まえてお読みください。

詳細

WebRTC によってお手軽に Web ブラウザー間で P2P 通信を行えるようになりました。P2P 型のソフトウェアといえばファイル共有ソフトが代表的ですが、このファイル共有ソフトはこれまで著作権を侵害するようなファイルの交換に多く利用されてきたという歴史があります。

国内外を問わずこれまで P2P ファイル共有ソフトを作成した人に対する著作権侵害の訴訟は多く行われてきました。そこで今回はそれらの事例を踏まえながら、昨今登場した WebRTC を使った P2P ファイル共有ソフトを作って公開することは果たして違法なのかどうかを検討したいと思います。

事例 1: ナップスター事件

ナップスターP2P ファイル共有ソフトとして最も初期のものです。ナップスターも例に漏れず多くの違法ファイルの交換に利用され、1999 年にレコード会社がナップスター著作権侵害カリフォルニア地裁に提訴し、最終的に 2001 年の控訴審ナップスター側が敗訴しています。

ナップスター敗訴の理由としてそのアーキテクチャーが関わっています。ナップスターはハイブリッド P2P と呼ばれ、中央サーバーにそれぞれのユーザーが公開しているファイルのファイル名がインデックスされています。ユーザーは中央サーバーに「自分が欲しいファイルを誰が持っているか」を問い合わせ、その応答をもとにファイルを持っている人にダウンロードのアプローチをかけます。

このアーキテクチャーの場合、中央サーバーには「どのようなファイルが流通しているか」の情報が集約されます。つまり違法ファイルが大量に流通している場合、中央サーバーを運用している人はそのことを把握しているはずだと見なされます。そしてそれを知っていながらサーバーの運用を続けた場合、著作権侵害の幇助になり得るようです。

※ ただしこの判決は米国でのものだという点に注意

事例 2: グロックスター事件

これに対してグロックスターはピュア P2P と呼ばれるアーキテクチャーを取るファイル共有ソフトです。ピュア P2P はハイブリッド P2P とは違いファイル名をインデックスする中央サーバーを持たず、その役割は P2P ネットワークに参加しているユーザーが担います。

このアーキテクチャーの場合グロックスターを配布している人はどのようなファイルがネットワークに流通しているかについて管理できません。よって著作権侵害の幇助を問いづらそうです。事実、グロックスターも米国で裁判が行われましたが、一審二審はグロックスター側が勝訴しました。

しかし最高裁では判決が逆転し、グロックスター側が敗訴しました。その理由として、グロックスターを配布するときの態度が問題だったということです。グロックスターの配布者は「グロックスターを使えば有名な音楽にアクセスできる」と宣伝したり、ユーザーからの著作物の探し方などの質問に答えていたりしたそうです。このような態度により「そそのかし」の責任を問われ、敗訴のひとつの原因になったようです。

※ これも米国の事例

事例 3: ファイルローグ事件

日本の例を見てみましょう。ファイルローグはナップスターと同様に中央サーバーを立てるハイブリッド P2P 型のソフトウェアであり、MMO 社によって開発されました。

日本ではカラオケ法理という判例著作権侵害裁判でよく参照されるそうですが、ファイルローグ事件もカラオケ法理に照らし合わせた結果、違法という判決になりました。

理由として、やはり中央サーバーを立ててファイル名を管理していること、そしてあまりにも違法ファイルの流通の割合が高かったことが挙げられています。

事例 4: Winny 事件

そして有名な Winny 事件です。Winnyグロックスターと同じく中央サーバーを立てないピュア P2P 型のソフトウェアです。

Winny は 2004 年の京都地裁に始まり最高裁まで争いましたが、2011 年に Winny 側の逆転勝訴で幕を閉じました。

Winny 側勝訴の理由として、配布時に著作権侵害の用途に利用しないことを再三注意していたことが挙げられています。これにより作者に著作権侵害幇助の意図がなかったと判断されたようです。

では WebRTC はどうか

これまでの事例をまとめると、 作者に著作権侵害の意図がないことを前提として

  1. 中央サーバーを持たない ピュア P2P 型であること
  2. 違法行為に用いないことを注意し続けること

が重要なポイントであることが分かります。

さて WebRTC では一般的に相手と通信を始めるためにシグナリングサーバーが必要になります。シグナリングサーバーは「誰がネットワークに参加しているか」を管理していると言えます。

普通は「誰が参加しているか」だけでその人が違法ファイルをやり取りしているかは判断できないので、一般的な感覚ではそれを理由に違法だと判断されることはないように思います。

まとめ

作成した P2P ファイル共有ソフト著作権侵害に問われないようにするためには

  • 中央サーバーを持たない ピュア P2P 型であること
  • 違法行為に用いないことを注意し続けること

そして何より

が重要である

参考

P2P の視点で見たポータブル Web アプリケーション

概要

ポータブル Web アプリケーションと P2P アプリケーションの相性についてのお話です。

詳細

先週くらいに Heroku Button という Heroku へのデプロイを簡単にするツールが発表されました。Heroku Button により GitHub で公開しているアプリケーションを他人に動かしてもらうのがより手軽に行えるようになりました (こんなふうに)。

こういう「作った Web アプリケーションを人に渡しやすくするツール」としては Heroku Button の他にも Docker といったものが登場しましたが、このポータブル Web アプリケーションの流れは P2P アプリケーション、特に「一部のノードがサーバーの役割を果たすタイプの」P2P アプリケーションにとても都合がよいのではないかと思います。

「一部のノードがサーバーの役割を果たすタイプの P2P アプリケーション」とは例えば P2P 匿名掲示板である新月 のようなものです。新月のネットワークは掲示板の書き込みを受け付けて他のノードと同期するノード群と、書き込みを閲覧するだけのノード群がいます (参考: 新月の紹介)。

この種のアーキテクチャーをとる P2P アプリケーションでは書き込みを受け付けるノードがたくさんいるかどうかがサービスの性能に大きく関わってくるのですが、新月の場合は書き込みを受け付けるノードを動かすには基本的に自宅サーバーを立てねばならず、一方閲覧するだけなら Web ブラウザーだけでできてしまいます。

このため大抵の人は「閲覧するだけのノード」として参加することを選択してしまい、何も対策を取らなければ増加するユーザー数に対してシステムの性能が追い付かなくなってしまいます。

そこで今回の Heroku Button のような、ノードを動かすための障壁を低くしてくれるようなツールはこの種のアーキテクチャーをとる P2P アプリケーションにとって助けになります。今まではノードを動かすのに手間がかかっていたのがボタン一発でクラウド上でノードを動かせるようになれば、システムの負荷分散に貢献してくれるノードが増えやすくなるのではないかと思います。例えば作った P2P Web アプリケーションのトップページに Heroku Button を設置するとかするとおもしろいのではないでしょうか。

とりとめのない話

ポータブル Web アプリケーション とか Immutable Infrastructure が真に力を発揮するのって、それらが通信することでシステムを形作る P2P 型のアーキテクチャーにおいてではないだろうか。ネットワークシステムでは全体の性質を決めるのは個々のノードの性質よりむしろ「ノードの繋がり方」らしいし (水分子の性質は水素原子と酸素原子を個々に眺めても分からないとか)、個々のノードは単純極まりないセルオートマトンライフゲームに生命の神秘を見出すという人もいるらしい。「繋がり方」でサービスを表現するインフラとはどんなものになるだろうか。

まとめ

  • Heroku Button や Docker でポータブル Web アプリケーション

  • P2P Web アプリケーションには Heroku Button つけよう

  • ポータブル Web アプリケーションに P2P の要素を絡めて新しい何かが生まれそう

参考

Heroku Button で webrtc-bbs を容易にデプロイできるようにした

概要

Heroku Button という便利ツールが提供されるようになったので P2P 匿名掲示板 webrtc-bbs をそれに対応させてみました。

詳細

Heroku Button というツールが Heroku のブログで発表されています

Heroku Button に自分の GitHub 上のプロジェクトを対応させれば、「他の人にそのプロジェクトを Heroku にデプロイしてもらう」といった作業がとても簡単になります。

今回、この Heroku Button に WebRTC を使った P2P 型分散匿名掲示板 webrtc-bbs を対応させてみました。

例えば以下のボタンを押すと、その人の Heroku アカウントで webrtc-bbs をホスティングすることができます。

Deploy

ボタンを押すと Heroku へのログイン画面の後、アプリケーションの名前等を入力してデプロイする画面が表示されます。そこでデプロイボタンを押せば作業は完了します。簡単。

自分のアプリケーションを Heroku Button に対応させる手順は以下の通りです。

まとめ

  • Heroku Button に webrtc-bbs を対応させた

  • Heroku Button でますます広がるポータブル Web アプリケーション

  • この流れは P2P 型アプリケーションに実にマッチしている (この話は次回)

P2P ファイル共有の発展の鍵は経済学にある

未開社会の経済

アマゾン奥地に見られる未開社会では人々は狩猟により得られた獲物を分け合い生活している。食糧の分配は狩りで獲物を仕留められなかった者や狩りに出なかった者を問わず皆平等に行われる。しかし狩りは常に危険が伴うため、なるべく狩りに出ずに食糧を分け与えてもらおうとする者が現れる。ところが全員が狩りをやめてしまい、やがて食糧が尽きてしまうといったことは起こらない。なぜなら彼らの社会では狩りで獲物を仕留めた者は英雄として称えられ、逆に狩りに出ずに獲物を分け与えてもらってばかりいる者は相応の不名誉を被るからである。

Winny に見られる P2P ファイル共有ネットワークでは人々はファイル交換によって得られたファイルを分け合い生活している。ファイルの交換は頻繁にアップロードしている者やダウンロードに徹する者を問わず皆平等に行われる。しかし違法ファイルのアップロードは常に危険が伴うため、なるべくアップロードせずにダウンロードに徹しようとする者が現れる。ところが全員がアップロードをやめてしまい、やがてファイルの供給が尽きてしまうといったことは起こらない。なぜなら彼らの社会では需要の高いファイルをアップロードした者は ネ申 として称えられ、逆にダウンロードに徹する者は相応の不名誉を被るからである。

ものを交換する経済

経済が発展すると、人々はものを交換することを始めた。ものを効率的に生産するには分業が欠かせない。彼らは自分の得意とするものを生産することに専念し、自分で生産できないものはそれを生産している誰かを見つけ自分の生産物と交換することで得ることができた。

P2P ファイル共有が発展すると、人々は BitTorrent でファイルを交換することを始めた。ファイルを効率的に交換するにはファイルをピースに分割した上での分業が欠かせない。彼らは自分の持っているピースをアップロードし、自分の持っていないピースはそれをアップロードしている誰かを見つけ自分のピースと交換することで得ることができた。

貨幣の経済

さらに経済が発展すると今度は貨幣が登場した。貨幣はものの価値を統一的な尺度で測ることができ、さらにものを貨幣に換えて保存しておくことによって時間を超えてものの交換が行えるようになった。これによりものの交換はさらに広い範囲で行われるようになり、やがて市場が形成されるようになった。

さらに P2P ファイル共有が発展すると今度は貨幣が登場した。貨幣はファイルの価値を統一的な尺度で測ることができ、さらにファイルを貨幣に換えて保存しておくことによって時間を超えてファイルの交換が行えるようになった。これによりファイルの交換はさらに広い範囲で行われるようになり、やがて市場が形成されるようになった。

これまでの経済、これからの P2P

貨幣が登場すると商人が現れる。商人は地理的に離れた社会を行き来し、ものの価値の違いを利用して利益を得る。また貨幣を金利を付けて貸し出す銀行や、インフレ/デフレをコントロールするための経済政策、あるいは労働の対価として賃金を得る労使関係が生まれた。経済に関する思想もいくつも生まれた。

これからの P2P ファイル共有はどのように発展していくだろうか。現時点では経済の歴史における貨幣が生まれた年代にいる。それから経済は幾度も進化を遂げ、複雑怪奇なメカニズムを生み出した。この歴史をなぞるように P2P ファイル共有が進化していくとするならば、その進化をもたらすのは情報科学と経済学の両方に通じた人なのだろう。

参考

PeerJS でコネクションプールを実装した webrtc-connectionpool を公開しました

概要

WebRTC の定番ライブラリ PeerJS を使ってコネクションプールを実装した webrtc-connectionpool を公開しました。

tsujio/webrtc-connectionpool - GitHub

詳細

WebRTC のデータチャンネルはコネクション指向の通信インターフェースであり、コネクションを確立するためにはシグナリングサーバーによる SDP/ICE メッセージの中継が必要になります。

これでは例えば不特定多数の人とデータチャンネルでやり取りする場合に毎回コネクションを確立したりコネクションを大量に保持しすぎたりといった状況が発生し、パフォーマンスが心配になってしまいます。

そこで確立したコネクションを再利用できるように一定期間保持し、かつ保持するコネクション数を調節できるようにした webrtc-connectionpool を実装し公開しました。

特徴としては以下の通りです。

  • WebRTC ライブラリとして PeerJS を利用している
  • 一旦確立したコネクションは一定期間保持し、再利用される
  • 保持するコネクション数はパラメーターとして指定可能
  • コネクションが最大保持数を超えた場合は LRU 方式で破棄される

また、コネクションプール機能以外にもデータの送信とコネクションのクローズが重なった場合の対処など、webrtc-chord で得たノウハウが詰まったライブラリとなっております。

使い方

こんな感じで使えます。

セットアップ

// Setup
var connectionFactory = new ConnectionFactory({
  // An object to pass to the Peer constructor.
  // See the PeerJS document for details.
  peer: {
    id: 'yourid',
    options: {
      host: ...,
      ...
    }
  },

  // The capacity of the connection pool.
  connectionPoolSize: 10 
});

connectionFactory.onopen = function(myPeerId) {
  console.log("Setup ConnectionFactory: " + myPeerId);
};

connectionFactory.onconnection = function(connection) {
  console.log("Connection from " + connection.getRemotePeerId());

  connection.ondata = function(data) {
    console.log("Received data: " + data);
  };

  connection.onerror = function(error) {
    console.log("ERROR: " + error);
  };
};

connectionFactory.onerror = function(error) {
  console.log("ERROR: " + error);
};

コネクションの生成とデータの送信

// Create connection and send data
connectionFactory.create(peerIdToConnect, function(connection, error) {
  if (error) {
    console.log("Failed to create connection: " + error);
    return;
  }

  connection.ondata = function(data) {
    console.log("Received data: " + data);
  };

  connection.onerror = function(error) {
    console.log("ERROR: " + error);
  };

  connection.send(data);
});

まとめ

  • PeerJS でデータコネクションをプールするライブラリを書いた

  • 不特定多数の人とコネクションを張る時に使えます

  • WebRTC を使って大規模な P2P ネットワークを張るサービスを作ろう

P2P 匿名掲示板 webrtc-bbs で伝えたいこと

概要

先日 WebRTC を用いた P2P 型分散匿名掲示板 webrtc-bbs を公開しましたが、これについて私が思っていること、伝えたいことを文章の形で表現してみます。

P2P の悪いイメージ

Peer-to-Peer (P2P) といえばまず思いつくのがファイル共有ソフトです。P2Pアーキテクチャーは大容量のファイルの交換に適している一方、その匿名性ゆえにしばしば著作権を侵害するようなファイルの交換に利用されてきたことは周知のことかと思います。

日本で最も有名なものは金子勇さんによる Winny でしょう。Winny も他の P2P ファイル共有ソフトの例に漏れず、「例外的とはいえない」数のユーザーにより著作権侵害ファイルの交換に利用されました。

その結果、作者の金子さんは著作権侵害行為の幇助の罪で起訴され、およそ 7 年の間検察を相手に法廷で争うことになりました。そして 2011 年、金子さんに著作権侵害幇助の意図はなかったことが最高裁により認められ、裁判は無罪判決で幕を閉じました。

しかし現状として「P2P に関わると逮捕される」「サービスに P2P 技術を導入していることは伏せるべき」さらには「P2P 即ち悪」といった価値観、イメージが P2P に対して定着してしまっていることは否定できないと思います。そしてそれにより P2P で何かを表現したい若者が気後れしてしまい、その機会を失ってしまっている のではないかと思います。

P2P は夢と自由の技術である

確かに著作権を侵害する行為は罰せられるべきですし、Winny は作者の意図に反してその温床となってしまいました。

しかし、Winny や他の P2P ソフトには未来に繋げるべき素晴らしい技術、教訓があるということも事実だと思います。

P2P に見る夢

私たちがインターネットにおいて何かサービスを提供しようとする場合、その多くはクライアント/サーバー型のアーキテクチャーで実現されます。サービス提供者はクライアントをまかなうためのサーバーを用意する必要があり、サービスが大規模になると必然としてサーバー、ネットワーク設備への投資も大きくなりがちです。

これでは学生や非営利の団体のような経済力の大きくない開発者にとって、サービスのアイデアはあっても金銭的な問題によりそのアイデアを諦めなければならない場面が少なからずあると予想されます。

しかし Winny の例を見てみますと、ACCS の調査 によると 2007 年では 30 万のノードがファイル交換に参加していたことが分かります。30 万のノードが同時に大容量のファイルを交換するサービス。これを金子さんは 何も特別なインフラを保持せずに 展開していたのです。

P2P でなら設計次第で世界中で利用されるサービスを安価に展開できる」という夢を、Winny は私たちに示してくれています。

P2P に見る自由

インターネットは誰にでも自由な情報発信の機会を与えてくれますが、時としてその自由な表現が一部の権力によって規制されてしまうことがあります。そしてそれは常に外国で起こっていることばかりではなくて、日本でも 2008 年の青少年ネット規制法、2013 年の特定秘密保護法などインターネットを規制する動きは存在しています。

「自由」はとても難しい問題です。私自身もまだ確かなことを語ることはできませんが、それでも伝えたいことは、表現の規制や検閲が一部の権力によって行われるのは望ましくないのではないか ということです。

P2P では表現の場はそこにいる人たちで作り上げられます。一部のサーバーを停止させれば場は失われるといったことはなく、「不当な」規制、検閲に対抗できる力を持っています。そして 規制や検閲は場を構成する人たち自身により行われるべきである というのが、今私が考え、試行錯誤していることです。

P2P は自由を表現する力を備えているとともに、真の自由について考えさせてくれる技術です。

まとめ

  • P2P ってとても楽しい

  • 自由ってとても難しい

  • Winny の件は我々に夢と勇気を与えてくれる

参考