tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 18944 

3) # Last-Translator: buyoppy@yahoo.co.jp
4) 

5) #include "head.wmi" TITLE="Tor: ボランティア" CHARSET="UTF-8"

6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->

10) <h2>今すぐに誰にでもできるいくつかのこと:</h2>

11) <ol>

12) <li>私達のTorネットワークを成長させるために<a href="<page docs/tor-doc-relay>">リレーを運用する

13) </a>ことをご検討ください。</li>

14) <li>あなたの友人にも伝えてください！彼らにもリレーを運用し、またはヒドゥンサービスを

15) 運用するように、そして彼らの友人にそれを伝えるように伝えてください。</li>

16) 
17) <li>もしあなたがTorの目的に賛同なさるなら、

18) <a href="<page donate>">Torの開発に対してより深くサポートするために貢献してください</a>

19) 私たちはより多くのスポンサーも求めていますー
20) もしあなたが匿名性/プライバシー/コミュニケーションの安全性を望んでいる
21) 会社、NGO、機関、その他の組織を
22) ご存知なら私たちに知らせてください。</li>
23) 
24) <li>私たちはより多くの<a href="<page torusers>">Torのよいユーザ例および使用例</a>
25) 探しています。もしあなたがこのページにまだ書かれていないようなシナリオや目的の
26) ためにお使いなら、もし差し支えがなければそれを私たちにも知らせて頂けると幸いです。

27) </ol>
28) 
29) <a id="Usability"></a>
30) <h2><a class="anchor" href="#Usability">補助アプリケーション</a></h2>
31) <ol>
32) <li>匿名になろうとしているときに、これに反してDNSリクエストがその内容を

33) ローカルの盗聴者に"リーク"してしまわないようにそれらを遮断するするよい方法を探しています。
34) (アプリケーションがSOCKSプロキシに到達する前にDNS解決を行うために起こることです。)
35) </li>
36) <li>tsocks/dsocksアイテム:

37) <ul>
38) <li><a

39) href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">

40) tsocksパッチを当て</a>、新たな子プロジェクトを管理する必要があります。
41) もし必要なら私達が新プロジェクトをホスティングします。</li>
42) <li>Torの<i>mapaddress</i>コマンドをコントローラインターフェースから使えるように

43) するためDug Songの"dsocks"プログラムにパッチを当てる必要があります。
44) これによって接続前に一通り名前解決を行う作業をTor内部で無駄にせずに済みます。</li>
45) <li>

46) <li>tsocksとdsocksのどちらがインストールされているのかを検知し、
47) 適切にそれらを呼び出す<i>tor化</i>スクリプトを作る必要があります。
48) このためには、恐らくインターフェースを統一したうえで、それらの間で
49) コードを共有するようにするか、またはどちらか一方を完全に捨て去ること
50) も必要になるかも知れません。</li>
51) </ul>
52) </li>

53) <li>リレーを運用している人々は私達に対して、一日のうちのある時間帯だけに

54) ある帯域レートを適用し、残りの時間帯には別の帯域レートを適用したいという

55) 要望をしてきます。これをTorの内部でコーディングするよりも、<a href="<page gui/index>">
56) Torコントローラインターフェース</a>を通じて動作し、帯域レートを変更するための設定を
57) 行う小さなスクリプトがあったほうがいいでしょう。UnixおよびMac用のものは
58) すでにあります(それはbashとcronを使用しています)が、Windowsユーザについては
59) 依然として解決が求められています。
60) </li>
61) <li>地理位置データについて言えば、誰かがTorリレーの位置を表す世界地図を

62) 描く必要があります。ネットワークが成長し変更されるにつれ情報が自動的に
63) アップデートされるものなら、なお良いです。残念ながら、
64) これを実現する最も簡単な方法は、全てのデータをGoogleに送信して地図を描いて
65) もらうことになってしまいます。この方法がプライバシーに与える影響はどの程度の
66) ものでしょうか？あるいは他にもっといい選択肢があるでしょうか？</li>
67) </ol>
68) 

69) <a id="Advocacy"></a>
70) <h2><a class="anchor" href="#Advocacy">支援運動</a></h2>
71) <ol>
72) <li>Creative Commonsライセンスの下、コミュニティのロゴを作ってすべての人々がそれを使用し
73) またそれを変更できるようにすること。</li>
74) <li>世界中のユーザグループミーティングで使用できるようなプレゼンテーションを作成すること。</li>
75) <li>あなたが推薦するTorの使い方についてのビデオを作成すること。これは一部ですでにSeesmicで
76) 作成が始まっています。</li>
77) <li>「自由のためにTorを使おう！」といったような、
78) 単一のまたはいくつかの主題についてのポスターを作成する。</li>
79) </ol>
80) 

81) <a id="Documentation"></a>
82) <h2><a class="anchor" href="#Documentation">ドキュメント</a></h2>
83) <ol>

84) <li>Matt Edmanが自身の作ったTorコントローラ
85) <a href="http://vidalia-project.net/">Vidalia</a>

86) のためのドキュメントおよびhow-toを書くのを手伝ってください。</li>

87) <li>Torを使用するために使用できる
88) <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">私達のプログラムリスト
89) </a>にあるプログラムを使ってみて結果を報告してください。</li>

90) <li>私達は動的に接続を遮断してそれをTorを通して送信することについてのよりよい
91) ドキュメントを必要としています。私達の新しいTransPort機能のよりよい使用法に
92) ついてもそうですが、tsocks (Linux), dsocks (BSD),freecap (Windows)
93) がよい候補として挙げられるでしょう。</li>

94) <li>
95) <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">

96) Torの有用なインターフェースとなりうるプログラム</a>の巨大なリストがあります。
97) どのプログラムがどういった状況で使えるでしょうか？それらをテストして
98) 結果を報告してください。</li>
99) <li>ウェブページおよびドキュメントを他の言語に翻訳するのを手伝ってください。
100) 手伝ってくださる方は<a href="<page translation>">翻訳ガイドライン</a>

101) をご覧ください。検閲が行われている地域に住む多くのTorユーザのために、
102) 特にアラビア語またはペルシア語の翻訳を特に必要としています。
103) </li>

104) </ol>
105) 
106) <a id="Coding"></a>

107) <a id="Summer"></a>
108) <a id="Projects"></a>
109) <h2><a class="anchor" href="#Projects">Good Codingプロジェクト</a></h2>
110) 
111) <p>
112) これらのプロジェクトのうちのいくつかが<a href="<page
113) gsoc>">Google Summer of Code 2009</a>用のよいアイディアになると思われる
114) かも知れません。私たちはそれぞれのアイディアについて、それがTorプロジェクト
115) 全体にとってどの程度役に立つか(優先順位)、それを実現するために
116) どの程度の作業を要すると予想されるか(作業レベル)、どれだけの手掛かりから
117) 作業を始めなければならないか(スキルレベル)、私たちの<a href="<page
118) people>#Core">中心的開発者たち</a>のうちの誰がそれに助言をしたらいいかに
119) よってラベル付けを施しました。もしこれらのアイディアのうちの一つまたは
120) いくつかが有望だと思われた方は、分りにくい用途を送り付けるよりもむしろ
121) あなたの計画について議論を交わすために<a href="<page contact>">ご連絡ください</a>。
122) あなた自身のプロジェクトのアイディアを提案してくださっても構いません。その方が
123) 往々にして最善の用途となることが多いものです。
124) </p>
125) 

126) <ol>

127) 
128) <li>
129) <b> Linux/Mac OS X向けTorブラウザバンドル</b>
130) <br />
131) Priority: <i>High</i>
132) <br />
133) Effort Level: <i>High</i>
134) <br />
135) Skill Level: <i>Medium</i>
136) <br />
137) Likely Mentors: <i>Steven, Andrew</i>
138) <br />
139) TorブラウザバンドルにはTor、Firefox、Vidaliaユーザインターフェース(そして
140) オプションでPidgin IM)が含まれます。コンポーネントは安全に操作できるように
141) 予め設定されており、インストール先のOS上でほんの少しの依存性しか持ちません。
142) そのためこのバンドルはWindows上でTorを利用するための方法のうちで最も
143) 使いやすくて人気のあるものとなっています。
144) <br />
145) しかしながら、LinuxやMac OS Xのためのこれと同等のパッケージは今のところ存在
146) していません。そこでこのプロジェクトではこれらのプラットフォームのためにTor
147) ブラウザバンドルを実装することになるでしょう。この作業には、Vidalis(C++)および
148) 恐らくはFirefox(C)にも変更を加え、可搬性を評価するために一定の範囲のOSバージョン
149) についてランチャを作成してテストすることが含まれるでしょう。
150) <br />
151) 生徒諸君はLinuxまたはMac OS Xのうちのどちらかまたは両方でのアプリケーション
152) 開発に習熟していなければならず、C/C++およびシェルスクリプトに慣れ親しんで
153) いなければならない。
154) <br />
155) このプロジェクトの一部にはTorブラウザバンドルの利便性テストー理想を言えば
156) 私たちがターゲットとしている層におけるーが含まれるかも知れません。
157) それはバグフィクスないし新機能の方面で何が必要とされているのかを知るのに
158) 大いに役立つでしょう。当面のところこれは非公式のものとしておきますが、
159) より構造化されたプロセスとするほうがよいでしょう。
160) </li>
161) 
162) <li>
163) <b>私たちのウェブサイトのための翻訳wiki</b>
164) <br />
165) Priority: <i>High</i>
166) <br />
167) Effort Level: <i>Medium</i>
168) <br />
169) Skill Level: <i>Medium</i>
170) <br />
171) Likely Mentors: <i>Jacob</i>
172) <br />
173) Torプロジェクトはここ数年の間、ボランティアが私たちのアプリケーションを
174) 他の言語に翻訳するのを助けるウェブベースのツールをセットアップするために
175) 作業を続けてきました。最終的に私たちはPootleに行きあたりました。これを
176) 使えば、Vidalia、Torbutton、Torcheckのためのウェブベースの翻訳エンジンを
177) 使えるようになります。しかしながら、Pootleは"po"形式のファイル内の文字列
178) しか翻訳できない一方、私たちのウェブサイトはwmlファイルを使用しています。
179) このプロジェクトは私たちのwmlファイルをpo文字列へと変換および逆変換する
180) 方法を見付けてそれらがPootleによって扱えるようにすることについてのものです。
181) </li>
182) 
183) <li>
184) <b>Torネットワーク全体のステータスを追跡記録するのを助ける</b>
185) <br />
186) Priority: <i>Medium to High</i>
187) <br />
188) Effort Level: <i>Medium</i>
189) <br />
190) Skill Level: <i>Medium</i>
191) <br />
192) Likely Mentors: <i>Karsten, Roger</i>
193) <br />
194) 時間を追ってネットワークの健康状態を追跡記録し、それをグラフ化等する
195) 自動化されたシステムを完成させられたら素晴らしいことです。
196) このプロジェクトの一部には、ネットワークの健康状態と成長を評価する
197) よりよい指標を考案することが含まれるでしょう。ネットワークの平均
198) 稼働時間は増加しているか？今月は先月に比べていくつのリレーがGuardステータス
199) と認められているか？新しく参加したリレーと停止されたリレーとの交代数は？
200) 定期的に人々が短時間のスナップショットを収集するようですが、本当に
201) 興味深くなってくるのはこれを時間経過を追ってデータポイントを記録し
202) 始めたときなのです。
203) <br />
204) データは<a
205) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>の
206) Tor Network Scannerで各リレーが公開しているサーバデスクリプタから、
207) もしくはその他のソースから収集することができます。
208) 時間経過に伴う結果は<a
209) href="https://torstatus.blutmagie.de/">Tor Status</a>のウェブページに
210) 統合することもできるでしょうし、個別のままでおくこともできるでしょう。
211) Tor Statusページについては、Rogerの
212) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
213) Status要望リスト</a>を見てみてください。
214) </li>
215) 
216) <li>
217) <b>Torの検閲に抵抗する能力を向上させる</b>
218) <br />
219) Priority: <i>Medium to High</i>
220) <br />
221) Effort Level: <i>Medium</i>
222) <br />
223) Skill Level: <i>High</i>
224) <br />
225) Likely Mentors: <i>Nick, Roger, Steven</i>
226) <br />
227) Tor 0.2.0.xシリーズは国家や組織による検閲に対して抵抗力に関して
228) <a href="<svnsandbox>doc/design-paper/blocking.html">著しい進歩</a>
229) を遂げています。しかし、Torは依然としてその反検閲の設計のいくつかの
230) 部分についてよりよいメカニズムを必要としています。例えば、
231) 現在のTorは同時に単一のアドレス/ポートをリッスンすることしか
232) できません。<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">
233) この制限に対処する提案</a>がなされていますが、これについてはまだ作業が
234) 必要です。これによってクライアントは
235) 任意の与えられたTorに対して複数のアドレスおよびポートで接続することができる
236) ようになります。もう一つの（ずっと難しい)反検閲プロジェクトは、Torをより
237) スキャニングに対して抵抗力のあるものにする試みです。現在の時点では、
238) 攻撃者はTorのプロトコルに従いそれらに対して接続を試みるだけで
239) <a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Torブリッジ</a>
240) を識別することができます。この問題を解決するには、ブリッジはポートスキャニング
241) ツールでコンタクトされたときには
242) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">ウェブサーバの
243) ように振る舞い</a>(HTTPまたはHTTPSで)、ユーザがブリッジ固有の鍵を与えない限り
244) ブリッジとして振る舞うことがないようにすることが考えられます。
245) <br />
246) このプロジェクトには多くの調査や設計が含まれます。大きな挑戦のうちの一つとして、
247) 攻撃者が設計を知った後でもなお攻撃に耐えうるようなアプローチを特定してうまくそれを
248) 作成したうえで、検閲に対する抵抗力と利便性および堅牢性とをトレードオフすることが
249) あります。
250) </li>
251) 
252) <li>
253) <b>Torをチューンアップしよう！</b>
254) <br />
255) Priority: <i>Medium to High</i>
256) <br />
257) Effort Level: <i>Medium to High</i>
258) <br />
259) Skill Level: <i>High</i>
260) <br />
261) Likely Mentors: <i>Nick, Roger, Mike, Karsten</i>
262) <br />
263) 現在のところ、Torリレーは自身の帯域幅を測定して報告し、Torクライアントは
264) ある程度この帯域幅に基づいてどのリレーを使用するかを選択しています。
265) このアプローチは、
266) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">
267) リレーが自身の帯域幅について嘘をつく攻撃</a>に晒される危険を有しています;
268) この問題を解決するために、Torは現在のところ、すべてのリレーが提供する
269) 帯域幅に対して信用する上限値を設定するようにしています。これは限定的な
270) 修正に過ぎず、用意する帯域容量の無駄です。そのかわりに、Torはおそらく
271) より分散的なやり方ー恐らくはSnaderとBorisovによる
272) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
273) Tor"</a>の文書に述べられているように、より分散的なやり方で帯域を計測すべき
274) でしょう。この文書の結論を再調査してそれがどの程度実際に配置された
275) Torに適合するか検証し、Torネットワークにあまり多くの交信オーバーヘッドを
276) 課すことなくその結果を彼等の提案に取り込むための良い方法を
277) 見付けるために、現時点でのテストコードを使用することができます。
278) </li>
279) 
280) <li>
281) <b>Windows上のPolipoを改良する</b>
282) <br />
283) Priority: <i>Medium to High</i>
284) <br />
285) Effort Level: <i>Medium</i>
286) <br />
287) Skill Level: <i>Medium</i>
288) <br />
289) Likely Mentors: <i>Martin</i>
290) <br />
291) <a
292) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
293) をWindowsに移植するのを手伝ってください。取り組むべき課題の例としては
294) 以下のようなものが挙げられます:
295) 1)ネームサーバに非同期に問い合わせ、システムネームサーバを探索し、
296) netbiosおよびdnsのクエリを管理する能力
297) 2)イベントおよびバッファをネイティブに管理すること(Unix系OSではPolipoは
298) ramの25%まで使用するのがデフォルトですが、Windowsでは設定次第です)。
299) 3)何かGUIによる設定および報告のためのツールのようなものが必要です。
300) それが右クリック可能なメニューオプション付きのシステムトレイアイコン
301) を持っていればなお良く、さらにそれがクロスプラットフォーム互換なら
302) なおさら良いでしょう。
303) 4)ソフトウェアがWindowsのレジストリを使用し、"C:\Program Files\Polipo"
304) のようなWindowsの正しいディレクトリの位置を扱うことを可能にすること。
305) </li>
306) 
307) <li>
308) <b>Thandyパッケージをダウンロードするためのトーレントに基づいたスキームを実装する</b>
309) <br />
310) Priority: <i>Medium to High</i>
311) <br />
312) Effort Level: <i>High</i>
313) <br />
314) Skill Level: <i>Medium to High</i>
315) <br />
316) Likely Mentors: <i>Martin, Nick</i>
317) <br />
318) <a
319) href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
320) はTorおよび関連するソフトウェアのアップデートを支援する、比較的新しいソフトウェアです。
321) 現在のところこのソフトウェアを使用しているユーザは非常に少ないのですが、私たちは
322) 将来的にはすべてのTorユーザにThandyを使用してもらいたいと思っています。
323) Torをアップデートすべき日にサーバをクラッシュさせないために、私たちは新しい
324) パッケージを効率的に配布する新しい方法を必要としています。libtorrentを使用することが解決策
325) として考えられます。もしあなたがその他のよい考えをお持ちでしたら、それは素晴らしいことです
326) -是非私たちにそれを教えてください！<br />
327) 私たちはまた、ミラーサーバを含めるよい方法を調査する必要があります。できればそれは、
328) パッケージを配布するのを助ける簡単な方法によるべきでしょう。
329) </li>
330) 
331) <li>
332) <b>Torコントローラステータスイベントインターフェース</b>
333) <br />
334) Priority: <i>Medium</i>
335) <br />
336) Effort Level: <i>Medium</i>
337) <br />
338) Skill Level: <i>Low to Medium</i>
339) <br />
340) Likely Mentors: <i>Matt</i>
341) <br />
342) ユーザが知りたいと思う幾つかのTorの内部ステータスの変化があります。
343) 例えばユーザが自分のTorをリレーとしてセットアップしようとしている
344) 際、Torがそのポートが外部から到達できないことを検知した場合には、
345) ユーザに警告を発するべきです。現在のところ、ユーザが得られるものは
346) Vidaliaの'メッセージログ'内の二行のログメッセージだけですが、
347) ユーザは何かがまずいことになっているという通知を受け取っていないため、
348) それを見過ごしてしまう傾向があります。ユーザが実際にそのメッセージ
349) ログを見た場合でも、初心者ユーザにとってその多くはほとんど意味を
350) なさないでしょう。
351) <br />
352) Torはそういったステータスの変化をVidaliaに知らせる能力を持っており、
353) 最近になってそれらのイベントの幾つかをサポートする実装をしました。
354) しかしユーザが知らされるべきステータスイベントはまだ多く残っており、
355) 私たちは実際にそれらをユーザに対して表示するよりよいUIを必要と
356) しています。
357) <br />
358) このプロジェクトの目的はそうすると、Torのステータスイベントをユーザに
359) 対して表示するUIを設計し実装することにあるということになります。
360) 例えばVidaliaのトレイアイコン上に、ユーザに彼等が見るべき新たな
361) ステータスイベントを警告する小さなバッジを付けることが考えられる
362) でしょう。アイコンをダブルクリックすると、最近起こったステータスイベント
363) がわかりやすい用語でまとめられたダイアログが表示され、そこには
364) ユーザが修正可能な場合には否定的なイベントに対する対処法が提示される、
365) といった具合です。むろんこれは一例にすぎませんから、他のアプローチを
366) 提案することは自由です。
367) <br />
368) このプロジェクトを遂行する人物は良いUIデザインおよびレイアウトが出来、
369) いくらかのC++開発経験がなければいけません。QtおよびQtのデザイナ
370) 
371) A person undertaking this project should have good UI design and layout
372) and some C++ development experience. Previous experience with Qt and
373) Qt's Designer will be very helpful, but are not required. Some
374) English writing ability will also be useful, since this project will
375) likely involve writing small amounts of help documentation that should
376) be understandable by non-technical users. Bonus points for some graphic
377) design/Photoshop fu, since we might want/need some shiny new icons too.
378) </li>
379) 
380) <li>
381) <b>私たちのユニットテストプロセスを改良する</b>
382) <br />
383) Priority: <i>Medium</i>
384) <br />
385) Effort Level: <i>Medium</i>
386) <br />
387) Skill Level: <i>Medium</i>
388) <br />
389) Likely Mentors: <i>Nick, Roger</i>
390) <br />
391) Torにはまだまだテストが必要です。これは多方面にわたる作業になります。
392) 手始めに、私たちのユニットテストがカバーする範囲ーとりわけ
393) ユーティリティ関数以外の領域におけるーを大幅に増やさなければ
394) なりません。これには、グローバルスコープからロジックを切り離すために
395) Torのいくつかの部分について大規模なリファクタリング
396) が必要になるでしょう。
397) <br />
398) さらに、私たちのパフォーマンステストを自動化する必要があります。
399) 私たちはすでに私たちのregular integrationを自動化しテストコードを
400) コンパイルするためのbuildbotを持っています(Windowsでそれを
401) セットアップしてくれる方が必要ですが)が、私たちのネットワーク
402) シミュレーションテスト(<a
403) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>
404) にある)をより最近のTorのバージョンに合わせてアップデートし、
405) 単一のマシンまたは複数のマシン上でネットワークテストを起動して
406) 自動的に異なる役割におけるマシンのパフォーマンスの変化をテストすることが
407) 出来るように設計する必要があります。
408) </li>
409) 
410) <li>
411) <b>独立したTorクライアント実装の復活を助けてください</b>
412) <br />
413) Priority: <i>Medium</i>
414) <br />
415) Effort Level: <i>High</i>
416) <br />
417) Skill Level: <i>Medium to High</i>
418) <br />
419) Likely Mentors: <i>Karsten, Nick</i>
420) <br />
421) TorのクライアントをJavaで実装するアプローチのうちの一つ、例えば
422) <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
423) プロジェクト</a>
424) を復活させ、<a
425) href="http://code.google.com/android/">Android</a>上で動くように
426) しましょう。手始めとして既存のコードを移植してAndroid環境でそれを
427) 実行することになるでしょう。次に、そのコードが
428) <a href="<svnsandbox>doc/spec/dir-spec.txt">v3ディレクトリプロトコル</a>
429) のようなより新しいバージョンのTorプロトコルをサポートするように
430) アップデートしなければなりません。さらに、Torのヒドゥンサービスに
431) アクセスしさらにはそれを提供する機能をもサポートするなら行き届いたもの
432) になるでしょうが、それは必須というわけではありません。
433) <br />
434) これにあたる開発者はJavaの暗号APIを含む新しいJavaコードを理解してそれを
435) 書くことができなければなりません。Cのコードを読めるならそれも役に立つ
436) でしょう。既存のドキュメントを読み、それに基づいてコードを実装し、
437) ドキュメント化されていない項目があればドキュメントを改良していく意欲の
438) ある方でなければなりません。このプロジェクトのほとんどの部分は
439) コーディングに関するもので設計には少ししか関係しません。
440) </li>
441) 
442) <li>
443) <b>Torbuttonの新機能</b>
444) <br />
445) Priority: <i>Medium</i>
446) <br />
447) Effort Level: <i>High</i>
448) <br />
449) Skill Level: <i>High</i>
450) <br />
451) Likely Mentors: <i>Mike</i>
452) <br/>
453) Torbutton Flysprayの節の<a
454) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">
455) よい機能のリクエスト</a>にいくつかあります。特に、
456) <a
457) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">
458) '新しいID'をVidaliaに組み込む
459) </a>、
460) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">
461) 複数のクッキーjarおよびIDを管理する方法
462) </a>、 クッキーがクリアされる場合に<a
463) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">
464) 特定のクッキーを保存する
465) </a>、
466) 
467) <a
468) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">
469) よりよいリファラースプーフィング
470) </a>, <a
471) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">
472) 正しいTorステータスの報告
473) </a>、そして<a
474) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">
475) "tor://"および"tors://"URL</a>はすべて、もし実現できれば面白い機能です。
476) <br />
477) この作業はJavascriptの独立したコーディングと<a
478) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>
479) ファンの世界になり、Torの中身とはそれほど関係しないものになるでしょう。
480) </li>
481) 
482) <li>
483) <b>新しいThandyの機能 </b>
484) <br />
485) Priority: <i>Medium</i>
486) <br />
487) Effort Level: <i>Medium</i>
488) <br />
489) Skill Level: <i>Medium to High</i>
490) <br />
491) Likely Mentors: <i>Martin</i>
492) <br />
493) Windowsおよびその他のOSのためのTor関連ソフトウェアのアップデート補助の
494) 追加的機能が必要です。考えられる機能としては以下のようなものが挙げられます:
495) 1)認証付きHTTPSダウンロードのための<a
496) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto Python
497) ライブラリ</a>。
498) 2)タイムスタンプシグネチャとアップデートに含まれるパッケージファイルとの間
499) の迂回レベルを追加する。or-devの"Thandy attacks / suggestions"を参照。
500) 3)設定、ホスト、ユーザアカウント言語設定に基づき、
501) アップデート補助のロケールごとのインストールと設定をサポートする。
502) win32およびposix API全般の経験とPythonに習熟していることに加え、
503) Windowsコードページ、ユニコードおよびその他の文字セットに通じているとなお可。
504) </li>
505) 
506) <li>
507) <b>遅いインターネット接続のシミュレータ</b>
508) <br />
509) Priority: <i>Medium</i>
510) <br />
511) Effort Level: <i>Medium</i>
512) <br />
513) Skill Level: <i>Medium</i>
514) <br />
515) Likely Mentors: <i>Steven</i>
516) <br />
517) 多くのTorユーザは、狭い帯域幅、高いレイテンシ、高いパケットロスおよび再順序化を
518) 伴う低質なインターネット接続を利用しています。ユーザ経験上、
519) Torはこういった接続に対してはよい反応を示しません。しかし、
520) 問題を研究室で再現可能にせずしてこの状況を改善することは困難です。
521) <br />
522) このプロジェクトでは貧弱な接続を再現するシミュレーション環境を
523) 構築して、それがTorのパフォーマンスに与える影響を測定することが
524) できるようにすることになるでしょう。それ以外の要素としては、
525) 使用可能な接続の条件が何かを決定し、Torのパフォーマンスを向上させる
526) 変更の効果を測定するテストユーティリティが挙げられるでしょう。
527) <br />
528) 使用するツールは研究者にお任せしますが、dummynet(FreeBSD)および
529) nistnet(Linux)はこのプロジェクトがその基礎とすることのできる
530) 有力なコンポーネントです。研究者はネットワークプログラミング/
531) デバッギングおよびTCP/IPに通じていなければならず、できれば
532) Cと一つのスクリプト言語に慣れ親しんでいることが望まれます。
533) </li>
534) 
535) <li>
536) <b>Vidaliaのネットワークマップを改善してより使いやすいものにする</b>
537) <br />
538) Priority: <i>Low to Medium</i>
539) <br />
540) Effort Level: <i>Medium</i>
541) <br />
542) Skill Level: <i>Medium</i>
543) <br />
544) Likely Mentors: <i>Matt</i>
545) <br />
546) Vidaliaの既存の機能の一つとして、Torネットワーク上のリレーのおおまかな
547) 地理的位置をユーザに対して表示し、ユーザの行った通信がTorネットワークを
548) 通っていくに従ってそのパスを描画する、ネットワークマップがあります。
549) マップは現在のところあまりインタラクティブではなく、そのグラフィックは
550) かなり貧弱です。これに代えて、私たちはKDEのMarbleウィジットを実装して
551) より品質の良いマップを提供できるようにし、双方向性を向上させてユーザが
552) 個々のリレーをクリックしたり回路についての追加的情報を表示させることが
553) 可能になりました。私たちは、ユーザが特定のリレーまたは一個以上のTor出口
554) リレーが存在している国をクリックして、「私の接続はここから出て欲しい。」
555) と言えるような機能を追加したいと考えています。
556) <br />
557) このプロジェクトにはまずVidaliaおよびMarbleウィジットのAPIに慣れ親しむこと
558) が伴うでしょう。そののちにウィジットをVidaliaに統合しMarbleをカスタマイズ
559) して私たちのアプリケーションにより適合するようにすることになるでしょう。
560) それは例えば回路をクリック可能にすること、キャッシュされたマップデータを
561) Vidaliaの独自のデータディレクトリに格納すること、あるいはウィジットの
562) ダイアログのうちのいくつかをカスタマイズすることなどです。
563) <br />
564) このプロジェクトを遂行する人物は、C++開発について十分な経験を有している
565) 必要があります。QtおよびCMakeについての経験があればなおよいですが、
566) これは必須ではありません。
567) </li>
568) 
569) <li>
570) <b>moniTorを誕生させる</b>
571) <br />
572) Priority: <i>Low</i>
573) <br />
574) Effort Level: <i>Medium</i>
575) <br />
576) Skill Level: <i>Low to Medium</i>
577) <br />
578) Likely Mentors: <i>Karsten, Jacob</i>
579) <br />
580) Torリレーのための<a href="http://www.ss64.com/bash/top.html">topに似た</a>
581) 管理ツールを実装します。こういったツールの目的は、その制御ポートを通じて
582) ローカルのTorリレーをモニターし、実行しているマシンの有益なシステム情報
583) を盛りこむことです。このツールはtopがLinuxのプロセスに対してするのと
584) 同様、実行中にそのコンテンツを動的に更新することになるでしょう。
585) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">この
586) or-devの投稿</a>をまず始めに読むといいでしょう。
587) <br />
588) これに興味をお持ちの方は、Torリレーを管理することおよびそれを制御ポートを
589) 通じて調整することについて熟知しているかまたは学ぼうとする意欲があることが
590) 必要です。最初のプロトタイプはPythonで書かれていますので、Pythonを書くこと
591) についてのいくらかの知識があればそれも役に立つでしょう。
592) このプロジェクトはこういったツールに対する機能要求を同定することおよび
593) そのインターフェースをデザインすることと、多くのコーディングを行うこととの
594) 二つの部分に分けられます。
595) </li>
596) 
597) <li>
598) <b>ThunderbirdにもTorbuttonと同等のものを</b>
599) <br />
600) Priority: <i>Low</i>
601) <br />
602) Effort Level: <i>High</i>
603) <br />
604) Skill Level: <i>High</i>
605) <br />
606) Likely Mentors: <i>Mike</i>
607) <br />
608) ThunderbirdをTorとともに使いたいというユーザが増えていると聞いています。
609) しかしながら、それを実現するにはアプリケーションレベルにおける多くの課題
610) があります。例えば、Thunderbirdはデフォルトであなたのホスト名を送信する
611) メールに出力してしまいます。いずれかの時点で私たちはTorbuttonに似た
612) Thunderbird拡張を作成するための新たな行動を起こすべきでしょう。
613) </li>
614) 
615) <li>
616) <b>中間レベルネットワークデバイスドライバ</b>
617) <br />
618) Priority: <i>Low</i>
619) <br />
620) Effort Level: <i>High</i>
621) <br />
622) Skill Level: <i>High</i>
623) <br />
624) Likely Mentors: <i>Martin</i>
625) <br />
626) ブリッジを使用するネットワーキングのためにTorVMによって使用される
627) WinPCAPデバイスドライバは、いくつかの無線および非イーサネットネットワーク
628) アダプタをサポートしていません。win32および64ビット用の
629) 中間レベルデバイスドライバの実装があれば、そういったネットワーク上で
630) 通信を遮断したりルーティングしたりする道が開けます。
631) このプロジェクトはWindowsのカーネルデバイスドライバ開発およびテスティングの
632) 知識と経験を必要とするでしょう。WinsockおよびQemuについてよく知っていれば
633) それも役に立つでしょう。
634) </li>
635) 
636) <li>
637) <b>新しいアイディアを出してください！</b>
638) <br />
639) これらのうちのどれも気に入らない？
640) <a
641) href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor開発ロードマップ 
642) </a>を見てその他のアイディアを探してみてください。
643) <a href="<svnsandbox>doc/spec/proposals/">現在の提案</a>のうちのいくつかもまた、
644) 開発者にとっては手短かに過ぎるかも知れません。
645) </li>
646) 
647) <!-- Mike is already working on this.
648) <li>
649) <b>Tor Node Scanner improvements</b>
650) <br />
651) Similar to the SoaT exit scanner (or perhaps even during exit scanning),
652) statistics can be gathered about the reliability of nodes. Nodes that
653) fail too high a percentage of their circuits should not be given
654) Guard status. Perhaps they should have their reported bandwidth
655) penalized by some ratio as well, or just get marked as Invalid. In
656) addition, nodes that exhibit a very low average stream capacity but
657) advertise a very high node bandwidth can also be marked as Invalid.
658) Much of this statistics gathering is already done, it just needs to be
659) transformed into something that can be reported to the Directory
660) Authorities to blacklist/penalize nodes in such a way that clients
661) will listen.
662) <br />
663) In addition, these same statistics can be gathered about the traffic
664) through a node. Events can be added to the <a
665) href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor Control
666) Protocol</a> to
667) report if a circuit extend attempt through the node succeeds or fails, and
668) passive statistics can be gathered on both bandwidth and reliability
669) of other nodes via a node-based monitor using these events. Such a
670) scanner would also report information on oddly-behaving nodes to
671) the Directory Authorities, but a communication channel for this
672) currently does not exist and would need to be developed as well.
673) </li>
674) -->
675) 
676) <!-- Is this still a useful project? If so, move it to another section.
677) <li>
678) <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
679) <br />
680) Vidalia currently doesn't play nicely on Debian and Ubuntu with the
681) default Tor packages. The current Tor packages automatically start Tor
682) as a daemon running as the debian-tor user and (sensibly) do not have a
683) <a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
684) in the default torrc. Consequently, Vidalia will try
685) to start its own Tor process since it could not connect to the existing
686) Tor, and Vidalia's Tor process will then exit with an error message
687) the user likely doesn't understand since Tor cannot bind its listening
688) ports &mdash; they're already in use by the original Tor daemon.
689) <br />
690) The current solution involves either telling the user to stop the
691) existing Tor daemon and let Vidalia start its own Tor process, or
692) explaining to the user how to set a control port and password in their
693) torrc. A better solution on Debian would be to use Tor's ControlSocket,
694) which allows Vidalia to talk to Tor via a Unix domain socket, and could
695) possibly be enabled by default in Tor's Debian packages. Vidalia can
696) then authenticate to Tor using filesystem-based (cookie) authentication
697) if the user running Vidalia is also in the debian-tor group.
698) <br />
699) This project will first involve adding support for Tor's ControlSocket
700) to Vidalia. The student will then develop and test Debian and Ubuntu
701) packages for Vidalia that conform to Debian's packaging standards and
702) make sure they work well with the existing Tor packages. We can also
703) set up an apt repository to host the new Vidalia packages.
704) <br />
705) The next challenge would be to find an intuitive usable way for Vidalia
706) to be able to change Tor's configuration (torrc) even though it is
707) located in <code>/etc/tor/torrc</code> and thus immutable. The best
708) idea we've come up with so far is to feed Tor a new configuration via
709) the ControlSocket when Vidalia starts, but that's bad because Tor starts
710) each boot with a different configuration than the user wants. The second
711) best idea
712) we've come up with is for Vidalia to write out a temporary torrc file
713) and ask the user to manually move it to <code>/etc/tor/torrc</code>,
714) but that's bad because users shouldn't have to mess with files directly.
715) <br />
716) A person undertaking this project should have prior knowledge of
717) Debian package management and some C++ development experience. Previous
718) experience with Qt is helpful, but not required.
719) </li>
720) -->
721) 
722) <!-- This should be mostly done.
723) <li>
724) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
725) <br />
726) We're in need of a good authenticated-update framework.
727) Vidalia already has the ability to notice when the user is running an
728) outdated or unrecommended version of Tor, using signed statements inside
729) the Tor directory information. Currently, Vidalia simply pops
730) up a little message box that lets the user know they should manually
731) upgrade. The goal of this project would be to extend Vidalia with the
732) ability to also fetch and install the updated Tor software for the
733) user. We should do the fetches via Tor when possible, but also fall back
734) to direct fetches in a smart way. Time permitting, we would also like
735) to be able to update other
736) applications included in the bundled installers, such as Polipo and
737) Vidalia itself.
738) <br />
739) To complete this project, the student will first need to first investigate
740) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
741) their strengths, weaknesses, security properties, and ability to be
742) integrated into Vidalia. If none are found to be suitable, the student
743) will design their own auto-update framework, document the design, and
744) then discuss the design with other developers to assess any security
745) issues. The student will then implement their framework (or integrate
746) an existing one) and test it.
747) <br />
748) A person undertaking this project should have good C++ development
749) experience. Previous experience with Qt is helpful, but not required. One
750) should also have a good understanding of common security
751) practices, such as package signature verification. Good writing ability
752) is also important for this project, since a vital step of the project
753) will be producing a design document to review and discuss
754) with others prior to implementation.
755) </li>
756) -->
757) 
758) <!-- Jake already did most of this.
759) <li>
760) <b>Improvements on our active browser configuration tester</b> -
761) <a href="https://check.torproject.org/">https://check.torproject.org/</a>
762) <br />
763) We currently have a functional web page to detect if Tor is working. It
764) has a few places where it falls short. It requires improvements with
765) regard to default languages and functionality. It currently only responds
766) in English. In addition, it is a hack of a perl script that should have
767) never seen the light of day. It should probably be rewritten in python
768) with multi-lingual support in mind. It currently uses the <a
769) href="http://exitlist.torproject.org/">Tor DNS exit list</a>
770) and should continue to do so in the future. It currently result in certain
771) false positives and these should be discovered, documented, and fixed
772) where possible. Anyone working on this project should be interested in
773) DNS, basic perl or preferably python programming skills, and will have
774) to interact minimally with Tor to test their code.
775) <br />
776) If you want to make the project more exciting
777) and involve more design and coding, take a look at <a
778) href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
779) 131-verify-tor-usage.txt</a>.
780) </li>
781) -->
782) 
783) <!-- If we decide to switch to the exit list in TorStatus, this is obsolete.
784) <li>
785) <b>Improvements on our DNS Exit List service</b> -
786) <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
787) <br />
788) The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
789) is written by our fabulous anonymous
790) contributer Tup. It's a DNS server written in Haskell that supports part of our <a
791) href="<svnsandbox>doc/contrib/torel-design.txt">exitlist
792) design document</a>. Currently, it is functional and it is used by
793) check.torproject.org and other users. The issues that are outstanding
794) are mostly aesthetic. This wonderful service could use a much better
795) website using the common Tor theme. It would be best served with better
796) documentation for common services that use an RBL. It could use more
797) publicity. A person working on this project should be interested in DNS,
798) basic RBL configuration for popular services, and writing documentation.
799) The person would require minimal Tor interaction &mdash; testing their
800) own documentation at the very least. Furthermore, it would be useful
801) if they were interested in Haskell and wanted to implement more of the
802) torel-design.txt suggestions.
803) </li>
804) -->
805) 
806) <!-- Nobody wanted to keep this.
807) <li>
808) <b>Testing integration of Tor with web browsers for our end users</b>
809) <br />
810) The Tor project currently lacks a solid test suite to ensure that a
811) user has a properly and safely configured web browser. It should test for as
812) many known issues as possible. It should attempt to decloak the
813) user in any way possible. Two current webpages that track these
814) kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
815) href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
816) with their proof of concept code, bug issues, etc</a>. HD Moore runs
817) the <a href="http://www.decloak.net/">metasploit
818) decloak website</a>. A person interested in defending Tor could start
819) by collecting as many workable and known methods for decloaking a
820) Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
821) be helpful as a start.) One should be familiar with the common pitfalls but
822) possibly have new methods in mind for implementing decloaking issues. The
823) website should ensure that it tells a user what their problem is. It
824) should help them to fix the problem or direct them to the proper support
825) channels. The person should also be closely familiar with using Tor and how
826) to prevent Tor information leakage.
827) </li>
828) -->
829) 
830) <!-- Nick did quite some work here. Is this project still required then?
831) <li>
832) <b>Libevent and Tor integration improvements</b>
833) <br />
834) Tor should make better use of the more recent features of Niels
835) Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
836) library.  Tor already uses Libevent for its low-level asynchronous IO
837) calls, and could also use Libevent's increasingly good implementations
838) of network buffers and of HTTP.  This wouldn't be simply a matter of
839) replacing Tor's internal calls with calls to Libevent: instead, we'll
840) need to refactor Tor to use Libevent calls that do not follow the
841) same models as Tor's existing backends. Also, we'll need to add
842) missing functionality to Libevent as needed &mdash; most difficult likely
843) will be adding OpenSSL support on top of Libevent's buffer abstraction.
844) Also tricky will be adding rate-limiting to Libevent.
845) </li>
846) -->
847) 
848) <!--
849) <li>
850) <b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
851) <br />
852) It would be useful to have automated build processes for Windows and
853) probably other platforms. The purpose of having a continuous integration
854) build environment is to ensure that Windows isn't left behind for any of
855) the software projects used in the Tor project or its accompanying.<br />
856) Buildbot may be a good choice for this as it appears to support all of
857) the platforms Tor does. See the
858) <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
859) buildbot</a>.<br />
860) There may be better options and the person undertaking this task should
861) evaluate other options. Any person working on this automatic build
862) process should have experience or be willing to learn how to build all
863) of the respective Tor related code bases from scratch. Furthermore, the
864) person should have some experience building software in Windows
865) environments as this is the target audience we want to ensure we do not
866) leave behind. It would require close work with the Tor source code but
867) probably only in the form of building, not authoring.<br />
868) Additionally, we need to automate our performance testing for all platforms.
869) We've got buildbot (except on Windows &mdash; as noted above) to automate
870) our regular integration and compile testing already,
871) but we need to get our network simulation tests (as built in torflow)
872) updated for more recent versions of Tor, and designed to launch a test
873) network either on a single machine, or across several, so we can test
874) changes in performance on machines in different roles automatically.
875) </li>
876) -->
877) 
878) <!-- Removed, unless Mike still wants this to be in.
879) <li>
880) <b>Torbutton improvements</b>
881) <br />
882) Torbutton has a number of improvements that can be made in the post-1.2
883) timeframe. Most of these are documented as feature requests in the <a
884) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
885) flyspray section</a>. Good examples include: stripping off node.exit on http
886) headers, more fine-grained control over formfill blocking, improved referrer
887) spoofing based on the domain of the site (a-la <a
888) href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
889) tighter integration with Vidalia for reporting Tor status, a New Identity
890) button with Tor integration and multiple identity management, and anything
891) else you might think of.
892) <br />
893) This work would be independent coding in Javascript and the fun world of <a
894) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
895) with not too much involvement in the Tor internals.
896) </li>
897) -->
898) 
899) <!-- Is Blossom development still happening?
900) <li>
901) <b>Rework and extend Blossom</b>
902) <br />
903) Rework and extend Blossom (a tool for monitoring and
904) selecting appropriate Tor circuits based upon exit node requirements
905) specified by the user) to gather data in a self-contained way, with
906) parameters easily configurable by the user.  Blossom is presently
907) implemented as a single Python script that interfaces with Tor using the
908) Controller interface and depends upon metadata about Tor nodes obtained
909) via external processes, such as a webpage indicating status of the nodes
910) plus publically available data from DNS, whois, etc.  This project has
911) two parts: (1) Determine which additional metadata may be useful and
912) rework Blossom so that it cleanly obtains the metadata on its own rather
913) than depend upon external scripts (this may, for example, involve
914) additional threads or inter-process communication), and (2) develop a
915) means by which the user can easily configure Blossom, starting with a
916) configuration file and possibly working up to a web configuration engine.
917) Knowledge of Tor and Python are important; knowledge of
918) TCP, interprocess communication, and Perl will also be helpful.  An
919) interest in network neutrality is important as well, since the
920) principles of evaluating and understanding internet inconsistency are at
921) the core of the Blossom effort.
922) </li>
923) 
924) <li>
925) <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
926) <br />
927) Develop and implement a means of affording Blossom
928) users the ability to qualitatively describe the exit node that they
929) want.  The Internet is an inconsistent place: some Tor exit nodes see
930) the world differently than others.  As presently implemented, Blossom (a
931) tool for monitoring and selecting appropriate Tor circuits based upon
932) exit node requirements specified by the user) lacks a sufficiently rich
933) language to describe how the different vantage points are different.
934) For example, some exit nodes may have an upstream network that filters
935) certain kinds of traffic or certain websites.  Other exit nodes may
936) provide access to special content as a result of their location, perhaps
937) as a result of discrimination on the part of the content providers
938) themselves.  This project has two parts: (1) develop a language for
939) describing characteristics of networks in which exit nodes reside, and
940) (2) incorporate this language into Blossom so that users can select Tor
941) paths based upon the description.
942) Knowledge of Tor and Python are important; knowledge of
943) TCP, interprocess communication, and Perl will also be helpful.  An
944) interest in network neutrality is important as well, since the
945) principles of evaluating and understanding internet inconsistency are at
946) the core of the Blossom effort.
947) </li>
948) -->
949) 
950) <!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X
951) <li>
952) <b>Usability testing of Tor</b>
953) <br />
954) Priority: <i>Medium</i>
955) <br />
956) Effort Level: <i>Medium</i>
957) <br />
958) Skill Level: <i>Low to Medium</i>
959) <br />
960) Likely Mentors: <i>Andrew</i>
961) <br />
962) Especially the browser bundle, ideally amongst our target demographic.
963) That would help a lot in knowing what needs to be done in terms of bug
964) fixes or new features. We get this informally at the moment, but a more
965) structured process would be better.
966) </li>
967) -->
968) 
969) </ol>
970) 
971) <a id="OtherCoding"></a>
972) <h2><a class="anchor" href="#OtherCoding">その他コーディングおよび設計に関するアイディア</a></h2>
973) <ol>
974) <li>TorリレーがWindows XP上でうまく動きません。Windows上では、

975) Torは非ページプールメモリを使用する標準の<tt>select()</tt>

976) システムコールを使います。これは、中規模のTorリレーが非ページプールメモリ
977) を喰い潰してしまい、
978) <a

979) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">

980) 大混乱とシステムクラッシュを引き起こす</a>
981) ことを意味します。恐らく代わりに

982) オーバーラップIOを使用しなければならないでしょう。解決策の一つは、
983) <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
984) にWindows上でselect()ではなくオーバラップIOを使用する方法を教え、

985) Torを新しいlibeventインターフェースに適合させることでしょう。
986) Christian Kingが2007年の夏にこれについての
987) <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">よい出発点
988) </a>を作ってくれました。
989) </li>
990) 
991) <li>
992) 
993) <a href="<page

994) documentation>#DesignDoc">抗ブロッキングデザイン</a>の設計を実際に
995) 始めなければなりません。その作業には、デザインを具体化し、Torの多くの様々な

996) 部分を変更し<a href="http://vidalia-project.net/">Vidalia</a>を

997) Torの新しい機能をサポートするように変更して実際に配備できる
998) ように準備することが含まれます。</li>
999) <li>私達はエンドツーエンドトラフィックコンフォメーション攻撃を研究する
1000) ための柔軟なシミュレーションフレームワークを必要としています。
1001) 多くの研究者が、彼らの「この攻撃はうまくいくだろう」あるいは「ある防御方法が
1002) 大いに有効に違いない」という直観を証明するためにアドホックなシミュレータを
1003) 早くも設計しています。すべての人々がその正当性を知ることが出来るように
1004) 十分にドキュメント化されオープンであるようなシミュレータを作成することが
1005) できないでしょうか？これには多くの新たなリサーチが必要となるでしょう。
1006) コンフォメーション攻撃のこのタスクの研究側の詳細については
1007) <a href="#Research">下</a>のエントリをご覧くださいー時期は未定ですが、
1008) それが完了した時には文書を書くのを手伝ってもらえると思います。</li>

1009) 

1010) <li>Tor 0.1.1.xおよびそれ以降のバージョンはOpenSSLを利用したハードウェア

1011) 暗号処理アクセラレータのサポートが含まれています。これはまだ簡単にしか
1012) テストされておらず、恐らくはバグが多く残っていることでしょう。
1013) 私たちはより厳密なテスティング、パフォーマンス分析、そして出来れば必要に応じて
1014) openssloおよびTorに対するコード修正を探し求めています。</li>
1015) 

1016) <li><a

1017) href="http://en.wikipedia.org/wiki/fuzz_testing">"ファジング"</a>
1018) を使ってtorに対してセキュリティ分析を実行してください。

1019) 世の中に私達が望んでいるような用途に向いた良いファジングライブラリが
1020) あるかどうか調べてください。もしあなたのおかげで新しいリリースを
1021) 出すことが出来たら、その貢献は大いに感謝されるでしょう。</li>

1022) <li>
1023) 

1024) <li>TorはトランスポートにTCPを、接続の暗号化にはTLSを使用しています。
1025) これは簡単で良い実装なのですが、それはある接続上で一つのパケットがドロップ
1026) されるとその接続上のすべてのセルが遅延してしまうこと、従って
1027) TCPストリームしかサポートできない理由がある、ことを意味します。
1028) <a

1029) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">

1030) 私達が未だにUDPトランスポートへ移行していない理由のリスト</a>がありますが、
1031) このリストがもし今よりも短くなるのなら素晴らしいことです。
1032) この他にも、提案中の<a
1033) href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">
1034) TorとUDPの仕様</a>がありますーもしこれに誤りが含まれていたら

1035) 私達に知らせてください。</li>
1036) 

1037) <li>目的アドレスにIPv6アドレス(出口ノードにおいて)をサポートできるように
1038) なるのもそう遠い話ではありません。もしIPv6に強い関心がおありなら、
1039) おそらくまずここから始めるがよいでしょう。</li>
1040) 

1041) <li>ウェブサイトのダイアグラム(例えば
1042) <a href="<page overview>">概要ページ</a>の"Torはどうやって動くのか"の図)
1043) をGimpで手動で編集せずにそれをUTF-8のテキストに翻訳できるように、
1044) ソースから生成する方法を必要としています。
1045) 私たちがウェブサイトを構築するときはいつでも翻訳が簡単で画像が複数の言語で
1046) 生成されるように、それをwmlファイルとして統合することができればよいでしょう。
1047) </li>
1048) 
1049) <li><a
1050) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
1051) のメンテナンス、改良、ドキュメントをどうやったらより簡単にできるでしょう？
1052) </li>

1053) </ol>
1054) 
1055) <a id="Research"></a>
1056) <h2><a class="anchor" href="#Research">リサーチ</a></h2>
1057) <ol>
1058) <li>"ウェブサイトフィンガープリント攻撃":
1059) 	数百におよぶ人気のあるウェブサイトのリストを作成してそれらのページを
1060) ダウンロードし、サイト毎に"シグネチャ"のセットを作ります。その上で、
1061) Torクライアントのトラフィックを監視します。あるクライアントが
1062) データを受信したのを観察したら、すばやくどのサイト(もし件のリストに
1063) 該当するものがあれば)にアクセスしたのかを訪れたのかの推測を
1064) 試みるのです。第一に、この攻撃は配備済みのTorコードベースに対して
1065) どの程度有効なのでしょうか？次にこれに対する防御について
1066) 考えてみましょう:　例えば、Torのセルサイズを512バイトから
1067) 1024バイトに変更する、<a
1068) href="http://freehaven.net/anonbib/#timing-fc2004">
1069) ディフェンシブドロッピング</a>と同様のパディングテクニックを採用する、
1070) あるいはトラフィック遅延を加えることが考えられます。
1071) これらの対策を採用して防御に成功した場合、その影響はどれくらいで、利便性は
1072) どの程度(何か適当な測定基準を用いて)の影響を被ることになるでしょうか？
1073) </li>
1074) <a
1075) href="http://freehaven.net/anonbib/#danezis:pet2004">
1076) トラフィックシグネチャを比較することで同じストリームを監視している
1077) ことに確信を持つ</a>ことができます。これまでのところ、Torはこの
1078) 攻撃のついてはやむを得ないことでどのような場合でもこれは些細な
1079) ことに過ぎないと考えてきました。そもそも、それは本当に可能な
1080) 方法なのでしょうか？敵が勝利を確信するまでにいったいどのような
1081) 種類の、どれだけ多くのトラフィックが必要となるのでしょうか？
1082) 攻撃をスローダウンさせるようなシナリオ(例えば転送量が少ないとか)
1083) があるのでしょうか？トラフィックパディングまたはトラフィック
1084) シェイピング手法は他の手段より有効でしょうか？</li>

1085) <li>関連する疑問:リレーやブリッジを運用することはこれらの
1086) タイミング攻撃に対する追加的防御となるのでしょうか？TLSリンクの内部を
1087) 見ることができない外部の攻撃者は確実に個々のストリームを識別することが
1088) できるのでしょうか？通信量を増加させることでこの能力を少しでも低減させる
1089) ことができるのでしょうか？クライアントリレーがキューを作成して中継している
1090) 通信のアップをわざと送らせ、そのキューを使用してクライアントの
1091) ダウンストリームも中継されたもののように見せかけるためにそのタイミングを
1092) 模擬するのはどうでしょう？この同じキューは、<a
1093) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>
1094) と同じ技術を用いて、しかし余分な通信を追加せず、クライアントの
1095) アップストリーム通信のタイミングにマスキングを施すのに使うことが
1096) できるかもしれません。このようにクライアントのアップストリーム通信に
1097) 間を置くことは、外部の攻撃者から見てタイミングを曖昧にする働きが
1098) あるでしょうか？非対称リンクの場合には戦略を調整する必要があるでしょうか？
1099) 例えば非対称リンクの場合、その非対称的容量ゆえにクライアントの通信を
1100) 通常の通信から区別することが実際に可能になるのでしょうか？
1101) それとも対称的リンクにおけるよりもそれが他の何らかの理由で
1102) より容易になるのでしょうか？</li>
1103) <li>MurdochとDanezisの<a
1104) href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">
1105) Oaklandからの攻撃 05</a>を現在のTorネットワーク上で再現してください。
1106) あるノードはうまく動き他のノードではうまく動かない理由が分かるか
1107) どうかを確かめてください。(私の理論では容量に余裕のある速いノードは
1108) 攻撃に対してより抵抗力が強いことになります。)もしそれが本当なら、
1109) RelayBandwidthRateおよびRelayBandwidthBurstオプションをいろいろ
1110) 試しながら、攻撃者からの通信を中継しつつクライアントとしても
1111) 使用されるリレーを動かしてみてください:RelayBandwidthRateを下げると
1112) 攻撃はより難しくなるでしょうか？実際の容量として正しいRelayBandwidthRate
1113) の比率はどれだけでしょう？そもそもそれは比率の問題なのでしょうか？
1114) 私たちがそれに取り組んでいる一方で、より多くのリレー候補の集合が
1115) 攻撃側の誤診率や別の複雑さを増加させてはいないでしょうか？
1116) (Torネットワークはかつてこの文書が書かれた当時と比較して、
1117) 現在だいたい2乗の規模になっています。)
1118) <a href="http://freehaven.net/anonbib/#clog-the-queue">Don't
1119) Clog the Queue</a>も必ずお読みください。</li>
1120) <li>"ルーティングゾーン攻撃":ほとんどの資料では、
1121) アリスとその入口ノードとの間

1122) (および出口ノードとボブとの間)は、あるグラフ上の
1123) 単一のリンクと捉えられています。しかしながら、実際にはこのパスは
1124) 多くの自律システム(AS)を横断することになり、<a
1125) href="http://freehaven.net/anonbib/#feamster:wpes2004">
1126) 同じASが入口パスと出口パスとの両方に出現することは稀です
1127) </a>。残念ながら、アリス、入口ノード、出口ノード、ボブの四者ともが
1128) 危険であると予測するためには、インターネットルーティングゾーン全体を
1129) ダウンロードしてそれに対して高価な操作を加えなければなりません。
1130) 単一の/8ネットワーク内で同じIPアドレスを避けるというようなケースに
1131) 関する実地の概算は存在しないでしょうか？</li>
1132) <li>他の地理的多様性に関連したリサーチ質問は、効率的な回路を選択する
1133) こととランダムな回路を選択することとの間のトレードオフについて
1134) 言及しています。匿名性を"著しく"損なうことなく特に遅い回路を
1135) 捨てる方法について書かれたStephen Rollysonの<a
1136) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">
1137) ポジションペーパー</a>をご覧ください。この論証についてはさらに多くの
1138) 作業と思索が必要ですが、非常に有望と思われます。</li>
1139) <li>Torは、サーバが非対称の帯域幅を持つ場合(ケーブルないしDSL)にはあまり
1140) うまく機能しません。Torは各ホップ毎に個別のTCPコネクションを
1141) 張るので、入力バイトが順調に到着する一方で出力バイトが床にこぼれて
1142) しまっていると、TCPのプッシュバック機構はこの情報を入力
1143) ストリームに対してちゃんと返送することができないのです。
1144) 恐らく、Torは自身で出力パケットの多くがドロップされている場合にこれを
1145) 検出して、入力ストリームに対してレート制限をすることでこれを
1146) 調整するべきでしょうか？まず控えめなレート制限を掛け、そこから
1147) 徐々にレートを上げて行き、ロストパケットが出た時点で戻し、また繰り返す
1148) ーといったビルドアップ・ドロップオフ手法を想像できます。
1149) 私達は、これをネットワークでシミュレートして設計を助けてくれる
1150) 適当な方を探しています;さらに／またはパフォーマンス低下の限度を
1151) 知る必要があり、このことをUDPトランスポートを再考慮する動機と
1152) したいと考えています。</li>
1153) <li>関連する話題として、輻輳制御の問題があります。現在の私達の
1154) デザインは負荷の高い使用に耐えうるものなのでしょうか？恐らく、
1155) 私達は固定ウィンドウサイズよりも可変ウィンドウサイズを試して
1156) 見るべきでしょうか？<a
1157) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">SSH
1158) スループット実験</a>を見る限りうまく行っているように見えますが。
1159) 私達は測定して調整する必要があるでしょう。そして結果が良ければ
1160) より徹底した調査をすることになるでしょう。</li>

1161) <li>私たちの抗検閲の目標の一つとして、回線上のTorの通信を観察している
1162) 攻撃者が<a
1163) href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint">
1164) Torの通信を通常のSSLの通信と区別する</a>
1165) ことを妨げることが挙げられます。明らかに私たちは完全で依然利用可能な
1166) ステガノグラフィをを得ることは出来ませんが、始めの一歩として数個の
1167) パケットを観察しただけで成果をあげてしまうような攻撃はすべてブロック
1168) したいと考えています。私たちがあまり検証していないままの攻撃としては、
1169) Torのセルが512バイトであることから、回線上の通信が512バイトの倍数だろうと
1170) 推測するというものがあります。バッチングとTLSレコードのオーバーヘッド
1171) は回線上でこれをどれだけ曖昧にしてくれるでしょうか？1ビットのパディング
1172) でも大いに役立つのか、それともこれは我々が受容すべき攻撃なのでしょうか？</li>

1173) <li>Tor回路は一度に一ホップずつ構築されるので、理論的には二番目のホップ
1174) であるストリームを回路から離脱させ、三番目のホップでもまた別のストリーム
1175) を離脱させ、以下同様にすることが可能です。これはあるサーバから見ることの
1176) できる出力ストリームを分割することになるので良い方法だと思われます。
1177) しかし、各ストリームについて安全性を確保しようということになると、
1178) 私達の現在の理論によれば、安全な"最短の"パスは少なくとも3ホップの長さを
1179) 持っている必要があるため、残りはさらに長くなってしまいます。この
1180) パフォーマンス／セキュリティのトレードオフを検討する必要があります。</li>

1181) <li>Torリレーやディレクトリサーバに対してDoS攻撃を仕掛けることは

1182) そんなに難しいことではありません。クライアントは正しい答を得られずに
1183) 頭を悩ますでしょうか？他のアプローチもあるでしょうか？もしこれを
1184) 現在のTorプロトコルとの後方互換のまま修正できたらなお良いです。</li>

1185) <li><a
1186) href="<page torbutton/index>">Torbutton</a>のようなプログラムは、
1187) あなたのブラウザのUserAgent文字列を全Torユーザ共通の
1188) 答えで置き換えることによってそれを隠蔽することを狙いとしています。
1189) こうすることによって、攻撃者はヘッダを見てTorの匿名性集団を見破る
1190) ことが出来なくなります。それは非Torユーザにも広く使われている文字列を
1191) 選ぶようにしていますので、目立つことはありません。質問1:Torbuttonが
1192) 要求するFirefoxのバージョンへと定期的にアップデートするのにどれだけ
1193) 面倒な目に遭わなければいけないんでしょう？もし私たちがそれをあまりにも
1194) 頻繁にアップデートすれば、匿名集団が自ら露見してしまいます。しかし
1195) もしそれを十分頻繁にアップデートしなければ、すべてのTorユーザが
1196) Firefoxのかなり古いバージョンを運用すべきだと主張することで目立って
1197) しまうでしょう。これに対する答えは恐らく、ネット上で見られるFirefoxの
1198) バージョンによるでしょう。質問2:時々、人々がN個のUserAgent文字列を使いまわす
1199) ように依頼してくるのですが、このアプローチは役に立つ、悪い、無害のどれですか？
1200) 考慮すべき点:クッキーおよびローテートしているUserAgentからTorbuttonユーザを
1201) 識別すること;特定のブラウザだけを攻撃する悪意あるウェブサイト;
1202) 質問1の答えがこの質問の答えに影響を与えるかどうか。
1203) </li>
1204) <li>現在のところ、Torクライアントはある一つの回路を最初にそれが使用
1205) された時点から10分間再利用しようとします。これは、回路拡張作業を多く
1206) し過ぎてネットワークがダウンしてしまうのを防ぐ一方で、クライアントが
1207) あまりに長い時間同じ回路を使い続けて出口ノード
1208) が有用なクライアントの変名のプロファイルを構築できてしまうことを防ぐ
1209) ことを目的としています。残念なことに、10分間という時間は、
1210) 特に複数のプロトコルからの接続(例えばIMとウェブブラウジング)が同じ回路に
1211) 押しつけられた場合には、恐らく長すぎます。ネットワークが必要とする
1212) 回路拡張の総合計数を固定化し、クライアントがストリームを回路に
1213) 割り当てるより効率的かつ/または安全な方法、またはクライアントがプリエンプティブ
1214) な回路を構築できる方法はないでしょうか？恐らくこのリサーチ項目は、
1215) 典型的クライアントがどんな接続を起動しようとするかについてのトレースを
1216) 収集して、現実に何を最適化しようとすべきかを把握することから
1217) 始める必要があるでしょう。
1218) </li>
1219) <li>到達性を確保するためにいくつのブリッジリレーを知る必要があるでしょうか？
1220) ブリッジの中に常時稼働していないものがいくつあるのかを測定する
1221) 必要があります。もし多くの非常時稼働ブリッジがある場合には、ブリッジ
1222) ユーザが接続を維持しやすくなるような方法があるでしょうか？
1223) </li>

1224) </ol>
1225) 

1226) <p>

1227) これらの問題について何か前進があったら
1228) <a href="<page contact>">私達にお知らせください</a>！

1229) </p>