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>Stwórz film o Twoim pozytywnym wykorzystaniu Tora, czym jest Tor lub jak go
61) używać. Kilka osób już zaczęło na <a
62) href="http://media.torproject.org/video/">serwerze mediów Tora</a>, <a
63) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>
64) i <a href="http://www.youtube.com/freedom4internet">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>Przepisać TorDNSEL, tym razem ze specyfikacją!</b> <br /> Priorytet:
144) <i>Wysoki</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
145) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Mike,
146) Roger, Sebastian, Damian</i> <br /> <a href="<page tordnsel/index>">Tor DNS
147) Exit List</a> jest programem w Haskellu , którym nikt się nie opiekuje, a
148) który służy trzem celom. Po pierwsze, dostarcza interfejsu DNS w stylu rbl
149) dla osób chcących sprawdzić, czy dany adres IP jest (lub ostatnio był)
150) węzłem wyjściowym Tora. Po drugie, aktywnie buduje obwody w sieci Tora i
151) łączy się sam ze sobą, by poznać właściwy wyjściowy adres IP każdego
152) przekaźnika &mdash; niektóre z przekaźników wychodzą z innego adresu niż ten
153) podany w ich deskryptorze. Po trzecie, eksportuje <a

154) href="http://exitlist.torproject.org/exitAddresses">zestaw wniosków</a>, by

155) <a href="https://check.torproject.org/">check.torproject.org</a> mógł
156) zgadnąć, czy Twoja przeglądarka jest skonfigurowana, by używać Tora. <br />
157) Ten projekt wykorzystałby <a
158) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>,
159) zestaw skryptów Pythona do interakcji z Torem, by dowiedzieć się, jak nasz
160) program do sprawdzania wyjścia z Tora powinien działać, po czym stworzyłby
161) go &mdash; proawdopodobnie w Pythonie, gdyż Torflow jest w Pythonie. Głównym
162) celem jest zmniejszenie fałszywych wyników pozytywnych tak bardzo, jak to
163) jest możliwe, przez sprawienie, by dowiadywał się o nowych przekaźnikach tak
164) szybko, jak to jest możliwe, spawienie, że faza testowania kończy się szybko
165) i upewnianie się, że odpowiedzi sdzybko trafiają do skryptu Check. Jako
166) bonus, powinniśmy ustandaryzować (wyspecyfikować) format pliku exitAddresses
167) i przepisać skrypt <a
168) href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor
169) Bulk Exit List</a>, by używał tamtego pliku zamiast bieżących <a
170) href="https://bugs.torproject.org/flyspray/index.php?do=details&id=1019">strasznych
171) prowizorek DNS</a>. Jako dodatkowy bonus, powinniśmy pracować z Freenode,
172) OFTC oraz innymi sieciami IRC, by upewnić się, że skrypty, które oferujemy
173) są tymi, które oni chcieli, w sensie dokładnego identyfikowania, którzy z
174) ich użytkowników przychodzą z sieci Tora. <br /> Możesz pobrać <a
175) href="git://git.torproject.org/git/tordnsel">najnowszą wersję tordnsel</a>
176) przez git.

177) </li>
178) 
179) <li>

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

208) </li>
209) 

210) 
211) 
212) <!--<li>
213) 
214) <b>Tuneup Tor!</b>

215) <br />

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

261) </li>
262) 

263) <li>

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

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

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

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

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

295) </li>
296) 
297) <li>

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

314) </li>

315) 
316) <li>

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

333) pisania kodu i w mniejszym - z projektowania.
334) </li>
335) <li>

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

375) </li>
376) 

377) 
378) 
379) 
380) 
381) <!--<li>
382) 
383) <b>New Torbutton Features</b>

384) <br />

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

386) <br />

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

388) <br />

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

390) <br />

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

463) </li>
464) 
465) <li>

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

485) </li>
486) 
487) <li>

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

497) </li>
498) 

499) 
500) 
501) <!--<li>
502) 
503) <b>Intermediate Level Network Device Driver</b>

504) <br />

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

506) <br />

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

508) <br />

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

510) <br />

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

512) <br />

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

541) </li>
542) 
543) <li>

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

583) </li>
584) 

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

621) <li>

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

647) </li>
648) 
649) 

650) 

651) <!--<li>
652) 
653) <b>Usability testing of Tor</b>

654) <br />

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

656) <br />

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

658) <br />

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

660) <br />

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

662) <br />

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

668) <li>

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

698) </li>

699) 
700) <li>

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

721) </li>
722) 

723) <li>

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

730) </li>
731) 

732) </ol>
733) 

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

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

737) <ol>

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

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

771) 

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

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

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

786) 

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

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

803) 
804) <li>

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

816) </li>
817) 

818) </ol>
819) 
820) <a id="Research"></a>
821) <h2><a class="anchor" href="#Research">Badania</a></h2>
822) <ol>

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

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

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

849) symetrycznych z innych przyczyn?</li>

850) <li>Powtórzcie <a

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

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

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

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

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

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

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

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

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

942) </li>

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

956) </li>

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

960) </li>

961) </ol>
962) 

963) <p>

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

966) </p>

967) 

968)   </div>

969) 
970)