tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 9921

3) # Last-Translator: bogdandr_at_op . pl
4) 
5) #include "head.wmi" TITLE="Wolontariusze" CHARSET="UTF-8"
6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->

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

11) <ol>
12) <li>Prosimy rozważyć <a href="<page docs/tor-doc-server>">uruchomienie
13)  serwera</a>, by wspomóc rozwój sieci Tor'a.</li>
14) <li>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili serwer.
15)  Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.</li>
16) <li>Szukamy funduszy i sponsorów. Jeśli podobają ci się cele Tor'a,

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

18)   Jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
19)   są zainteresowane bezpieczną komunikacją, daj im znać o nas.</li>
20) </ol>
21) 
22) <a id="Usability"></a>
23) <h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
24) <ol>
25)  <li>Potrzebujemy dobrych sposobów na przechwytywanie żądań DNS, żeby nie

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

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

29) <li><ul>

30) <li>Musimy <a
31)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">zastosować
32)  nasze wszystkie łaty tsocks do kodu</a> i utrzymywać nową gałąź. Możemy ją hostować, jeśli chcesz.</li>
33) <li>Powinniśmy załatać program "dsocks" Dug'a Song'a, by używał komend
34)  <i>mapaddress</i> Tor'a z interfejsu kontroli, żeby nie marnować przejścia

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

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

40) </ul></li>

41) <li>Ludzie, którzy uruchomili serwer Tor'a mówią nam, że chcą dać jedną

42)  przepustowość łącza dla Tor'a (BandwidthRate) w czasie pewnej części dnia,
43)  a inną w innych częściach dnia. Zamiast programować to w Torze, powinniśmy mieć
44)  mały skrypt, który łączy się przez <a href="<page gui/index>">Tor Controller Interface</a>,
45)  i wykonuje SETCONF by zmienić przepustowość. Być może ten skrypt byłby uruchamiany
46)  z cron'a, a może byłby uśpiony aż do właściwego momentu i wtedy wykonywał swoją
47)  pracę (to by raczej było bardziej przenośne). Czy ktoś mógłby napisać taki
48)  skrypt za nas, a my byśmy go umieścili w katalogu <a href="<svnsandbox>contrib/">contrib/</a>?

49)  To byłby dobry wkład w <a href="<page gui/index>">Konkurs na GUI dla Tor'a</a>.
50) 	 <!-- We have a good script to adjust stuff now, right? -NM -->
51)  </li>

52) <li>Tor może <a
53)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">wychodzić
54)  z sieci Tor'a z podanego węzła</a>, ale powinniśmy móc podać tylko kraj i mieć coś,
55)  co automatycznie za nas wybierze węzeł. Najlepszym kandydatem jest pobranie także
56)  katalogu Blossom i uruchomienie lokalnego klienta Blossom, który pobrałby swój katalog w
57)  sposób bezpieczny (poprzez Tor i sprawdzając jego podpis), przechwycałby nazwy
58)  hostów <tt>.country.blossom</tt>  i robił to, co trzeba.</li>
59) <li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z
60)  zaznaczonym każdym serwerem Tor'a. Dodatkowe punkty, jeśli mapa bęzdie się
61)  aktualizować w miarę jak sieć rośnie i się zmienia. Niestety, łatwy sposób na
62)  dokonanie tego to wysłanie wszystkich danych do Google, w celu narysowania
63)  przez nich taj mapy. Jak bardzo to uderza w prywatność i czy mamy jakieś inne
64)  dobre wyjścia?</li>
65) </ol>
66) 
67) <a id="Documentation"></a>
68) <h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
69) <ol>
70) <li>Słyszeliśmy, że użytkownicy Tor'a mogą paść ofiarami ataków
71)  łamiących ich anonimowość ze strony JavaScript'u, Javy, ActiveX'a, Flash'a itp.,
72)  jeśli ich nie wyłączą. Czy są jakieś wtyczki/rozszerzenia (jak NoScript dla

73)  Firefox'a), które ułatwiają panowanie nad tym ryzykiem? Jakie dokładnie jest to ryzyko?

74)  </li>
75) <li>Czy istnieje kompletny zestaw wtyczek/rozszerzeń, który zastąpi całą
76)  funkcjonalność Privoxy w Firefoksie 1.5+? Podobno Tor jest o wiele szybszy, gdy
77)  nie używa się Privoxy.</li>
78) <li>Proszę pomóc Matt'owi Edman'owi z dokumentacją i dokumentami jak-to-zrobić do

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

80) <li>Przejrzyj i udokumentuj
81)  <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">naszą
82)  listę programów</a>, które można skonfigurować do współpracy z Tor'em.</li>
83) <li>Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń
84)  i wysyłania ich przez Tor'a. tsocks (Linux), dsocks (BSD),

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

87) <li>Mamy ogromną listę <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">potencjalnie

88)  użytecznych programów, które współpracują z Tor'em</a>. Które z nich są

89)  przydatne w jakich sytuacjach? Proszę pomóż nam je testować i zapisuj
90)  swoje wyniki.</li>
91) <li>Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na
92)  <a href="<page translation>">wskazówki do
93)  tłumaczenia</a>, jeśli chcesz pomóc. Potrzebujemy też ludzi do opieki nad

94)  istniejącymi tłumaczeniami: francuskim i szwedzkim - zobacz

95)  <a href="<page translation-status>">stan tłumaczeń</a>.</li>

96) <li>Czy ktoś może nas przekonać, że powinniśmy używać
97)   <a href="http://www.cacert.org/">cacert</a> do
98)   SSL w naszym <a href="<page documentation>#Developers">repozytorium SVN?</a></li>

99) </ol>
100) 
101) <a id="Coding"></a>
102) <h2><a class="anchor" href="#Coding">Programowanie i Projektowanie</a></h2>

103) 
104) <p>Chcesz spędzić swoje <a href="http://code.google.com/soc/">Google Summer
105)    of Code</a> pracując na Torem? Wspaniale.
106)    <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SummerOfCode">Przeczytaj
107)    więcej o Torze i GSoC</a>, i zobacz, czy któreś z poniższych pomysłów wpadają ci w oko.</p>
108) 

109) <ol>

110) 
111) <li>Serwery Tor'a nie dzialają zbyt dobrze na Windows XP. Pod systemem Windows Tor
112)  używa standardowej funkcji systemowej <tt>select()</tt>, która zużywa miejsce
113)  w niestronicowanym obszarze pamięci, <a
114)  href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">będąc
115)  przyczyną dziwnych zachowań i padów systemu</a>. Powinniśmy raczej używać
116)  nakładającego IO. Jednym z rozwiązań byłoby nauczenie biblioteki <a
117)  href="http://www.monkey.org/~provos/libevent/">libevent</a>, jak używać nakładającego IO
118)  zamiast select() pod Windows, po czym zaadaptować Tora do nowego interfejsu.</li>
119) 
120) <li>Ponieważ serwer Tor'a muszą przechować i podać dalej każdą komórkę,
121)  którą obsługują, serwery o wysokiej przepustowości używają wiele
122)  megabajtów pamięci na same bufory. Potrzebujemy lepszej heurystyki do
123)  określenia, kiedy skurczyć/rozszerzyć bufory. Może to powinno być zaprojektowane
124)  podobnie jak bufory w jądrze Linuksa, gdzie jest wiele mniejszych buforów, które
125)  łączą się wzajemnie, zamiast używać monolitycznych buforów?</li>
126) 
127) <li>Potrzebujemy oficjalnej, centralnej strony, która odpowiadałaby na pytania
128)  "Czy to jest adres serwera wyjściowego z sieci Tor?". Strona powinna dostarczyć klika
129)  interfejsów, łącznie z interfejsem www i w stylu DNSBL. Powinna dostarczać najbardziej
130)  aktualne odpowiedzi, przechowując lokalną kopię katalogów. Haczyk jest w tym, że
131)  bycie serwerem wyjściowym to nie tylko prawda czy fałsz, więc pytanie powinno raczej
132)  brzmieć: "Czy to jest adres serwera wyjściowego z sieci Tor, z którego można się
133)  połączyć z moim adresem IP i portem?". Interfejs DNSBL będzie pewnie otrzymywał
134)  setki zapytań na minutę, potrzeba więc mądrych algorytmów. Dodatkowe punkty, jeśli
135)  aktywnie byłoby sprawdzane każdego węzła wyjściowego, z jakiego adresu IP naprawdę
136)  wychodzą dane. <a href="<svnsandbox>doc/contrib/torbl-design.txt">Czytaj więcej tu</a>.</li>
137) 
138) <li>Byłoby wspaniale imeć LiveCD zawierające najnowsze wersje Tor, Polipo lub Privoxy,
139)  Firefox, Gaim+OTR itp. Są tu dwa wyzwania: pierwszym jest udokumentowanie systemu i
140)  możliwości wyboru dość dobrze, by ludzie zajmujący się bezpieczeństwem mogli wydać opinię
141)  o tym, czy taki system byłby bezpieczny, a drugim wyzwaniem jest jak sprawić, by taki
142)  system był łatwy w utrzymaniu, żeby nie ulegał szybkim przedawnieniom, jak AnonymOS.
143)  Dodatkowe punkty, jeśli obraz CD zmieści się na małej płycie.</li>
144) 
145) <li>W połączeniu z obrazem LiveCD, powinniśmy popracować nad intuicyjnie bezpiecznym
146)  i dobrze udokumentowanym obrazem USB dla Tor'a i aplikacji obsługujących. Ciężką
147)  częścią tutaj jest zdecydowanie, jakie konfiguracje są bezpieczne, dokumentowanie
148)  tych decyzji i zrobienie czegoś, co łatwo będzie utrzymać w przyszłości.</li>
149) 
150) <li>Nasz preferowany interfejs graficzny dla Tor'aaa, o nazwie
151)  <a href="http://vidalia-project.net/">Vidalia</a>, potrzebuje różnego rodzaju pracy włożonej
152)  w rozwój.</li>
153) 
154) <li>Musimy zacząć budować nasz <a href="<page
155)  documentation>#DesignDoc">projekt odporny na blokowanie</a>. Wchodzi w to
156)  przemyślenie projektu, zmiana wielu różnych elementór Tor'a, zaadaptowanie
157)  <a href="http://vidalia-project.net/">Vidalii</a>, by obsługiwała nowe cechy i
158)  planowanie rozpowszechniania.</li>
159) 
160) <li>Potrzebujemy elastycznego framework'a symulacji do badania ataków potwierdzenia
161)  ruchu od nadawcy do odbiorcy (end-to-end). Wielu ludzi szybko wyciągnęło/napisało doraźne
162)  symulatory odpowiadające ich intuicji, że albo ataki znakomicie się udają, albo
163)  że obrona działa dobrze. Czy możemy zbudować symulator, który jest dobrze udokumentowany
164)  i dość otwarty, by wszyscy wiedzieli, że daje rozsądną odpowiedź? To zacznie wiele nowych
165)  badań. Spójrz na wpis <a href="#Research">poniżej</a> o atakach potwierdzenia po szczegóły
166)  strony badawczej tego zadania &mdash; kto wie, może gdy będzie skończone, pomożesz nam też
167)  napisać dokumentację.</li>
168) 
169) <li>Potrzebujemy badań pomiarowych/porównawczych <a
170)  href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
171)  vs <a href="http://www.privoxy.org/">Privoxy</a>. Czy Polipo jest rzeczywiście znacznie
172)  szybszy, po wliczeniu opóźnienia spowodowanego Tor'em? Czy wyniki są takie same na
173)  Linuksie i Windows? Związan z tym problem: czy Polipo obsługuje więcej stron poprawnie,
174)  niże Privoxy, czy na odwrót? Czy są problemy ze stabilnością na jednej z popularnych
175)  platform, np. Windows?</li>
176) 
177) <li>W związku z powyższym, czy chciałbyś pomóc przenieść <a
178)  href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> tak, by działało
179)  stabilnie i wydajnie pod Windows?</li>
180) 
181) <li>Potrzebujemy framework'a do testów rozproszonych. Mamy pojedyncze testy, ale byłoby
182)  wspaniale mieć skrypt, który uruchamia sieć Tor'a, używa jej przez chwilę i weryfikuje,
183)  że przynajmniej jej część działa.</li>
184) 
185) <li>Pomóżcie Mike'owi Perry z jego biblioteką <a
186)  href="http://tor.eff.org/svn/torflow/">TorFlow</a>
187)  (<a href="http://tor.eff.org/svn/torflow/TODO">TODO</a>):
188)  jest to biblioteka napisana w Pythonie, która używa <a
189)  href="http://tor.eff.org/svn/torctl/doc/howto.txt">protokołu kontroli Tor'a</a>,
190)  by instruować Tor'a do budowania obwodów na wiele różnych sposobów, po czym
191)  mierzy wydajność i próbuje wykryć anomalie.</li>
192)   	 <!--
193) 

194) <li>W tej chwili deskryptory usług ukrytych są przechowywane na zaledwie
195)  kilku serwerach katalogowych. To źle dla prywatności i wydajności. By to
196)  polepszyć, będziemy musieli uczynić deskryptory usług ukrytych jeszcze
197)  mniej prywatnymi, gdyż będziemy musieli je skopiować w wiele miejsc.
198)  Idealnie byłoby całkowicie oddzielić system przechowywania/pobierania od
199)  serwerów katalogowych Tor'a. Pierwszą rzeczą jest to, że musimy zaprojektować
200)  nowy format deskryptora usługi ukrytej tak, by a) dla wygody był w postaci ASCII,
201)  a nie binarnej b) przechowywać listę punktów przedstawiania w postaci zaszyfrowanej,
202)  chyba że zna się adres <tt>.onion</tt>, by katalog nie mógł ich pobrać, c)
203)  pozwolić katalogom na weryfikację znacznika czasu i podpisu na deskryptorze
204)  usługi ukrytej, żeby nie mogły zostać oszukane poprzez podanie im fałszywych.
205)  Po drugie, każdy wiarygodny system przechowywania sprawdzi się, dopóki
206)  umożliwia autentyfikowane aktualizacje, ale według naszych informacji,
207)  żaden zaimplementowany kod typu DHT (z dystrybuowaną tablicą haszowaną) nie
208)  obsługuje autentyfikowanych aktualizacji.</li>

209) -->

210) 

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

212)  poprzez OpenSSL. Ale nikt tego jeszcze nie przetestował. Czy ktoś chce
213)  zdobyć kartę i powiadomić nas, jak to działa?</li>
214) <li>Dokonać analizy bezpieczeństwa Tor'a z <a
215)  href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Sprawdzić, czy
216)  istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
217)  gdy wydamy nową wersję dzięki Tobie!</li>
218) <li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
219)  ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
220)  opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
221)  obsługiwać możemy tylko strumienie TCP. Mamy <a
222)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">listę
223)  powodów, dla których nie przenieśliśmy się na UDP</a>, ale byłoby dobrze
224)  skrócić tę listę. Mamy też proponowaną <a

225)  href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specyfikację dla Tor'a i

226)  UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>
227) <li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
228)  wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
229)  startu.</li>

230) <li>Nie podoba ci się żaden z tych pomysłów? Spójrz na <a
231)  href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">plan rozwoju Tor'a</a> po więcej pomysłów.</li>
232) <li>Nie widzisz tu swojego pomysłu? Prawdopodobnie i tak go potrzebujemy! Skontaktuj się
233)  z nami, by to sprawdzić.</li>

234) </ol>
235) 
236) <a id="Research"></a>
237) <h2><a class="anchor" href="#Research">Badania</a></h2>
238) <ol>
239) <li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
240)  popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"
241)  dla każdej z nich. Potem obserwuj ruch sieciowy klienta Tor'a. Jak
242)  patrzysz na odbierane przez niego dane, szybko zgadujesz, którą
243)  (jeśli w ogóle) on odbiera. Po pierwsze, jak bardzo ten atak jest
244)  efektywny? Potem zacznij badać sposoby obrony: na przykład, moglibyśmy
245)  zmienić rozmiar komórki Tor'a z 512 na 1024 bajty, moglibyśmy użyć
246)  technik dopełniających, jak <a
247)  href="http://freehaven.net/anonbib/#timing-fc2004">odrzucanie obronne (defensive dropping)</a>,
248)  lub moglibyśmy dodać opóźnienia w ruchu. Jak wielki wpływ mają te
249)  rozwiązania i jak wielki wpływ na używalność (używając odpowiedniego
250)  sposobu mierzenia) ma udana obrona w każdym z przypadków?
251) </li>
252) <li>"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack):
253)  obserwując ruch od Alicji do Boba, możemy <a
254)  href="http://freehaven.net/anonbib/#danezis:pet2004">porównać
255)  sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych</a>.

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

257)  trywialny we wszystkich przypadkach. Po pierwsze, czy tak rzeczywiście jest?
258)  Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne, by przeciwnik
259)  upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie wysyłanie wiele daych),
260)  które spowolniłyby atak? Czy jakieś dopełenienia transmisji lub inne sposoby
261)  kształtowania działają lepiej od innych?
262)  </li>
263) <li>"Atak stref trasowania" (routing zones attack): większość literatury
264)  mówi o ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między
265)  węzłem wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie.
266)  W rzeczywisctości, ścieżka przemierza wiele systemów autonomicznych (SA), i <a
267)  href="http://freehaven.net/anonbib/#feamster:wpes2004">często zdarza się, że
268)  ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej</a>.
269)  Niestety, by dokładnie przewidzieć, czy podany czworobok
270)  Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć
271)  całą strefę trasowania internetu i dokonać na niej czasochłonnych operacji.
272)  Czy są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej
273)  samej sieci /8?
274)  </li>

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

282) <li>Tor nie działa za dobrze, gdy serwery mają asymetryczne łącze
283)  (np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
284)  każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
285)  są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji
286)  z powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
287)  wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące,
288)  by sam tym regulować? Można sobie wyobrazić schemat działania, w którym
289)  najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
290)  chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie się.
291)  Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
292)  zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
293)  użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.
294)  </li>
295) <li>Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt
296)  okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
297)  poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
298)  To zdawało się działać nieźle w <a
299)  href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">eksperymencie
300)  przepustowości SSH</a>. Będziemy musieli mierzyć i podkręcać, i być może
301)  wykonać poprawki, jeśli wyniki okażą się dobre.
302)  </li>
303) <li>Aby umożliwić dysydentom w innych krajach używanie Tor'a bez bycia
304)  zablokowanym przez zaporę ogniową w ich kraju, potrzebujemy sposobu na
305)  zdobycie dziesiątek tysięcy serwerów pośredniczących, nie zaledwie kilkuset.

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

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

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

315)  href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">wpis w FAQ</a>
316)  o tym, a potem przeczytaj <a
317)  href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sekcję w anonbib o
318)  przeciwstawianiu się cenzurze</a>.</li>
319) <li>Obwody Tor'a są budowane po jednym elemencie na raz, więc teoretycznie
320)  możemy uczynić, aby część strumieni wychodziła z drugiego węzła, część z

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

322)  które dany serwer może zobaczyć. Ale jeśli chcemy by każdy strumień był
323)  bezpieczny, "najkrótsza" ścieżka powinna, według naszego bieżącego rozumowania,

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

325)  Musimy zbadać ten kompromis wydajność/bezpieczeństwo.
326)  </li>
327) <li>Nie jest trudno wykonać atak DoS na serwery Tor'a lub serwery katalogowe.

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