tor-webwml.git

1) 
2) 

3) 
4) 
5) 
6) 
7) ## translation metadata
8) # Revision: $Revision$
9) # Translation-Priority: 4-optional
10) #include "head.wmi" TITLE="Tor: Volunteer" CHARSET="UTF-8"

11) <div class="main-column">
12) 

13) 

14) <!-- PUT CONTENT AFTER THIS TAG -->

15) <h2>Kilka rzeczy, które każdy może zrobić już teraz:</h2>

16) <ol>

17) <li>Prosimy rozważyć <a href="<page docs/tor-doc-relay>">uruchomienie

18) przekaźnika sieci Tor</a>, by wspomóc rozwój sieci Tora.</li>
19) <li>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili przekaźniki
20) sieci. Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor
21) swoim znajomym.</li>
22) <li>Jeśli podobają ci się cele Tora, <a href="<page donate>">poświęć chwilę, by
23) złożyć dotację, aby wspomóc przyszły rozwój Tora</a>. Szukamy też dalszych
24) sponsorów &mdash; jeśli znasz jakieś firmy, organizacje pozarządowe, agencje
25) lub inne organizacje, które są zainteresowane anonimowością / prywatnością /
26) bezpieczną komunikacją, daj im znać o nas.</li>

27) <li>Szukamy więcej <a href="<page torusers>">dobrych przykładów użytkowników

28) Tora i przypadków jego używania</a>. Jeśli używasz Tora w sposób jeszcze nie
29) przedstawiony na tamtej stronie i nie masz nic przeciw podzieleniu się z
30) nami tym sposobem, z chęcią przyjmiemy taką wiadomość.</li>

31) </ol>
32) 

33) <p>Tor ma <a href="<page open-positions>">dwa wolne etaty</a>, prosimy <a
34) href="<page contact>">skontaktuj się z nami</a>, jeśli masz kwalifikacje!</p>

35) 

36) <a id="Documentation"></a>
37) <h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>

38) <ol>

39) <li>Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na <a
40) href="<page translation>">wskazówki do tłumaczenia</a>, jeśli chcesz
41) pomóc. Potrzebujemy zwłaszcza tłumaczy na język arabski i Farsi dla wielu
42) użytkowników Tora w cenzorowanych obszarach.</li>

43) <li>Evaluate and document <a
44) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO">our
45) list of programs</a> that can be configured to use Tor.</li>
46) <li>We have a huge list of <a
47) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/SupportPrograms">potentially
48) useful programs that interface to Tor</a>. Which ones are useful in which
49) situations? Please help us test them out and document your results.</li>

50) </ol>
51) 

52) <a id="Advocacy"></a>
53) <h2><a class="anchor" href="#Advocacy">Pokazanie się jako zwolennik Tora</a></h2>
54) <ol>

55) <li>Create a <a
56) href="https://trac.torproject.org/projects/tor/wiki/CommunityLogos">community
57) logo</a> under a Creative Commons license that all can use and modify</li>

58) <li>Stwórz prezentację, której będzie można używać na spotkaniach różnych grup
59) na całym świecie</li>

60) <li>Create a video about the positive uses of Tor, what Tor is, or how to use
61) it.  Some have already started on <a
62) href="http://media.torproject.org/video/">Tor's Media server</a>, <a
63) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,
64) and <a href="http://www.youtube.com/thetorproject">Youtube</a>.</li> 

65) <li>Stwórz plakat, lub zestaw plakatów, skupionych na jakimś motywie, np. "Tor
66) to Wolność!"</li>

67) </ol>
68) 

69) <a id="Coding"></a> <a id="Summer"></a> <a id="Projects"></a>

70) <h2><a class="anchor" href="#Projects">Dobre Projekty Programistyczne</a></h2>

71) 
72) <p>

73) Niektóre z tych projektów mogą być dobrymi pomysłami na <a href="<page
74) gsoc>">Google Summer of Code 2010</a>. Opisaliśmy każdy z nich informacją,
75) jak użyteczny byłby dla projektu Tor (priorytet), ile pracy według nas
76) wymaga (poziom wysiłku), z iloma informacjami powinno się zaczynać (poziom
77) umiejętności), i którzy z naszych <a href="<page people>#Core">głównych
78) deweloperów</a> byliby dobrymi opiekunami. Jeśli jeden lub więcej z tych
79) pomysłów wygląda dla Ciebie obiecująco, <a href="<page contact>">skontaktuj
80) się z nami</a>, by omówić Twoje plany zamiast wysyłać zgłoszenia na
81) ślepo. Możesz też zaproponować swój własny pomysł na projekt &mdash; co
82) często daje najlepsze programy.

83) </p>
84) 

85) <ol>
86) 
87) <li>

88) <b>Paczka Tora z Przeglądarką dla Mac OS X</b> <br /> Priorytet:
89) <i>Wysoki</i> <br /> Poziom wysiłku: <i>Wysoki</i> <br /> Poziom
90) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Steven,
91) Erinn, Andrew, Jacob</i> <br /> Paczka Tora z Przeglądarką zawiera Tora,
92) Firefoksa, Polipo i interfejs użytkownika - Vidalię (i opcjonalnie
93) komunikator <a href="http://pidgin.im/">Pidgin</a>). Komponenty te są
94) prekonfigurowane do bezpiecznego działania, a paczka ma małe wymagania co do
95) systemu operacyjnego. Stała się więc jednym z najprostszych i najbardziej
96) popularnych sposobów używania Tora na Windows. <br /> Nie ma jednak w chwili
97) obecnej działającej paczki dla Mac OS X, więc celem tego projektu byłaby
98) implementacja Paczki Tora z Przeglądarką dla OS X. Będzie to pociągało
99) zmiany w Vidalii (C++), być może w Firefoksie (C), po czym stworzenie i
100) testowanie programu uruchamiającego na różnych wersjach i konfiguracjach
101) systemów operacyjnych, by sprawdzić przenośność. Część pracy w tym temacie
102) została wykonana w czasie Google Summer of Code 2009. Kolejną częścią
103) projektu będzie zidentyfikowanie wszystkich śladów pozostawionych na
104) komputerze przez korzystanie z Paczki Tora z Przeglądarką na Linuksie lub
105) Mac OS X. Rozwijanie sposobów na powstrzymanie, przeciwdziałanie lub
106) usuwanie tych śladów będzie ostatnim krokiem. <br /> Studenci powinni być
107) zaznajomieni z rozwojem aplikacji na jednym, lub najlepiej obu, Linuksie i
108) Mac OS X oraz czuć się swobodnie z C/C++ i pisaniem skryptów powłoki.<br />
109) Częścią tego projektu byłoby testowanie użyteczności Paczki Tora z
110) Przeglądarką, najlepiej pośród naszej widowni docelowej. To pomogłoby w
111) dowiedzeniu się, co musi zostać zrobione w kontekście usuwania błędów lub
112) dodawania nowych funkcjonalności. W tej chwili dostajemy to nieformalnie, a
113) lepszy byłby proces mający strukturę.<br /> Wersja beta Paczki Tora z
114) Przeglądarką została wydana dla systemu GNU/Linux, ale wymagane jest więcej
115) pracy w Paczce Tora z Przeglądarką i IM. Prace trwają też już dla wersji Mac
116) OS X. Jeśli chcesz pomóc w rozszerzeniu, przeprowadzać audyty bezpieczeństwa
117) (lub obie te rzeczy), skontaktuj się z Erinn.

118) </li>
119) 

120) <li>

121) <b>Pomóż śledzić ogólny status Sieci Tora</b> <br /> Priorytet: <i>Średni do
122) wysokiego</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
123) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Karsten,
124) Roger</i> <br /> Byłoby wspaniale uruchomić automatyczny system śledzenia
125) stanu sieci w czasie, wyświetlanie wykresów itp. Częścią tego projektu
126) byłoby wynalezienie lepszych miary do oceny stanu i wzrostu sieci. Czy
127) wzrasta średni czas działania sieci? Ile węzłów kwalifikuje się do bycia
128) Strażnikami w tym miesiącu w porównaniu z ubiegłym? Jaka jest rotacja w
129) sensie pojawiania się nowych węzłów i znikania starych? Okresowo ludzie
130) gromadzą krótkie migawki stanu, ale to robi się naprawdę interesujące
131) dopiero, gdy zaczynamy śledzić te dane w czasie. <br /> Dane mogłyby być
132) zbierane ze Skanerów Węzłów Tora w <a

133) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, z

134) deskryptorów serwerów, które są publikowane przez każdy przekaźnik i z
135) innych źródeł. Wyniki w czasie mogłyby być zintegrowane z jedną ze stron
136) opisujących <a href="https://torstatus.blutmagie.de/">Stan Tora</a> lub być
137) trzymane osobno. Skoro mówimy o stronach stanu Tora, spójrzcie na <a
138) href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">listę życzeń

139) stanu Tora</a> napisaną przez Rogera.
140) </li>
141) 
142) <li>

143) <b>Rewrite TorDNSEL, this time with a spec!</b> <br /> Priority: <i>High</i>
144) <br /> Effort Level: <i>Medium</i> <br /> Skill Level: <i>Medium</i> <br />
145) Likely Mentors: <i>Mike, Roger, Sebastian, Damian</i> <br /> The <a
146) href="<page tordnsel/index>">Tor DNS Exit List</a> is an unmaintained
147) Haskell program that serves three purposes. First, it provides an rbl-style
148) DNS interface for people to look up whether a given IP address is (or has
149) recently been) a Tor exit relay. Second, it actively builds circuits over
150) the Tor network and connects back to itself, to learn the actual exit IP
151) address of each relay &mdash; some Tor relays exit from a different address
152) than they advertise in their descriptor. Third, it exports a <a
153) href="http://exitlist.torproject.org/exitAddresses">set of conclusions</a>
154) so that <a href="https://check.torproject.org/">check.torproject.org</a> can
155) guess for you whether your browser is configured to point to Tor.  <br />
156) This project would make use of <a
157) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, a
158) set of Python scripts to interact with Tor, to figure out how our Tor Exit
159) Checker should actually work, and then build it &mdash; probably in Python
160) since Torflow is in Python. The main goal is to reduce false positives as
161) much as possible, by making sure that it learns about new relays as soon as
162) possible, making sure that the testing phase concludes quickly, and making
163) sure the answers get passed to the Check script quickly. As a bonus, we
164) should standardize (specify) the format of the exitAddresses file, and
165) rewrite the <a

166) href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor

167) Bulk Exit List</a> script to use that file rather than its current <a
168) href="https://trac.torproject.org/projects/tor/ticket/1019">horrible DNS
169) hacks</a>. As an extra bonus, we should work with Freenode, OFTC, and/or
170) other IRC networks to make sure that the scripts we offer are actually the
171) scripts they want, in terms of accurately identifying which of their users
172) are coming from the Tor network.  <br /> You can fetch the <a
173) href="git://git.torproject.org/git/tordnsel">latest tordnsel</a> via git.

174) </li>
175) 
176) <li>

177) <b>Polepszanie naszych zdolności opierania się cenzurze</b> <br />
178) Priorytet: <i>Średni do wysokiego</i> <br /> Poziom wysiłku: <i>Średni do
179) wysokiego</i> <br /> Poziom umiejętności: <i>Wysoki</i> <br /> Prawdopodobni
180) opiekunowie: <i>Nick, Roger, Steven</i> <br /> Wersje 0.2.1.x Tora robią <a
181) href="<svnprojects>design-paper/blocking.html">znaczne postępy</a> w
182) opieraniu się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje
183) lepszych mechanizmów w niektórych częściach projektu anty-cenzurowania. <br
184) /> Jedną z dużych kategorii jest dodawanie funkcjonalności do naszej usługi
185) <a href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
186) (Python). Tor chce dawać <a href="<page bridges>">adresy przekaźników
187) mostkowych</a> użytkownikom nie mogącym bezpośrednio połączyć się z siecią
188) Tora, ale trwa wyścig zbrojeń między algorytmami dystrybucji adresów a
189) algorytmami do zbierania i blokowania adresów. Przeczytaj <a
190) href="https://blog.torproject.org/blog/bridge-distribution-strategies">nasz
191) wpis o tym na blogu</a> jako wprowadzenie, a potem spójrz na <a
192) href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">post Rogera na
193) or-dev</a> z grudnia, by poznać nowsze pomysły &mdash; pozostało do
194) zrobienia wiele pracy projektowej. <br /> Jeśli chcesz wejść bardziej we
195) wnętrze samego Tora (C), pomniejszym problemem, którym powinniśmy się zająć
196) jest to, że bieżące wersje mogą nasłuchiwać połączeń tylko na jednym
197) zestawie adres/port na raz. Istnieje <a
198) href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">propozycja
199) zajęcia się tą sprawą</a> i umożliwienia klientom łączenią się z danym Torem
200) na wielu adresach i portach, ale wymaga to więcej pracy.<br /> Ten projekt
201) zawiera wiele badań i projektowania. Jednym z większych wyzwań będzie
202) zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą się atakom
203) nawet po tym, jak atakujący pozna projekt, po czym równoważenie odporności
204) na cenzurę z użytecznością i siłą.

205) </li>
206) 

207) 
208) 
209) <!--<li>
210) 
211) <b>Tuneup Tor!</b>

212) <br />

213) Priority: <i>Medium to High</i>
214) <br />
215) Effort Level: <i>Medium to High</i>
216) <br />
217) Skill Level: <i>High</i>
218) <br />
219) Likely Mentors: <i>Nick, Roger, Mike, Karsten</i>
220) <br />
221) Right now, Tor relays measure and report their own bandwidth, and Tor
222) clients choose which relays to use in part based on that bandwidth.
223) This approach is vulnerable to
224) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
225) relays lie about their bandwidth</a>;
226) to address this, Tor currently caps the maximum bandwidth
227) it's willing to believe any relay provides.  This is a limited fix, and
228) a waste of bandwidth capacity to boot.  Instead,
229) Tor should possibly measure bandwidth in a more distributed way, perhaps
230) as described in the
231) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
232) Tor"</a> paper
233) by Snader and Borisov. One could use current testing code to
234) double-check this paper's findings and verify the extent to which they
235) dovetail with Tor as deployed in the wild, and determine good ways to
236) incorporate them into their suggestions Tor network without adding too
237) much communications overhead between relays and directory
238) authorities.
239) </li>-->
240) <li>
241) <b>Ulepszenie Polipo na Windows</b> <br /> Priorytet: <i>Średni do
242) Wysokiego</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
243) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Chris</i>
244) <br /> Pomóż przenieść <a
245) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na
246) Windows. Przykładowe tematy to:
247) <ol><li> zdolność do asynchronicznego wysyłania zapytań do serwerów nazw, znajdowania
248) systemowych serwerów nazw i zarządzanie zapytaniami NetBIOS i DNS.</li>
249) <li> natywna obsługa zdarzeń i buforów (tj. w systemach uniksopodobnych Polipo
250) domyślnie używa 25% pamięci RAM, a pod Windows jest to cokolwiek wpisane w
251) plik konfiguracyjny).</li>
252) <li> jakieś narzędzie z graficznym interfejsem do konfiguracji i raportowania,
253) dodatkowe punkty, jeśli ma ikonkę w zasobniku z opcjami menu po kliknięciu
254) prawym przyciskiem myszy. Podwójny bonus, jeśli działa na wielu platformach.</li>
255) <li> umożliwienie programowi używania rejestru Windowsa i obsługiwania
256) prawidłowych ścieżek w Windowsie, np. "C:\Program Files\Polipo".</li>
257) </ol>

258) </li>
259) 

260) <li>

261) <b>Interfejs zdarzeń stanu kontrolera Tora dla programu Vidalia</b> <br />
262) Priorytet: <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
263) umiejętności: <i>Niski do średniego</i> <br /> Prawdopodobni opiekunowie:
264) <i>Matt</i> <br /> Jest pewna liczba zmian stanu, o których użytkownik
265) powinien być informowany. Na przykład, jeśli użytkownik chce uruchomić
266) przekaźnik sieci Tor, a Tor stwierdzi, że nie jest on osiągalny z zewnątrz,
267) użytkownik powinien zostać o tym poinformowany. W tej chwili wszystko, co
268) dostaje użytkownik, to kilka wiadomości w "dzienniku wiadomości" Vidalii,
269) których pewnie nie zobaczy, gdyż nie dostaje informacji, że coś poszło nie
270) tak. Nawet jeśli użytkownik spojrzy na zapis logów, większość wiadomości
271) będzie miała mały sens dla początkującego. <br /> Tor ma możliwość
272) informowania Vidalii o wielu takich zmianach stanu, a ostatnio

273) zaimplementowaliśmy obsługę kilku takich zdarzeń. Jednak jest wiele więcej
274) zdarzeń, o których użytkownik powinien być informowany i potrzebujemy

275) lepszego interfejsu użytkownika do wyświetlania takich wiadomości. <br />

276) Celem tego projektu jest zaprojektowanie i zaimplementowanie interfejsu
277) użytkownika do wyświetlania wiadomości o stanie Tora. Na przykład, można

278) byłoby umieścić mały znaczek na ikonie Vidalii w zasobniku, który
279) alarmowałby użytkownika o nowych zmianach stanu, którym powinien się
280) przyjrzeć. Podwójne kliknięcie tej ikonki pokazywałoby okienko dialogowe
281) podsumowujące ostatnie zmiany stanu prostymi słowami i może sugerujące
282) rozwiązania do negatywnych wiadomości, jeśli mogą one być naprawione przez
283) użytkownika. Oczywiście to tylko przykład i można zaproponować inne
284) podejście. <br /> Osoba podejmująca się tego projektu powinna dobrze znać
285) projektowanie i tworzenie interfejsu użytkownika i mieć trochę doświadczenia
286) z C++. Uprzednie doświadczenie z Qt i Qt Designer będzie przydatne, ale nie
287) jest wymagane. Przydatne mogą być też pewne umiejętności w pisaniu po
288) angielsku, gdyż ten projekt prawdopodobnie będzie wymagał napisania małej
289) ilości dokumentacji pomocniczej, która powinna być zrozumiała dla
290) nie-technicznych użytkowników. Dodatkowe punkty za jakiś projekt graficzny
291) /Photoshop fu, gdyż moglibyśmy chcieć/potrzebować nowych ikonek.

292) </li>
293) 
294) <li>

295) <b>Polepszenie procesu testów jednostkowych</b> <br /> Priorytet:
296) <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
297) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Nick,
298) Erinn</i> <br /> Tor musi zostać znaczniej bardziej przetestowany. To jest
299) projekt wieloczęściowy. Na początek, nasze testy jednostkowe powinny
300) znacznie się wzbogacić, zwłaszcza w obszarach poza funkcjami
301) narzędziowymi. Będzie to wymagało poważnych zmian niektórych części Tora,
302) aby oddzielić jak najwięcej programu od zmiennych globalnych.<br /> Ponadto,
303) musimy zautomatyzować nasze testy wydajności dla wszystkich systemów. Mamy
304) już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji
305) testów (ale potrzebujemy osoby do uruchomienia tego pod Windows), ale musimy
306) zaktualizować nasze testy symulacji sieci (takie, jak w <a
307) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>) do
308) nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe
309) albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie badać
310) zmiany wydajności na maszynach pełniących różne zadania.

311) </li>

312) 
313) <li>

314) <b>Pomóż w niezależnych implementacjach klienta Tora</b> <br /> Priorytet:
315) <i>Średni</i> <br /> Poziom wysiłku: <i>Wysoki</i> <br /> Poziom
316) umiejętności: <i>Średni do wysokiego</i> <br /> Prawdopodobni opiekunowie:
317) <i>Karsten, Nick</i> <br /> Pracujemy w tej chwili nad klientami Tora dla
318) środowisk Java, Android i Maemo. Pierszym krokiem byłoby zapoznanie się z
319) bieżacym stanem projektu, któremu chcesz pomóc; <a
320) href="http://github.com/brl/JTor">Tor dla Javy</a>, <a
321) href="https://svn.torproject.org/svn/projects/android/trunk/">Android/Orbot
322) lub <a href="<page docs/N900>">Tor dla Maemo</a>. Pobierz repozytorium i
323) zapoznaj się z kodem źródłowym. Ponadto, obsługa żądań lub choćby
324) dostarczania usług ukrytych Tora byłaby fajna, choć nie wymagana.<br />
325) Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie,
326) łącznie z korzystaniem z kryptograficznego API Javy. Umiejętność czytania
327) kodu w C też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej
328) dokumentacji, implementacji kodu w oparciu o nią oraz, poprawiać
329) dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu

330) pisania kodu i w mniejszym - z projektowania.
331) </li>
332) <li>

333) <b>Więcej o Orbocie i rozwoju specyficznym dla systemu Android</b> <br/> <br
334) /> Priorytet: <i>Średni</i> <br /> Poziom wysiłku: <i>Wysoki</i> <br />
335) Poziom umiejętności: <i>Średni do Wysokiego</i> <br /> Prawdopodobni
336) opiekunowie: <i>Nathan</i> <br /> <b>Praca z interfejsem użytkownika w Javie
337) na Androidzie:</b> Lepszy ekran powitalny, by pokazywać lepsze statystyki o
338) transferze danych (wysyłanie/odbieranie), liczbie podłączonych obwodów,
339) jakości połączenia i tak dalej. Aplikacja "Tether Wifi" na Androida jest
340) dobrym modelem do naśladowania w tym, jak pokazuje w czasie rzeczywistym
341) ilość wysłanych i odebranych bajtów, jak również powiadomienia o połączeniu
342) klienta wifi. Ponadto, lepsze wyświetlanie/załatwianie wiadomości
343) systemowych lub o błędach Tora też byłoby bardzo pomocne. W końcu dodanie
344) kreatora lub przewodnika dla początkujących użytkowników, by wyjaśnić im, co
345) jest, a co nie jest anonimizowane lub chronione, bardzo zwiększyłoby
346) prawdopodobieństwo, że będą używać Orbota prawidłowo. <br/><br/> <b>Praca z
347) systemem w Javie/wnętrzem aplikacji:</b> Lepszy wskaźnik systemowy, poprzez
348) pasek powiadomień, okna dialogowe "Toast" lub inny mechanizm, że dane
349) aplikacji są rzeczywiście przekazywane przez Orbota/Tora. Na przykład, teraz
350) musisz najpierw wejść na usługę torcheck, by upewnić się, że Twoja
351) przeglądarka przechodzi przez Tora. Orbot powinien móc powiadamiać Cię, że
352) obwody są otwierane, używane itd. Wspomniane wcześniej śledzenie transferu
353) danych też mogłoby dostarczać tego typu uświadamiania. <br/><br/> <b>Praca z
354) biblioteką Javy w Androidzie/Zasięgiem w społeczeństwie</b> Potrzebujemy
355) mieć paczkę z prostą biblioteką do wykorzystania z aplikacjami innych
356) producentów, by łatwo umożliwić im "Toryfikację" na nie-głównych
357) urządzeniach (bez przezroczystego proxy) Ta biblioteka powinan zwierać
358) owijkę na bibliotekę Apache HTTPClient, klasę narzędziową do sprawdzenia
359) stanu połączenia Orbota i inne istotne/przydatne rzeczy, których aplikacja
360) na Androida może potrzebować do zanonimizowania się. Ta praca powinna
361) składać się ze stworzenia biblioteki, dokumentacji i przykładowego
362) kodu. Wychodzenie z tym projektem lub podjęcie wysiłku implementacji
363) biblioteki w innych otwartych aplikacjach byłoby następnym
364) krokiem. <br/><br/> <b>Praca Android OS/C/Linux</b> przeniesienie Tora na
365) Androida jest w zasadzie prostą kompilacją na Linux ARM. Nie została
366) wykonana żadna praca odnośnie optymalizacji Tora w środowisku sprzętu
367) przenośnego na prcesorze ARM lub innym sprzęcie z Androidem lub w sieciach
368) mobilnych. Należy zauważyć, że nawet bez optymalizacji, Tor bardzo dobrze
369) radzi sobie ze środowiskiem sieci mobilnych, automatycznie wykrywając zmiany
370) adresu IP, ponownie łącząc obwody itd, przełączając się z 2G na 3G i Wifi i
371) tak dalej. 

372) </li>
373) 

374) 
375) 
376) 
377) 
378) <!--<li>
379) 
380) <b>New Torbutton Features</b>

381) <br />

382) Priority: <i>Medium</i>

383) <br />

384) Effort Level: <i>High</i>

385) <br />

386) Skill Level: <i>High</i>

387) <br />

388) Likely Mentors: <i>Mike</i>
389) <br/>
390) There are several <a

391) href="https://trac.torproject.org/projects/tor/report/14">good
392) feature requests</a> on the Torbutton Trac section. In particular, <a
393) href="https://trac.torproject.org/projects/tor/ticket/523">Integrating

394) 'New Identity' with Vidalia</a>,

395) <a href="https://trac.torproject.org/projects/tor/ticket/940">ways of
396) managing multiple cookie jars/identities</a>, 
397) <a href="https://trac.torproject.org/projects/tor/ticket/637">preserving

398) specific cookies</a> when cookies are cleared,
399) <a

400) href="https://trac.torproject.org/projects/tor/ticket/524">better

401) referrer spoofing</a>, <a

402) href="https://trac.torproject.org/projects/tor/ticket/564">correct

403) Tor status reporting</a>, and <a

404) href="https://trac.torproject.org/projects/tor/ticket/462">"tor://"

405) and "tors://" urls</a> are all interesting
406) features that could be added.
407) <br />
408) This work would be independent coding in Javascript and the fun world of <a
409) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
410) with not too much involvement in the Tor internals.
411) </li>-->
412) <!-- <li>
413) 
414) <b>New Thandy Features</b>
415) <br />
416) Priority: <i>Medium</i>
417) <br />
418) Effort Level: <i>Medium</i>
419) <br />
420) Skill Level: <i>Medium to High</i>
421) <br />
422) Likely Mentors: <i>Martin</i>
423) <br />
424) Additional capabilities are needed for assisted updates of all the Tor
425) related software for Windows and other operating systems. Some of the
426) features to consider include:
427) <ol>
428) <li> Integration of the <a
429) href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
430) Python library</a>
431) for authenticated HTTPS downloads.</li>
432) <li> Adding a level of indirection
433) between the timestamp signatures and the package files included in an
434) update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
435) <li> Support locale specific installation and configuration of assisted
436) updates based on preference, host, or user account language settings.
437) Familiarity with Windows codepages, unicode, and other character sets
438) is helpful in addition to general win32 and posix API experience and
439) Python proficiency.</li>
440) </ol>
441) </li> -->
442) <li>
443) <b>Symulator wolnych połączeń internetowych</b> <br /> Priorytet:
444) <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
445) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Steven</i>
446) <br /> Wielu użytkowników Tora ma łącza internetowe niskiej jakości, dające
447) niską przepustowość, długie czasy trwania operacji i wysoki współczynnik
448) utraty lub przekładania pakietów. Z doświadczeń użytkowników wiemy, że Tor
449) źle reaguje na te warunki, ale ciężko jest poprawić tę sytuację bez
450) możliwości powtórzenia tych problemów w laboratorium. <br /> Celem tego
451) projektu byłoby zbudowania środowiska symulacyjnego, które replikowałoby tę
452) słabą łączność, by można było zmierzyć jej działanie na wydajność
453) Tora. Innymi komponentami byłby program testujący, w celu określenia
454) dostępnych parametrów połączenia i mierzenia wpływu zmian polepszających
455) wydajność Tora. <br /> Wybór narzędzi zależałby od studenta/ki, ale dummynet
456) (dla FreeBSD) i nistnet (pod Linux) są dwoma potencjalnymi komponentami, na
457) których można byłoby zbudować ten projekt. Studenci powinni mieć
458) doświadczenie w programowaniu i debugowaniu sieciowym i TCP/IP oraz
459) najlepiej znać C i język skryptowy.

460) </li>
461) 
462) <li>

463) <b>Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia</b> <br />
464) Priorytet: <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
465) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Matt</i>
466) <br /> Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje
467) użytkownikowi przybliżone lokalizacje geograficzne przekaźników sieci Tora i
468) rysuje ścieżki, przez które przechodzi ruch użytkownika w sieci Tora. Mapa
469) jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę. Zamiast
470) tego, zaimplementowaliśmy widget Marble z KDE, który daje mapę lepszej
471) jakości i umożliwia lepszą interaktywność, jak na przykład pozwalanie
472) użytkownikowi na klikanie w poszczególne przekaźniki lub obwody, by
473) wyświetlić dodatkowe informacje. Chcemy też dodać użytkownikowi możliwość
474) klikania na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
475) stwierdzenia "chcę, by moje połączenia wychodziły stąd." <br /> Podczas tego
476) projektu, osoba najpierw zapozna się z Vidalią i API widgetu Marble. Potem
477) zintegruje widget z Vidalią i zmieni go, by bardziej pasował do naszych
478) zastosowań, np. można było klikać w obwody, zapisywać mapy we własnym
479) katalogu Vidalii i dostosować część okien dialogowych widgetu. <br /> Osoba
480) podejmująca się tego projektu powinna dobrze znać C++. Uprzednie
481) doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.

482) </li>
483) 
484) <li>

485) <b>Odpowiednik Torbuttona dla Thunderbirda</b> <br /> Priorytet:
486) <i>Średni</i> <br /> Poziom wysiłku: <i>Wysoki</i> <br /> Poziom
487) umiejętności: <i>Wysoki</i> <br /> Prawdopodobni opiekunowie: <i>Mike</i>
488) <br /> Od ciągle powiększającej się grupy użytkowników słyszymy, że chcą
489) używać Thunderbirda z Torem. Jest jednak wiele spraw na poziomie aplikacji,
490) na przykład to, że Thunderbird domyślnie umieści Twoją nazwę hosta w
491) wysyłanej przez siebie poczcie. W pewnym momencie powinniśmy zapoczątkować
492) nowe działania mające na celu stworzenie rozszerzenia dla Thunderbirda,
493) podobnego do Torbuttona.

494) </li>
495) 

496) 
497) 
498) <!--<li>
499) 
500) <b>Intermediate Level Network Device Driver</b>

501) <br />

502) Priority: <i>Low</i>

503) <br />

504) Effort Level: <i>High</i>

505) <br />

506) Skill Level: <i>High</i>

507) <br />

508) Likely Mentors: <i>Martin</i>

509) <br />

510) The WinPCAP device driver used by Tor VM for bridged networking does
511) not support a number of wireless and non-Ethernet network adapters.
512) Implementation of a intermediate level network device driver for win32
513) and 64bit would provide a way to intercept and route traffic over such
514) networks. This project will require knowledge of and experience with
515) Windows kernel device driver development and testing. Familiarity with
516) Winsock and Qemu would also be helpful.
517) </li>-->
518) <li>
519) <b>Ulepszenie Pogody Tora</b> <br /> Priorytet: <i>Średni</i> <br /> Poziom
520) wysiłku: <i>Średni</i> <br /> Poziom umiejętności: <i>Średni</i> <br />
521) Prawdopodobni opiekunowie: <i>Christian, Roger, Damian</i> <br /> <a
522) href="https://weather.torproject.org/">Pogoda Tora</a> jest narzędziem,
523) które umożliwia zapisanie się do otrzymywania powiadomień pocztą e-mail, gdy
524) obserwowany przekaźnik sieci Tora nie działa. W chwili obecnej nie jest to
525) zbyt użyteczne dla osób używających hibernacji Tora i dla tych, którzy muszą
526) regularnie wyłączać swoje przekaźniki. W czasie tego projektu, Pogoda Tora
527) mogłaby być rozszerzona o bardziej elastyczne możliwości
528) konfiguracji. Możliwe są też inne udoskonalenia: mogłaby wysyłać
529) ostrzeżenia, gdy Twój przekaźnik używa przestarzałej wersji Tora, lub gdy
530) jego zaobserwowana przepustowość spadnie poniżej pewnego poziomu. To może
531) być też przydatne narzędzie do sprawdzania, czy Twój przekaźnik zarobił dla
532) Ciebie <a href="<page tshirt>">T-Shirt</a> lub do przesyłania przypomnień do
533) serwerów katalogowych, że ich klucze się wkrótce przedawnią. Bądźcie twórczy
534) i pomyślcie, jak powyższy projekt śledzenia ogólnego stanu sieci Tora mógłby
535) Wam pomóc w szybszym ukończeniu zadania! Przeczytajcie też pliki <a
536) href="https://svn.torproject.org/svn/weather/trunk/README">README</a> i <a
537) href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.

538) </li>
539) 
540) <li>

541) <b>Poprawa interakcji dla Tora+Vidalii na platformach Linux/Unix</b> <br />
542) Priorytet: <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
543) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Erinn,
544) Peter</i> <br /> Vidalia w chwili obecnej nie działa dobrze z Torem na
545) platformach Linux iUnix. W chili obecnej na Debianie i Ubuntu jest mechanizm
546) konfiguracji, który pozwala Vidalii na obejście zdolności Tora do
547) uruchamiania się przy starcie systemu (poprzez wykonanie
548) <code>/etc/default/tor.vidalia</code>, który ustawia
549) <code>RUN_DAEMON=no</code> na żądanie użytkownika), ale ciągle wymagana jest
550) pełna implementacja komunikacji z <a
551) href="<gitblob>doc/spec/control-spec.txt">ControlPort</a>. <br /> Lepszym
552) rozwiązaniem na platformach Linux i Unix byłoby wykorzystanie ControlSocket
553) Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez gniazdo
554) domeny Unix, i który mógłby być domyślnie włączony w paczkach
555) dystrybucyjnych Tora. Vidalia może się wtedy uwierzytelniać z Torem,
556) korzystajac z uwierzytelniania opartego na systemie plików (ciasteczka),
557) jeśli użytkownik, który uruchamia Vidalię jest też w specyficznej dla
558) dystrybucji grupie tor. <br /> Ten projekt najpierw będzie wymagał dodania
559) obsługi ControlSocket Tora do Vidalii. Student potem rozwinie i sprawdzi tę
560) obsługę na różnych dystrybucjach, by upewnić się, że działa w sposób
561) przewidywalny i spójny na nich wszystkich. <br /> Kolejnym wyzwaniem byłoby
562) znalezienie użytecznego i intuicyjnego sposobu na to, by Vidalia mogła
563) zmieniać konfigurację Tora (torrc), mimo iż jest umieszczona w
564) <code>/etc/tor/torrc</code> i przez to niezmienna. Na Debianie i Ubuntu
565) zajmujemy się tym poprzez wspomniany wcześniej
566) <code>/etc/default/tor.vidalia</code>, ale ta funkcjonalność mogłaby (lub
567) powinna) być mniej zależna od dystrybucji. <br /> Najlepszy jak dotąd pomysł
568) jest taki, aby przekazywać Torowi nową konfigurację poprzez ControlSocket w
569) czasie startu Vidalii, ale jest to złe rozwiazanie, gdyż jeśli użytkownik
570) nie korzysta z najnowszysch paczek dla Debiana/Ubuntu, mógł nie wyłączyć
571) możliwości Tora do uruchamiania się w czasie startu systemu, co skończy się
572) tym, że będzie mieć konfigurację inną niż ta, którą chciał. Drugi najlepszy
573) jak dotąd pomysł jest taki, by Vidalia tworzyła tymczasowy plik torrc i
574) prosiła użytkownika, aby ręcznie przeniósł go do
575) <code>/etc/tor/torrc</code>, ale to jest złe rozwiązanie, gdyż użytkownicy
576) nie powinni musieć grzebać w katalogach z plikami. <br /> Osoba podejmująca
577) się tego projektu powinna mieć wiedzę o różnych dystrybucjach Linuksa i ich
578) mechanizmach paczek, jak również trochę doświadczenia z pisaniu w
579) C++. Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.

580) </li>
581) 

582) 
583) 
584) <!--<li>
585) 
586) <b>Tor/Polipo/Vidalia Auto-Update Framework</b>
587) <br />
588) We're in need of a good authenticated-update framework.
589) Vidalia already has the ability to notice when the user is running an
590) outdated or unrecommended version of Tor, using signed statements inside
591) the Tor directory information. Currently, Vidalia simply pops
592) up a little message box that lets the user know they should manually
593) upgrade. The goal of this project would be to extend Vidalia with the
594) ability to also fetch and install the updated Tor software for the
595) user. We should do the fetches via Tor when possible, but also fall back
596) to direct fetches in a smart way. Time permitting, we would also like
597) to be able to update other
598) applications included in the bundled installers, such as Polipo and
599) Vidalia itself.
600) <br />
601) To complete this project, the student will first need to first investigate
602) the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
603) their strengths, weaknesses, security properties, and ability to be
604) integrated into Vidalia. If none are found to be suitable, the student
605) will design their own auto-update framework, document the design, and
606) then discuss the design with other developers to assess any security
607) issues. The student will then implement their framework (or integrate
608) an existing one) and test it.
609) <br />
610) A person undertaking this project should have good C++ development
611) experience. Previous experience with Qt is helpful, but not required. One
612) should also have a good understanding of common security
613) practices, such as package signature verification. Good writing ability
614) is also important for this project, since a vital step of the project
615) will be producing a design document to review and discuss
616) with others prior to implementation.
617) </li>-->

618) <li>

619) <b>Polepszenie procesu QA Tora: Ciągła integracja dla paczek</b> <br />
620) Priorytet: <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
621) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Erinn</i>
622) <br /> Przydałby się automatyczny system tworzenia paczek dla Windows i być
623) może innych systemów. Celem posiadania środowiska ciągłej integracji jest
624) upewnienie się, że Windows nie zostanie w tyle z żadnym z projektów
625) używanych lub związanych z projektem Tor. Buildbot może być dobrym
626) rozwiązaniem, gdyż zdaje się obsługiwać te same platformy, co
627) Tor. Przeczytaj (po angielsku) <a
628) href="http://en.wikipedia.org/wiki/BuildBot">wpis na Wikipedii dotyczący
629) Buildbota</a>.<br /> Może jednak są lepsze rozwiązania, więc osoba
630) podejmująca się tego zadania powinna rozważyć inne opcje. Jakakolwiek osoba
631) pracująca nad tym systemem automatycznego budowania powinna mieć
632) doświadczenie lub chęć do nauczenia się tego, jak buduje się wszystkie
633) odpowiednie elementy Tora od zera. Ponadto, ta osoba powinna mieć jakieś
634) doświadczenie w kompilowaniu programów w Windows, jako że to jest ta część
635) użytkowników, których nie chcemy zostawiać w tyle. Zadanie będzie wymagała
636) bliskiej pracy z kodem Tora, ale prawdopodobnie tylko od strony kompilacji,
637) nie pisania.<br /> Ponadto, musimy zautomatyzować nasze testy wydajności dla
638) wszystkich systemów. Mamy już buildbota (za wyjątkiem Windows &mdash; jak
639) napisane powyżej) do automatyzacji naszej zwyczajnej integracji i kompilacji
640) testów, ale musimy zaktualizować nasze testy symulacji sieci (takie, jak w
641) torflow) do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci
642) testowe albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie
643) badać zmiany wydajności na maszynach pełniących różne zadania.<br />

644) </li>
645) 
646) 

647) 

648) <!--<li>
649) 
650) <b>Usability testing of Tor</b>

651) <br />

652) Priority: <i>Medium</i>

653) <br />

654) Effort Level: <i>Medium</i>

655) <br />

656) Skill Level: <i>Low to Medium</i>

657) <br />

658) Likely Mentors: <i>Andrew</i>

659) <br />

660) Especially the browser bundle, ideally amongst our target demographic.
661) That would help a lot in knowing what needs to be done in terms of bug
662) fixes or new features. We get this informally at the moment, but a more
663) structured process would be better.
664) </li>-->

665) <li>

666) <b>Uwierzytelniające proxy dla IRC</b> <br /> Priorytet: <i>Niski</i> <br />
667) Poziom wysiłku: <i>Średni do Wysokiego</i> <br /> Poziom umiejętności:
668) <i>Średni do Wysokiego</i> <br /> Prawdopodobni opiekunowie: <i>Sebastian,
669) Weasel, Roger</i> <br /> Świat potrzebuje uwierzytelniającego serwera
670) pośredniczącego (proxy) dla IRC. Jak przypomina się na okresowo w komiksie
671) internetowym Penny Arcade, "Użytkownik Internetu + anonimowość =
672) pacan". Odnoścnie stron internetowych, dobrze się sprawujemy, gdyż strony
673) mogą zmusić swoich użytkowników do logowania i użyuwać innych podejść do
674) uwierzytelniania na poziomie aplikacji. Ale serwery IRC są znacznie gorsze,
675) gdyż kod większości serwerów IRC jest źle napisany: trudny w utrzymaniu,
676) jeszcze trudniejszy w zmienianiu. Wiele sieci IRC blokuje teraz połączenia z
677) Tora, zostaliśmy praktycznie na dwóch przyczółkach (OFTC i Freenode). Ten
678) stan rzeczy oznacza, że wielu ludzi na świecie myśli "Mówiłem, że tak
679) będzie" o anonimowości on-line, podczas gdy w rzeczywistości problemem jest
680) brak technologii, które umożliwiłyby zarządzanie tym problemem. Musimy mieć
681) jakiś sposób na umożliwienie sieciom IRC rozróżnianie, którzy użytkownicy
682) wyrobili sobie reputację nie bycia pacanami, by mogli traktować te dwie
683) grupy osobno. Są jakieś naprawdę fajne projekty badawcze jak <a
684) href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>, których celem jest
685) umozliwienie stronom internetowym wpisywanie użytkowników na czarną listę
686) bez wiedzy, kim oni są. Ale Nymble opiera się na interakcjach ze stronami
687) internetowymi. Musimy stworzyć klej wokół protokołu IRC, który umożliwiłby
688) nam włożenie projektu taiego jak Nymble (lub na początek jakiegoś
689) prostszego, jako dowód działania). Jednym ze sposobów na zrobienie tego
690) byłoby zbudowanie proxy dla IRC, które wiedziałoby, jak rozmawiać z
691) klientami i serwerami i posiadałoby dodatkową warstwę, która wymaga
692) uwierzytelnienia od użytkowników. Trochę pracy w tym temacie zostało
693) wykonane przez innych wolontariuszy, zobacz ich postęp na <a
694) href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.

695) </li>

696) 
697) <li>

698) <b>Więcej pracy nad torsocks/dsocks na OS X</b> <br /> Priorytet:
699) <i>Średni</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
700) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>?</i> <br
701) /> <a href="http://code.google.com/p/torsocks/">Torsocks</a> i <a
702) href="http://code.google.com/p/dsocks/">dsocks</a> są owijkami, które
703) uruchamiają aplikacje, przechwytują ich wychodzące połaczenia sieciowe i
704) wysyłają je przez Tora. Celem jest obsługa aplikacji, które nie obsługują
705) serwerów pośredniczących (lub obsługują je słabo). By to działało dobrze,
706) musimy przechwytywać wiele wywołań systemowych. Funkcje systemowe, które
707) trzeba przechwytywać na Linuksie różnią się znacznie od tych na BSD. Dlatego
708) Torsocks działa dobrze na Linuksie, dsocks działa dobrze na BSD (choć zdaje
709) się, że mniej osób się nim zajmuje, więc może mu brakować niektórych funkcji
710) systemowych), a nic nie działa dobrze na obu. Po pierwsze, powinniśmy
711) załatać dsocks, by używał komend <i>mapaddress</i> Tora z jego interfejsu
712) kontrolera, byśmy nie marnowali całego przejścia przez Tora, robiąc
713) rozwiązanie nazw przed połączeniem. Po drugie, powinniśmy sprawić, by nasz
714) skrypt <i>torify</i> wykrywał, który z torsocks lub dsocks jest
715) zainstalowany i wywoływać je odpowiednio. To prawdopodobnie oznacz
716) unifikację ich interfejsów i może oznaczać współdzielenie kodu między nimi
717) lub całkowite odrzucenie jednego.

718) </li>
719) 

720) <li>

721) <b>Przynieś nowe pomysły!</b> <br />Nie podoba Ci się żaden z tych pomysłów?
722) Sięgnij do <a href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">planu
723) rozwoju Tora</a> po więcej pomysłów lub po prostu wypróbuj Tora, Vidalię,
724) Torbutton i dowiedz się, co Twoim zdaniem wymaga poprawy. Niektórym z <a
725) href="<gittree>doc/spec/proposals/">bieżących propozycji</a> też może
726) brakować deweloperów.

727) </li>
728) 

729) </ol>
730) 

731) <a id="OtherCoding"></a>

732) <h2><a class="anchor" href="#OtherCoding">Inne pomysły związane z programowaniem
733) i projektowaniem</a></h2>

734) <ol>

735) <li>Tor relays don't work well on Windows XP. On Windows, Tor uses the standard
736) <tt>select()</tt> system call, which uses space in the non-page pool. This
737) means that a medium sized Tor relay will empty the non-page pool, <a
738) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/WindowsBufferProblems">causing
739) havoc and system crashes</a>. We should probably be using overlapped IO
740) instead. One solution would be to teach <a
741) href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use
742) overlapped IO rather than select() on Windows, and then adapt Tor to the new
743) libevent interface. Christian King made a <a
744) href="https://svn.torproject.org/svn/libevent-urz/trunk/">good start</a> on
745) this in the summer of 2007.</li>

746) 
747) <li>Musimy zacząć budować nasz <a href="<page documentation>#DesignDoc">projekt
748) odporny na blokowanie</a>. Wchodzi w to przemyślenie projektu, zmiana wielu
749) różnych elementów Tora, zaadaptowanie <a href="<page
750) vidalia/index>">Vidalii</a>, by obsługiwała nowe cechy i planowanie
751) rozpowszechniania.</li>
752) 
753) <li>Potrzebujemy elastycznego frameworka symulacji do badania ataków
754) potwierdzenia ruchu od nadawcy do odbiorcy (end-to-end). Wielu ludzi szybko
755) wyciągnęło/napisało doraźne symulatory odpowiadające ich intuicji, że albo
756) ataki znakomicie się udają, albo że obrona działa dobrze. Czy możemy
757) zbudować symulator, który jest dobrze udokumentowany i dość otwarty, by
758) wszyscy wiedzieli, że daje rozsądną odpowiedź? To zacznie wiele nowych
759) badań. Spójrz na wpis <a href="#Research">poniżej</a> o atakach
760) potwierdzenia po szczegóły strony badawczej tego zadania &mdash; kto wie,
761) może gdy będzie skończone, pomożesz nam też napisać dokumentację.</li>
762) 
763) <li>Tor 0.1.1.x i późniejsze zawiera obsługę sprzętowych akceleratorów
764) kryptograficznych, poprzez OpenSSL. Zostało to trochę przetestowane i
765) prawdopodobnie ma dużo błędów. Czekamy na bardziej rygorystyczne testy,
766) analizy wydajności i najlepiej poprawki kodu do OpenSSL i Tora, jeśli będzie
767) trzeba.</li>

768) 

769) <li>Dokonać analizy bezpieczeństwa Tora z <a

770) href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Sprawdzić, czy
771) istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
772) gdy wydamy nową wersję dzięki Tobie!</li>
773) 

774) <li>Tor uses TCP for transport and TLS for link encryption. This is nice and
775) simple, but it means all cells on a link are delayed when a single packet
776) gets dropped, and it means we can only reasonably support TCP streams. We
777) have a <a
778) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">list
779) of reasons why we haven't shifted to UDP transport</a>, but it would be
780) great to see that list get shorter. We also have a proposed <a
781) href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification for
782) Tor and UDP</a> &mdash; please let us know what's wrong with it.</li>

783) 

784) <li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach

785) wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy
786) punkt startu.</li>
787) 
788) <li>Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład,
789) obrazków "Jak działa Tor" na <a href="<page overview>">stronie
790) wprowadzenia</a> ze źródeł, byśmy mogli je tłumaczyć jako tekst w UTF-8
791) zamiast edytować je ręcznie za pomocą GIMPa. Należy zintegrować to z plikiem
792) WML, by tłumaczenie było proste, a obrazki generowane w wielu językach w
793) czasie publikacji strony.</li>
794) 
795) <li>Jak można uczynić różne systemy LiveCD/USB łatwiejszym w utrzymaniu,
796) ulepszaniu i dokumentowaniu? Jednym z przykładów jest <a
797) href="http://anonymityanywhere.com/incognito/">(Amnesic) Incognito Live
798) System</a>
799) </li>

800) 
801) <li>

802) Kolejny projekt przeciw cenzurze to próba uczynienia Tora bardziej odpornym
803) na skanowanie. W chwili obecnej ktokolwiek może zidentyfikować <a
804) href="<gitblob>doc/spec/proposals/125-bridges.txt">mostki Tora</a> po prostu
805) łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając, czy
806) odpowiadają. By rozwiązać ten problem, mostki mogłyby <a
807) href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">udawać serwery
808) internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do
809) skanowania portów, a nie zachowywać się jak mostki do chwili, gdy użytkownik
810) poda klucz specyficzny dla mostka. Na początek, sprawdź<a
811) href="http://dl.dropbox.com/u/37735/index.html">pracę i prototyp</a>Shane'a
812) Pope.

813) </li>
814) 

815) </ol>
816) 
817) <a id="Research"></a>
818) <h2><a class="anchor" href="#Research">Badania</a></h2>
819) <ol>

820) <li>"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic
821) confirmation attack): obserwując ruch od Alicji do Boba, możemy <a
822) href="http://freehaven.net/anonbib/#danezis:pet2004">porównać sygnatury
823) ruchu i przekonać się, że obserwujemy ciągle ten sam strumień
824) danych</a>. Jak na razie, Tor przyjmuje to jako pewnik i zakłada, że ten
825) atak jest trywialny we wszystkich przypadkach. Po pierwsze, czy tak
826) rzeczywiście jest? Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne,
827) by przeciwnik upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie
828) wysyłanie wiele danych), które spowolniłyby atak? Czy jakieś dopełnienia
829) transmisji lub inne sposoby kształtowania działają lepiej od innych?</li>

830) <li>Powiązane pytanie brzmi: Czy prowadzenie przekaźnika/mostka daje dodatkową
831) ochronę przed atakami opartymi na czasie? Czy ktoś z zewnątrz, kto nie może

832) przeczytać linków zaszyfrowanych przez TLS, dalej jest w stanie prawidłowo
833) rozpoznać poszczególne strumienie danych? Czy ilość ruchu jakoś zmniejsza tę
834) możliwość? A co, jeśli klient-przekaźnik celowo opóźnia wychodzący ruch, by
835) stworzyć kolejkę, która mogłaby być używana do udawania czasów pobierania
836) danych przez klienta tak, by wyglądało, że ten ruch też jest przekierowany?
837) Ta sama kolejka mogłaby być używana do maskowania czasów w ruchu
838) wychodzącym, korzystając z technik <a
839) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptacyjnego
840) dopełniania</a>, ale bez potrzeby dodatkowego ruchu (wysyłania dodatkowych
841) danych). Czy takie przeplatanie prawdziwych danych popsułoby mierzenie
842) czasów u atakujących? Czy strategie te musiałyby by zmienione dla
843) asymetrycznych łączy? Na przykład, czy jest możliwe na łączu asymetrycznym
844) odróżnienie ruchu klienta od naturalnego wzmożenia ruchu ze względu na ich
845) asymetryczną pojemność? Czy jest to jednak łatwiejsze niż dla łączy

846) symetrycznych z innych przyczyn?</li>

847) <li>Powtórzcie <a

848) href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">atak z Oakland
849) 05</a> Murdocha i Danezisa na bieżącej sieci Tora. Sprawdźcie, czy możecie
850) dowiedzieć się, czemu działa on dobrze na niektórych węzłach, a gorzej na
851) innych. (Moja teoria mówi, że szybkie węzły mające trochę wolnego pasma
852) lepiej opierają się atakowi.) Jeśli to prawda, poeksperymentujcie z opcjami
853) RelayBandwidthRate i RelayBandwidthBurst prowadząc węzeł używany jako klient
854) do przekierowywania ruchu atakującego: jeśli zmniejszamy RelayBandwidthRate,
855) czy atak jest trudniejszy? Jaki jest najwłaściwszy stosunek
856) RelayBandwidthRate do rzeczywistej szybkości łącza? Czy to w ogóle jest
857) jakiś stosunek? Skoro już przy tym jesteśmy, czy znacznie większy zbiór
858) węzłów kandydujących zwiększa odsetek fałszywych wyników pozytywnych lub
859) innych trudności dla tego rodzaju ataku? (Sieć Tora jest teraz większa o
860) prawie dwa rzędy wielkości niż wtedy, gdy napisano ten dokument.) Przeczytaj
861) też <a href="http://freehaven.net/anonbib/#clog-the-queue">Nie zapychaj
862) kolejki</a>.</li>
863) <li>"Atak stref trasowania" (routing zones attack): większość literatury mówi o
864) ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między węzłem
865) wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie. W
866) rzeczywistości, ścieżka przemierza wiele systemów autonomicznych (SA), i <a
867) href="http://freehaven.net/anonbib/#feamster:wpes2004">często zdarza się, że
868) ten sam SA pojawia się zarówno na ścieżce wejściowej i
869) wyjściowej</a>. Niestety, by dokładnie przewidzieć, czy podany czworobok
870) Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć całą
871) strefę trasowania internetu i dokonać na niej czasochłonnych operacji. Czy
872) są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej samej
873) sieci /8?</li>

874) <li>Inne pytania badawcze dotyczące różnorodności geograficznej rozpatrują

875) kompromis między wybieraniem obwodu wydajnego a losowego. Spójrz na <a
876) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">dokument
877) o pozycjach</a> Stephena Rollysona na temat tego, jak odrzucać szczególnie
878) wolne możliwości bez zbytniej utraty anonimowości. Ta argumentacja wymaga
879) więcej pracy i myślenia, ale wygląda bardzo obiecująco.</li>

880) <li>Tor nie działa za dobrze, gdy przekaźnik sieci ma asymetryczne łącze

881) (np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
882) każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
883) są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji z
884) powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
885) wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące, by
886) sam tym regulować? Można sobie wyobrazić schemat działania, w którym
887) najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
888) chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie
889) się. Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
890) zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
891) użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.</li>

892) <li>Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt

893) okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
894) poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
895) To zdawało się działać nieźle w <a
896) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">eksperymencie
897) przepustowości SSH</a>. Będziemy musieli mierzyć i podkręcać, i być może
898) wykonać poprawki, jeśli wyniki okażą się dobre.</li>

899) <li>Nasze cele w opieraniu się cenzurze to m.in. zapobieganie temu, by napastnik
900) podglądający ruch Tora mógł <a

901) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">odróżnić
902) go od normalnego ruchu SSL</a>. Oczywiście, nie możemy osiągnąć idealnej
903) steganografii i dalej mieć użyteczną i działającą sieć, ale w pierwszym
904) kroku chcielibyśmy blokować jakiekolwiek ataki, które mogą się udać po
905) obserwacji tylko kilku pakietów. Jednym z pozostałych ataków, którego nie
906) zbadaliśmy za bardzo, polega na tym, że komórki Tora mają 512 bajtów, więc
907) ruch w sieci może mieć długość będącą wielokrotnością 512 bajtów. Jak bardzo
908) wkładanie nowych danych w nagłówkach TLS rozmywa ten fakt w transmisji? Czy
909) inne strategie opróżniania bufora w Torze mają na to wpływ? Czy trochę
910) dokładania może bardzo pomóc, czy jest o atak, z którym musimy żyć?</li>
911) <li>Obwody Tora są budowane po jednym elemencie na raz, więc teoretycznie możemy
912) uczynić, aby część strumieni wychodziła z drugiego węzła, część z trzeciego
913) itd. To wydaje się dobre, bo ogranicza zbiór strumieni wychodzących, które
914) dany przekaźnik sieci może zobaczyć. Ale jeśli chcemy by każdy strumień był
915) bezpieczny, "najkrótsza" ścieżka powinna, według naszego bieżącego
916) rozumowania, składać się z co najmniej 3 elementów, więc inne będą jeszcze
917) dłuższe. Musimy zbadać ten kompromis wydajność/bezpieczeństwo.</li>
918) <li>Nie jest trudno wykonać atak DoS na przekaźniki sieci Tora lub centra
919) katalogowe. Czy zagadki dla klientów (client puzzles) są właściwą
920) odpowiedzią? Jakie są inne praktyczne podejścia? Dodatkowe punkty, jeśli są
921) zgodne wstecz z bieżącym protokołem Tora.</li>
922) <li>Programy takie jak <a href="<page torbutton/index>">Torbutton</a> mają na
923) celu ukrycie pola UserAgent przeglądarki, zastępując je jednakową
924) odpowiedzią dla każdego użytkownika Tora. W ten sposób napastnik nie może
925) złamać anonimowości Tora, patrząc na ten nagłówek. Aby się nie wyróżniać,
926) program próbuje wybrać nazwy przeglądarek często używanych także przez tych,
927) którzy nie używają Tora. Pytanie numer jeden: jak bardzo szkodzimy sami
928) sobie, okresowo zwiększając wersję Firefoksa, za którego podaje się
929) Torbutton? Jeśli aktualizujemy zbyt często, sami łamiemy swoją
930) anonimowość. Jeśli za rzadko, to wszyscy użytkownicy Tora się wyróżniają ze
931) względu na to, że twierdzą, iż używają starych wersji Firefoksa. Tutaj
932) odpowiedź zależy pewnie na tym, które wersje Firefoksa są spotykane. Pytanie
933) numer dwa: raz na jakiś czas ludzie pytają nas, byśmy krążyli po N nazwach
934) UserAgent, zamiast trzymać się jednej. Czy to podejście pomaga, przeszkadza,
935) czy nic nie wnosi? Weź pod uwagę: ciaseczka i rozpoznawanie użytkowników
936) Tora poprzez ich zmieniające się nagłówki UserAgent, złe strony atakujące
937) tylko określone przeglądarki; oraz to, czy odpowiedź na pytanie 1 wpływa na
938) tę odpowiedź.

939) </li>

940) <li>W chwili obecnej klienci Tora mogą używać tego samego obwodu w ciągu
941) dziesięciu minut od jego pierwszego użycia. Celem tego jest uniknięcie
942) przeładowania sieci zbyt wielką liczbą operacji przedłużania obwodów,
943) równocześnie unikając używania obwodu tak długo, że węzeł wyjściowy mógłby
944) stworzyć przydatny profil pseudonimowy użytkownika. Dziesięć minut to jednak
945) prawdopodobnie znacznie za dużo, zwłaszcza gdy przez ten sam obwód
946) prowadzone sa połączenia różnych protokołów (np. IM i przeglądanie
947) sieci). Jeśli nie zmienimy całkowitej liczby obwodów, które należy
948) utrzymywać, to czy będą jakieś wydajniejsze lub bezpieczniejsze metody
949) alokcaji strumieni do obwodów, lub do tworzenia wywłaszczających obwodów?
950) Być może ten temat badań powinien być rozpoczęty poprzez zebranie śladów,
951) jakie połączenia typowy użytkownik otwiera, by mieć coś realistycznego do
952) optymalizacji.

953) </li>

954) <li>Ile przekaźników mostkowych potrzeba, by utrzymać osiągalność? Powinniśmy
955) zmierzyć zajętość w naszych mostkach. Jeśli jest duża, czy są jakieś sposoby
956) na zwiększenie szans użytkowników mostków na pozostanie połączonymi?

957) </li>

958) </ol>
959) 

960) <p>

961) <a href="<page contact>">Daj nam znać</a>, jeśli poczyniłeś postępy nad
962) którąkolwiek z tych rzeczy!

963) </p>

964) 

965)   </div>

966) 
967)