tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 14707

3) # Last-Translator: bogdandr_at_op . pl
4) 

5) #include "head.wmi" TITLE="Tor: Wolontariusze" CHARSET="UTF-8"

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

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

11) <ol>

12) <li>Prosimy rozważyć <a href="<page docs/tor-doc-relay>">uruchomienie
13)  przekaźnika sieci Tor</a>, by wspomóc rozwój sieci Tora.</li>
14) <li>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili przekaźniki sieci.

15)  Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.</li>

16) <li>Jeśli podobają ci się cele Tora,

17)   <a href="<page donate>">poświęć chwilę, by złożyć dotację, aby wspomóc przyszły rozwój Tora</a>.

18)   Szukamy też dalszych sponsorów —
19)   jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
20)   są zainteresowane anonimowością / prywatnością / bezpieczną komunikacją, daj im znać o nas.</li>
21) <li>Szukamy więcej <a href="<page torusers>">dobrych przykładów użytkowników
22)  Tora i przypadków jego używania</a>. Jeśli używasz Tora w sposób jeszcze nie przedstawiony
23)  na tamtej stronie i nie masz nic przeciw podzieleniu się z nami tym sposobem, z chęcią
24)  przyjmiemy taką wiadomość.</li>

25) </ol>
26) 
27) <a id="Usability"></a>
28) <h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
29) <ol>

30)  <li>Potrzebujemy więcej dobrych sposobów na przechwytywanie żądań DNS, żeby nie

31)  "przeciekały" do lokalnych obserwatorów, podczas gdy chcemy zachować anonimowość.

32)  (Dzieje się tak, gdyż aplikacja wysyła żądanie DNS przed przejściem przez serwer
33)  Proxy SOCKS.)</li>

34) <li>Sprawy z Tsocks/dsocks:
35)  <ul>

36) <li>Musimy <a

37)  href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">zastosować

38)  nasze wszystkie łaty tsocks do kodu</a> i utrzymywać nową gałąź. Możemy ją hostować, jeśli chcesz.</li>

39) <li>Powinniśmy załatać program "dsocks" Duga Songa, by używał komend

40)  <i>mapaddress</i> Tora z interfejsu kontroli, żeby nie marnować przejścia

41)  całej trasy w Torze, wykonując rozwiązywanie adresów przed połączeniem.</li>

42) <li>Musimy sprawić, by nasz skrypt <i>torify</i> wykrywał, który z programów
43)  tsocks lub dsocks jest zainstalowany, i odpowiednio je uruchamiał. To
44)  prawdopodobnie oznacza zunifikowanie ich interfejsów i w grę może wchodzić
45)  dzielenie kodu między nimi lub całkowita rezygnacja z jednego z nich.</li>

46) </ul>
47) </li>

48) <li>Ludzie, którzy uruchomili przekaźnik sieci Tora mówią nam, że chcą dać jedną

49)  przepustowość łącza dla Tora (BandwidthRate) w czasie pewnej części dnia,

50)  a inną w innych częściach dnia. Zamiast programować to w Torze, powinniśmy mieć
51)  mały skrypt, który łączy się przez <a href="<page gui/index>">Tor Controller Interface</a>,

52)  i wykonuje SETCONF by zmienić przepustowość. Jest już po jednym skrypcie dla systemów
53)  Unix i Mac (korzystają z basha i crona), ale dalej potrzebne jest rozwiązanie
54)  dla użytkowników Windowsa.

55)  </li>

56) <li>Tor może <a

57)  href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">wychodzić

58)  z sieci Tora używając podanego węzła</a>, ale powinniśmy móc podać tylko kraj i mieć coś,

59)  co automatycznie za nas wybierze węzeł. Najlepszym kandydatem jest pobranie także
60)  katalogu Blossom i uruchomienie lokalnego klienta Blossom, który pobrałby swój katalog w

61)  sposób bezpieczny (poprzez Tor i sprawdzając jego podpis), przechwytywałby nazwy

62)  hostów <tt>.country.blossom</tt>  i robił to, co trzeba.</li>
63) <li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z

64)  zaznaczonym każdym przekaźnikiem sieci Tora. Dodatkowe punkty, jeśli mapa będzie się

65)  aktualizować w miarę jak sieć rośnie i się zmienia. Niestety, łatwy sposób na
66)  dokonanie tego to wysłanie wszystkich danych do Google, w celu narysowania
67)  przez nich taj mapy. Jak bardzo to uderza w prywatność i czy mamy jakieś inne
68)  dobre wyjścia?</li>
69) </ol>
70) 
71) <a id="Documentation"></a>
72) <h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
73) <ol>

74) <li>Proszę pomóc Mattowi Edmanowi z dokumentacją i dokumentami jak-to-zrobić do

75)  jego projektu Tor Controller i <a href="http://vidalia-project.net/">Vidalia</a>.</li>

76) <li>Przejrzyj i udokumentuj

77)  <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">naszą

78)  listę programów</a>, które można skonfigurować do współpracy z Torem.</li>

79) <li>Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń

80)  i wysyłania ich przez Tora. tsocks (Linux), dsocks (BSD),

81)  i freecap (Windows) zdają się być dobrymi kandydatami, jako że lepiej
82)  używałyby naszej nowej cechy TransPort.</li>

83) <li>Mamy ogromną listę <a
84)  href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">potencjalnie

85)  użytecznych programów, które współpracują z Torem</a>. Które z nich są

86)  przydatne w jakich sytuacjach? Proszę pomóż nam je testować i zapisuj
87)  swoje wyniki.</li>
88) <li>Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na
89)  <a href="<page translation>">wskazówki do

90)  tłumaczenia</a>, jeśli chcesz pomóc. Potrzebujemy zwłaszcza tłumaczy na język
91)  arabski i Farsi dla wielu użytkowników Tora w cenzorowanych obszarach.</li>
92) 

93) </ol>
94) 
95) <a id="Coding"></a>

96) <a id="Summer"></a>
97) <a id="Projects"></a>
98) <h2><a class="anchor" href="#Projects">Dobre Projekty Programistyczne</a></h2>

99) 
100) <p>

101) Część z poniższych projektów może być dobrymi pomysłami na <a
102) href="<page gsoc>">Google Summer of Code 2008</a>. Oznaczyliśmy każdy z nich informacją,

103) jak bardzo by się przydał do całości projektu Tor (priorytet), ile według nas
104) potrzeba na niego pracy (poziom wysiłku), z jaką wiedzą powinno się zaczynać

105) (poziom umiejętności), i który z naszych <a
106) href="<page people>#Core">głównych deweloperów</a> byłby dobrym prowadzącym.

107) Jest wiele inych dobrych pomysłów, nad którymi można popracować — przeczytaj
108) na przykład listę <a href="<svnsandbox>doc/spec/proposals/">bieżących propozycji</a>
109) lub po prostu wymyśl swoje własne.

110) </p>
111) 
112) 

113) <ol>
114) 
115) <li>

116) <b>Ulepszenie Skanera Wyjściowego Tora (Tor Exit Scanner)</b>

117) <br />
118) Priorytet: <i>Wysoki</i>
119) <br />
120) Poziom wysiłku: <i>Wysoki</i>
121) <br />
122) Poziom umiejętności: <i>Wysoki</i>
123) <br />

124) Prawdopodobni prowadzący: <i>Mike</i>

125) <br />

126) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>5</i>

127) <br />

128) Skaner węzłów wyjściowych Tora, 'SoaT', część <a
129) href="https://www.torproject.org/svn/torflow/">projektu Torflow</a>, jest
130) w chwili obecnej napisany w chwiejnym Perlu i opiera się na sumach
131) kontrolnych MD5 dla całych dokumentów w celu stwierdzenia, czy
132) węzły wyjściowe zmieniają zawartość. Problem z tym składa się z 3 części:
133) 1) Perl jest do bani 2) skaner nie umie weryfikować stron dynamicznych, a
134) atakujący mogą skupić się na umieszczaniu złośliwego oprogramowania
135) tylko na stronach dynamicznych 3) strony zmieniają się raz na jakiś czas
136) (lub opierając się na GeoIP) i zaczynają generować fałszywe pozytywne wyniki.

137) <br />

138) Najlepiej byłoby reimplementować soat.pl w jakimś normalnym języku z
139) dobrą biblioteką do parsowania HTML (dobry byłby Python, jako że reszta Torflow
140) jest w nim napisana, lecz nie jest to wymagane) i wyliczać sygnatury stron
141) tylko dla znaczników i zawartości, która może stać się celem ataku (znaczniki
142) skryptów, linki do obiektów, obrazki). Program powinien też działać dobrze
143) w obliczu zewnętrznych w stosunku do Tora zmian zawartości, a docelowo nawet
144) z lokalizowaną zawartością poprzez GeoIP.
145) <br />
146) Skaner ten prawdopodobnie byłby uruchamiany przez serwery katalogowe i
147) zgłaszał swoje wyniki na port kontroli poprzez zmienną konfiguracji AuthDirBadExit.

148) <br />
149) </li>
150) 
151) <li>

152) <b>Ulepszenie Skanera Węzłów Tora (Tor Node Scanner)</b>

153) <br />

154) Priorytet: <i>Wysoki</i>

155) <br />

156) Poziom wysiłku: <i>Średni do Wysokiego</i>

157) <br />
158) Poziom umiejętności: <i>Średni do Wysokiego</i>
159) <br />

160) Prawdopodobni prowadzący: <i>Mike</i>

161) <br />

162) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>1</i>

163) <br />

164) Podobnie do skanera wyjściowego (lub może nawet w czasie jego działania),
165) można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które
166) źle działają dla pewnej części swoich obwodów nie powinny być używane do
167) statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną
168) przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo,
169) węzły wykazujące bardzo niską średnią przepustowość strumienia,
170) lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne.
171) Większość zbierania statystyk już jest zrobiona, dane te muszą tylko
172) zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym,
173) by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci
174) się o tym dowiedzą.

175) <br />

176) Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego
177) przez węzeł. Do <a
178) href="https://www.torproject.org/svn/torctl/doc/howto.txt">Protokołu Kontroli
179) Tora</a> można dodać zdarzenia mówiące, czy udaje się stworzyć obwód
180) przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące
181) zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty
182) na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też
183) informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych,
184) ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby
185) zostać stworzony.
186) </li>
187) 
188) <li>
189) <b>Pomóż śledzić ogólny status Sieci Tora</b>

190) <br />

191) Priorytet: <i>Wysoki</i>
192) <br />
193) Poziom wysiłku: <i>Średni</i>
194) <br />
195) Poziom umiejętności: <i>Średni</i>
196) <br />
197) Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>
198) <br />
199) Byłoby wspaniale uruchomić automatyczny system śledzenia stanu sieci w czasie,
200) wyświetlanie wykresów itp. Częścią tego projektu byłoby wynalezienie lepszych
201) miary do oceny stanu i wzrostu sieci. Czy wzrasta średni czas działania sieci?
202) Ile węzłów kwalifikuje się do bycia Strażnikami w tym miesiącu w porównaniu z
203) ubiegłym? Jaka jest rotacja w sensie pojawiania się nowych węzłów i znikania
204) starych? Okresowo ludzie gromadzą krótkie migawki stanu, ale to robi się naprawdę
205) interesujące dopiero, gdy zaczynamy śledzić te dane w czasie.
206) <br />
207) Dane powinny być zbierane z powyższego narzędzia "Skaner Węzłów Tora", z
208) deskryptorów serwerów, które są publikowane przez każdy przekaźnik i z innych
209) źródeł. Wyniki w czasie mogłyby być zintegrowane z jedną ze stron opisujących
210) <a href="https://torstatus.blutmagie.de/">Stan Tora</a> lub być trzymane osobno.
211) Skoro mówimy o stronach stanu Tora, spójrzcie na
212) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">listę życzeń
213) stanu Tora</a> napisaną przez Rogera.
214) </li>
215) 
216) <li>
217) <b>Polepszenia w wybieraniu ścieżki przez Tora</b>
218) <br />
219) Priorytet: <i>Wysoki</i>
220) <br />
221) Poziom wysiłku: <i>Niski do Średniego</i>
222) <br />
223) Poziom umiejętności: <i>Wysoki</i>
224) <br />
225) Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>
226) <br />

227) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>3</i>

228) <br />

229) Można dokonać pewnych prostych ulepszeń do algorytmu wyboru ścieżki przez Tora,
230) by znacznie zwiększyć jego szybkość. Na przykład, kilka (nieoficjalnych)  <a
231) href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Zaleceń
232) Wydajności Tora</a> na wiki to zwiększenie liczby strażników i zmniejszenie
233) CircuitBuildTimeout. Najlepiej by było, gdyby klient sam uczył się tych
234) wartości poprzez zbieranie statystyk dotyczących czasu budowania obwodów
235) (lub używać wartości uzyskanych z Torflow) i ustawiał czasy dość nisko, by
236) wysoki procent (75%, 90%, 1-stddev?) obwodów uległ stworzeniu, lecz by
237) strasznie wolne węzły były unikane. Wymagałoby to pewnego zbierania
238) statystyk i podstawowych badań oraz pewnych zmian w kodzie Tora dotyczącym
239) wyboru ścieżki.
240) <br />
241) Dodatkowo, by zwiększyć bezpieczeństwo ścieżek, można byłoby dołączyć niektóre
242) elementy z <a
243) href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt"
244) >Propozycji Ścieżek 2-Skokowych</a> (jako że będzie to i tak dotyczyć tego samego kodu),
245) bez uwagi na to, czy ta Propozycja będzie przyjęta. W szczególności, klienci powinni
246) unikać strażników, którzy zdają się mieć problem ze zbudowaniem znacznej części
247) swoich obwodów, a klienci bez firewalli powinni pokazywać ostrzeżenia, że udało im
248) się połączyć tylko z ograniczoną liczbą węzłów-strażników. Przeczytaj także
249) <a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">tę wiadomość
250) na or-dev</a>.
251) </li>
252) 
253) <li>
254) <b>Wiki do tłumaczenia</b>
255) <br />
256) Priorytet: <i>Wysoki</i>
257) <br />
258) Poziom wysiłku: <i>Średni</i>
259) <br />
260) Poziom umiejętności: <i>Średni</i>
261) <br />
262) Prawdopodobni prowadzący: <i>Jacob</i>
263) <br />
264) Potrzebujemy sposobu na edycję i tłumaczenie sekcji strony &mdash;
265) z możliwością, że stworzy to łatę na oficjalne drzewo svn. Bieżący
266) "koszt" publikacji zmian na stronie jest dość wysoki nawet dla
267) anglojęzycznych użytkowników. Muszą oni pobierać pliki z szablonami,
268) tłumaczyć je i przysyłać tłumaczenia nam. Jeśli trzeba zmienić pojedyncze słowo
269) lub coś małego, strona może nigdy nie zostać poprawiona lub przetłumaczona.
270) Dobrze byłoby mieć wiki nastawione specjalnie na tłumaczenia, które jakoś
271) śledziłoby nowe (angielskie) wersje i pokazywałoby, kiedy potrzebne będzie
272) świeże tłumaczenie, jak nasza aktualna <a href="<page translation-status>"
273) >strona ze stanem tłumaczenia</a>. Wydaje się to zadaniem głównie dla integratorów wiki
274) lub twórców oprogramowania wiki. Z pewnością osoba powinna interesować się
275) językami i tłumaczeniem. Powinna być choć minimalnie zaznajomiona z tym,
276) co to jest Tor, ale nie musiałaby stykać się z samym oprogramowaniem,
277) tylko z dokumentacją na stronie.

278) </li>
279) 
280) <li>
281) <b>Lepsze wsparcie i pakowanie dla Debiana</b>
282) <br />
283) Priorytet: <i>Wysoki</i>
284) <br />
285) Poziom wysiłku: <i>Średni</i>
286) <br />
287) Poziom umiejętności: <i>Średni</i>
288) <br />

289) Prawdopodobni prowadzący: <i>Peter, Matt</i>

290) <br />

291) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>1</i>

292) <br />

293) Vidalia obecnie nie współpracuje dobrze na Debianie i Ubuntu z domyślnymi
294) paczkami Tora. Bieżące paczki Tora automatycznie uruchamiają Tora jako demona
295) systemowego z konta użytkownika debian-tor i (rozsądnie) nie mają zdefiniowanego
296) ControlPort w domyślnym torrc. Stąd Vidalia będzie próbować uruchomić własny
297) proces Tora, bo nie może połączyć się z istniejącym, po czym proces Tora
298) uruchomiony przez Vidalię zamknie się z błędem, którego użytkownik raczej nie zrozumie,
299) jako że Tor nie będzie mógł podpiąć się pod swoje porty nasłuchowe, które są
300) już zajęte przez pierwszy proces Tora.
301) <br />
302) Bieżące rozwiązanie to albo mówienie użytkownikowi, by zatrzymał istniejący
303) proces Tora i pozwolił Vidalii uruchomić własny, albo tłumaczenie, jak ustawić
304) port kontrolny i hasło w pliku torrc. Lepszym rozwiązaniem na Debianie byłoby używanie
305) ControlSocket Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez
306) gniazdo w domenie Unix i mógłby być domyślnie włączony w paczkach Tora dla Debiana.
307) Vidalia może wtedy uwierzytelnić się do Tora używając ciasteczek, jeśli użytkownik
308) uruchamiający Vidalię jest w grupie debian-tor.
309) <br />
310) Pierwsza część tego projektu będzie polegała na dodaniu obsługi ControlSocket
311) do Vidalii. Potem student stworzy i przetestuje paczki Vidalii na Debianie i
312) Ubuntu, które będą zgodne ze standardami pakowania w Debianie, oraz upewni się,

313) że działają dobrze z istniejącymi paczkami Tora. Możemy też stworzyć repozytorium

314) apt zawierające nowe paczki Vidalia.
315) <br />

316) Kolejnym wyzwaniem byłoby znalezienie intuicyjnego sposobu, by Vidalia mogła
317) zmienić konfigurację Tora (torrc) mimo iż ta jest w <code>/etc/tor/torrc</code>,
318) a więc nienaruszalna. Najlepszy jak dotąd pomysł, na jaki wpadliśmy, to
319) przekazanie Torowi nowej konfiguracji poprzez ControlSocket w czasie uruchamiania
320) Vidalii, ale jest to zły pomysł, gdyż Tor za każdym razem uruchamia się z inną
321) konfiguracją niż użytkownik by tego chciał. Drugi najlepszy pomysł jest taki, by
322) Vidalia stworzyła tymczasowy plik konfiguracyjny i poprosiła użytkownika, by
323) ręcznie przeniósł go do <code>/etc/tor/torrc</code>, ale to jest zły pomysł, gdyż
324) użytkownicy nie powinni być zmuszani do bezpośredniego zajmowania się plikami.
325) <br />

326) Student podejmujący się tego projektu powinien znać system pakowania Debiana i
327) mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przydatne,
328) ale nie jest wymagane.
329) </li>
330) 

331) <li>
332) <b>Polepszanie naszych zdolności opierania się cenzurze</b>
333) <br />
334) Priorytet: <i>Wysoki</i>
335) <br />
336) Poziom wysiłku: <i>Wysoki</i>
337) <br />
338) Poziom umiejętności: <i>Średni do Wysokiego</i>
339) <br />
340) Prawdopodobni prowadzący: <i>Roger, inni</i>
341) <br />
342) Wersje 0.2.0.x Tora robią <a
343) href="<svnsandbox>doc/design-paper/blocking.html">znaczne postępy</a> w opieraniu
344) się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w
345) niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą
346) nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje
347) <a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">propozycja
348) zajęcia się tą sprawą</a> i umożliwienia klientom łączenie się z danym Torem
349) na wielu adresach i portach, ale wymaga to więcej pracy. Kolejny projekt
350) przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie.
351) W chwili obecnej ktokolwiek może zidentyfikować
352) <a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">mostki Tora</a>
353) po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając,
354) czy odpowiadają. By rozwiązać ten problem, mostki mogłyby
355) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">udawać serwery
356) internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów,
357) a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny
358) dla mostka.
359) <br />
360) Ten projekt zawiera wiele badań i projektowania. Jednym z większych wyzwać
361) będzie zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą
362) się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie
363) odporności na cenzurę z użytecznością i siłą.
364) </li>
365) 
366) <li>
367) <b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>
368) <br />
369) Priorytet: <i>Wysoki</i>
370) <br />
371) Poziom wysiłku: <i>Wysoki</i>
372) <br />
373) Poziom umiejętności: <i>Wysoki</i>
374) <br />
375) Prawdopodobni prowadzący: <i>Matt, Jacob</i>
376) <br />
377) Potrzebujemy dobrego frameworka automatycznej aktualizacji.
378) Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub
379) niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe
380) okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.
381) Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i
382) zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,
383) chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy
384) Vidalia.
385) <br />
386) By wykonać ten projekt, student będzie musiał najpierw poznać istniejące
387) mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,
388) cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże
389) się przydatny, student zaprojektuje własny framework aktualizacyjny,
390) udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat
391) jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)
392) i przetestuje.
393) <br />
394) Student podejmujący się tego projektu powinien dobrze znać C++.
395) Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.
396) Student powinien mieć też podstawowe pojęcie o powszechnych praktykach
397) bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w
398) pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie
399) zrobienie dokumentacji projektu dla innych do przejrzenia i przedyskutowania
400) ze studentem przed implementacją.
401) </li>
402) 
403) <li>
404) <b>Poprawiona i bardziej użyteczna mapa sieci</b>
405) <br />
406) Priorytet: <i>Średni</i>
407) <br />
408) Poziom wysiłku: <i>Średni</i>
409) <br />
410) Poziom umiejętności: <i>Średni do Wysokiego</i>
411) <br />
412) Prawdopodobni prowadzący: <i>Matt</i>
413) <br />
414) Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi
415) przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje
416) ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.
417) Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.
418) Wolelibyśmy użyć widgetu Marble z KDE, który daje mapę lepszej jakości i
419) umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na
420) klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe
421) informacje. Moglibyśmy też rozważyć dodanie możliwości klikania przez
422) użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
423) stwierdzenia "chcę, by moje połączenia do foo.com wychodziły stąd."
424) <br />
425) Podczas tego projektu, student najpierw zapozna się z Vidalią i API widgetu
426) Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował
427) do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we
428) własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.
429) <br />
430) Student podejmujący się tego projektu powinien dobrze znać C++.
431) Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
432) </li>
433) 

434) <li>

435) <b>Interfejs zdarzeń stanu kontrolera Tora</b>

436) <br />
437) Priorytet: <i>Średni</i>
438) <br />
439) Poziom wysiłku: <i>Średni</i>
440) <br />
441) Poziom umiejętności: <i>Średni</i>
442) <br />

443) Prawdopodobni prowadzący: <i>Matt, Roger</i>

444) <br />
445) Jest pewna liczba zmian stanu, o których użytkownik powinien być może być
446) informowany. Na przykład, jeśli użytkownik chce uruchomić przekaźnik sieci Tor,
447) a Tor stwierdzi, że nie jest on osiągalny z zewnątrz, użytkownik powinien zostać
448) o tym poinformowany. W tej chwili wszystko, co dostaje użytkownik, to kilka
449) wiadomości w "dzienniku wiadomości" Vidalii, których pewnie nie zobaczy, gdyż

450) nie dostaje informacji, że coś poszło nie tak. Nawet jeśli użytkownik spojrzy na
451) zapis logów, większość wiadomości będzie miała mały sens dla początkującego.

452) <br />
453) Tor ma możliwość informowania Vidalii o wielu takich zmianach stanu, a ostatnio
454) zaimplementowaliśmy obsługę kilku takich zdarzeń. Jednak jest wiele więcej
455) zdarzeń, o których użytkownik powinien być informowany i potrzebujemy
456) lepszego interfejsu użytkownika do wyświetlania takich wiadomości.
457) <br />
458) Celem tego projektu jest zaprojektowanie i zaimplementowanie interfejsu
459) użytkownika do wyświetlania wiadomości o stanie Tora. Na przykład, można
460) byłoby umieścić mały znaczek na ikonie Vidalii w zasobniku, który alarmowałby

461) użytkownika o nowych zmianach stanu, którym powinien się przyjrzeć.

462) Podwójne kliknięcie tej ikonki pokazywałoby okienko dialogowe podsumowujące
463) ostatnie zmiany stanu prostymi słowami i może sugerujące rozwiązania
464) do negatywnych wiadomości, jeśli mogą one być naprawione przez użytkownika.
465) Oczywiście to tylko przykład i student może zaproponować inne podejście.
466) <br />
467) Student podejmujący się tego projektu powinien dobrze znać projektowanie i
468) tworzenie interfejsu użytkownika i mieć trochę doświadczenia z C++.
469) Uprzednie doświadczenie z Qt i Qt Designer będzie przydatne, ale nie jest wymagane.
470) Przydatne mogą być też pewne umiejętności w pisaniu po angielsku, gdyż

471) ten projekt prawdopodobnie będzie wymagał napisania małej ilości dokumentacji

472) pomocniczej, która powinna być zrozumiała dla nie-technicznych użytkowników.
473) Dodatkowe punkty za jakiś projekt graficzny /Photoshop fu, gdyż moglibyśmy
474) chcieć/potrzebować nowych ikonek.
475) </li>
476) 
477) <li>
478) <b>Ulepszenia naszego aktywnego testera konfiguracji przeglądarek</b> -
479) <a href="https://check.torproject.org">https://check.torproject.org</a>
480) <br />
481) Priorytet: <i>Średni</i>
482) <br />
483) Poziom wysiłku: <i>Niski</i>
484) <br />
485) Poziom umiejętności: <i>Niski to Średniego</i>
486) <br />

487) Prawdopodobni prowadzący: <i>Jacob, Steven</i>

488) <br />

489) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>1</i>
490) <br />

491) Mamy w tej chwili funkcjonalną stronę www, która sprawdza, czy Tor działa.
492) Ma jednak parę miejsc, w których działa źle. Wymaga ulepszeń dotyczących
493) domyślnych języków i funkcjonalności. W chwili obecnej odpowiada tylko po angielsku.
494) Ponadto, jest to kawał skryptu Perla, który nigdy nie powinien był ujrzeć światła
495) dziennego. Strona powinna prawdopodobnie zostać przepisana w Pythonie

496) z uwagą na wielojęzyczności. Teraz używa <a
497) href="http://exitlist.torproject.org/">listy punktów wyjściowych Tor DNS</a>

498) i powinna to robić w przyszłości. Może to dawać fałszywe pozytywne wyniki - te
499) powinny zostać wykryte, udokumentowane i naprawione, gdzie to będzie możliwe.

500) Ktokolwiek pracujący nad tym projektem powinien interesować się DNS,

501) znać podstawy Perla lub lepiej - Pythona. Będzie musiał tylko minimalnie
502) stykać się z Torem, by testować swój kod.

503) <br />
504) Jeśli chcesz, by ten projekt był bardziej ekscytujący i zawierał więcej
505) projektowania i programowania, przeczytaj <a
506) href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">propozycję
507) 131-verify-tor-usage.txt</a>.

508) </li>
509) 
510) <li>
511) <b>Ulepszenia w naszej usłudze punktów wyjściowych Tora - DNS Exit List</b> -
512) <a href="http://exitlist.torproject.org">http://exitlist.torproject.org</a>
513) <br />
514) Priorytet: <i>Średni</i>
515) <br />
516) Poziom wysiłku: <i>Niski</i>
517) <br />
518) Poziom umiejętności: <i>Niski</i>
519) <br />

520) Prawdopodobni prowadzący: <i>Jacob, Tup</i>

521) <br />

522) <a href="http://p56soo2ibjkx23xo.onion/">Oprogramowanie</a> to zostało
523) napisane przez naszego wspaniałego wolontariusza - Tup.

524) Jest to serwer DNS napisany w języku Haskell, obsługujące część naszego <a
525) href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">dokumentu
526) projektowania listy punktów wyjściowych</a>. W chwili obecnej, usługa jest
527) funkcjonalna i używana przez check.torproject.org i innych użytkowników. Sprawy,
528) które zostały do zrobienia to głównie estetyka. Tej wspaniałej usłudze przydałaby
529) się o wiele lepsza strona z motywem wspólnym dla stron Tora. Lepiej by wyglądała
530) z lepszą dokumentacją częstych usług korzystających z RBL. Przydałby się rozgłos.
531) Osoba pracująca nad tym projektem powinna interesować się DNS, podstawową konfiguracją
532) RBL dla popularnych usług i pisaniem dokumentacji. Osoba ta wymagałaby tylko minimalnego
533) stykania się z Torem &mdash; co najmniej podczas testowania własnej dokumentacji.

534) Ponadto, byłoby dobrze, gdyby interesowała się Haskellem i chciała zaimplementować

535) więcej z sugestii w dokumencie torel-design.txt.
536) </li>
537) 
538) <li>
539) <b>Testowanie integracji Tora z przeglądarkami dla użytkowników końcowych</b>
540) <br />
541) Priorytet: <i>Średni</i>
542) <br />
543) Poziom wysiłku: <i>Średni</i>
544) <br />
545) Poziom umiejętności: <i>Średni</i>
546) <br />

547) Prawdopodobni prowadzący: <i>Jacob, Mike, Greg</i>

548) <br />

549) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>1</i>
550) <br />

551) Projektowi Tor brakuje obecnie solidnego testu do upewnienia się, że

552) użytkownik poprawnie skonfigurował przeglądarkę. Taki test powinien sprawdzać

553) tyle elementów, ile się da. Powinien spróbować zdjąć ukrycie użytkownika
554) na każdy możliwy sposób. Dwie aktualne strony śledzące takie sprawy są
555) prowadzone przez Grega i HD Moore'a. Greg trzyma ładną <a
556) href="http://pseudo-flaw.net/tor/torbutton/">listę problemów wraz z dowodami

557) jak ich użyć oraz listę błędów itp.</a>. HD Moore prowadzi

558) <a href="http://metasploit.com/research/misc/decloak/">stronę metasploit
559) decloak</a>. Osoba zainteresowana atakiem na Tora mogłaby zacząć od
560) zbierania jak największej liczby działających i znanych metod odkrywania

561) użytkownika Tora. (<a href="https://torcheck.xenobite.eu/">Ta strona</a> może być
562) pomocna na początek.) Ta osoba powinna znać częste pułapki, ale też myśleć o

563) nowych metodach zdejmowania osłony użytkowników. Strona powinna

564) informować użytkownika, w czym ma problem. Powinna pomóc mu w naprawieniu

565) problemu lub skierować go na właściwe kanały wsparcia. Osoba wykonująca powinna
566) dobrze znać Tora i to, jak zapobiegać wyciekom.
567) </li>
568) 
569) <li>
570) <b>Lepsza integracja Tora i Libevent</b>
571) <br />
572) Priorytet: <i>Średni</i>
573) <br />
574) Poziom wysiłku: <i>Wysoki</i>
575) <br />
576) Poziom umiejętności: <i>Średni do Wysokiego</i>
577) <br />

578) Prawdopodobni prowadzący: <i>Nick</i>
579) <br />
580) Tor powinien lepiej używać nowych cech biblioteki
581) <a href="http://monkey.org/~provos/libevent/">Libevent</a> Nielsa Provosa.

582) Tor już używa Libevent do niskopoziomowych funkcji wejścia/wyjścia i mógłby użyć

583) coraz lepszych implementacji buforów sieciowych i HTTP. Nie byłaby to po prostu

584) kwestia zastąpienia wewnętrznych funkcji Tor wywołaniami funkcji z Libevent -

585) zamiast tego musimy zmienić Tora, by używał wywołań Libevent, które nie
586) trzymają się modelu istniejących funkcji. Ponadto, będzie trzeba dodać pewne
587) funkcjonalności do Libevent, jeśli będzie trzeba — prawdopodobnie
588) najtrudniejsze będzie dodanie obsługi OpenSSL na abstrakcje buforów w Libevent.
589) Niełatwe również będzie dodanie ograniczanie transferu do Libevent.

590) </li>
591) 
592) <li>
593) <b>Tuneup Tor!</b>
594) <br />
595) Priorytet: <i>Średni</i>
596) <br />
597) Poziom wysiłku: <i>Średni</i>
598) <br />
599) Poziom umiejętności: <i>Średni do Wysokiego</i>
600) <br />

601) Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>

602) <br />

603) W chwili obecnej węzły Tora mierzą i zgłaszają własną przepustowość łącza,
604) a klienci Tora wybierają, których węzłów używać po części opierając się
605) na tej zgłaszanej przepustowości. To podejście jest podatne na
606) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">ataki, w których węzły oszukują
607) na temat przepustowości swoich łączy</a>; by to zmienić, Tor aktualnie ogranicza
608) maksymalną przepustowość każdego węzła, w którą jest w stanie uwierzyć. To jest
609) ograniczone rozwiązanie i marnotrawienie przepustowości. Zamiast tego,

610) Tor powinien w miarę możliwości mierzyć przepustowość łączą w rozproszony sposób,
611) jak jest napisane w dokumencie

612) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tuneup for Tor"</a> autorstwa

613) Snadera i Borisova. Student mógłby użyć bieżącego kodu testującego, by sprawdzić

614) odkrycia napisane w tym dokumencie i zweryfikować, w jakim stopniu opisują one
615) normalnie działającego Tora i określić dobre sposoby na wcielenie tych odkryć

616) do sieci Tora bez dodawania niepożądanego ruchu wielkości między węzłami a serwerami
617) katalogowymi.

618) </li>
619) 

620) <!--

621) <li>
622) <b>Polepszenie procesu QA Tora: Ciągła integracja dla paczek pod Windows</b>
623) <br />
624) Priorytet: <i>Wysoki</i>
625) <br />
626) Poziom wysiłku: <i>Średni</i>
627) <br />
628) Poziom umiejętności: <i>Średni</i>
629) <br />

630) Prawdopodobni prowadzący: <i>Jacob, Andrew</i>

631) <br />
632) Przydałby się automatyczny system tworzenia paczek dla Windows i być może
633) innych systemów. Celem posiadania środowiska ciągłej integracji jest
634) upewnienie się, że Windows nie zostanie w tyle z żadnym z projektów

635) używanych lub związanych z projektem Tor. Buildbot

636) może być dobrym rozwiązaniem, gdyż zdaje się obsługiwać te same platformy, co Tor.
637) Przeczytaj (po angielsku) <a href="http://en.wikipedia.org/wiki/BuildBot">wpis na
638) Wikipedii dotyczący Buildbota</a>.<br />
639) Może jednak są lepsze rozwiązania, więc osoba podejmująca się tego zadania
640) powinna rozważyć inne opcje. Jakakolwiek osoba pracująca nad tym systemem
641) automatycznego budowania powinna mieć doświadczenie lub chęć do nauczenia
642) się tego, jak buduje się wszystkie odpowiednie elementy Tora od zera.

643) Ponadto, ta osoba powinna mieć jakieś doświadczenie w kompilowaniu

644) programów w Windows, jako że to jest ta część użytkowników, których nie chcemy
645) zostawiać w tyle. Zadanie będzie wymagała bliskiej pracy z kodem Tora,

646) ale prawdopodobnie tylko od strony kompilacji, nie pisania.<br />

647) Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.
648) Mamy już buildbota (za wyjątkiem Windows — jak napisane powyżej) do
649) automatyzacji naszej zwyczajnej integracji i kompilacji testów, ale

650) musimy zaktualizować nasze testy symulacji sieci (takie, jak w torflow)

651) do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe
652) albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie
653) badać zmiany wydajności na maszynach pełniących różne zadania.<br />
654) </li>

655) -->

656) 
657) <li>
658) <b>Polepszenie procesu testów jednostkowych</b>
659) <br />
660) Priorytet: <i>Średni</i>
661) <br />
662) Poziom wysiłku: <i>Średni</i>
663) <br />
664) Poziom umiejętności: <i>Średni</i>
665) <br />

666) Prawdopodobni prowadzący: <i>Nick</i>

667) <br />

668) Tor musi zostać znaczniej bardziej przetestowany. To jest projekt wieloczęściowy.

669) Na początek, nasze testy jednostkowe powinny znacznie się wzbogacić, zwłaszcza
670) w obszarach poza funkcjami narzędziowymi. Będzie to wymagało poważnych zmian
671) niektórych części Tora, aby oddzielić jak najwięcej programu od zmiennych
672) globalnych.<br />
673) Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.

674) Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów
675) (ale potrzebujemy osoby do uruchomienia tego pod Windows), ale
676) musimy zaktualizować nasze testy symulacji sieci (takie, jak w TorFlow: spójrz na punkt
677) "Ulepszenie Skanera Węzłów Tora")

678) do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe
679) albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie

680) badać zmiany wydajności na maszynach pełniących różne zadania.

681) </li>
682) 
683) <li>

684) <b>Pomóż wznowić niezależną implementację klienta Tora</b>

685) <br />

686) Priorytet: <i>Średni</i>

687) <br />
688) Poziom wysiłku: <i>Wysoki</i>
689) <br />
690) Poziom umiejętności: <i>Średni do Wysokiego</i>
691) <br />

692) Prawdopodobni prowadzący: <i>Karsten, Nick</i>

693) <br />

694) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>4</i>

695) <br />

696) Reanimuj jedno z podejść do implementacji klienta Tora w Javie, np.
697) <a href="http://onioncoffee.sourceforge.net/">projekt OnionCoffee</a>
698) i spraw, by działał pod <a href="http://code.google.com/android/">Androidem</a>.
699) Pierwszym krokiem byłoby przeniesienie istniejącego kodu i uruchomienie go
700) w środowisku Android. Potem kod powinien zostać zaktualizowany, by obsługiwać
701) nowsze wersje protokołu Tora, jak na przykład
702) <a href="<svnsandbox>doc/spec/dir-spec.txt">protokół katalogowy w wersji 3</a>.
703) Poza tym, obsługa żądań lub choćby dostarczania usług ukrytych Tora byłaby fajna,

704) choć nie wymagana.<br />3
705)  Student powinien rozumieć i pisać nowy kod w Javie, łącznie

706) z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C
707) też byłaby przydatna. Student powinien być chętny do czytania istniejącej dokumentacji,
708) implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać
709) dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z
710) pisania kodu i w mniejszym - z projektowania.
711) </li>
712) 
713) <li>

714) <b>Automatyczne testy systemu i automatyczne uruchamianie prywatnych sieci Tora</b>

715) <br />
716) Priorytet: <i>Średni</i>
717) <br />
718) Poziom wysiłku: <i>Średni</i>
719) <br />
720) Poziom umiejętności: <i>Średni</i>
721) <br />

722) Prawdopodobni prowadzący: <i>Karsten, Nick, Roger</i>

723) <br />

724) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>2</i>
725) <br />

726) Napisz narzędzie, które uruchamia automatyczne testy systemu, poza
727) istniejącymi testami jednostkowymi. Oparty na Javie symulator Tora - <a
728) href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
729) może służyć za dobry początek do uruchomienia prywatnej sieci Tora,
730) używaniu jej przez jakiś czas i sprawdzeniu, czy choć części jej działają.
731) Projekt ten wymaga przygotowania planu przeprowadzenia testów systemu
732) prywatnych sieci Tora przed zaczęciem pisania kodu. Typowe typy testów
733) obejmują zakres od wykonywania pojedynczych żądań w prywatnej sieci
734) do manipulowania wymienianymi wiadomościami i sprawdzaniu, czy węzły

735) prawidłowo reagują na uszkodzone wiadomości.<br />
736)  Student powinien móc

737) zdobyć dobrą wiedzę na temat działania Tora i tego, jakie problemy i
738) błędy mogą wyjść na jaw, by zaprojektować dobre przypadki testowe.
739) Niezbędne jest zrozumienie istniejącego kodu i dokumentacji Tora.
740) Jeśli używany będzie PuppeTor, student powinien też móc zrozumieć
741) i być może rozszerzyć istniejącą aplikację w Javie. Ten projekt to
742) po części projektowanie, a po części - pisanie kodu.
743) </li>
744) 
745) <li>
746) <b>Ożywienie projektu moniTor</b>
747) <br />
748) Priorytet: <i>Średni</i>
749) <br />
750) Poziom wysiłku: <i>Średni</i>
751) <br />
752) Poziom umiejętności: <i>Niski do Średniego</i>
753) <br />

754) Prawdopodobni prowadzący: <i>Karsten, Jacob</i>

755) <br />

756) Zgłoszenia do 1 Kwietnia 00:00 UTC: <i>2</i>

757) <br />

758) Zaimplementuj narzędzie <a href="http://www.ss64.com/bash/top.html">podobne do top</a>
759) dla przekaźników siei Tora. Celem takiego narzędzia byłoby monitorowanie lokalnego przekaźnika

760) sieci poprzez jego port kontrolny i dołączanie użytecznych informacji systemowych

761) samej maszyny. Podczas działania, narzędzie to dynamicznie aktualizowałoby
762) swoje informacje, tak jak program top robi to dla procesów linuksowych.
763) <a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ta

764) wiadomość na or-dev</a> może być dobrą lekturą na początek.<br />
765)  Student powinien znać lub

766) być chętnym do nauki administrowania przekaźnikiem Tora i konfigurowania go
767) za pomocą portu kontroli. Jako że wstępny prototyp jest napisany w Pythonie,
768) pewna wiedza na temat pisania programów w tym języku też byłaby przydatna.
769) Ten projekt z jednej strony opiera się na określeniu wymagań dla takiego
770) narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony
771) wymaga również dużo programowania.
772) </li>
773) 
774) 
775) <li>
776) <b>Ulepszenia w Torbutton</b>
777) <br />
778) Priorytet: <i>Średni</i>
779) <br />
780) Poziom wysiłku: <i>Wysoki</i>
781) <br />
782) Poziom umiejętności: <i>Wysoki</i>
783) <br />

784) Prawdopodobni prowadzący: <i>Mike</i>

785) <br/>
786) Jest parę ulepszeń, które można byłoby wprowadzić do Torbutton w wersji po 1.2.
787) Większość z nich jest pisana jako prośby o ulepszenia w <a
788) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5">sekcji
789) flyspray Torbuttona</a>. Dobrymi przykładami są: wycinanie node.exit z nagłówków

790) HTTP, lepsza kontrola blokowania wypełniania formularzy, ulepszone imitowanie

791) odnośników do stron poprzednich (tzw. referrers) w oparciu o domenę strony

792) (coś jak <a href="https://addons.mozilla.org/en-US/firefox/addon/953"
793) >rozszerzenie refcontrol</a>), bliższa integracja z Vidalią do zgłaszania

794) stanu Tora, przycisk Nowa Tożsamość z integracją z Torem i zarządzanie

795) wieloma tożsamościami, i cokolwiek jeszcze, co zdołasz wymyślić.

796) <br />

797) To zadanie składałoby się z niezależnego pisania w JavaScripcie i miłym

798) świecie <a
799) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
800) bez zbytniego zagłębiania się do wnętrzności Tora.
801) 
802) </li>
803) 
804) <li>
805) <b>Przeniesienie Polipo na Windows</b>
806) <br />

807) Priorytet: <i>Średni</i>

808) <br />

809) Poziom wysiłku: <i>Średni</i>

810) <br />
811) Poziom umiejętności: <i>Średni do Wysokiego</i>
812) <br />

813) Prawdopodobni prowadzący: <i>Andrew, Steven, Roger</i>

814) <br />
815) Pomóż przenieść <a
816) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na Windows.
817) 1) obsługa spacji w ścieżkach i zrozumienie przestrzeni nazw systemu plików
818) &mdash; przestrzeń nazw tu oznacza gdzie dane aplikacji, dane osobiste i
819) program zwykle się znajdują w różnych wersjach Windows. 2) zdolność obsługi
820) połączeń przez IPv6. 3) zdolność do asynchronicznego wysyłania zapytań do
821) serwerów nazw. 4) używanie natywnych zdolności Windows odnośnie wyrażeń regularnych
822) zamiast używania bibliotek GNU. 5) natywna obsługa zdarzeń i buforów (tj. w
823) systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows
824) jest to cokolwiek wpisane w plik konfiguracyjny). 6) jakieś narzędzie z
825) graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli
826) ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy.
827) Podwójny bonus, jeśli działa na wielu platformach.
828) </li>
829) 
830) <li>
831) <b>Zrobienie naszych diagramów pięknymi i zautomatyzowanymi</b>
832) <br />

833) Priorytet: <i>Średni</i>

834) <br />
835) Poziom wysiłku: <i>Niski</i>
836) <br />
837) Poziom umiejętności: <i>Niski</i>
838) <br />

839) Prawdopodobni prowadzący: <i>Andrew</i>

840) <br />

841) Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład, obrazków
842) "Jak działa Tor" na <a href="<page overview>">stronie wprowadzenia</a>
843) ze źródeł, byśmy mogli je tłumaczyć
844) jako tekst w UTF-8 zamiast edytować je ręcznie za pomocą GIMPa.

845) Należy zintegrować to z plikiem WML, by tłumaczenie było proste, a obrazki

846) generowane w wielu językach w czasie publikacji strony. Przeczytaj punkt
847) "Wiki do tłumaczenia" powyżej.

848) </li>
849) 
850) <li>
851) <b>Ulepszenie oferty LiveCD dla społeczeństwa Tora</b>
852) <br />
853) Priorytet: <i>Niski</i>
854) <br />
855) Poziom wysiłku: <i>Niski</i>
856) <br />
857) Poziom umiejętności: <i>Średni do Wysokiego</i>
858) <br />

859) Prawdopodobni prowadzący: <i>Anonym, Jacob, Roger</i>

860) <br />
861) <li>Jak można uczynić <a
862) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
863) łatwiejszym w utrzymaniu, ulepszaniu i dokumentowaniu?</li>
864) 

865) <li>
866) <b>Zmiana i rozszerzenie Blossom</b>
867) <br />
868) Priorytet: <i>Średni</i>
869) <br />
870) Poziom wysiłku: <i>Średni do Wysokiego</i>
871) <br />
872) Poziom umiejętności: <i>Średni do Wysokiego</i>
873) <br />
874) Prawdopodobni prowadzący: <i>Goodell</i>
875) <br />
876) Należy zmienić i rozszerzyć Blossom (narzędzie do monitorowania i wybierania
877) właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane

878) przez użytkownika) do zbierania danych własnym sposobem, z łatwymi do zmiany

879) przez użytkownika parametrami. Blossom jest aktualnie zaimplementowany
880) jako pojedynczy skrypt Pythona, który łączy się z Torem używając interfejsu
881) Kontrolera i opiera się na danych zbieranych o węzłach Tora przez zewnętrzne
882) procesy takiej jak strona www pokazująca status węzłów wraz z publicznymi
883) danymi z DNSów, whois itp. Ten projekt ma 2 części: (1) Określenie, jakie jeszcze
884) dane mogą być potrzebne i przerobić Blossom tak, by sam zbierał dane zamiast polegać
885) na zewnętrznych skryptach (to może, oczywiście, wprowadzić dodatkowe wątki i
886) komunikację międzyprocesową) i (2) stworzenie metody łatwej konfiguracji Blossom
887) przez użytkownika, zaczynając od pliku konfiguracyjnego i być może kończąc na
888) konfiguracji przez przeglądarkę. Ważna jest znajomość Tora i Pythona; znajomość
889) TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie
890) neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie
891) niespójności Internetu są podstawą projektu Blossom.
892) </li>
893) 
894) <li>
895) <b>Ulepszenie Blossom: pozwolenie użytkownikom na jakościowy opis węzłów wyjściowych,
896) z których chcą korzystać</b>
897) <br />
898) Priorytet: <i>Niski</i>
899) <br />
900) Poziom wysiłku: <i>Średni</i>
901) <br />
902) Poziom umiejętności: <i>Średni</i>
903) <br />
904) Prawdopodobni prowadzący: <i>Goodell</i>
905) <br />
906) Należy zaprojektować i zaimplementować możliwość dania użytkownikom programu Blossom
907) opisania węzła wyjściowego, z którego chcą korzystać. Internet jest niespójnym
908) miejscem: niektóre węzły wyjściowe Tora widzą świat inaczej niż inne. W bieżącej
909) implementacji Blossom (narzędzie do monitorowania i wybierania
910) właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane
911) przez użytkownika) nie ma dość bogatego języka, by opisać, jak bardzo różne
912) są różne punkty widzenia. Na przykład, niektóre węzły wyjściowe mogą być w
913) sieciach filtrujących pewne rodzaje ruchu lub strony. Inne węzły mogą dawać dostęp

914) do specjalnej zawartości w związku ze swoją lokalizacją, być może jako rezultat

915) dyskryminacji ze strony samych dostawców treści. Ten projekt składa się z 2 części:
916) (1) stworzenie języka do opisywania charakterystyk sieci, w której znajdują się
917) węzły, oraz (2) wprowadzenie tego języka do Blossom, by użytkownicy mogli
918) wybierać ścieżki Tora w oparciu o ten opis.
919) Ważna jest znajomość Tora i Pythona; znajomość
920) TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie
921) neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie
922) niespójności Internetu są podstawą projektu Blossom.
923)   	 </li>

924) 
925) <li>
926) <b>Przynieś nowe pomysły!</b>
927) <br />
928) <li>Nie podoba ci się żaden z tych pomysłów? Spójrz na <a
929)  href="<svnsandbox>doc/design-paper/roadmap-future.pdf">plan rozwoju Tora</a> po więcej pomysłów.</li>
930) <li>Nie widzisz tu swojego pomysłu? Prawdopodobnie i tak go potrzebujemy! Skontaktuj się
931)  z nami, by to sprawdzić.</li>
932) </ol>
933) 

934) <h2><a class="anchor" href="#Coding">Programowanie i Projektowanie</a></h2>

935) 

936) <ol>

937) 

938) <li>Przekaźniki sieci Tora nie działają zbyt dobrze na Windows XP. Pod systemem Windows Tor

939)  używa standardowej funkcji systemowej <tt>select()</tt>, która zużywa miejsce

940)  w niestronicowanym obszarze pamięci. Znaczy to, że średnich rozmiarów

941)  przekaźnik sieci Tora zapełni dostępną przestrzeń, <a

942)  href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">będąc

943)  przyczyną dziwnych zachowań i padów systemu</a>. Powinniśmy raczej używać
944)  nakładającego IO. Jednym z rozwiązań byłoby nauczenie biblioteki <a
945)  href="http://www.monkey.org/~provos/libevent/">libevent</a>, jak używać nakładającego IO

946)  zamiast select() pod Windows, po czym zaadaptować Tora do nowego interfejsu.
947)  Christian King zrobił
948)  <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">pierwszy dobry

949)  krok</a> lata roku 2007.</li>

950) 

951) <li>Ponieważ przekaźniki sieci Tora muszą przechować i podać dalej każdą komórkę,
952)  którą obsługują, przekaźniki o wysokiej przepustowości zużywają wiele

953)  megabajtów pamięci na same bufory. Potrzebujemy lepszej heurystyki do
954)  określenia, kiedy skurczyć/rozszerzyć bufory. Może to powinno być zaprojektowane
955)  podobnie jak bufory w jądrze Linuksa, gdzie jest wiele mniejszych buforów, które
956)  łączą się wzajemnie, zamiast używać monolitycznych buforów?</li>
957) 
958) <li>Potrzebujemy oficjalnej, centralnej strony, która odpowiadałaby na pytania

959)  "Czy to jest adres przekaźnika wyjściowego z sieci Tor?". Strona powinna dostarczyć klika

960)  interfejsów, łącznie z interfejsem www i w stylu DNSBL. Powinna dostarczać najbardziej
961)  aktualne odpowiedzi, przechowując lokalną kopię katalogów. Haczyk jest w tym, że

962)  bycie przekaźnikiem wyjściowym nie jest takie proste jak tylko prawda czy fałsz,
963)  więc pytanie powinno raczej
964)  brzmieć: "Czy to jest adres przekaźnika wyjściowego z sieci Tor, z którego można się

965)  połączyć z moim adresem IP i portem?". Interfejs DNSBL będzie pewnie otrzymywał
966)  setki zapytań na minutę, potrzeba więc mądrych algorytmów. Dodatkowe punkty, jeśli
967)  aktywnie byłoby sprawdzane każdego węzła wyjściowego, z jakiego adresu IP naprawdę

968)  wychodzą dane. <a href="<svnsandbox>doc/contrib/torel-design.txt">Czytaj więcej tu</a>.</li>

969) 

970) <li>Czasami przekaźniki sieci Tora padają, komputery z tymi serwerami zostają odłączone od sieci

971)  lub zdarzają się inne wypadki. Część operatorów Tora wyraziła zainteresowanie zapisaniem

972)  się do usługi "powiadamiającej", która okresowo sprawdzałaby, czy ich przekaźnik działa, i

973)  wysyłała list przypominający, gdy serwer nie działa. Czy ktoś chce napisać kilka skryptów
974)  CGI, kilka stron internetowych i używać jakiegoś sposobu z Wget lub czegoś bardziej
975)  złożonego jak <a href="http://nagios.org/">Nagios</a> do monitorowania? Pierwsza wersja
976)  mogłaby po prostu sprawdzać port w katalogu, np. przeglądając zapisaną stronę ze
977)  stanem sieci w poszukiwaniu właściwego adresu IP i portu, po czym żądając strony
978)  "/tor/server/authority".</li>
979) 

980) <li>Byłoby wspaniale mieć LiveCD zawierające najnowsze wersje Tor, Polipo lub Privoxy,

981)  Firefox, Gaim+OTR itp. Są tu dwa wyzwania: pierwszym jest udokumentowanie systemu i
982)  możliwości wyboru dość dobrze, by ludzie zajmujący się bezpieczeństwem mogli wydać opinię
983)  o tym, czy taki system byłby bezpieczny, a drugim wyzwaniem jest jak sprawić, by taki
984)  system był łatwy w utrzymaniu, żeby nie ulegał szybkim przedawnieniom, jak AnonymOS.
985)  Dodatkowe punkty, jeśli obraz CD zmieści się na małej płycie.</li>
986) 
987) <li>W połączeniu z obrazem LiveCD, powinniśmy popracować nad intuicyjnie bezpiecznym

988)  i dobrze udokumentowanym obrazem USB dla Tora i aplikacji obsługujących. Ciężką

989)  częścią tutaj jest zdecydowanie, jakie konfiguracje są bezpieczne, dokumentowanie
990)  tych decyzji i zrobienie czegoś, co łatwo będzie utrzymać w przyszłości.</li>
991) 
992) <li>Musimy zacząć budować nasz <a href="<page
993)  documentation>#DesignDoc">projekt odporny na blokowanie</a>. Wchodzi w to

994)  przemyślenie projektu, zmiana wielu różnych elementów Tora, zaadaptowanie

995)  <a href="http://vidalia-project.net/">Vidalii</a>, by obsługiwała nowe cechy i
996)  planowanie rozpowszechniania.</li>
997) 

998) <li>Potrzebujemy elastycznego frameworka symulacji do badania ataków potwierdzenia

999)  ruchu od nadawcy do odbiorcy (end-to-end). Wielu ludzi szybko wyciągnęło/napisało doraźne
1000)  symulatory odpowiadające ich intuicji, że albo ataki znakomicie się udają, albo
1001)  że obrona działa dobrze. Czy możemy zbudować symulator, który jest dobrze udokumentowany
1002)  i dość otwarty, by wszyscy wiedzieli, że daje rozsądną odpowiedź? To zacznie wiele nowych
1003)  badań. Spójrz na wpis <a href="#Research">poniżej</a> o atakach potwierdzenia po szczegóły
1004)  strony badawczej tego zadania &mdash; kto wie, może gdy będzie skończone, pomożesz nam też
1005)  napisać dokumentację.</li>
1006) 

1007) <li>Tor 0.1.1.x i późniejsze zawiera obsługę sprzętowych akceleratorów kryptograficznych,

1008)  poprzez OpenSSL. Ale nikt tego jeszcze nie przetestował. Czy ktoś chce
1009)  zdobyć kartę i powiadomić nas, jak to działa?</li>

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

1011)  href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Sprawdzić, czy
1012)  istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
1013)  gdy wydamy nową wersję dzięki Tobie!</li>
1014) <li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
1015)  ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
1016)  opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
1017)  obsługiwać możemy tylko strumienie TCP. Mamy <a

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

1019)  powodów, dla których nie przenieśliśmy się na UDP</a>, ale byłoby dobrze
1020)  skrócić tę listę. Mamy też proponowaną <a

1021)  href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specyfikację dla Tora i

1022)  UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>
1023) <li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
1024)  wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
1025)  startu.</li>
1026) </ol>
1027) 
1028) <a id="Research"></a>
1029) <h2><a class="anchor" href="#Research">Badania</a></h2>
1030) <ol>
1031) <li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
1032)  popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"

1033)  dla każdej z nich. Potem obserwuj ruch sieciowy klienta Tora. Jak

1034)  patrzysz na odbierane przez niego dane, szybko zgadujesz, którą
1035)  (jeśli w ogóle) on odbiera. Po pierwsze, jak bardzo ten atak jest
1036)  efektywny? Potem zacznij badać sposoby obrony: na przykład, moglibyśmy

1037)  zmienić rozmiar komórki Tora z 512 na 1024 bajty, moglibyśmy użyć

1038)  technik dopełniających, jak <a
1039)  href="http://freehaven.net/anonbib/#timing-fc2004">odrzucanie obronne (defensive dropping)</a>,
1040)  lub moglibyśmy dodać opóźnienia w ruchu. Jak wielki wpływ mają te
1041)  rozwiązania i jak wielki wpływ na używalność (używając odpowiedniego
1042)  sposobu mierzenia) ma udana obrona w każdym z przypadków?
1043) </li>
1044) <li>"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack):
1045)  obserwując ruch od Alicji do Boba, możemy <a
1046)  href="http://freehaven.net/anonbib/#danezis:pet2004">porównać
1047)  sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych</a>.

1048)  Jak na razie, Tor przyjmuje to jako pewnik i zakłada, że ten atak jest

1049)  trywialny we wszystkich przypadkach. Po pierwsze, czy tak rzeczywiście jest?
1050)  Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne, by przeciwnik

1051)  upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie wysyłanie wiele danych),
1052)  które spowolniłyby atak? Czy jakieś dopełnienia transmisji lub inne sposoby

1053)  kształtowania działają lepiej od innych?
1054)  </li>

1055) 
1056) <li>Powiązane pytanie brzmi: Czy prowadzenie przekaźnika/mostka daje dodatkową
1057) ochronę przed atakami opartymi na czasie? Czy ktoś z zewnątrz, kto nie może
1058) przeczytać linków zaszyfrowanych przez TLS, dalej jest w stanie prawidłowo rozpoznać
1059) poszczególne strumienie danych? Czy ilość ruchu jakoś zmniejsza tę możliwość?

1060) A co, jeśli klient-przekaźnik celowo opóźnia wychodzący ruch, by stworzyć kolejkę,

1061) która mogłaby być używana do udawania czasów pobierania danych przez klienta tak,
1062) by wyglądało, że ten ruch też jest przekierowany? Ta sama kolejka mogłaby być używana do
1063) maskowania czasów w ruchu wychodzącym, korzystając z technik <a
1064) href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptacyjnego dopełniania</a>,
1065) ale bez potrzeby dodatkowego ruchu (wysyłania dodatkowych danych). Czy takie
1066) przeplatanie prawdziwych danych popsułoby mierzenie czasów u atakujących? Czy strategie
1067) te musiałyby by zmienione dla asymetrycznych łączy? Na przykład, czy jest możliwe
1068) na łączu asymetrycznym odróżnienie ruchu klienta od naturalnego wzmożenia ruchu ze

1069) względu na ich asymetryczną pojemność? Czy jest to jednak łatwiejsze niż dla łączy

1070) symetrycznych z innych przyczyn?</li>
1071) 

1072) <li>Powtórzcie <a
1073) href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">atak z
1074) Oakland 05</a> Murdocha i Danezisa na bieżącej sieci Tora. Sprawdźcie, czy możecie
1075) dowiedzieć się, czemu działa on dobrze na niektórych węzłach, a gorzej na innych.
1076) (Moja teoria mówi, że szybkie węzły mające trochę wolnego pasma lepiej opierają się
1077) atakowi.) Jeśli to prawda, poeksperymentujcie z opcjami RelayBandwidthRate i
1078) RelayBandwidthBurst prowadząc węzeł używany jako klient do przekierowywania
1079) ruchu atakującego: jeśli zmniejszamy RelayBandwidthRate, czy atak jest trudniejszy?
1080) Jaki jest najwłaściwszy stosunek RelayBandwidthRate do rzeczywistej szybkości
1081) łącza? Czy to w ogóle jest jakiś stosunek? Skoro już przy tym jesteśmy, czy znacznie
1082) większy zbiór węzłów kandydujących zwiększa odsetek fałszywych wyników pozytywnych
1083) lub innych trudności dla tego rodzaju ataku? (Sieć Tora jest teraz większa o prawie
1084) dwa rzędy wielkości niż wtedy, gdy napisano ten dokument.) Przeczytaj też
1085) <a href="http://freehaven.net/anonbib/#clog-the-queue">Nie zapychaj kolejki</a>.</li>
1086) 

1087) <li>"Atak stref trasowania" (routing zones attack): większość literatury
1088)  mówi o ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między
1089)  węzłem wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie.

1090)  W rzeczywistości, ścieżka przemierza wiele systemów autonomicznych (SA), i <a

1091)  href="http://freehaven.net/anonbib/#feamster:wpes2004">często zdarza się, że
1092)  ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej</a>.
1093)  Niestety, by dokładnie przewidzieć, czy podany czworobok
1094)  Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć
1095)  całą strefę trasowania internetu i dokonać na niej czasochłonnych operacji.
1096)  Czy są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej
1097)  samej sieci /8?
1098)  </li>

1099) <li>Inne pytania badawcze dotyczące różnorodności geograficznej rozpatrują
1100)  kompromis między wybieraniem obwodu wydajnego a losowego. Spójrz na <a
1101)  href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">dokument o
1102)  pozycjach</a> Stephena Rollysona na temat tego, jak odrzucać szczególnie wolne
1103)  możliwości bez zbytniej utraty anonimowości. Ta argumentacja wymaga więcej pracy i
1104)  myślenia, ale wygląda bardzo obiecująco.</li>
1105) 

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

1107)  (np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
1108)  każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
1109)  są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji
1110)  z powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
1111)  wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące,
1112)  by sam tym regulować? Można sobie wyobrazić schemat działania, w którym
1113)  najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
1114)  chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie się.
1115)  Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
1116)  zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
1117)  użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.
1118)  </li>
1119) <li>Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt
1120)  okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
1121)  poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
1122)  To zdawało się działać nieźle w <a
1123)  href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">eksperymencie
1124)  przepustowości SSH</a>. Będziemy musieli mierzyć i podkręcać, i być może
1125)  wykonać poprawki, jeśli wyniki okażą się dobre.
1126)  </li>

1127) <li>Aby umożliwić dysydentom w innych krajach używanie Tora bez bycia

1128)  zablokowanym przez zaporę ogniową w ich kraju, potrzebujemy sposobu na
1129)  zdobycie dziesiątek tysięcy serwerów pośredniczących, nie zaledwie kilkuset.

1130)  Wyobrażamy sobie GUI klienta Tora, które na górze ma przycisk "Tor dla wolności",

1131)  który otwiera port i przekierowuje kilka kB/s ruchu do sieci Tor. (Kilka kB/s
1132)  nie powinno być dużym kłopotem i nie będzie wiele spraw o nadużycia, gdyż
1133)  nie będą to węzły wyjściowe.) Ale jak rozpowszechniać listę tych
1134)  klientów-wolontariuszy do dobrych dysydentów automatycznie w taki sposób, który
1135)  nie pozwoli krajowym zaporom ogniowym przechwycić i zliczyć ich? To prawdopodobnie

1136)  musi działać poziomie zaufania ludzkiego. Spójrz na nasz
1137)  <a href="<page documentation>#DesignDoc">wstępny dokument o
1138)  ochronie przed blokowaniem</a> i na nasz <a

1139)  href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">wpis w FAQ</a>

1140)  o tym, a potem przeczytaj <a
1141)  href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sekcję w anonbib o
1142)  przeciwstawianiu się cenzurze</a>.</li>

1143) 
1144) <li>Nasze cele w opieraniu się cenzurze to m.in. zapobieganie temu, by napastnik
1145) podglądający ruch Tora mógł <a
1146) href="https://www.torproject.org/svn/trunk/doc/design-paper/blocking.html#sec:network-fingerprint"
1147) >odróżnić go od normalnego ruchu SSL</a>. Oczywiście, nie możemy osiągnąć idealnej
1148) steganografii i dalej mieć użyteczną i działającą sieć, ale w pierwszym kroku
1149) chcielibyśmy blokować jakiekolwiek ataki, które mogą się udać po obserwacji tylko
1150) kilku pakietów. Jednym z pozostałych ataków, którego nie zbadaliśmy za bardzo,
1151) polega na tym, że komórki Tora mają 512 bajtów, więc ruch w sieci może mieć długość
1152) będącą wielokrotnością 512 bajtów. Jak bardzo wkładanie nowych danych
1153) w nagłówkach TLS rozmywa ten fakt w transmisji? Czy inne strategie opróżniania bufora
1154) w Torze mają na to wpływ? Czy trochę dokładania może bardzo pomóc, czy jest o atak,
1155) z którym musimy żyć?</li>
1156) 

1157) <li>Obwody Tora są budowane po jednym elemencie na raz, więc teoretycznie

1158)  możemy uczynić, aby część strumieni wychodziła z drugiego węzła, część z

1159)  trzeciego itd. To wydaje się dobre, bo ogranicza zbiór strumieni wychodzących,

1160)  które dany przekaźnik sieci może zobaczyć. Ale jeśli chcemy by każdy strumień był

1161)  bezpieczny, "najkrótsza" ścieżka powinna, według naszego bieżącego rozumowania,

1162)  składać się z co najmniej 3 elementów, więc inne będą jeszcze dłuższe.

1163)  Musimy zbadać ten kompromis wydajność/bezpieczeństwo.
1164)  </li>

1165) <li>Nie jest trudno wykonać atak DoS na przekaźniki sieci Tora lub centra katalogowe.

1166)  Zagadki dla klientów (?) (client puzzles) są właściwą odpowiedzią? Jakie są

1167)  inne praktyczne podejścia? Dodatkowe punkty, jeśli są zgodne wstecz z

1168)  bieżącym protokołem Tora.</li>

1169) <li>Programy takie jak <a href="https://torbutton.torproject.org/dev/">Torbutton</a>
1170)  mają na celu ukrycie pola UserAgent przeglądarki, zastępując je jednakową odpowiedzią
1171)  dla każdego użytkownika Tora. W ten sposób napastnik nie może złamać anonimowości
1172)  Tora, patrząc na ten nagłówek. Aby się nie wyróżniać, program próbuje wybrać nazwy
1173)  przeglądarek często używanych także przez tych, którzy nie używają Tora.
1174)  Pytanie numer jeden: jak bardzo szkodzimy sami sobie, okresowo zwiększając
1175)  wersję Firefoksa, za którego podaje się Torbutton? Jeśli aktualizujemy zbyt często,
1176)  sami łamiemy swoją anonimowość. Jeśli za rzadko, to wszyscy użytkownicy Tora się
1177)  wyróżniają ze względu na to, że twierdzą, iż używają starych wersji Firefoksa.
1178)  Tutaj odpowiedź zależy pewnie na tym, które wersje Firefoksa są spotykane.
1179)  Pytanie numer dwa: raz na jakiś czas ludzie pytają nas, byśmy krążyli po N
1180)  nazwach UserAgent, zamiast trzymać się jednej. Czy to podejście pomaga, przeszkadza,
1181)  czy nic nie wnosi? Weź pod uwagę: ciaseczka i rozpoznawanie użytkowników Tora poprzez
1182)  ich zmieniające się nagłówki UserAgent, złe strony atakujące tylko określone
1183)  przeglądarki; oraz to, czy odpowiedź na pytanie 1 wpływa na tę odpowiedź.
1184) </li>

1185) </ol>
1186) 

1187) <p>

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

1189) </p>