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>Przejrzyj i udokumentuj <a
44) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO">naszą
45) listę programów</a>, które można skonfigurować do współpracy z Torem.</li>
46) <li>Mamy ogromną listę <a
47) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/SupportPrograms">potencjalnie
48) użytecznych programów, które współpracują z Torem</a>. Które z nich są
49) przydatne w jakich sytuacjach? Prosimy pomóż nam je testować i zapisuj swoje
50) wyniki.</li>

51) </ol>
52) 

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

56) <li>Stwórz <a
57) href="https://trac.torproject.org/projects/tor/wiki/CommunityLogos">logo
58) społeczności</a> pod licencją Creative Commons, którego wszyscy będą mogli
59) używać i modyfikować</li>

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

62) <li>Stwórz film o Twoim pozytywnym wykorzystaniu Tora, czym jest Tor lub jak go
63) używać. Kilka osób już zaczęło na <a
64) href="http://media.torproject.org/video/">serwerze mediów Tora</a>, <a
65) href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>
66) i <a href="http://www.youtube.com/thetorproject">Youtube</a>.</li> 

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

69) </ol>
70) 

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

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

73) 
74) <p>

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

85) </p>
86) 

87) <ol>
88) 
89) <li>

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

120) </li>
121) 

122) <li>

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

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

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

141) stanu Tora</a> napisaną przez Rogera.
142) </li>
143) 
144) <li>

145) <b>Przepisać TorDNSEL, tym razem ze specyfikacją!</b> <br /> Priorytet:
146) <i>Wysoki</i> <br /> Poziom wysiłku: <i>Średni</i> <br /> Poziom
147) umiejętności: <i>Średni</i> <br /> Prawdopodobni opiekunowie: <i>Mike,
148) Roger, Sebastian, Damian</i> <br /> <a href="<page tordnsel/index>">Tor DNS
149) Exit List</a> jest programem w Haskellu , którym nikt się nie opiekuje, a
150) który służy trzem celom. Po pierwsze, dostarcza interfejsu DNS w stylu rbl
151) dla osób chcących sprawdzić, czy dany adres IP jest (lub ostatnio był)
152) węzłem wyjściowym Tora. Po drugie, aktywnie buduje obwody w sieci Tora i
153) łączy się sam ze sobą, by poznać właściwy wyjściowy adres IP każdego
154) przekaźnika &mdash; niektóre z przekaźników wychodzą z innego adresu niż ten
155) podany w ich deskryptorze. Po trzecie, eksportuje <a
156) href="http://exitlist.torproject.org/exitAddresses">zestaw wniosków</a>, by
157) <a href="https://check.torproject.org/">check.torproject.org</a> mógł
158) zgadnąć, czy Twoja przeglądarka jest skonfigurowana, by używać Tora. <br />
159) Ten projekt wykorzystałby <a
160) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>,
161) zestaw skryptów Pythona do interakcji z Torem, by dowiedzieć się, jak nasz
162) program do sprawdzania wyjścia z Tora powinien działać, po czym stworzyłby
163) go &mdash; proawdopodobnie w Pythonie, gdyż Torflow jest w Pythonie. Głównym
164) celem jest zmniejszenie fałszywych wyników pozytywnych tak bardzo, jak to
165) jest możliwe, przez sprawienie, by dowiadywał się o nowych przekaźnikach tak
166) szybko, jak to jest możliwe, spawienie, że faza testowania kończy się szybko
167) i upewnianie się, że odpowiedzi sdzybko trafiają do skryptu Check. Jako
168) bonus, powinniśmy ustandaryzować (wyspecyfikować) format pliku exitAddresses
169) i przepisać skrypt <a

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

171) Bulk Exit List</a>, by używał tamtego pliku zamiast bieżących <a
172) href="https://trac.torproject.org/projects/tor/ticket/1019">strasznych
173) prowizorek DNS</a>. Jako dodatkowy bonus, powinniśmy pracować z Freenode,
174) OFTC oraz innymi sieciami IRC, by upewnić się, że skrypty, które oferujemy
175) są tymi, które oni chcieli, w sensie dokładnego identyfikowania, którzy z
176) ich użytkowników przychodzą z sieci Tora. <br /> Możesz pobrać <a
177) href="git://git.torproject.org/git/tordnsel">najnowszą wersję tordnsel</a>
178) przez git.

179) </li>
180) 
181) <li>

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

210) </li>
211) 

212) 
213) 
214) <!--<li>
215) 
216) <b>Tuneup Tor!</b>

217) <br />

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

263) </li>
264) 

265) <li>

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

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

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

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

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

297) </li>
298) 
299) <li>

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

316) </li>

317) 
318) <li>

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

335) pisania kodu i w mniejszym - z projektowania.
336) </li>
337) <li>

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

377) </li>
378) 

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

386) <br />

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

388) <br />

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

390) <br />

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

392) <br />

393) Likely Mentors: <i>Mike</i>
394) <br/>
395) There are several <a

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

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

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

403) specific cookies</a> when cookies are cleared,
404) <a

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

406) referrer spoofing</a>, <a

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

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

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

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

465) </li>
466) 
467) <li>

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

487) </li>
488) 
489) <li>

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

499) </li>
500) 

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

506) <br />

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

508) <br />

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

510) <br />

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

512) <br />

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

514) <br />

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

543) </li>
544) 
545) <li>

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

585) </li>
586) 

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

623) <li>

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

649) </li>
650) 
651) 

652) 

653) <!--<li>
654) 
655) <b>Usability testing of Tor</b>

656) <br />

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

658) <br />

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

660) <br />

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

662) <br />

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

664) <br />

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

670) <li>

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

700) </li>

701) 
702) <li>

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

723) </li>
724) 

725) <li>

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

732) </li>
733) 

734) </ol>
735) 

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

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

739) <ol>

740) <li>Przekaźniki sieci Tora nie działają zbyt dobrze na Windows XP. Pod systemem
741) Windows Tor używa standardowej funkcji systemowej <tt>select()</tt>, która
742) zużywa miejsce w niestronicowanym obszarze pamięci. Znaczy to, że średnich
743) rozmiarów przekaźnik sieci Tora zapełni dostępną przestrzeń, <a
744) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/WindowsBufferProblems">będąc
745) przyczyną dziwnych zachowań i padów systemu</a>. Powinniśmy raczej używać
746) nakładającego IO. Jednym z rozwiązań byłoby nauczenie biblioteki <a
747) href="http://www.monkey.org/~provos/libevent/">libevent</a>, jak używać
748) nakładającego IO zamiast select() pod Windows, po czym zaadaptować Tora do
749) nowego interfejsu. Christian King zrobił <a
750) href="https://svn.torproject.org/svn/libevent-urz/trunk/">pierwszy dobry
751) krok</a> latem roku 2007.</li>

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

774) 

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

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

780) <li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest ładne i
781) proste, ale oznacza to, że wszystkie komórki na łączu zostają opóźnione, gdy
782) pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie obsługiwać
783) możemy tylko strumienie TCP. Mamy <a
784) href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">listę
785) powodów, dla których nie przenieśliśmy się na UDP</a>, ale byłoby dobrze
786) skrócić tę listę. Mamy też proponowaną <a
787) href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specyfikację dla
788) Tora i UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>

789) 

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

791) wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy
792) punkt startu.</li>
793) 

794) <li>We need a way to generate the website diagrams (for example, the "How Tor
795) Works" pictures on the <a href="<page overview>">overview page</a> from
796) source, so we can translate them as UTF-8 text rather than edit them by hand
797) with image editors. We might want to integrate this as an wml file so
798) translations are easy and images are generated in multiple languages
799) whenever we build the website.</li>

800) 
801) <li>Jak można uczynić różne systemy LiveCD/USB łatwiejszym w utrzymaniu,
802) ulepszaniu i dokumentowaniu? Jednym z przykładów jest <a
803) href="http://anonymityanywhere.com/incognito/">(Amnesic) Incognito Live
804) System</a>
805) </li>

806) 
807) <li>

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

819) </li>
820) 

821) </ol>
822) 
823) <a id="Research"></a>
824) <h2><a class="anchor" href="#Research">Badania</a></h2>
825) <ol>

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

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

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

852) symetrycznych z innych przyczyn?</li>

853) <li>Powtórzcie <a

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

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

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

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

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

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

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

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

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

945) </li>

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

959) </li>

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

963) </li>

964) </ol>
965) 

966) <p>

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

969) </p>

970) 

971)   </div>

972) 
973)