tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 18524
3) # Translation-Priority: 4-optional

4) # Last-Translator: bogdandr_at_op . pl
5) 
6) #include "head.wmi" TITLE="Projekt NLnet: Tor dla klientów o wolnym łączu" CHARSET="UTF-8"
7) 
8) <div class="main-column">
9) 
10) <!-- PUT CONTENT AFTER THIS TAG -->
11) 
12) <h2>Projekt NLnet: Tor dla klientów o wolnym łączu</h2>
13) <hr />
14) 
15) <p>
16) System Tor jest w tej chwili najbardziej nadający się do używania dla ludzi mających połączenie z
17) Internetem o dużej przepustowości. W czasie uruchamiania klienta Tora pobierany jest
18) ogromny plik z opisem wszystkich serwerów Tora. Ten plik to tak zwany Katalog Tora i
19) umożliwia on klientowi wybieranie spośród serwerów w sieci Tora. Pobieranie całego katalogu
20) jest wymagane w bieżącej wersji protokołu Tora. Ten plik z katalogiem jest zbyt duży dla
21) użytkowników z modemami lub będącymi w sieciach mobilnych jak GPRS, jako że wstępne
22) pobieranie uruchamiane przy każdym logowaniu użytkownika trwa od 10 do 30 minut na
23) wolnym połączeniu. W wyniku tego, Tor nie jest zdatny do używania przez użytkowników modemów
24) lub sieci mobilnych. Jednym z głównych celów Tora jest dostarczanie bezpiecznego anonimowego
25) Internetu użytkownikom w krajach z dyktaturą lub represjami. Takie miejsca często mają wolne
26) połączenia internetowe, przez modem albo niskiej przepustowości łącza do świata zewnętrznego.
27) Poprzez umożliwienie tym użytkownikom używania sieci Tora można uczynić znaczny postęp
28) w kierunku swobodnej komunikacji i informacji w tych krajach.
29) </p>
30) 
31) <p>
32) By Tor nadawał się do użycia na wolnych łączach, potrzebny jest rozwój protokołu Tora,
33) by zmniejszyć rozmiar wstępnego pobierania. Nowa wersja protokołu Tora powinna zmienić sposób,
34) w jaki klient otrzymuje informacje do stworzenia obwodu tak, by pierwsze pobieranie
35) mogło być wykonane na linii modemowej 14.4k w czasie około trzech minut. Celem prac w tym
36) projekcie jest umożliwienie wprowadzenia zmian w protokole
37) i rozprowadzenia ich wśród użytkowników Tora w przeciągu 12 miesięcy. Stworzone oprogramowanie
38) zostanie wydane na 3-punktowej licencji BSD, jak cały kod Tora. Wszystkie części będą
39) całkowicie publiczne.
40) </p>
41) 
42) <p>
43) Ten projekt jest hojnie sponsorowany przez:
44) </p>
45) 
46) <p>
47) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html">
48) <img src="$(IMGROOT)/nlnet-160x60.png" alt="Fundacja NLnet" /></a>
49) </p>
50) 
51) <table width="100%" border="0" cellspacing="0" cellpadding="3">
52) <thead>
53) <tr>
54) <th><big>Projekt</big></th>
55) <th><big>Czas zakończenia</big></th>
56) </tr>
57) </thead>
58) 
59) <tr bgcolor="#e5e5e5">
60)   <td>
61)     <b>Część A:</b> Projektowanie i sprawdzanie zmian protokołu<br />
62)     <small><em>W tej części zawarty jest szczegółowy projekt i oparte na symulacjach
63)     sprawdzenie niezbędnych zmian i modyfikacji projektu bieżącego protokołu Tora.
64)     Zmiany w protokole będą raczej istotne, więc wymaga to dokładnego sprawdzenia wszystkich
65)     możliwych skutków dla bezpieczeństwa i anonimowości sieci Tora. Dla tej fazy projektowania
66)     i sprawdzania przewidziany jest dwumiesięczny okres, zakończony wyczerpującą recenzją.
67)     Celem tej części jest m.in. zdefiniowanie wydajności do osiągnięcia w fazie implementacji.
68)     Celem projektowym jest zmniejszenie pobieranego rozmiaru Katalogu Tora do około
69)     300 kilobajtów, co umożliwiłoby użytkownikowi łącza 14.4 kbps pobranie go w ciągu około
70)     trzech minut. Mogą być odstępstwa od tego celu, jeśli będą wymagane do zachowania
71)     bezpieczeństwa i anonimowości, ale to jest obszar, w który należy celować.

72)     </em></small>

73)   </td>
74)   <td>
75)     15 Lipca 2008
76)   </td>
77) </tr>
78) 
79) <tr>
80)   <td>
81)     <b>Część B:</b>Implementacja zmiany protokołu<br />
82)     <small><em>Po projekcie, sprawdzeniu i przeglądzie, zmiany muszą zostać
83)     zaimplementowane i zintegrowane z bieżącym kodem Tora. Sama implementacja
84)     niezbędnych zmian zajmie około trzech miesięcy.
85)     </em></small>
86)   </td>
87)   <td>
88)     15 Października 2008
89)   </td>
90) </tr>
91) 
92) <tr bgcolor="#e5e5e5">
93)   <td>
94)     <b>Część C:</b>Testowanie<br />
95)     <small><em>Zmiana jest bardzo ważna dla bezpieczeństwa i anonimowości sieci Tora,
96)     wymaga więc dogłębnego testowania i szukania błędów w warunkach laboratoryjnych
97)     i rzeczywistych. Okres trzech miesięcy jest przewidziany na testowanie i usuwanie błędów,
98)     podczas którego odpowiedzialny za to programista poświęci 1/3 swojego czasu na testowanie.
99)     Część fazy testowania będzie okresem publicznej wersji beta.
100)     </em></small>
101)   </td>
102)   <td>

103)     15 Stycznia 2008

104)   </td>
105) </tr>
106) 
107) <tr>
108)   <td>
109)     <b>Część D:</b>Wypuszczenie<br />
110)     <small><em>Wypuszczenie zmian do sieci serwerów Tora będzie zsynchronizowane
111)     z regularnymi wydaniami Tora. Jako że regularne wydania zależą od wielu
112)     czynników zewnętrznych, jak zakończenie innych projektów, które powinny wyjść
113)     w tym samym wydaniu, właściwy czas wydania i instalacji u większości operatorów
114)     serwerów Tora może być różny. Z doświadczenia wiemy, że można oczekiwać okresu
115)     od trzech do czterech miesięcy. Wydanie będzie przeprowadzone jako część regularnego
116)     procesu wydawania Tora, który jest działaniem wykonywanym przez wolontariuszy i
117)     personel wynagradzany z innych grantów przeznaczonych na projekt Tor.
118)     </em></small>
119)   </td>
120)   <td>

121)     15 Kwietnia 2009

122)   </td>
123) </tr>
124) </table>
125) 
126) <br />
127) 
128) <a id="Reports"></a>
129) <h2><a class="anchor" href="#Reports">Miesięczne raporty o bieżącym stanie</a></h2>
130) <p>
131) Łącznie będzie osiem miesięcznych raportów zaczynających się od pierwszej części 15. czerwca

132) 2008 i kończących się na ukończeniu implementacji i testów 15. stycznia 2009.

133) </p>
134) 
135) <table width="100%" border="0" cellspacing="0" cellpadding="3">
136) <thead>
137) <tr>
138) <th><big>Miesiąc,</big></th>
139) <th><big>Raport o stanie</big></th>
140) </tr>
141) </thead>
142) 
143) <tr bgcolor="#e5e5e5">
144)   <td>
145)     <a id="Jun08"></a>
146)     <a class="anchor" href="#Jun08">Czerwiec 08</a>
147)   </td>
148)   <td>
149)     <small><em>Przeprowadziliśmy trochę wstępnych badan uruchamiania się klienta Tora.
150)     Wyniki nie są zbyt zadziwiające: klient pobiera około 10kB certyfikatów, jeden
151)     konsensus rozmiaru 140kB (teraz 90kB, zobacz kolejny paragraf) i około 1,5MB

152)     deskryptorów serwerów (po pobraniu połowy zaczyna budować obwody).</em></small>

153)     <br />
154)     <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Propozycja
155)     138</a> zmniejsza rozmiar konsensusu od 30% do 40% i została już zaimplementowana
156)     i połączona ze specyfikacją. Implementacja jest częścią drzewa 0.2.1.x-alpha
157)     i odniesie skutek, gdy ponad dwie trzecie serwerów katalogowych (czyli 5 z 6)

158)     zainstalują nową wersję.</em></small>

159)     <br />
160)     <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycja
161)     140</a> nie jest bezpośrednio związana ze zmniejszeniem rozmiaru wstępnego pobierania,
162)     zamiast tego próbuje zmniejszyć kolejne pobierania dokumentów konsensusu
163)     i została <a href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">wysłana na
164)     or-dev</a>. Najpierw jest jeszcze kilka pytań wymagających odpowiedzi od innych
165)     deweloperów Tora, ale poza tym propozycja wydaje się być dobra i może być

166)     implementowana.</em></small>

167)     <br />
168)     <small><em>Wielką Sprawą jest sprawienie, by klienci nie pobierali całych 1,5MB
169)     deskryptorów serwerów. <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycja
170)     141</a> została <a
171)     href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">wysłana na
172)     or-dev</a>. Składa się w chwili bieżącej z 3 podstawowych rzeczy: przenieść
173)     informacje o równowadze wykorzystania łącza do konsensusu (nie powinno być trudne),
174)     zaimplementować coś, co pozwoli klientom Tora pobieranie deskryptorów na żądanie
175)     od routerów na ich obwodzie w czasie jesgo budowania (opisane w szkicu), zabrać się
176)     za wybór punktu wyjścia. Ciągle tworzymy pomysły odnośnie ostatniej części; niektóre

177)     możliwości są wspomniane w szkicu.</em></small>

178)   </td>
179) </tr>
180) 
181) <tr>
182)   <td>

183)     <a id="Jul08"></a>
184) 	<a class="anchor" href="#Jul08">Lipiec 08</a>

185)   </td>
186)   <td>

187)   <small><em>Praca nad <a
188)  href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Propozycją
189)  141</a> trwa: Są dwa podstawowe pomysły na to, jak przenieść informacje o
190)  równowadze wykorzystania łącza do konsensusu: jeden pomysł mówi, że centra
191)  katalogowe generują wagi, których klienci powinni używać i umieszczają to w
192)  konsensusie, drugi jest taki, by po prostu umieścić w nim informacje o łączu
193)  z deskryptora serwera. Ta druga opcja jest prawdopodobnie lepsza, gdy weźmie się
194)  też pod uwagę <a
195)  href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Propozycję
196)  140</a>, gdyż unika to dużej ilości często zmieniających się liczb w konsensusie.</em></small>
197)  <br />
198)  <small><em>Odnośnie polityk wyjścia, <a
199)  href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">list
200)  na liście mailingowej or-dev</a> sugeruje dodanie hasza identyfikującego politykę wyjścia
201)  węzła do dokumentu konsensusu. Dodanie kolejnych 160 bitów o wysokiej entropii na każdy
202)  węzeł może budzić niepokój, ale naszym zdaniem wiele polityk wyjścia jest takich samych,
203)  więc dokument konsensusu powinien dobrze się kompresować. Pomiary trwają.</em></small>

204)   </td>
205) </tr>
206) 
207) <tr bgcolor="#e5e5e5">
208)   <td>

209)   <a id="Aug08"></a>
210)   <a class="anchor" href="#Aug08">Sierpień 08</a>

211)   </td>
212)   <td>

213)     <small><em>Dokumenty głosowania serwerów katalogowych i ich algorytm tworzenia
214)     dokumentów konsensusu zostały zmienione, by uwzględniać informacje o przepustowości
215)     łącza i podsumowania polityk, według Propozycji 141. Gdy już pięć z sześciu
216)     działających centrów katalogowych zaktualizują się do wersji SVN co najmniej 16554,
217)     dokumenty konsensusu zaczną zawierać te informacje.</em></small>

218)   </td>
219) </tr>
220) 
221) <tr>
222)   <td>

223)    <a id="Sep08"></a>
224)    <a class="anchor" href="#Sep08">Wrzesień 08</a>

225)   </td>
226)   <td>

227)    <small><em>We wrześniu nie było żadnych aktualizacji.</em></small>

228)   </td>
229) </tr>
230) 
231) <tr bgcolor="#e5e5e5">
232)   <td>

233)    <a id="Oct08"></a>
234)    <a class="anchor" href="#Oct08">Październik 08</a>

235)   </td>
236)   <td>

237)    <p><small><em>Nie osiągnęliśmy naszego kroku milowego "skończenia implementacji"

238)     w tym miesiącu, gdyż deweloper prowadzący ten projekt ma zbyt dużo zajęć.
239)     Dobrą wiadomością jest to, że zrobiliśmy całkiem sporą część implementacji,
240)     a było to kilka miesięcy temu (od etapu sierpniowego), więc zdążyliśmy już ją
241)     nieźle przetestować. Pozostałe kroki implementacji to nauczenie przekaźników,
242)     jak otrzymywać żądania pobierania deskryptorów przekaźników z wewnątrz obwodów
243)     (prawdopodobnie potrzebujemy nowego typu komórki specjalnie do tych celów,
244)     abyśmy mogli wyciąć drogę naokoło), a potem nauczyć klientów, by robiły to,
245)     gdy używany przez nich przekaźnik używa dostatecznie nowej wersji. Te dwa
246)     kroki są szczegółowo opisane w
247)     <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt"

248)     >Sekcji 3.2 propozycji 141</a></em></small></p>

249) 

250)     <p><small><em>Nasz nowy plan czasowy to zrobienie tych dwóch rzeczy do połowy listopada,

251)     a jeśli to zacznie wyglądać na coraz mniej prawdopodobne, zrobimy większe zmiany

252)     planu i być może też projektu.</em></small></p>

253) 

254)     <p><small><em>Jest kilka innych komponentów, którymi chcielibyśmy się zająć potem --

255)     jeden, o którym dużo ostatni myśleliśmy, to pobieranie różnic ostatnich
256)     konsensusów:
257)     <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt"
258)     >140-consensus-diffs.txt</a>.
259)     Po pierwsze, to mogłoby zaoszczędzić przepustowość łącza, co zawsze jest dobre,
260)     gdy pomnożyć je przez liczbę klientów, ale to też oznacza, że możemy użyć
261)     tej zaoszczędzonej przepustowości do pobierania różnic częściej niż bieżące
262)     "co 3-4 godziny". Jeśli klienci poznają bardziej aktualne informacje katalogowe,
263)     mogą budować szybsze ścieżki, gdyż mają lepsze dane o przepustowości każdego
264)     przekaźnika (co wiąże się z projektem NLnet), ale głównym nowym pomysłem jest
265)     to, że lepiej korzystamy z przelotnych przekaźników: w chwili obecnej przekaźnik
266)     musi działać przez 3-4 godziny, zanim zobaczy jakichkolwiek użytkowników, a to
267)     wyklucza wielu wolontariuszy chcących prowadzić przekaźniki tylko przez kilka

268)     godzin na raz.</em></small></p>
269)     <p><small><em>Kolejnym krokiem jest skończenie implementacji propozycji 141, byśmy mogli
270)     przedstawić ją użytkownikom do testów. Mamy nadzieję, że wkrótce!</em></small></p>

271)   </td>
272) </tr>
273) 
274) <tr>
275)   <td>

276)    <a id="Nov08"></a>
277)    <a class="anchor" href="#Nov08">Listopad 08</a>

278)   </td>
279)   <td>

280)    <p><small><em>Zdaje się, że pierwszy plan, który mieliśmy na ostatnią fazę

281)    rozwoju jest zarówno a) znacznie trudniejszy, niż myśleliśmy i b) przypuszczalnie

282)    przesadny w stosunku do tego, czego potrzebujemy.</em></small></p>

283) 

284)   	 <p><small><em> Roger wznowił dyskusję projektową na or-dev:
285)   	 <a href="http://archives.seul.org/or/dev/Nov-2008/threads.html">http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.
286)   	 </em></small></p>

287) 

288)   	 <p><small><em>Myślę, że teraz mamy lepsze rozeznanie w możliwościach i ich kosztach:
289)   	 <a href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html">http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.
290)   	 </em></small></p>

291) 

292)   	 <p><small><em>Nick został zasypany innymi projektami deweloperskimi (miejmy nadzieję, że

293)   	 zacznie kończenie ich w tym miesiącu), a ja chcę znać jego zdanie na temat

294)   	 kontynuacji; mam nadzieję, że wybierzemy jedno z prostszych podejść.</em></small></p>

295) 

296)   	 <p><small><em>Z drugiej strony, te najprostsze rozwiązania dają też mniejszą skalowalność.

297)   	 Ale moim zdaniem będą dobrymi rozwiązaniami tymczasowymi na pewien czas

298)   	 -- a gdy nadejdzie ta chwila, kto wie, co jeszcze zostanie zmienione.</em></small></p>

299)   </td>
300) </tr>
301) 
302) <tr bgcolor="#e5e5e5">
303)   <td>

304)     <a id="Jan09"></a>
305)     <a class="anchor" href="#Jan09">Styczeń 09</a>

306)     Grudzień 08
307)   </td>
308)   <td>

309)    <p><small><em>

310)    Napisałem bardziej szczegółową wersję naszego nowego pomysłu projektowego jako <a
311)     href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdescriptors.txt"
312)     >propozycję #158</a>, a dyskusja zaczęła się od <a
313)    href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html"

314)    >http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.</em></small></p>

315) 

316)    <p><small><em>

317)    Myślę, że to w końcu jest to! (No, jak już skończę zajmować się komentarzami.)

318)    </em></small></p>

319) 

320)    <p><small><em>

321)    Jednym z głównych powodów, dla których ten projekt nie jest realizowany zgodnie z
322)    planem jest to, że główny wniosek z <a href="<page projects/hidserv>">projektu
323)    Karstena z NLnet o wydajności usług ukrytych</a> mówi, iż to rozszerzenie
324)    obwodu jest głównym powodem spadku wydajności. Ale ten projekt zaproponował dodanie
325)    większej liczby przejść i złożoności właśnie do tego punktu. Tak więc, musimy stworzyć
326)    lepszy plan, by dotrzeć do pierwotnego celu bez dodatkowego pogarszania wydajności.

327)    </em></small></p>

328) 

329)    <p><small><em>

330)    Przeglądaliśmy propozycję projektową w ciagu ostatnich kilku tygodni i moim zdaniem
331)    wkrótce będziemy gotowi, by zacząć implementację. Skoro jednak mamy kilka zadań
332)    deweloperskich, które już lądują w lutym, jest prawdopodobne, że tą implementacją

333)    nie zajmiemy się przed końcem lutego lub w marcu. Ale tym razem na pewno!</em></small></p>