tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 21122

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) <p>Tor ma <a href="<page open-positions>">dwa wolne etaty</a>, prosimy
29) <a href="<page contact>">skontaktuj się z nami</a>, jeśli masz kwalifikacje!</p>
30) 

31) <a id="Usability"></a>
32) <h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
33) <ol>

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

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

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

38) <li>Sprawy z Tsocks/dsocks:
39)  <ul>

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="Advocacy"></a>
66) <h2><a class="anchor" href="#Advocacy">Pokazanie się jako zwolennik Tora</a></h2>
67) <ol>

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

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

71) <li>Stwórz film o Twoim pozytywnym wykorzystaniu Tora. Kilka osób już zaczęło na
72)   <a href="http://tinyvid.tv">TinyVid</a>.</li>

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

76) <a id="Documentation"></a>
77) <h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
78) <ol>

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

80)  jego projektu Tor Controller i <a href="<page vidalia/index>">Vidalia</a>.</li>

81) <li>Przejrzyj i udokumentuj

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

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

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

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

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

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

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

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

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

98) </ol>
99) 
100) <a id="Coding"></a>

101) <a id="Summer"></a>
102) <a id="Projects"></a>
103) <h2><a class="anchor" href="#Projects">Dobre Projekty Programistyczne</a></h2>

104) 
105) <p>

106) Niektóre z tych projektów mogą być dobrymi pomysłami na <a

107) href="<page gsoc>">Google Summer of Code 2010</a>.

108) Opisaliśmy każdy z nich informacją, jak użyteczny byłby dla projektu Tor (priorytet),
109) ile pracy według nas wymaga (poziom wysiłku), z iloma informacjami powinno się
110) zaczynać (poziom umiejętności), i którzy z naszych <a href="<page
111) people>#Core">głównych deweloperów</a> byliby dobrymi opiekunami.
112) Jeśli jeden lub więcej z tych pomysłów wygląda dla Ciebie obiecująco, <a
113) href="<page contact>">skontaktuj się z nami</a>, by omówić Twoje plany zamiast wysyłać
114) zgłoszenia na ślepo. Możesz też zaproponować swój własny pomysł na projekt, co często
115) daje najlepsze programy.

116) </p>
117) 
118) 

119) <ol>
120) 
121) <li>

122) <b>Paczka Tora z Przeglądarką dla Linux/Mac OS X</b>

123) <br />

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

125) <br />

126) Poziom wysiłku: <i>Wysoki</i>
127) <br />
128) Poziom umiejętności: <i>Średni</i>
129) <br />

130) Prawdopodobni opiekunowie: <i>Steven, Andrew, Jacob</i>

131) <br />

132) Paczka Tora z Przeglądarką zawiera Tora, Firefoksa, Polipo i interfejs użytkownika - Vidalię
133) (i opcjonalnie komunikator <a href="http://pidgin.im/">Pidgin</a>). Komponenty te są
134) prekonfigurowane do bezpiecznego

135) działania, a paczka ma małe wymagania co do systemu operacyjnego. Stała się więc
136) jednym z najprostszych i najbardziej popularnych sposobów używania Tora na Windows.
137) <br />

138) Nie ma jednak w chwili obecnej działającej paczki dla Linuksa i Mac OS X, więc celem

139) tego projektu byłaby implementacja Paczki Tora z Przeglądarką dla tych systemów.
140) Będzie to pociągało zmiany w Vidalii (C++), być może w Firefoksie (C), po czym stworzenie
141) i testowanie programu uruchamiającego na różnych wersjach i konfiguracjach systemów operacyjnych,

142) by sprawdzić przenośność. Część pracy w tym temacie została wykonana w czasie
143) Google Summer of Code 2009.

144) <br />
145) Studenci powinni być zaznajomieni z rozwojem aplikacji na jednym, lub najlepiej obu,
146) Linuksie i Mac OS X oraz czuć się swobodnie z C/C++ i pisaniem skryptów powłoki.
147) </li>
148) 

149) <li>
150) <b>Pomóż śledzić ogólny status Sieci Tora</b>

151) <br />

152) Priorytet: <i>Średni do wysokiego</i>
153) <br />
154) Poziom wysiłku: <i>Średni</i>
155) <br />
156) Poziom umiejętności: <i>Średni</i>
157) <br />

158) Prawdopodobni opiekunowie: <i>Karsten, Roger</i>

159) <br />

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

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

170) deskryptorów serwerów, które są publikowane przez każdy przekaźnik i z innych
171) źródeł. Wyniki w czasie mogłyby być zintegrowane z jedną ze stron opisujących
172) <a href="https://torstatus.blutmagie.de/">Stan Tora</a> lub być trzymane osobno.
173) Skoro mówimy o stronach stanu Tora, spójrzcie na
174) <a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">listę życzeń
175) stanu Tora</a> napisaną przez Rogera.
176) </li>
177) 
178) <li>
179) <b>Polepszanie naszych zdolności opierania się cenzurze</b>
180) <br />

181) Priorytet: <i>Średni do wysokiego</i>

182) <br />

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

184) <br />
185) Poziom umiejętności: <i>Wysoki</i>
186) <br />

187) Prawdopodobni opiekunowie: <i>Nick, Roger, Steven</i>

188) <br />

189) Wersje 0.2.1.x Tora robią <a

190) href="<svnprojects>design-paper/blocking.html">znaczne postępy</a> w opieraniu

191) się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w
192) niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą
193) nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje

194) <a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">propozycja

195) zajęcia się tą sprawą</a> i umożliwienia klientom łączenie się z danym Torem
196) na wielu adresach i portach, ale wymaga to więcej pracy. Kolejny projekt
197) przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie.
198) W chwili obecnej ktokolwiek może zidentyfikować

199) <a href="<gitblob>doc/spec/proposals/125-bridges.txt">mostki Tora</a>

200) po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając,
201) czy odpowiadają. By rozwiązać ten problem, mostki mogłyby

202) <a href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">udawać serwery

203) internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów,
204) a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny
205) dla mostka.
206) <br />
207) Ten projekt zawiera wiele badań i projektowania. Jednym z większych wyzwać
208) będzie zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą
209) się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie
210) odporności na cenzurę z użytecznością i siłą.
211) </li>
212) 
213) <li>

214) <b>Tuneup Tor!</b>

215) <br />

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

217) <br />

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

219) <br />

220) Poziom umiejętności: <i>Średni do wysokiego</i>
221) <br />
222) Prawdopodobni opiekunowie: <i>Nick, Roger, Mike</i>
223) <br />
224) W chwili obecnej węzły Tora mierzą i zgłaszają własną przepustowość łącza,
225) a klienci Tora wybierają, których węzłów używać po części opierając się
226) na tej zgłaszanej przepustowości. To podejście jest podatne na
227) <a href="http://freehaven.net/anonbib/#bauer:wpes2007">ataki, w których węzły oszukują
228) na temat przepustowości swoich łączy</a>; by to zmienić, Tor aktualnie ogranicza
229) maksymalną przepustowość każdego węzła, w którą jest w stanie uwierzyć. To jest
230) ograniczone rozwiązanie i marnotrawienie przepustowości. Zamiast tego,
231) Tor powinien w miarę możliwości mierzyć przepustowość łączą w rozproszony sposób,
232) jak jest napisane w dokumencie
233) <a href="http://freehaven.net/anonbib/author.html#snader08">"A Tuneup for Tor"</a> autorstwa
234) Snadera i Borisova. Można byłoby użyć bieżącego kodu testującego, by sprawdzić
235) odkrycia napisane w tym dokumencie i zweryfikować, w jakim stopniu opisują one
236) normalnie działającego Tora i określić dobre sposoby na wcielenie tych odkryć
237) do sieci Tora bez dodawania niepożądanego ruchu wielkości między węzłami a serwerami
238) katalogowymi.

239) </li>
240) 
241) <li>

242) <b>Ulepszenie Polipo na Windows</b>

243) <br />

244) Priorytet: <i>Średni</i>
245) <br />

246) Poziom wysiłku: <i>Niski</i>

247) <br />
248) Poziom umiejętności: <i>Średni</i>
249) <br />

250) Prawdopodobni opiekunowie: <i>Martin, Chris</i>

251) <br />

252) Pomóż przenieść <a
253) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na Windows.
254) 1) zdolność do asynchronicznego wysyłania zapytań do
255) serwerów nazw. 2) natywna obsługa zdarzeń i buforów (tj. w
256) systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows
257) jest to cokolwiek wpisane w plik konfiguracyjny). 3) jakieś narzędzie z
258) graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli
259) ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy.
260) Podwójny bonus, jeśli działa na wielu platformach.
261) 4) umożliwienie programowi używania rejestru Windowsa i obsługiwania prawidłowych
262) ścieżek w Windowsie, np. "C:\Program Files\Polipo".
263) </li>
264) 

265) <li>

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

267) <br />

268) Priorytet: <i>Średni</i>
269) <br />
270) Poziom wysiłku: <i>Średni</i>
271) <br />

272) Poziom umiejętności: <i>Niski do średniego</i>

273) <br />
274) Prawdopodobni opiekunowie: <i>Matt</i>
275) <br />

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

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

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

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

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

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

297) <br />

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

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

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

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

308) 

309) <li>

310) <b>Polepszenie procesu testów jednostkowych</b>

311) <br />

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

313) <br />

314) Poziom wysiłku: <i>Średni</i>
315) <br />
316) Poziom umiejętności: <i>Średni</i>
317) <br />
318) Prawdopodobni opiekunowie: <i>Nick, Roger</i>
319) <br />
320) Tor musi zostać znaczniej bardziej przetestowany. To jest projekt wieloczęściowy.
321) Na początek, nasze testy jednostkowe powinny znacznie się wzbogacić, zwłaszcza
322) w obszarach poza funkcjami narzędziowymi. Będzie to wymagało poważnych zmian
323) niektórych części Tora, aby oddzielić jak najwięcej programu od zmiennych
324) globalnych.<br />
325) Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.
326) Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów
327) (ale potrzebujemy osoby do uruchomienia tego pod Windows), ale
328) musimy zaktualizować nasze testy symulacji sieci (takie, jak w <a
329) href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
330) do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe
331) albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie
332) badać zmiany wydajności na maszynach pełniących różne zadania.

333) </li>

334) 
335) <li>

336) <b>Pomóż w niezależnych implementacjach klienta Tora</b>

337) <br />
338) Priorytet: <i>Średni</i>
339) <br />
340) Poziom wysiłku: <i>Wysoki</i>
341) <br />
342) Poziom umiejętności: <i>Średni do wysokiego</i>
343) <br />
344) Prawdopodobni opiekunowie: <i>Karsten, Nick</i>
345) <br />

346) Pracujemy w tej chwili nad klientami Tora dla środowisk Java, Android i Maemo.
347) Pierszym krokiem byłoby zapoznanie się z bieżacym stanem projektu, któremu chcesz
348) pomóc; Tor dla Javy, Android/Orbot lub Tor dla Maemo. Pobierz repozytorium i
349) zapoznaj się z kodem źródłowym.
350) Ponadto, obsługa żądań lub choćby dostarczania usług ukrytych Tora byłaby fajna,

351) choć nie wymagana.<br />

352) Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie, łącznie

353) z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C
354) też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej dokumentacji,
355) implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać
356) dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z
357) pisania kodu i w mniejszym - z projektowania.
358) </li>
359) 
360) <li>
361) <b>Nowe funkcjonalności Torbuttona</b>
362) <br/>
363) Priorytet: <i>Średni</i>
364) <br />
365) Poziom wysiłku: <i>Wysoki</i>
366) <br />
367) Poziom umiejętności: <i>Wysoki</i>
368) <br />
369) Prawdopodobni opiekunowie: <i>Mike</i>
370) <br/>
371) Jest kilka <a
372) href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">dobrych
373) próśb o nowe funkcjonalności</a> w sekcji Flyspray Torbuttona. W szczególności, <a
374) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integracja
375) 'Nowej Tożsamości' z Vidalią</a>,
376) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">sposoby
377) zarządzania wieloma plikami z ciasteczkami/tożsamościami</a>, <a
378) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">zachowywanie
379) określonych ciasteczek</a> gdy ciasteczka są usuwane,
380) <a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">lepsza
381) podmiana odnośnika wstecznego</a>, <a
382) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">prawidłowe
383) zgłaszanie stanu Tora</a>, i <a
384) href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">adresy "tor://"
385) i "tors://"</a> są interesującymi cechami, które można byłoby dodać.
386) <br />
387) Ta praca byłaby niezależnym programowaniem w Javascripcie i przyjemnym świecie <a
388) href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>, z
389) niewielkim zaangażowaniem w wewnętrzne sprawy Tora.
390) </li>
391) 
392) <li>
393) <b>Nowe funkcjonalności Thandy</b>
394) <br />
395) Priorytet: <i>Średni</i>
396) <br />
397) Poziom wysiłku: <i>Średni</i>
398) <br />
399) Poziom umiejętności: <i>Średni do wysokiego</i>
400) <br />
401) Prawdopodobni opiekunowie: <i>Martin</i>
402) <br />
403) Potrzebujemy dodatkowych funkcjonalności do wspomaganych aktualizacji całego
404) oprogramowania związanego z Torem na Windows i innych systemach operacyjnych.
405) Niektóre funkcjonalności do rozważenia to:
406) 1) Integracja <a
407) href="http://chandlerproject.org/Projects/MeTooCrypto">biblioteki Pythona MeTooCrypto</a>
408) do uwierzytelnianych pobierań przez HTTPS. 2) Dodanie poziomu niezależności między
409) sygnaturami czasowymi a plikami załączonymi w aktualizacji. Przeczytaj wątek
410) "Thandy attacks / suggestions" na or-dev.
411) 3) Obsługa specyficznych dla lokalizacji instalacji i konfiguracji wspomaganych
412) aktualizacji w oparciu o ustawienia języka według preferencji, hosta lub konta użytkownika.
413) Znajomość stron kodowych Windows, unikodu i innych zestawów znaków będzie pomocna,
414) jak również ogólne doświadczenie w programowaniu win32 i POSIX API oraz biegłość w Pythonie.
415) </li>
416) 
417) <li>
418) <b>Symulator wolnych połączeń internetowych</b>
419) <br />
420) Priorytet: <i>Średni</i>
421) <br />
422) Poziom wysiłku: <i>Średni</i>
423) <br />
424) Poziom umiejętności: <i>Średni</i>
425) <br />
426) Prawdopodobni opiekunowie: <i>Steven</i>
427) <br />
428) Wielu użytkowników Tora ma łącza internetowe niskiej jakości, dające niską przepustowość,
429) długie czasy trwania operacji i wysoki współczynnik utraty lub przekładania pakietów.
430) Z doświadczeń użytkowników wiemy, że Tor źle reaguje na te warunki, ale ciężko jest
431) poprawić tę sytuację bez możliwości powtórzenia tych problemów w laboratorium.
432) <br />
433) Celem tego projektu byłoby zbudowania środowiska symulacyjnego, które replikowałoby
434) tę słabą łączność, by można było zmierzyć jej działanie na wydajność Tora. Innymi
435) komponentami byłby program testujący, w celu określenia dostępnych parametrów połączenia
436) i mierzenia wpływu zmian polepszających wydajność Tora.
437) <br />
438) Wybór narzędzi zależałby od studenta/ki, ale dummynet (dla FreeBSD) i
439) nistnet (pod Linux) są dwoma potencjalnymi komponentami, na których można byłoby zbudować ten
440) projekt. Studenci powinni mieć doświadczenie w programowaniu i debugowaniu sieciowym i TCP/IP
441) oraz najlepiej znać C i język skryptowy.
442) </li>
443) 
444) <li>
445) <b>Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia</b>
446) <br />
447) Priorytet: <i>Średni</i>
448) <br />
449) Poziom wysiłku: <i>Średni</i>
450) <br />
451) Poziom umiejętności: <i>Średni</i>
452) <br />
453) Prawdopodobni opiekunowie: <i>Matt</i>
454) <br />
455) Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi
456) przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje
457) ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.
458) Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.
459) Zamiast tego, zaimplementowaliśmy widget Marble z KDE, który daje mapę lepszej jakości i
460) umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na
461) klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe
462) informacje. Chcemy też dodaće możliwość klikania przez
463) użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
464) stwierdzenia "chcę, by moje połączenia do wychodziły stąd."
465) <br />
466) Podczas tego projektu, osoba najpierw zapozna się z Vidalią i API widgetu
467) Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował
468) do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we
469) własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.
470) <br />
471) Osoba podejmująca się tego projektu powinna dobrze znać C++.
472) Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
473) </li>
474) 
475) <li>
476) <b>Odpowiednik Torbuttona dla Thunderbirda</b>
477) <br />
478) Priorytet: <i>Średni</i>
479) <br />
480) Poziom wysiłku: <i>Wysoki</i>
481) <br />
482) Poziom umiejętności: <i>Wysoki</i>
483) <br />
484) Prawdopodobni opiekunowie: <i>Mike</i>
485) <br />
486) Od ciągle powiększającej się grupy użytkowników słyszymy, że chcą używać Thunderbirda z
487) Torem. Jest jednak wiele spraw na poziomie aplikacji, na przykład to, że Thunderbird
488) domyślnie umieści Twoją nazwę hosta w wysyłanej przez siebie poczcie. W pewnym momencie
489) powinniśmy zapoczątkować nowe działania mające na celu stworzenie rozszerzenia dla
490) Thunderbirda, podobnego do Torbuttona.
491) </li>
492) 
493) <li>
494) <b>Sterownik Pośredniego Poziomu Sieci</b>
495) <br />
496) Priorytet: <i>Niski</i>
497) <br />
498) Poziom wysiłku: <i>Wysoki</i>
499) <br />
500) Poziom umiejętności: <i>Wysoki</i>
501) <br />
502) Prawdopodobni opiekunowie: <i>Martin</i>
503) <br />
504) Sterownik WinPCAP używany przez Tor VM do działań sieciowych nie obsługuje sporej
505) liczby kart bezprzewodowych i nie-ethernetowych. Zaimplementowanie sterownika
506) pośredniego poziomu sieciowego dla win32 i 64-bitowego dałoby możliwość przechwytywania
507) i przekierowywania ruchu w takich sieciach. Ten projekt wymaga znajomości i doświadczenia
508) z pisaniem i testowaniem sterowników poziomu jądra Windows. Znajomość Winsock i Qemu
509) też byłaby pomocna.
510) </li>
511) 

512) <li>
513) <b>Ulepszenie Pogody Tora</b>
514) <br />
515) Priorytet: <i>Średni</i>
516) <br />
517) Poziom wysiłku: <i>Średni</i>
518) <br />
519) Poziom umiejętności: <i>Średni</i>
520) <br />

521) Prawdopodobni opiekunowie: <i>Christian, Roger</i>

522) <br />
523) <a href="https://weather.torproject.org/">Pogoda Tora</a> jest narzędziem, które
524) umożliwia zapisanie się do otrzymywania powiadomień pocztą e-mail, gdy obserwowany przekaźnik
525) sieci Tora nie działa. W chwili obecnej nie jest to zbyt użyteczne dla osób używających
526) hibernacji Tora i dla tych, którzy muszą regularnie wyłączać swoje przekaźniki.
527) W czasie tego projektu, Pogoda Tora mogłaby być rozszerzona o bardziej elastyczne możliwości
528) konfiguracji. Możliwe są też inne udoskonalenia: mogłaby wysyłać ostrzeżenia, gdy Twój
529) przekaźnik używa przestarzałej wersji Tora, lub gdy jego zaobserwowana przepustowość
530) spadnie poniżej pewnego poziomu. To może być też przydatne narzędzie do sprawdzania, czy
531) Twój przekaźnik zarobił dla Ciebie <a href="<page tshirt>">T-Shirt</a> lub do przesyłania
532) przypomnień do serwerów katalogowych, że ich klucze się wkrótce przedawnią. Bądźcie
533) twórczy i pomyślcie, jak powyższy projekt śledzenia ogólnego stanu sieci Tora mógłby
534) Wam pomóc w szybszym ukończeniu zadania! Przeczytajcie też pliki
535) <a href="https://svn.torproject.org/svn/weather/trunk/README">README</a> i
536) <a href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.
537) </li>
538) 
539) 

540) <li>
541) <b>Przynieś nowe pomysły!</b>
542) <br />
543) <li>Nie podoba Ci się żaden z tych pomysłów? Sięgnij do <a

544)  href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">planu rozwoju Tora</a> po więcej

545)  pomysłów.

546)  Niektórym z <a href="<gittree>doc/spec/proposals/">bieżących propozycji</a>

547)  też może brakować deweloperów.</li>
548) 
549) <li>

550) <b>Lepsze pakowanie dla Debiana/Ubuntu</b>

551) <br />
552) Vidalia obecnie nie współpracuje dobrze na Debianie i Ubuntu z domyślnymi
553) paczkami Tora. Bieżące paczki Tora automatycznie uruchamiają Tora jako demona
554) systemowego z konta użytkownika debian-tor i (rozsądnie) nie mają zdefiniowanego
555) ControlPort w domyślnym torrc. Stąd Vidalia będzie próbować uruchomić własny
556) proces Tora, bo nie może połączyć się z istniejącym, po czym proces Tora
557) uruchomiony przez Vidalię zamknie się z błędem, którego użytkownik raczej nie zrozumie,
558) jako że Tor nie będzie mógł podpiąć się pod swoje porty nasłuchowe, które są
559) już zajęte przez pierwszy proces Tora.
560) <br />
561) Bieżące rozwiązanie to albo mówienie użytkownikowi, by zatrzymał istniejący
562) proces Tora i pozwolił Vidalii uruchomić własny, albo tłumaczenie, jak ustawić
563) port kontrolny i hasło w pliku torrc. Lepszym rozwiązaniem na Debianie byłoby używanie
564) ControlSocket Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez
565) gniazdo w domenie Unix i mógłby być domyślnie włączony w paczkach Tora dla Debiana.
566) Vidalia może wtedy uwierzytelnić się do Tora używając ciasteczek, jeśli użytkownik
567) uruchamiający Vidalię jest w grupie debian-tor.
568) <br />
569) Pierwsza część tego projektu będzie polegała na dodaniu obsługi ControlSocket
570) do Vidalii. Potem student stworzy i przetestuje paczki Vidalii na Debianie i
571) Ubuntu, które będą zgodne ze standardami pakowania w Debianie, oraz upewni się,
572) że działają dobrze z istniejącymi paczkami Tora. Możemy też stworzyć repozytorium
573) apt zawierające nowe paczki Vidalia.
574) <br />
575) Kolejnym wyzwaniem byłoby znalezienie intuicyjnego sposobu, by Vidalia mogła
576) zmienić konfigurację Tora (torrc) mimo iż ta jest w <code>/etc/tor/torrc</code>,
577) a więc nienaruszalna. Najlepszy jak dotąd pomysł, na jaki wpadliśmy, to
578) przekazanie Torowi nowej konfiguracji poprzez ControlSocket w czasie uruchamiania
579) Vidalii, ale jest to zły pomysł, gdyż Tor za każdym razem uruchamia się z inną
580) konfiguracją niż użytkownik by tego chciał. Drugi najlepszy pomysł jest taki, by
581) Vidalia stworzyła tymczasowy plik konfiguracyjny i poprosiła użytkownika, by
582) ręcznie przeniósł go do <code>/etc/tor/torrc</code>, ale to jest zły pomysł, gdyż
583) użytkownicy nie powinni być zmuszani do bezpośredniego zajmowania się plikami.
584) <br />
585) Osoba podejmująca się tego projektu powinna znać system pakowania Debiana i
586) mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przydatne,
587) ale nie jest wymagane.
588) </li>
589) 
590) <li>
591) <b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>
592) <br />
593) Potrzebujemy dobrego frameworka automatycznej aktualizacji.
594) Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub
595) niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe
596) okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.
597) Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i
598) zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,
599) chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy
600) Vidalia.
601) <br />
602) By wykonać ten projekt, student będzie musiał najpierw poznać istniejące
603) mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,
604) cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże
605) się przydatny, student zaprojektuje własny framework aktualizacyjny,
606) udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat
607) jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)
608) i przetestuje.
609) <br />
610) Osoba podejmująca się tego projektu powinna dobrze znać C++.
611) Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.
612) Powinno się mieć też podstawowe pojęcie o powszechnych praktykach
613) bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w
614) pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie
615) zrobienie dokumentacji projektu do przejrzenia i przedyskutowania
616) z innymi ludźmi przed implementacją.
617) </li>

618) 
619) <li>

620) <b>Polepszenie procesu QA Tora: Ciągła integracja dla paczek</b>

621) <br />

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

644) </li>
645) 

646) <li>
647) <b>Badania używalności Tora</b>
648) <br />

649) Priorytet: <i>Średni</i>
650) <br />
651) Poziom wysiłku: <i>Średni</i>
652) <br />
653) Poziom umiejętności: <i>Niski do średniego</i>
654) <br />
655) Prawdopodobni opiekunowie: <i>Andrew</i>
656) <br />

657) Zwłaszcza paczki z przeglądarką, najlepiej wśród docelowego przekroju ludności.
658) To by bardzo pomogło w dowiedzeniu się, co musi zostać zrobione w dziedzinie poprawek
659) błędów lub nowych funkcjonalności. W tej chwili dostajemy to nieformalnie, ale lepszy
660) byłby bardziej strukturalny proces.
661) </li>
662) 

663) </ol>
664) 

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

667) 

668) <ol>

669) 

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

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

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

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

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

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

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

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

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

682) 

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

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

686)  <a href="<page vidalia/index>">Vidalii</a>, by obsługiwała nowe cechy i

687)  planowanie rozpowszechniania.</li>
688) 

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

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

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

699)  poprzez OpenSSL. Zostało to trochę przetestowane i prawdopodobnie ma dużo błędów.
700)  Czekamy na bardziej rygorystyczne testy, analizy wydajności i najlepiej poprawki
701)  kodu do OpenSSL i Tora, jeśli będzie trzeba.</li>

702) 

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

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

707) 

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

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

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

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

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

717) 
718) 

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

722) 
723) <li>
724) Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład, obrazków
725) "Jak działa Tor" na <a href="<page overview>">stronie wprowadzenia</a>
726) ze źródeł, byśmy mogli je tłumaczyć
727) jako tekst w UTF-8 zamiast edytować je ręcznie za pomocą GIMPa.
728) Należy zintegrować to z plikiem WML, by tłumaczenie było proste, a obrazki
729) generowane w wielu językach w czasie publikacji strony.
730) </li>
731) 
732) <li>Jak można uczynić <a
733) href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
734) łatwiejszym w utrzymaniu, ulepszaniu i dokumentowaniu?</li>
735) 

736) </ol>
737) 
738) <a id="Research"></a>
739) <h2><a class="anchor" href="#Research">Badania</a></h2>
740) <ol>
741) <li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
742)  popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"

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

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

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

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

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

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

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

763)  kształtowania działają lepiej od innych?
764)  </li>

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

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

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

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

780) symetrycznych z innych przyczyn?</li>
781) 

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

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

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

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

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

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

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

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

840) href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

896) </ol>
897) 

898) <p>

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

900) </p>