tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 18861

3) # Translation-Priority: 4-optional

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

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

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

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

12) <ol>

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

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

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

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

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

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

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

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

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

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

37) <li>Musimy <a

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

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

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

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

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

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

47) </ul>
48) </li>

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

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

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

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

56)  </li>

57) <li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z

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

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

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

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

70) <li>Przejrzyj i udokumentuj

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

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

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

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

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

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

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

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

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

87) </ol>
88) 
89) <a id="Coding"></a>

90) <a id="Summer"></a>
91) <a id="Projects"></a>
92) <h2><a class="anchor" href="#Projects">Dobre Projekty Programistyczne</a></h2>

93) 
94) <p>

95) Oto lista pomysłów zaproponowanych na <a
96) href="<page gsoc>">Google Summer of Code 2009</a>.

97) Części <a href="<svnsandbox>doc/spec/proposals/">bieżących propozycji</a>
98) może też brakować deweloperów. Jeśli Twoim zdaniem możesz nam pomóc,
99) <a href="<page contact>">daj nam znać!</a>

100) </p>
101) 
102) 

103) <ol>
104) 

105) <!-- Mike is already working on this.

106) <li>

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

108) <br />

109) Podobnie do skanera wyjściowego SoaT (lub może nawet w czasie jego działania),

110) można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które
111) źle działają dla pewnej części swoich obwodów nie powinny być używane do
112) statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną
113) przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo,
114) węzły wykazujące bardzo niską średnią przepustowość strumienia,
115) lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne.
116) Większość zbierania statystyk już jest zrobiona, dane te muszą tylko
117) zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym,
118) by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci
119) się o tym dowiedzą.

120) <br />

121) Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego
122) przez węzeł. Do <a

123) href="https://svn.torproject.org/svn/torctl/trunk/doc/howto.txt">Protokołu Kontroli

124) Tora</a> można dodać zdarzenia mówiące, czy udaje się stworzyć obwód
125) przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące
126) zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty
127) na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też
128) informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych,
129) ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby
130) zostać stworzony.
131) </li>

132) -->

133) 
134) <li>
135) <b>Pomóż śledzić ogólny status Sieci Tora</b>

136) <br />

137) Byłoby wspaniale uruchomić automatyczny system śledzenia stanu sieci w czasie,
138) wyświetlanie wykresów itp. Częścią tego projektu byłoby wynalezienie lepszych
139) miary do oceny stanu i wzrostu sieci. Czy wzrasta średni czas działania sieci?
140) Ile węzłów kwalifikuje się do bycia Strażnikami w tym miesiącu w porównaniu z
141) ubiegłym? Jaka jest rotacja w sensie pojawiania się nowych węzłów i znikania
142) starych? Okresowo ludzie gromadzą krótkie migawki stanu, ale to robi się naprawdę
143) interesujące dopiero, gdy zaczynamy śledzić te dane w czasie.
144) <br />

145) Dane mogłyby być zbierane ze Skanerów Węzłów Tora w <a
146) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, z

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

155) <!-- Is this still a useful project? If so, move it to another section.

156) <li>

157) <b>Lepsze wsparcie i pakowanie dla Debiana/Ubuntu</b>

158) <br />
159) Vidalia obecnie nie współpracuje dobrze na Debianie i Ubuntu z domyślnymi
160) paczkami Tora. Bieżące paczki Tora automatycznie uruchamiają Tora jako demona
161) systemowego z konta użytkownika debian-tor i (rozsądnie) nie mają zdefiniowanego
162) ControlPort w domyślnym torrc. Stąd Vidalia będzie próbować uruchomić własny
163) proces Tora, bo nie może połączyć się z istniejącym, po czym proces Tora
164) uruchomiony przez Vidalię zamknie się z błędem, którego użytkownik raczej nie zrozumie,
165) jako że Tor nie będzie mógł podpiąć się pod swoje porty nasłuchowe, które są
166) już zajęte przez pierwszy proces Tora.
167) <br />
168) Bieżące rozwiązanie to albo mówienie użytkownikowi, by zatrzymał istniejący
169) proces Tora i pozwolił Vidalii uruchomić własny, albo tłumaczenie, jak ustawić
170) port kontrolny i hasło w pliku torrc. Lepszym rozwiązaniem na Debianie byłoby używanie
171) ControlSocket Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez
172) gniazdo w domenie Unix i mógłby być domyślnie włączony w paczkach Tora dla Debiana.
173) Vidalia może wtedy uwierzytelnić się do Tora używając ciasteczek, jeśli użytkownik
174) uruchamiający Vidalię jest w grupie debian-tor.
175) <br />
176) Pierwsza część tego projektu będzie polegała na dodaniu obsługi ControlSocket
177) do Vidalii. Potem student stworzy i przetestuje paczki Vidalii na Debianie i
178) Ubuntu, które będą zgodne ze standardami pakowania w Debianie, oraz upewni się,

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

180) apt zawierające nowe paczki Vidalia.
181) <br />

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

192) Osoba podejmująca się tego projektu powinna znać system pakowania Debiana i

193) mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przydatne,
194) ale nie jest wymagane.
195) </li>

196) -->

197) 

198) <li>
199) <b>Polepszanie naszych zdolności opierania się cenzurze</b>
200) <br />
201) Wersje 0.2.0.x Tora robią <a
202) href="<svnsandbox>doc/design-paper/blocking.html">znaczne postępy</a> w opieraniu
203) się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w
204) niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą
205) nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje
206) <a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">propozycja
207) zajęcia się tą sprawą</a> i umożliwienia klientom łączenie się z danym Torem
208) na wielu adresach i portach, ale wymaga to więcej pracy. Kolejny projekt
209) przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie.
210) W chwili obecnej ktokolwiek może zidentyfikować
211) <a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">mostki Tora</a>
212) po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając,
213) czy odpowiadają. By rozwiązać ten problem, mostki mogłyby
214) <a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">udawać serwery
215) internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów,
216) a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny
217) dla mostka.
218) <br />
219) Ten projekt zawiera wiele badań i projektowania. Jednym z większych wyzwać
220) będzie zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą
221) się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie
222) odporności na cenzurę z użytecznością i siłą.
223) </li>
224) 

225) <!-- This should be mostly done.

226) <li>
227) <b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>
228) <br />
229) Potrzebujemy dobrego frameworka automatycznej aktualizacji.
230) Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub
231) niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe
232) okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.
233) Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i
234) zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,
235) chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy
236) Vidalia.
237) <br />
238) By wykonać ten projekt, student będzie musiał najpierw poznać istniejące
239) mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,
240) cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże
241) się przydatny, student zaprojektuje własny framework aktualizacyjny,
242) udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat
243) jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)
244) i przetestuje.
245) <br />

246) Osoba podejmująca się tego projektu powinna dobrze znać C++.

247) Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.

248) Powinno się mieć też podstawowe pojęcie o powszechnych praktykach

249) bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w
250) pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie

251) zrobienie dokumentacji projektu do przejrzenia i przedyskutowania
252) z innymi ludźmi przed implementacją.

253) </li>

254) -->

255) 

256) <!-- Matt already made good progress on this.

257) <li>

258) <b>Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia</b>

259) <br />
260) Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi
261) przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje
262) ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.
263) Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.
264) Wolelibyśmy użyć widgetu Marble z KDE, który daje mapę lepszej jakości i
265) umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na
266) klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe
267) informacje. Moglibyśmy też rozważyć dodanie możliwości klikania przez
268) użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
269) stwierdzenia "chcę, by moje połączenia do foo.com wychodziły stąd."
270) <br />

271) Podczas tego projektu, osoba najpierw zapozna się z Vidalią i API widgetu

272) Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował
273) do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we
274) własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.
275) <br />

276) Osoba podejmująca się tego projektu powinna dobrze znać C++.

277) Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
278) </li>

279) -->

280) 

281) <li>

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

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

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

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

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

301) Podwójne kliknięcie tej ikonki pokazywałoby okienko dialogowe podsumowujące
302) ostatnie zmiany stanu prostymi słowami i może sugerujące rozwiązania
303) do negatywnych wiadomości, jeśli mogą one być naprawione przez użytkownika.

304) Oczywiście to tylko przykład i można zaproponować inne podejście.

305) <br />

306) Osoba podejmująca się tego projektu powinna dobrze znać projektowanie i

307) tworzenie interfejsu użytkownika i mieć trochę doświadczenia z C++.
308) Uprzednie doświadczenie z Qt i Qt Designer będzie przydatne, ale nie jest wymagane.
309) Przydatne mogą być też pewne umiejętności w pisaniu po angielsku, gdyż

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

311) pomocniczej, która powinna być zrozumiała dla nie-technicznych użytkowników.
312) Dodatkowe punkty za jakiś projekt graficzny /Photoshop fu, gdyż moglibyśmy
313) chcieć/potrzebować nowych ikonek.
314) </li>
315) 

316) <!-- Jake already did most of this.

317) <li>
318) <b>Ulepszenia naszego aktywnego testera konfiguracji przeglądarek</b> -
319) <a href="https://check.torproject.org">https://check.torproject.org</a>
320) <br />
321) Mamy w tej chwili funkcjonalną stronę www, która sprawdza, czy Tor działa.
322) Ma jednak parę miejsc, w których działa źle. Wymaga ulepszeń dotyczących
323) domyślnych języków i funkcjonalności. W chwili obecnej odpowiada tylko po angielsku.
324) Ponadto, jest to kawał skryptu Perla, który nigdy nie powinien był ujrzeć światła
325) dziennego. Strona powinna prawdopodobnie zostać przepisana w Pythonie

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

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

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

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

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

338) </li>

339) -->

340) 

341) <!-- If we decide to switch to the exit list in TorStatus, this is obsolete.

342) <li>
343) <b>Ulepszenia w naszej usłudze punktów wyjściowych Tora - DNS Exit List</b> -
344) <a href="http://exitlist.torproject.org">http://exitlist.torproject.org</a>
345) <br />

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

348) Jest to serwer DNS napisany w języku Haskell, obsługujące część naszego <a

349) href="<svnsandbox>doc/contrib/torel-design.txt">dokumentu

350) projektowania listy punktów wyjściowych</a>. W chwili obecnej, usługa jest
351) funkcjonalna i używana przez check.torproject.org i innych użytkowników. Sprawy,
352) które zostały do zrobienia to głównie estetyka. Tej wspaniałej usłudze przydałaby
353) się o wiele lepsza strona z motywem wspólnym dla stron Tora. Lepiej by wyglądała
354) z lepszą dokumentacją częstych usług korzystających z RBL. Przydałby się rozgłos.
355) Osoba pracująca nad tym projektem powinna interesować się DNS, podstawową konfiguracją
356) RBL dla popularnych usług i pisaniem dokumentacji. Osoba ta wymagałaby tylko minimalnego
357) stykania się z Torem &mdash; co najmniej podczas testowania własnej dokumentacji.

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

359) więcej z sugestii w dokumencie torel-design.txt.
360) </li>

361) -->

362) 

363) <!-- Nobody wanted to keep this.

364) <li>
365) <b>Testowanie integracji Tora z przeglądarkami dla użytkowników końcowych</b>
366) <br />
367) Projektowi Tor brakuje obecnie solidnego testu do upewnienia się, że

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

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

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

374) <a href="http://www.decloak.net/">stronę metasploit

375) decloak</a>. Osoba zainteresowana obroną Tora mogłaby zacząć od

376) zbierania jak największej liczby działających i znanych metod odkrywania

377) użytkownika Tora. (<a href="https://torcheck.xenobite.eu/">Ta strona</a> może być

378) pomocna na początek.) Powinno się znać częste pułapki, ale też myśleć o
379) nowych metodach "zdejmowania" osłony użytkowników. Strona powinna

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

381) problemu lub skierować go na właściwe kanały wsparcia. Osoba wykonująca powinna
382) dobrze znać Tora i to, jak zapobiegać wyciekom.
383) </li>

384) -->

385) 

386) <!-- Nick did quite some work here. Is this project still required then?

387) <li>
388) <b>Lepsza integracja Tora i Libevent</b>
389) <br />

390) Tor powinien lepiej używać nowych cech biblioteki
391) <a href="http://monkey.org/~provos/libevent/">Libevent</a> Nielsa Provosa.

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

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

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

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

400) </li>

401) -->

402) 
403) <li>
404) <b>Tuneup Tor!</b>
405) <br />

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

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

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

416) Snadera i Borisova. Można byłoby użyć bieżącego kodu testującego, by sprawdzić

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

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

421) </li>
422) 

423) <!--

424) <li>
425) <b>Polepszenie procesu QA Tora: Ciągła integracja dla paczek pod Windows</b>
426) <br />
427) Przydałby się automatyczny system tworzenia paczek dla Windows i być może
428) innych systemów. Celem posiadania środowiska ciągłej integracji jest
429) upewnienie się, że Windows nie zostanie w tyle z żadnym z projektów

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

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

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

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

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

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

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

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

450) -->

451) 
452) <li>
453) <b>Polepszenie procesu testów jednostkowych</b>
454) <br />

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

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

461) Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów
462) (ale potrzebujemy osoby do uruchomienia tego pod Windows), ale

463) musimy zaktualizować nasze testy symulacji sieci (takie, jak w <a
464) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)

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

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

468) </li>
469) 
470) <li>

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

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

481) choć nie wymagana.<br />
482)  Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie, łącznie

483) z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C

484) też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej dokumentacji,

485) implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać
486) dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z
487) pisania kodu i w mniejszym - z projektowania.
488) </li>
489) 
490) <li>
491) <b>Ożywienie projektu moniTor</b>
492) <br />
493) Zaimplementuj narzędzie <a href="http://www.ss64.com/bash/top.html">podobne do top</a>
494) dla przekaźników siei Tora. Celem takiego narzędzia byłoby monitorowanie lokalnego przekaźnika

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

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

499) wiadomość na or-dev</a> może być dobrą lekturą na początek.<br />

500)  Obsoba powinna znać lub
501) być chętną do nauki administrowania przekaźnikiem Tora i konfigurowania go

502) za pomocą portu kontroli. Jako że wstępny prototyp jest napisany w Pythonie,
503) pewna wiedza na temat pisania programów w tym języku też byłaby przydatna.
504) Ten projekt z jednej strony opiera się na określeniu wymagań dla takiego
505) narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony
506) wymaga również dużo programowania.
507) </li>
508) 

509) <!-- Removed, unless Mike still wants this to be in.

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

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

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

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

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

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

523) <br />

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

525) świecie <a
526) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
527) bez zbytniego zagłębiania się do wnętrzności Tora.
528) </li>

529) -->

530) 
531) <li>
532) <b>Przeniesienie Polipo na Windows</b>
533) <br />
534) Pomóż przenieść <a
535) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na Windows.
536) 1) obsługa spacji w ścieżkach i zrozumienie przestrzeni nazw systemu plików
537) &mdash; przestrzeń nazw tu oznacza gdzie dane aplikacji, dane osobiste i
538) program zwykle się znajdują w różnych wersjach Windows. 2) zdolność obsługi
539) połączeń przez IPv6. 3) zdolność do asynchronicznego wysyłania zapytań do
540) serwerów nazw. 4) używanie natywnych zdolności Windows odnośnie wyrażeń regularnych
541) zamiast używania bibliotek GNU. 5) natywna obsługa zdarzeń i buforów (tj. w
542) systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows
543) jest to cokolwiek wpisane w plik konfiguracyjny). 6) jakieś narzędzie z
544) graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli
545) ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy.
546) Podwójny bonus, jeśli działa na wielu platformach.
547) </li>
548) 

549) <!-- Is Blossom development still happening?

550) <li>
551) <b>Zmiana i rozszerzenie Blossom</b>
552) <br />
553) Należy zmienić i rozszerzyć Blossom (narzędzie do monitorowania i wybierania
554) właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane

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

556) przez użytkownika parametrami. Blossom jest aktualnie zaimplementowany
557) jako pojedynczy skrypt Pythona, który łączy się z Torem używając interfejsu
558) Kontrolera i opiera się na danych zbieranych o węzłach Tora przez zewnętrzne
559) procesy takiej jak strona www pokazująca status węzłów wraz z publicznymi
560) danymi z DNSów, whois itp. Ten projekt ma 2 części: (1) Określenie, jakie jeszcze
561) dane mogą być potrzebne i przerobić Blossom tak, by sam zbierał dane zamiast polegać
562) na zewnętrznych skryptach (to może, oczywiście, wprowadzić dodatkowe wątki i
563) komunikację międzyprocesową) i (2) stworzenie metody łatwej konfiguracji Blossom
564) przez użytkownika, zaczynając od pliku konfiguracyjnego i być może kończąc na
565) konfiguracji przez przeglądarkę. Ważna jest znajomość Tora i Pythona; znajomość
566) TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie
567) neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie
568) niespójności Internetu są podstawą projektu Blossom.
569) </li>
570) 
571) <li>
572) <b>Ulepszenie Blossom: pozwolenie użytkownikom na jakościowy opis węzłów wyjściowych,
573) z których chcą korzystać</b>
574) <br />
575) Należy zaprojektować i zaimplementować możliwość dania użytkownikom programu Blossom
576) opisania węzła wyjściowego, z którego chcą korzystać. Internet jest niespójnym
577) miejscem: niektóre węzły wyjściowe Tora widzą świat inaczej niż inne. W bieżącej
578) implementacji Blossom (narzędzie do monitorowania i wybierania
579) właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane
580) przez użytkownika) nie ma dość bogatego języka, by opisać, jak bardzo różne
581) są różne punkty widzenia. Na przykład, niektóre węzły wyjściowe mogą być w
582) sieciach filtrujących pewne rodzaje ruchu lub strony. Inne węzły mogą dawać dostęp

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

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

592) </li>
593) -->

594) 

595) <li>
596) <b>Zaimplementowanie opartego na torrencie sposobu pobierania paczek Thandy</b>
597) <br />
598) <a
599) href="http://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
600) jest względnie nowym oprogramowaniem, które umożliwia automatyczne aktualizacje Tora i
601) związanych z nim programów. W tej chwili użytkowników jest niewielu, ale oczekujemy, że
602) Thandy będzie w przyszłości używane przez prawie każdego użytkownika Tora. By uniknąć
603) padających serwerów w dniu aktualizacji Tora, potrzebujemy nowych sposobów na
604) wydajną dystrybucję nowych paczek, a wykorzystanie libtorrent zdaje się być
605) możliwym rozwiązaniem. Jeśli myślisz o innych dobrych pomysłach, to wspaniale
606) - proszę dać nam znać!<br />
607) Musimy też zbadać, jak lepiej dołączyć nasze mirrory. Jeśli to możliwe, powinien
608) znaleźć się łatwy sposób na to, by łatwo pomogły w dystrybucji paczek.
609) </li>
610) 

611) <li>
612) <b>Przynieś nowe pomysły!</b>
613) <br />
614) <li>Nie podoba ci się żaden z tych pomysłów? Spójrz na <a

615)  href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">plan rozwoju Tora</a> po więcej
616)  pomysłów.</li>

617) <li>Nie widzisz tu swojego pomysłu? Prawdopodobnie i tak go potrzebujemy! Skontaktuj się
618)  z nami, by to sprawdzić.</li>
619) </ol>
620) 

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

623) 

624) <ol>

625) 

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

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

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

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

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

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

634)  zamiast select() pod Windows, po czym zaadaptować Tora do nowego interfejsu.
635)  Christian King zrobił

636)  <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">pierwszy dobry

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

638) 

639) <li>Musimy zacząć budować nasz <a href="<page
640)  documentation>#DesignDoc">projekt odporny na blokowanie</a>. Wchodzi w to

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

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

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

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

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

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

657) 

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

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

662) 

663) <li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
664)  ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
665)  opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
666)  obsługiwać możemy tylko strumienie TCP. Mamy <a

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

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

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

671)  UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>

672) 
673) 

674) <li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
675)  wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
676)  startu.</li>

677) 
678) <li>
679) Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład, obrazków
680) "Jak działa Tor" na <a href="<page overview>">stronie wprowadzenia</a>
681) ze źródeł, byśmy mogli je tłumaczyć
682) jako tekst w UTF-8 zamiast edytować je ręcznie za pomocą GIMPa.
683) Należy zintegrować to z plikiem WML, by tłumaczenie było proste, a obrazki
684) generowane w wielu językach w czasie publikacji strony.
685) </li>
686) 
687) <li>Jak można uczynić <a
688) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
689) łatwiejszym w utrzymaniu, ulepszaniu i dokumentowaniu?</li>
690) 

691) </ol>
692) 
693) <a id="Research"></a>
694) <h2><a class="anchor" href="#Research">Badania</a></h2>
695) <ol>
696) <li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
697)  popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"

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

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

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

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

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

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

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

718)  kształtowania działają lepiej od innych?
719)  </li>

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

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

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

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

735) symetrycznych z innych przyczyn?</li>
736) 

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

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

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

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

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

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

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

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

795) href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint"

796) >odróżnić go od normalnego ruchu SSL</a>. Oczywiście, nie możemy osiągnąć idealnej
797) steganografii i dalej mieć użyteczną i działającą sieć, ale w pierwszym kroku
798) chcielibyśmy blokować jakiekolwiek ataki, które mogą się udać po obserwacji tylko
799) kilku pakietów. Jednym z pozostałych ataków, którego nie zbadaliśmy za bardzo,
800) polega na tym, że komórki Tora mają 512 bajtów, więc ruch w sieci może mieć długość
801) będącą wielokrotnością 512 bajtów. Jak bardzo wkładanie nowych danych
802) w nagłówkach TLS rozmywa ten fakt w transmisji? Czy inne strategie opróżniania bufora
803) w Torze mają na to wpływ? Czy trochę dokładania może bardzo pomóc, czy jest o atak,
804) z którym musimy żyć?</li>
805) 

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

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

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

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

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

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

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

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

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

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

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

818) <li>Programy takie jak <a href="<page torbutton/index>">Torbutton</a>

819)  mają na celu ukrycie pola UserAgent przeglądarki, zastępując je jednakową odpowiedzią
820)  dla każdego użytkownika Tora. W ten sposób napastnik nie może złamać anonimowości
821)  Tora, patrząc na ten nagłówek. Aby się nie wyróżniać, program próbuje wybrać nazwy
822)  przeglądarek często używanych także przez tych, którzy nie używają Tora.
823)  Pytanie numer jeden: jak bardzo szkodzimy sami sobie, okresowo zwiększając
824)  wersję Firefoksa, za którego podaje się Torbutton? Jeśli aktualizujemy zbyt często,
825)  sami łamiemy swoją anonimowość. Jeśli za rzadko, to wszyscy użytkownicy Tora się
826)  wyróżniają ze względu na to, że twierdzą, iż używają starych wersji Firefoksa.
827)  Tutaj odpowiedź zależy pewnie na tym, które wersje Firefoksa są spotykane.
828)  Pytanie numer dwa: raz na jakiś czas ludzie pytają nas, byśmy krążyli po N
829)  nazwach UserAgent, zamiast trzymać się jednej. Czy to podejście pomaga, przeszkadza,
830)  czy nic nie wnosi? Weź pod uwagę: ciaseczka i rozpoznawanie użytkowników Tora poprzez
831)  ich zmieniające się nagłówki UserAgent, złe strony atakujące tylko określone
832)  przeglądarki; oraz to, czy odpowiedź na pytanie 1 wpływa na tę odpowiedź.
833) </li>

834) <li>W chwili obecnej klienci Tora mogą używać tego samego obwodu w ciągu dziesięciu
835) minut od jego pierwszego użycia. Celem tego jest uniknięcie przeładowania sieci
836) zbyt wielką liczbą operacji przedłużania obwodów, równocześnie unikając używania
837) obwodu tak długo, że węzeł wyjściowy mógłby stworzyć przydatny profil pseudonimowy
838) użytkownika. Dziesięć minut to jednak prawdopodobnie znacznie za dużo, zwłaszcza
839) gy przez ten sam obwód prowadzone sa połączenia różnych protokołów (np. IM i przeglądanie
840) sieci). Jeśli nie zmienimy całkowitej liczby obwodów, które należy utrzymywać, to czy
841) będą jakieś wydajniejsze lub bezpieczniejsze metody alokcaji strumieni do obwodów,
842) lub do tworzenia wywłaszczających obwodów? Być może ten temat badań powinien być rozpoczęty
843) poprzez zebranie śladów, jakie połączenia typowy użytkownik otwiera, by mieć coś
844) realistycznego do optymalizacji.
845) </li>
846) <li>Ile przekaźników mostkowych potrzeba, by utrzymać osiągalność? Powinniśmy zmierzyć
847) zajętość w naszych mostkach. Jeśli jest duża, czy są jakieś sposoby na zwiększenie
848) szans użytkowników mostków na pozostanie połączonymi?
849) </li>
850) 

851) </ol>
852) 

853) <p>

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

855) </p>