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) </li>

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

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

38) <ul>
39) <li><a

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

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

44) するためDug Songの"dsocks"プログラムにパッチを当てる必要があります。
45) これによって接続前に一通り名前解決を行う作業をTor内部で無駄にせずに済みます。</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="<svnprojects>design-paper/blocking.html">著しい進歩</a>

229) を遂げています。しかし、Torは依然としてその反検閲の設計のいくつかの
230) 部分についてよりよいメカニズムを必要としています。例えば、
231) 現在のTorは同時に単一のアドレス/ポートをリッスンすることしか

232) できません。<a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">

233) この制限に対処する提案</a>がなされていますが、これについてはまだ作業が
234) 必要です。これによってクライアントは
235) 任意の与えられたTorに対して複数のアドレスおよびポートで接続することができる
236) ようになります。もう一つの（ずっと難しい)反検閲プロジェクトは、Torをより
237) スキャニングに対して抵抗力のあるものにする試みです。現在の時点では、
238) 攻撃者はTorのプロトコルに従いそれらに対して接続を試みるだけで

239) <a href="<gitblob>doc/spec/proposals/125-bridges.txt">Torブリッジ</a>

240) を識別することができます。この問題を解決するには、ブリッジはポートスキャニング
241) ツールでコンタクトされたときには

242) <a href="<svnprojects>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) ありません。このプロジェクトには非技術者ユーザでも理解できなければ
372) ならないヘルプドキュメントを少し書くことが含まれることになりそう
373) なので、英文を書く能力が多少あればそれも役に立つでしょう。
374) 私たちは新しい光るアイコンを幾つか欲しい/必要としているので、
375) グラフィックデザイン/Photoshop fuが使えればなおよいでしょう。

376) </li>
377) 
378) <li>
379) <b>私たちのユニットテストプロセスを改良する</b>
380) <br />
381) Priority: <i>Medium</i>
382) <br />
383) Effort Level: <i>Medium</i>
384) <br />
385) Skill Level: <i>Medium</i>
386) <br />
387) Likely Mentors: <i>Nick, Roger</i>
388) <br />
389) Torにはまだまだテストが必要です。これは多方面にわたる作業になります。
390) 手始めに、私たちのユニットテストがカバーする範囲ーとりわけ
391) ユーティリティ関数以外の領域におけるーを大幅に増やさなければ
392) なりません。これには、グローバルスコープからロジックを切り離すために
393) Torのいくつかの部分について大規模なリファクタリング
394) が必要になるでしょう。
395) <br />
396) さらに、私たちのパフォーマンステストを自動化する必要があります。
397) 私たちはすでに私たちのregular integrationを自動化しテストコードを
398) コンパイルするためのbuildbotを持っています(Windowsでそれを
399) セットアップしてくれる方が必要ですが)が、私たちのネットワーク
400) シミュレーションテスト(<a
401) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>
402) にある)をより最近のTorのバージョンに合わせてアップデートし、
403) 単一のマシンまたは複数のマシン上でネットワークテストを起動して
404) 自動的に異なる役割におけるマシンのパフォーマンスの変化をテストすることが
405) 出来るように設計する必要があります。
406) </li>
407) 
408) <li>
409) <b>独立したTorクライアント実装の復活を助けてください</b>
410) <br />
411) Priority: <i>Medium</i>
412) <br />
413) Effort Level: <i>High</i>
414) <br />
415) Skill Level: <i>Medium to High</i>
416) <br />
417) Likely Mentors: <i>Karsten, Nick</i>
418) <br />
419) TorのクライアントをJavaで実装するアプローチのうちの一つ、例えば
420) <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
421) プロジェクト</a>
422) を復活させ、<a
423) href="http://code.google.com/android/">Android</a>上で動くように
424) しましょう。手始めとして既存のコードを移植してAndroid環境でそれを
425) 実行することになるでしょう。次に、そのコードが

426) <a href="<gitblob>doc/spec/dir-spec.txt">v3ディレクトリプロトコル</a>

427) のようなより新しいバージョンのTorプロトコルをサポートするように
428) アップデートしなければなりません。さらに、Torのヒドゥンサービスに
429) アクセスしさらにはそれを提供する機能をもサポートするなら行き届いたもの
430) になるでしょうが、それは必須というわけではありません。
431) <br />
432) これにあたる開発者はJavaの暗号APIを含む新しいJavaコードを理解してそれを
433) 書くことができなければなりません。Cのコードを読めるならそれも役に立つ
434) でしょう。既存のドキュメントを読み、それに基づいてコードを実装し、
435) ドキュメント化されていない項目があればドキュメントを改良していく意欲の
436) ある方でなければなりません。このプロジェクトのほとんどの部分は
437) コーディングに関するもので設計には少ししか関係しません。
438) </li>
439) 
440) <li>
441) <b>Torbuttonの新機能</b>
442) <br />
443) Priority: <i>Medium</i>
444) <br />
445) Effort Level: <i>High</i>
446) <br />
447) Skill Level: <i>High</i>
448) <br />
449) Likely Mentors: <i>Mike</i>
450) <br/>
451) Torbutton Flysprayの節の<a
452) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">
453) よい機能のリクエスト</a>にいくつかあります。特に、
454) <a
455) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">
456) '新しいID'をVidaliaに組み込む
457) </a>、
458) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">
459) 複数のクッキーjarおよびIDを管理する方法
460) </a>、 クッキーがクリアされる場合に<a
461) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">
462) 特定のクッキーを保存する
463) </a>、
464) 
465) <a
466) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">
467) よりよいリファラースプーフィング
468) </a>, <a
469) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">
470) 正しいTorステータスの報告
471) </a>、そして<a
472) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">
473) "tor://"および"tors://"URL</a>はすべて、もし実現できれば面白い機能です。
474) <br />
475) この作業はJavascriptの独立したコーディングと<a
476) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>
477) ファンの世界になり、Torの中身とはそれほど関係しないものになるでしょう。
478) </li>
479) 
480) <li>
481) <b>新しいThandyの機能 </b>
482) <br />
483) Priority: <i>Medium</i>
484) <br />
485) Effort Level: <i>Medium</i>
486) <br />
487) Skill Level: <i>Medium to High</i>
488) <br />
489) Likely Mentors: <i>Martin</i>
490) <br />
491) Windowsおよびその他のOSのためのTor関連ソフトウェアのアップデート補助の
492) 追加的機能が必要です。考えられる機能としては以下のようなものが挙げられます:
493) 1)認証付きHTTPSダウンロードのための<a
494) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto Python
495) ライブラリ</a>。
496) 2)タイムスタンプシグネチャとアップデートに含まれるパッケージファイルとの間
497) の迂回レベルを追加する。or-devの"Thandy attacks / suggestions"を参照。
498) 3)設定、ホスト、ユーザアカウント言語設定に基づき、
499) アップデート補助のロケールごとのインストールと設定をサポートする。
500) win32およびposix API全般の経験とPythonに習熟していることに加え、
501) Windowsコードページ、ユニコードおよびその他の文字セットに通じているとなお可。
502) </li>
503) 
504) <li>
505) <b>遅いインターネット接続のシミュレータ</b>
506) <br />
507) Priority: <i>Medium</i>
508) <br />
509) Effort Level: <i>Medium</i>
510) <br />
511) Skill Level: <i>Medium</i>
512) <br />
513) Likely Mentors: <i>Steven</i>
514) <br />
515) 多くのTorユーザは、狭い帯域幅、高いレイテンシ、高いパケットロスおよび再順序化を
516) 伴う低質なインターネット接続を利用しています。ユーザ経験上、
517) Torはこういった接続に対してはよい反応を示しません。しかし、
518) 問題を研究室で再現可能にせずしてこの状況を改善することは困難です。
519) <br />
520) このプロジェクトでは貧弱な接続を再現するシミュレーション環境を
521) 構築して、それがTorのパフォーマンスに与える影響を測定することが
522) できるようにすることになるでしょう。それ以外の要素としては、
523) 使用可能な接続の条件が何かを決定し、Torのパフォーマンスを向上させる
524) 変更の効果を測定するテストユーティリティが挙げられるでしょう。
525) <br />
526) 使用するツールは研究者にお任せしますが、dummynet(FreeBSD)および
527) nistnet(Linux)はこのプロジェクトがその基礎とすることのできる
528) 有力なコンポーネントです。研究者はネットワークプログラミング/
529) デバッギングおよびTCP/IPに通じていなければならず、できれば
530) Cと一つのスクリプト言語に慣れ親しんでいることが望まれます。
531) </li>
532) 
533) <li>
534) <b>Vidaliaのネットワークマップを改善してより使いやすいものにする</b>
535) <br />
536) Priority: <i>Low to Medium</i>
537) <br />
538) Effort Level: <i>Medium</i>
539) <br />
540) Skill Level: <i>Medium</i>
541) <br />
542) Likely Mentors: <i>Matt</i>
543) <br />
544) Vidaliaの既存の機能の一つとして、Torネットワーク上のリレーのおおまかな
545) 地理的位置をユーザに対して表示し、ユーザの行った通信がTorネットワークを
546) 通っていくに従ってそのパスを描画する、ネットワークマップがあります。
547) マップは現在のところあまりインタラクティブではなく、そのグラフィックは
548) かなり貧弱です。これに代えて、私たちはKDEのMarbleウィジットを実装して
549) より品質の良いマップを提供できるようにし、双方向性を向上させてユーザが
550) 個々のリレーをクリックしたり回路についての追加的情報を表示させることが
551) 可能になりました。私たちは、ユーザが特定のリレーまたは一個以上のTor出口
552) リレーが存在している国をクリックして、「私の接続はここから出て欲しい。」
553) と言えるような機能を追加したいと考えています。
554) <br />
555) このプロジェクトにはまずVidaliaおよびMarbleウィジットのAPIに慣れ親しむこと
556) が伴うでしょう。そののちにウィジットをVidaliaに統合しMarbleをカスタマイズ
557) して私たちのアプリケーションにより適合するようにすることになるでしょう。
558) それは例えば回路をクリック可能にすること、キャッシュされたマップデータを
559) Vidaliaの独自のデータディレクトリに格納すること、あるいはウィジットの
560) ダイアログのうちのいくつかをカスタマイズすることなどです。
561) <br />
562) このプロジェクトを遂行する人物は、C++開発について十分な経験を有している
563) 必要があります。QtおよびCMakeについての経験があればなおよいですが、
564) これは必須ではありません。
565) </li>
566) 
567) <li>
568) <b>moniTorを誕生させる</b>
569) <br />
570) Priority: <i>Low</i>
571) <br />
572) Effort Level: <i>Medium</i>
573) <br />
574) Skill Level: <i>Low to Medium</i>
575) <br />
576) Likely Mentors: <i>Karsten, Jacob</i>
577) <br />
578) Torリレーのための<a href="http://www.ss64.com/bash/top.html">topに似た</a>
579) 管理ツールを実装します。こういったツールの目的は、その制御ポートを通じて
580) ローカルのTorリレーをモニターし、実行しているマシンの有益なシステム情報
581) を盛りこむことです。このツールはtopがLinuxのプロセスに対してするのと
582) 同様、実行中にそのコンテンツを動的に更新することになるでしょう。
583) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">この
584) or-devの投稿</a>をまず始めに読むといいでしょう。
585) <br />
586) これに興味をお持ちの方は、Torリレーを管理することおよびそれを制御ポートを
587) 通じて調整することについて熟知しているかまたは学ぼうとする意欲があることが
588) 必要です。最初のプロトタイプはPythonで書かれていますので、Pythonを書くこと
589) についてのいくらかの知識があればそれも役に立つでしょう。
590) このプロジェクトはこういったツールに対する機能要求を同定することおよび
591) そのインターフェースをデザインすることと、多くのコーディングを行うこととの
592) 二つの部分に分けられます。
593) </li>
594) 
595) <li>
596) <b>ThunderbirdにもTorbuttonと同等のものを</b>
597) <br />
598) Priority: <i>Low</i>
599) <br />
600) Effort Level: <i>High</i>
601) <br />
602) Skill Level: <i>High</i>
603) <br />
604) Likely Mentors: <i>Mike</i>
605) <br />
606) ThunderbirdをTorとともに使いたいというユーザが増えていると聞いています。
607) しかしながら、それを実現するにはアプリケーションレベルにおける多くの課題
608) があります。例えば、Thunderbirdはデフォルトであなたのホスト名を送信する
609) メールに出力してしまいます。いずれかの時点で私たちはTorbuttonに似た
610) Thunderbird拡張を作成するための新たな行動を起こすべきでしょう。
611) </li>
612) 
613) <li>
614) <b>中間レベルネットワークデバイスドライバ</b>
615) <br />
616) Priority: <i>Low</i>
617) <br />
618) Effort Level: <i>High</i>
619) <br />
620) Skill Level: <i>High</i>
621) <br />
622) Likely Mentors: <i>Martin</i>
623) <br />
624) ブリッジを使用するネットワーキングのためにTorVMによって使用される
625) WinPCAPデバイスドライバは、いくつかの無線および非イーサネットネットワーク
626) アダプタをサポートしていません。win32および64ビット用の
627) 中間レベルデバイスドライバの実装があれば、そういったネットワーク上で
628) 通信を遮断したりルーティングしたりする道が開けます。
629) このプロジェクトはWindowsのカーネルデバイスドライバ開発およびテスティングの
630) 知識と経験を必要とするでしょう。WinsockおよびQemuについてよく知っていれば
631) それも役に立つでしょう。
632) </li>
633) 
634) <li>
635) <b>新しいアイディアを出してください！</b>
636) <br />
637) これらのうちのどれも気に入らない？
638) <a

639) href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor開発ロードマップ 

640) </a>を見てその他のアイディアを探してみてください。

641) <a href="<gittree>doc/spec/proposals/">現在の提案</a>のうちのいくつかもまた、

642) 開発者にとっては手短かに過ぎるかも知れません。
643) </li>
644) 
645) <!-- Mike is already working on this.
646) <li>
647) <b>Tor Node Scanner improvements</b>
648) <br />
649) Similar to the SoaT exit scanner (or perhaps even during exit scanning),
650) statistics can be gathered about the reliability of nodes. Nodes that
651) fail too high a percentage of their circuits should not be given
652) Guard status. Perhaps they should have their reported bandwidth
653) penalized by some ratio as well, or just get marked as Invalid. In
654) addition, nodes that exhibit a very low average stream capacity but
655) advertise a very high node bandwidth can also be marked as Invalid.
656) Much of this statistics gathering is already done, it just needs to be
657) transformed into something that can be reported to the Directory
658) Authorities to blacklist/penalize nodes in such a way that clients
659) will listen.
660) <br />
661) In addition, these same statistics can be gathered about the traffic
662) through a node. Events can be added to the <a
663) href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Tor Control
664) Protocol</a> to
665) report if a circuit extend attempt through the node succeeds or fails, and
666) passive statistics can be gathered on both bandwidth and reliability
667) of other nodes via a node-based monitor using these events. Such a
668) scanner would also report information on oddly-behaving nodes to
669) the Directory Authorities, but a communication channel for this
670) currently does not exist and would need to be developed as well.
671) </li>
672) -->
673) 
674) <!-- Is this still a useful project? If so, move it to another section.
675) <li>
676) <b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>
677) <br />
678) Vidalia currently doesn't play nicely on Debian and Ubuntu with the
679) default Tor packages. The current Tor packages automatically start Tor
680) as a daemon running as the debian-tor user and (sensibly) do not have a

681) <a href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> defined

682) in the default torrc. Consequently, Vidalia will try
683) to start its own Tor process since it could not connect to the existing
684) Tor, and Vidalia's Tor process will then exit with an error message
685) the user likely doesn't understand since Tor cannot bind its listening
686) ports — they're already in use by the original Tor daemon.
687) <br />
688) The current solution involves either telling the user to stop the
689) existing Tor daemon and let Vidalia start its own Tor process, or
690) explaining to the user how to set a control port and password in their
691) torrc. A better solution on Debian would be to use Tor's ControlSocket,
692) which allows Vidalia to talk to Tor via a Unix domain socket, and could
693) possibly be enabled by default in Tor's Debian packages. Vidalia can
694) then authenticate to Tor using filesystem-based (cookie) authentication
695) if the user running Vidalia is also in the debian-tor group.
696) <br />
697) This project will first involve adding support for Tor's ControlSocket
698) to Vidalia. The student will then develop and test Debian and Ubuntu
699) packages for Vidalia that conform to Debian's packaging standards and
700) make sure they work well with the existing Tor packages. We can also
701) set up an apt repository to host the new Vidalia packages.
702) <br />
703) The next challenge would be to find an intuitive usable way for Vidalia
704) to be able to change Tor's configuration (torrc) even though it is
705) located in <code>/etc/tor/torrc</code> and thus immutable. The best
706) idea we've come up with so far is to feed Tor a new configuration via
707) the ControlSocket when Vidalia starts, but that's bad because Tor starts
708) each boot with a different configuration than the user wants. The second
709) best idea
710) we've come up with is for Vidalia to write out a temporary torrc file
711) and ask the user to manually move it to <code>/etc/tor/torrc</code>,
712) but that's bad because users shouldn't have to mess with files directly.
713) <br />
714) A person undertaking this project should have prior knowledge of
715) Debian package management and some C++ development experience. Previous
716) experience with Qt is helpful, but not required.
717) </li>
718) -->
719) 
720) <!-- This should be mostly done.
721) <li>
722) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
723) <br />
724) We're in need of a good authenticated-update framework.
725) Vidalia already has the ability to notice when the user is running an
726) outdated or unrecommended version of Tor, using signed statements inside
727) the Tor directory information. Currently, Vidalia simply pops
728) up a little message box that lets the user know they should manually
729) upgrade. The goal of this project would be to extend Vidalia with the
730) ability to also fetch and install the updated Tor software for the
731) user. We should do the fetches via Tor when possible, but also fall back
732) to direct fetches in a smart way. Time permitting, we would also like
733) to be able to update other
734) applications included in the bundled installers, such as Polipo and
735) Vidalia itself.
736) <br />
737) To complete this project, the student will first need to first investigate
738) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
739) their strengths, weaknesses, security properties, and ability to be
740) integrated into Vidalia. If none are found to be suitable, the student
741) will design their own auto-update framework, document the design, and
742) then discuss the design with other developers to assess any security
743) issues. The student will then implement their framework (or integrate
744) an existing one) and test it.
745) <br />
746) A person undertaking this project should have good C++ development
747) experience. Previous experience with Qt is helpful, but not required. One
748) should also have a good understanding of common security
749) practices, such as package signature verification. Good writing ability
750) is also important for this project, since a vital step of the project
751) will be producing a design document to review and discuss
752) with others prior to implementation.
753) </li>
754) -->
755) 
756) <!-- Jake already did most of this.
757) <li>
758) <b>Improvements on our active browser configuration tester</b> -
759) <a href="https://check.torproject.org/">https://check.torproject.org/</a>
760) <br />
761) We currently have a functional web page to detect if Tor is working. It
762) has a few places where it falls short. It requires improvements with
763) regard to default languages and functionality. It currently only responds
764) in English. In addition, it is a hack of a perl script that should have
765) never seen the light of day. It should probably be rewritten in python
766) with multi-lingual support in mind. It currently uses the <a
767) href="http://exitlist.torproject.org/">Tor DNS exit list</a>
768) and should continue to do so in the future. It currently result in certain
769) false positives and these should be discovered, documented, and fixed
770) where possible. Anyone working on this project should be interested in
771) DNS, basic perl or preferably python programming skills, and will have
772) to interact minimally with Tor to test their code.
773) <br />
774) If you want to make the project more exciting
775) and involve more design and coding, take a look at <a

776) href="<gitblob>doc/spec/proposals/131-verify-tor-usage.txt">proposal

777) 131-verify-tor-usage.txt</a>.
778) </li>
779) -->
780) 
781) <!-- If we decide to switch to the exit list in TorStatus, this is obsolete.
782) <li>
783) <b>Improvements on our DNS Exit List service</b> -
784) <a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
785) <br />
786) The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
787) is written by our fabulous anonymous
788) contributer Tup. It's a DNS server written in Haskell that supports part of our <a

789) href="<gitblob>doc/contrib/torel-design.txt">exitlist

790) design document</a>. Currently, it is functional and it is used by
791) check.torproject.org and other users. The issues that are outstanding
792) are mostly aesthetic. This wonderful service could use a much better
793) website using the common Tor theme. It would be best served with better
794) documentation for common services that use an RBL. It could use more
795) publicity. A person working on this project should be interested in DNS,
796) basic RBL configuration for popular services, and writing documentation.
797) The person would require minimal Tor interaction &mdash; testing their
798) own documentation at the very least. Furthermore, it would be useful
799) if they were interested in Haskell and wanted to implement more of the
800) torel-design.txt suggestions.
801) </li>
802) -->
803) 
804) <!-- Nobody wanted to keep this.
805) <li>
806) <b>Testing integration of Tor with web browsers for our end users</b>
807) <br />
808) The Tor project currently lacks a solid test suite to ensure that a
809) user has a properly and safely configured web browser. It should test for as
810) many known issues as possible. It should attempt to decloak the
811) user in any way possible. Two current webpages that track these
812) kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
813) href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
814) with their proof of concept code, bug issues, etc</a>. HD Moore runs
815) the <a href="http://www.decloak.net/">metasploit
816) decloak website</a>. A person interested in defending Tor could start
817) by collecting as many workable and known methods for decloaking a
818) Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
819) be helpful as a start.) One should be familiar with the common pitfalls but
820) possibly have new methods in mind for implementing decloaking issues. The
821) website should ensure that it tells a user what their problem is. It
822) should help them to fix the problem or direct them to the proper support
823) channels. The person should also be closely familiar with using Tor and how
824) to prevent Tor information leakage.
825) </li>
826) -->
827) 
828) <!-- Nick did quite some work here. Is this project still required then?
829) <li>
830) <b>Libevent and Tor integration improvements</b>
831) <br />
832) Tor should make better use of the more recent features of Niels
833) Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
834) library.  Tor already uses Libevent for its low-level asynchronous IO
835) calls, and could also use Libevent's increasingly good implementations
836) of network buffers and of HTTP.  This wouldn't be simply a matter of
837) replacing Tor's internal calls with calls to Libevent: instead, we'll
838) need to refactor Tor to use Libevent calls that do not follow the
839) same models as Tor's existing backends. Also, we'll need to add
840) missing functionality to Libevent as needed &mdash; most difficult likely
841) will be adding OpenSSL support on top of Libevent's buffer abstraction.
842) Also tricky will be adding rate-limiting to Libevent.
843) </li>
844) -->
845) 
846) <!--
847) <li>
848) <b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
849) <br />
850) It would be useful to have automated build processes for Windows and
851) probably other platforms. The purpose of having a continuous integration
852) build environment is to ensure that Windows isn't left behind for any of
853) the software projects used in the Tor project or its accompanying.<br />
854) Buildbot may be a good choice for this as it appears to support all of
855) the platforms Tor does. See the
856) <a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
857) buildbot</a>.<br />
858) There may be better options and the person undertaking this task should
859) evaluate other options. Any person working on this automatic build
860) process should have experience or be willing to learn how to build all
861) of the respective Tor related code bases from scratch. Furthermore, the
862) person should have some experience building software in Windows
863) environments as this is the target audience we want to ensure we do not
864) leave behind. It would require close work with the Tor source code but
865) probably only in the form of building, not authoring.<br />
866) Additionally, we need to automate our performance testing for all platforms.
867) We've got buildbot (except on Windows &mdash; as noted above) to automate
868) our regular integration and compile testing already,
869) but we need to get our network simulation tests (as built in torflow)
870) updated for more recent versions of Tor, and designed to launch a test
871) network either on a single machine, or across several, so we can test
872) changes in performance on machines in different roles automatically.
873) </li>
874) -->
875) 
876) <!-- Removed, unless Mike still wants this to be in.
877) <li>
878) <b>Torbutton improvements</b>
879) <br />
880) Torbutton has a number of improvements that can be made in the post-1.2
881) timeframe. Most of these are documented as feature requests in the <a
882) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">Torbutton
883) flyspray section</a>. Good examples include: stripping off node.exit on http
884) headers, more fine-grained control over formfill blocking, improved referrer
885) spoofing based on the domain of the site (a-la <a
886) href="https://addons.mozilla.org/en-US/firefox/addon/953">refcontrol extension</a>),
887) tighter integration with Vidalia for reporting Tor status, a New Identity
888) button with Tor integration and multiple identity management, and anything
889) else you might think of.
890) <br />
891) This work would be independent coding in Javascript and the fun world of <a
892) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
893) with not too much involvement in the Tor internals.
894) </li>
895) -->
896) 
897) <!-- Is Blossom development still happening?
898) <li>
899) <b>Rework and extend Blossom</b>
900) <br />
901) Rework and extend Blossom (a tool for monitoring and
902) selecting appropriate Tor circuits based upon exit node requirements
903) specified by the user) to gather data in a self-contained way, with
904) parameters easily configurable by the user.  Blossom is presently
905) implemented as a single Python script that interfaces with Tor using the
906) Controller interface and depends upon metadata about Tor nodes obtained
907) via external processes, such as a webpage indicating status of the nodes
908) plus publically available data from DNS, whois, etc.  This project has
909) two parts: (1) Determine which additional metadata may be useful and
910) rework Blossom so that it cleanly obtains the metadata on its own rather
911) than depend upon external scripts (this may, for example, involve
912) additional threads or inter-process communication), and (2) develop a
913) means by which the user can easily configure Blossom, starting with a
914) configuration file and possibly working up to a web configuration engine.
915) Knowledge of Tor and Python are important; knowledge of
916) TCP, interprocess communication, and Perl will also be helpful.  An
917) interest in network neutrality is important as well, since the
918) principles of evaluating and understanding internet inconsistency are at
919) the core of the Blossom effort.
920) </li>
921) 
922) <li>
923) <b>Improve Blossom: Allow users to qualitatively describe exit nodes they desire</b>
924) <br />
925) Develop and implement a means of affording Blossom
926) users the ability to qualitatively describe the exit node that they
927) want.  The Internet is an inconsistent place: some Tor exit nodes see
928) the world differently than others.  As presently implemented, Blossom (a
929) tool for monitoring and selecting appropriate Tor circuits based upon
930) exit node requirements specified by the user) lacks a sufficiently rich
931) language to describe how the different vantage points are different.
932) For example, some exit nodes may have an upstream network that filters
933) certain kinds of traffic or certain websites.  Other exit nodes may
934) provide access to special content as a result of their location, perhaps
935) as a result of discrimination on the part of the content providers
936) themselves.  This project has two parts: (1) develop a language for
937) describing characteristics of networks in which exit nodes reside, and
938) (2) incorporate this language into Blossom so that users can select Tor
939) paths based upon the description.
940) Knowledge of Tor and Python are important; knowledge of
941) TCP, interprocess communication, and Perl will also be helpful.  An
942) interest in network neutrality is important as well, since the
943) principles of evaluating and understanding internet inconsistency are at
944) the core of the Blossom effort.
945) </li>
946) -->
947) 
948) <!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X
949) <li>
950) <b>Usability testing of Tor</b>
951) <br />
952) Priority: <i>Medium</i>
953) <br />
954) Effort Level: <i>Medium</i>
955) <br />
956) Skill Level: <i>Low to Medium</i>
957) <br />
958) Likely Mentors: <i>Andrew</i>
959) <br />
960) Especially the browser bundle, ideally amongst our target demographic.
961) That would help a lot in knowing what needs to be done in terms of bug
962) fixes or new features. We get this informally at the moment, but a more
963) structured process would be better.
964) </li>
965) -->
966) 
967) </ol>
968) 
969) <a id="OtherCoding"></a>
970) <h2><a class="anchor" href="#OtherCoding">その他コーディングおよび設計に関するアイディア</a></h2>
971) <ol>
972) <li>TorリレーがWindows XP上でうまく動きません。Windows上では、

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

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

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

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

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

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

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

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

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

1007) 

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

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

1014) <li><a

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

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

1020) 

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

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

1027) 私達が未だにUDPトランスポートへ移行していない理由のリスト</a>がありますが、
1028) このリストがもし今よりも短くなるのなら素晴らしいことです。
1029) この他にも、提案中の<a

1030) href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">

1031) TorとUDPの仕様</a>がありますーもしこれに誤りが含まれていたら

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

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

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

1050) </ol>
1051) 
1052) <a id="Research"></a>
1053) <h2><a class="anchor" href="#Research">リサーチ</a></h2>
1054) <ol>
1055) <li>"ウェブサイトフィンガープリント攻撃":
1056) 	数百におよぶ人気のあるウェブサイトのリストを作成してそれらのページを
1057) ダウンロードし、サイト毎に"シグネチャ"のセットを作ります。その上で、
1058) Torクライアントのトラフィックを監視します。あるクライアントが
1059) データを受信したのを観察したら、すばやくどのサイト(もし件のリストに
1060) 該当するものがあれば)にアクセスしたのかを訪れたのかの推測を
1061) 試みるのです。第一に、この攻撃は配備済みのTorコードベースに対して
1062) どの程度有効なのでしょうか？次にこれに対する防御について
1063) 考えてみましょう:　例えば、Torのセルサイズを512バイトから
1064) 1024バイトに変更する、<a
1065) href="http://freehaven.net/anonbib/#timing-fc2004">
1066) ディフェンシブドロッピング</a>と同様のパディングテクニックを採用する、
1067) あるいはトラフィック遅延を加えることが考えられます。
1068) これらの対策を採用して防御に成功した場合、その影響はどれくらいで、利便性は
1069) どの程度(何か適当な測定基準を用いて)の影響を被ることになるでしょうか？
1070) </li>

1071) <li><a

1072) href="http://freehaven.net/anonbib/#danezis:pet2004">
1073) トラフィックシグネチャを比較することで同じストリームを監視している
1074) ことに確信を持つ</a>ことができます。これまでのところ、Torはこの
1075) 攻撃のついてはやむを得ないことでどのような場合でもこれは些細な
1076) ことに過ぎないと考えてきました。そもそも、それは本当に可能な
1077) 方法なのでしょうか？敵が勝利を確信するまでにいったいどのような
1078) 種類の、どれだけ多くのトラフィックが必要となるのでしょうか？
1079) 攻撃をスローダウンさせるようなシナリオ(例えば転送量が少ないとか)
1080) があるのでしょうか？トラフィックパディングまたはトラフィック
1081) シェイピング手法は他の手段より有効でしょうか？</li>

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

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

1158) <li>私たちの抗検閲の目標の一つとして、回線上のTorの通信を観察している
1159) 攻撃者が<a

1160) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">

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

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

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

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

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

1221) </ol>
1222) 

1223) <p>

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

1226) </p>