[or-cvs] r14112: Mainetance/polish translation update. (website/trunk/pl)

bogdro at seul.org bogdro at seul.org
Tue Mar 18 20:05:28 UTC 2008 

Author: bogdro
Date: 2008-03-18 16:05:28 -0400 (Tue, 18 Mar 2008)
New Revision: 14112

Modified:
   website/trunk/pl/gsoc.wml
   website/trunk/pl/volunteer.wml
Log:
Mainetance/polish translation update.

Modified: website/trunk/pl/gsoc.wml
===================================================================
--- website/trunk/pl/gsoc.wml	2008-03-18 19:13:34 UTC (rev 14111)
+++ website/trunk/pl/gsoc.wml	2008-03-18 20:05:28 UTC (rev 14112)
@@ -1,5 +1,5 @@
 ## translation metadata
-# Based-On-Revision: 13984
+# Based-On-Revision: 14106
 # Last-Translator: bogdandr_at_op . pl
 
 #include "head.wmi" TITLE="Tor: Google Summer of Code 2008" CHARSET="UTF-8"
@@ -19,15 +19,14 @@
 
 <p>
 Google ogłosił, że będzie też <a
-href="http://code.google.com/soc/">Google Summer of Code 2008</a>,
-a my się zgłosiliśmy. Lista zaakceptowanych organizacji prowadzących
-będzie podana przez Google 17. marca. W międzyczasie, ta strona zawiera pewne
-informacje dla zainteresowanych studentów w nadziei, że nasze zgłoszenie
-będzie przyjęte.
+href="http://code.google.com/soc/">Google Summer of Code 2008</a> ...
+i zostaliśmy <a href="http://code.google.com/soc/2008/eff/about.html">przyjęci!</a>
+Ta strona zawiera trochę informacji dla zainteresowanych studentów.
 </p>
 
 <p>
-Ostateczny termin zgłoszenia mija <b>31 Marca 2008</b> o godzinie 17 czasu Pacific.
+Ostateczny <a href="http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline">termin</a>
+zgłoszenia mija <b>31 Marca 2008</b> o godzinie 17 czasu Pacific.
 </p>
 
 <p>
@@ -35,9 +34,12 @@
 zainteresowanych deweloperów na kanale IRC i listach mailingowych i chętnie
 będziemy z Tobą współpracować, myśleć nad projektowaniem itd., ale musisz
 sam zarządzać swoim czasem i już być zaznajomionym ze sposobami rozwijania
-Wolnego Oprogramowania w Internecie. Poza nadzieją, że będzie wykonana praca przy
+Wolnego Oprogramowania w Internecie.
+</p>
+
+<p>Poza nadzieją, że będzie wykonana praca przy
 Torze i związanych z nim aplikacjami, Google i Tor są najbardziej zainteresowani
-w pozyskiwaniu studentów dla projektu tak, by po lecie też byli z nim związani.
+w pozyskiwaniu studentów do rozwijania Tora tak, by po lecie też byli z nim związani.
 W związku z tym, dajemy priorytet studentom, którzy pokazali swoje
 trwające zainteresowanie i odpowiadali na wiadomości.
 </p>

Modified: website/trunk/pl/volunteer.wml
===================================================================
--- website/trunk/pl/volunteer.wml	2008-03-18 19:13:34 UTC (rev 14111)
+++ website/trunk/pl/volunteer.wml	2008-03-18 20:05:28 UTC (rev 14112)
@@ -1,5 +1,5 @@
 ## translation metadata
-# Based-On-Revision: 14040
+# Based-On-Revision: 14089
 # Last-Translator: bogdandr_at_op . pl
 
 #include "head.wmi" TITLE="Tor: Wolontariusze" CHARSET="UTF-8"
@@ -93,19 +93,19 @@
 <h2><a class="anchor" href="#Projects">Dobre Projekty Programistyczne</a></h2>
 
 <p>
-Część z poniższych projektów może być dobrymi pomysłami na <a href="<page
-gsoc>">Google Summer of Code 2008</a>. Oznaczyliśmy każdy z nich informacją,
+Część z poniższych projektów może być dobrymi pomysłami na <a
+href="<page gsoc>">Google Summer of Code 2008</a>. Oznaczyliśmy każdy z nich informacją,
 jak bardzo by się przydał do całości projektu Tor (priorytet), ile według nas
 potrzeba na niego pracy (poziom wysiłku), z jaką wiedzą powinno się zaczynać
-(poziom umiejętności), i który z naszych <a href="<page
-people>#Core">głównych deweloperów</a> byłby dobrym prowadzącym.
+(poziom umiejętności), i który z naszych <a
+href="<page people>#Core">głównych deweloperów</a> byłby dobrym prowadzącym.
 </p>
 
 
 <ol>
 
 <li>
-<b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>
+<b>Ulepszenie Skanera Wyjściowego Tora (Tor Exit Scanner)</b>
 <br />
 Priorytet: <i>Wysoki</i>
 <br />
@@ -113,66 +113,157 @@
 <br />
 Poziom umiejętności: <i>Wysoki</i>
 <br />
-Prawdopodobni prowadzący: <i>Matt, Jacob</i>
+Prawdopodobni prowadzący: <i>Mike</i>
 <br />
-Potrzebujemy dobrego frameworka automatycznej aktualizacji.
-Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub
-niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe
-okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.
-Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i
-zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,
-chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy
-Vidalia.
+Skaner węzłów wyjściowych Tora, 'SoaT', część <a
+href="https://www.torproject.org/svn/torflow/">projektu Torflow</a>, jest
+w chwili obecnej napisany w chwiejnym Perlu i opiera się na sumach
+kontrolnych MD5 dla całych dokumentów w celu stwierdzenia, czy
+węzły wyjściowe zmieniają zawartość. Problem z tym składa się z 3 części:
+1) Perl jest do bani 2) skaner nie umie weryfikować stron dynamicznych, a
+atakujący mogą skupić się na umieszczaniu złośliwego oprogramowania
+tylko na stronach dynamicznych 3) strony zmieniają się raz na jakiś czas
+(lub opierając się na GeoIP) i zaczynają generować fałszywe pozytywne wyniki.
 <br />
-By wykonać ten projekt, student będzie musiał najpierw poznać istniejące
-mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,
-cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże
-się przydatny, student zaprojektuje własny framework aktualizacyjny,
-udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat
-jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)
-i przetestuje.
+Najlepiej byłoby reimplementować soat.pl w jakimś normalnym języku z
+dobrą biblioteką do parsowania HTML (dobry byłby Python, jako że reszta Torflow
+jest w nim napisana, lecz nie jest to wymagane) i wyliczać sygnatury stron
+tylko dla znaczników i zawartości, która może stać się celem ataku (znaczniki
+skryptów, linki do obiektów, obrazki). Program powinien też działać dobrze
+w obliczu zewnętrznych w stosunku do Tora zmian zawartości, a docelowo nawet
+z lokalizowaną zawartością poprzez GeoIP.
 <br />
-Student podejmujący się tego projektu powinien dobrze znać C++.
-Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.
-Student powinien mieć też podstawowe pojęcie o powszechnych praktykach
-bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w
-pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie
-zrobienie dokumentacji projektu dla innych do przejrzenia i przedyskutowania
-ze studentem przed implementacją.
+Skaner ten prawdopodobnie byłby uruchamiany przez serwery katalogowe i
+zgłaszał swoje wyniki na port kontroli poprzez zmienną konfiguracji AuthDirBadExit.
+<br />
 </li>
 
 <li>
-<b>Poprawiona i bardziej użyteczna mapa sieci</b>
+<b>Ulepszenie Skanera Węzłów Tora (Tor Node Scanner)</b>
 <br />
-Priorytet: <i>Średni</i>
+Priorytet: <i>Wysoki</i>
 <br />
-Poziom wysiłku: <i>Średni</i>
+Poziom wysiłku: <i>Średni do Wysokiego</i>
 <br />
 Poziom umiejętności: <i>Średni do Wysokiego</i>
 <br />
-Prawdopodobni prowadzący: <i>Matt</i>
+Prawdopodobni prowadzący: <i>Mike</i>
 <br />
-Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi
-przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje
-ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.
-Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.
-Wolelibyśmy użyć widgetu Marble z KDE, który daje mapę lepszej jakości i
-umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na
-klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe
-informacje. Moglibyśmy też rozważyć dodanie możliwości klikania przez
-użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
-stwierdzenia "chcę, by moje połączenia do foo.com wychodziły stąd."
+Podobnie do skanera wyjściowego (lub może nawet w czasie jego działania),
+można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które
+źle działają dla pewnej części swoich obwodów nie powinny być używane do
+statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną
+przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo,
+węzły wykazujące bardzo niską średnią przepustowość strumienia,
+lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne.
+Większość zbierania statystyk już jest zrobiona, dane te muszą tylko
+zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym,
+by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci
+się o tym dowiedzą.
 <br />
-Podczas tego projektu, student najpierw zapozna się z Vidalią i API widgetu
-Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował
-do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we
-własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.
+Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego
+przez węzeł. Do <a
+href="https://www.torproject.org/svn/torctl/doc/howto.txt">Protokołu Kontroli
+Tora</a> można dodać zdarzenia mówiące, czy udaje się stworzyć obwód
+przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące
+zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty
+na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też
+informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych,
+ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby
+zostać stworzony.
+</li>
+
+<li>
+<b>Pomóż śledzić ogólny status Sieci Tora</b>
 <br />
-Student podejmujący się tego projektu powinien dobrze znać C++.
-Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
+Priorytet: <i>Wysoki</i>
+<br />
+Poziom wysiłku: <i>Średni</i>
+<br />
+Poziom umiejętności: <i>Średni</i>
+<br />
+Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>
+<br />
+Byłoby wspaniale uruchomić automatyczny system śledzenia stanu sieci w czasie,
+wyświetlanie wykresów itp. Częścią tego projektu byłoby wynalezienie lepszych
+miary do oceny stanu i wzrostu sieci. Czy wzrasta średni czas działania sieci?
+Ile węzłów kwalifikuje się do bycia Strażnikami w tym miesiącu w porównaniu z
+ubiegłym? Jaka jest rotacja w sensie pojawiania się nowych węzłów i znikania
+starych? Okresowo ludzie gromadzą krótkie migawki stanu, ale to robi się naprawdę
+interesujące dopiero, gdy zaczynamy śledzić te dane w czasie.
+<br />
+Dane powinny być zbierane z powyższego narzędzia "Skaner Węzłów Tora", z
+deskryptorów serwerów, które są publikowane przez każdy przekaźnik i z innych
+źródeł. Wyniki w czasie mogłyby być zintegrowane z jedną ze stron opisujących
+<a href="https://torstatus.blutmagie.de/">Stan Tora</a> lub być trzymane osobno.
+Skoro mówimy o stronach stanu Tora, spójrzcie na
+<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">listę życzeń
+stanu Tora</a> napisaną przez Rogera.
 </li>
 
 <li>
+<b>Polepszenia w wybieraniu ścieżki przez Tora</b>
+<br />
+Priorytet: <i>Wysoki</i>
+<br />
+Poziom wysiłku: <i>Niski do Średniego</i>
+<br />
+Poziom umiejętności: <i>Wysoki</i>
+<br />
+Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>
+<br />
+Można dokonać pewnych prostych ulepszeń do algorytmu wyboru ścieżki przez Tora,
+by znacznie zwiększyć jego szybkość. Na przykład, kilka (nieoficjalnych)  <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Zaleceń
+Wydajności Tora</a> na wiki to zwiększenie liczby strażników i zmniejszenie
+CircuitBuildTimeout. Najlepiej by było, gdyby klient sam uczył się tych
+wartości poprzez zbieranie statystyk dotyczących czasu budowania obwodów
+(lub używać wartości uzyskanych z Torflow) i ustawiał czasy dość nisko, by
+wysoki procent (75%, 90%, 1-stddev?) obwodów uległ stworzeniu, lecz by
+strasznie wolne węzły były unikane. Wymagałoby to pewnego zbierania
+statystyk i podstawowych badań oraz pewnych zmian w kodzie Tora dotyczącym
+wyboru ścieżki.
+<br />
+Dodatkowo, by zwiększyć bezpieczeństwo ścieżek, można byłoby dołączyć niektóre
+elementy z <a
+href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt"
+>Propozycji Ścieżek 2-Skokowych</a> (jako że będzie to i tak dotyczyć tego samego kodu),
+bez uwagi na to, czy ta Propozycja będzie przyjęta. W szczególności, klienci powinni
+unikać strażników, którzy zdają się mieć problem ze zbudowaniem znacznej części
+swoich obwodów, a klienci bez firewalli powinni pokazywać ostrzeżenia, że udało im
+się połączyć tylko z ograniczoną liczbą węzłów-strażników. Przeczytaj także
+<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">tę wiadomość
+na or-dev</a>.
+</li>
+
+<li>
+<b>Wiki do tłumaczenia</b>
+<br />
+Priorytet: <i>Wysoki</i>
+<br />
+Poziom wysiłku: <i>Średni</i>
+<br />
+Poziom umiejętności: <i>Średni</i>
+<br />
+Prawdopodobni prowadzący: <i>Jacob</i>
+<br />
+Potrzebujemy sposobu na edycję i tłumaczenie sekcji strony &mdash;
+z możliwością, że stworzy to łatę na oficjalne drzewo svn. Bieżący
+"koszt" publikacji zmian na stronie jest dość wysoki nawet dla
+anglojęzycznych użytkowników. Muszą oni pobierać pliki z szablonami,
+tłumaczyć je i przysyłać tłumaczenia nam. Jeśli trzeba zmienić pojedyncze słowo
+lub coś małego, strona może nigdy nie zostać poprawiona lub przetłumaczona.
+Dobrze byłoby mieć wiki nastawione specjalnie na tłumaczenia, które jakoś
+śledziłoby nowe (angielskie) wersje i pokazywałoby, kiedy potrzebne będzie
+świeże tłumaczenie, jak nasza aktualna <a href="<page translation-status>"
+>strona ze stanem tłumaczenia</a>. Wydaje się to zadaniem głównie dla integratorów wiki
+lub twórców oprogramowania wiki. Z pewnością osoba powinna interesować się
+językami i tłumaczeniem. Powinna być choć minimalnie zaznajomiona z tym,
+co to jest Tor, ale nie musiałaby stykać się z samym oprogramowaniem,
+tylko z dokumentacją na stronie.
+</li>
+
+<li>
 <b>Lepsze wsparcie i pakowanie dla Debiana</b>
 <br />
 Priorytet: <i>Wysoki</i>
@@ -222,6 +313,109 @@
 </li>
 
 <li>
+<b>Polepszanie naszych zdolności opierania się cenzurze</b>
+<br />
+Priorytet: <i>Wysoki</i>
+<br />
+Poziom wysiłku: <i>Wysoki</i>
+<br />
+Poziom umiejętności: <i>Średni do Wysokiego</i>
+<br />
+Prawdopodobni prowadzący: <i>Roger, inni</i>
+<br />
+Wersje 0.2.0.x Tora robią <a
+href="<svnsandbox>doc/design-paper/blocking.html">znaczne postępy</a> w opieraniu
+się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w
+niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą
+nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje
+<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">propozycja
+zajęcia się tą sprawą</a> i umożliwienia klientom łączenie się z danym Torem
+na wielu adresach i portach, ale wymaga to więcej pracy. Kolejny projekt
+przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie.
+W chwili obecnej ktokolwiek może zidentyfikować
+<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">mostki Tora</a>
+po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając,
+czy odpowiadają. By rozwiązać ten problem, mostki mogłyby
+<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">udawać serwery
+internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów,
+a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny
+dla mostka.
+<br />
+Ten projekt zawiera wiele badań i projektowania. Jednym z większych wyzwać
+będzie zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą
+się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie
+odporności na cenzurę z użytecznością i siłą.
+</li>
+
+<li>
+<b>Framework automatycznej aktualizacji programów Tor/Polipo/Vidalia.</b>
+<br />
+Priorytet: <i>Wysoki</i>
+<br />
+Poziom wysiłku: <i>Wysoki</i>
+<br />
+Poziom umiejętności: <i>Wysoki</i>
+<br />
+Prawdopodobni prowadzący: <i>Matt, Jacob</i>
+<br />
+Potrzebujemy dobrego frameworka automatycznej aktualizacji.
+Vidalia już ma możliwość informowania, że użytkownik używa przestarzałej lub
+niezalecanej wersji Tora. W chwili obecnej Vidalia po prostu pokazuje małe
+okienko, które informuje użytkownika, że powinien dokonać ręcznej aktualizacji.
+Celem tego projektu jest rozszerzenie Vidalii o możliwość pobrania i
+zaktualizowania nowej wersji Tora za użytkownika. Jeśli czas pozwoli,
+chcielibyśmy móc aktualizować też inne aplikacje z paczek, jak Polipo czy
+Vidalia.
+<br />
+By wykonać ten projekt, student będzie musiał najpierw poznać istniejące
+mechanizmy aktualizacji (np. Sparkle na OS X), by zbadać ich mocne i słabe punkty,
+cechy bezpieczeństwa i możliwości zintegrowania z Vidalią. Jeśli żaden nie okaże
+się przydatny, student zaprojektuje własny framework aktualizacyjny,
+udokumentuje projekt i przedyskutuje go z innymi deweloperami na temat
+jego bezpieczeństwa. Potem zaimplementuje go (lub zintegruje istniejący)
+i przetestuje.
+<br />
+Student podejmujący się tego projektu powinien dobrze znać C++.
+Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.
+Student powinien mieć też podstawowe pojęcie o powszechnych praktykach
+bezpieczeństwa, jak weryfikacja podpisu paczki. Dobre zdolności w
+pisaniu też są ważne w tym projekcie, gdyż ważnym krokiem będzie
+zrobienie dokumentacji projektu dla innych do przejrzenia i przedyskutowania
+ze studentem przed implementacją.
+</li>
+
+<li>
+<b>Poprawiona i bardziej użyteczna mapa sieci</b>
+<br />
+Priorytet: <i>Średni</i>
+<br />
+Poziom wysiłku: <i>Średni</i>
+<br />
+Poziom umiejętności: <i>Średni do Wysokiego</i>
+<br />
+Prawdopodobni prowadzący: <i>Matt</i>
+<br />
+Jedną z istniejących cech Vidalii jest mapa sieci, która pokazuje użytkownikowi
+przybliżone lokalizacje geograficzne przekaźników sieci Tora i rysuje
+ścieżki, przez które przechodzi ruch użytkownika w sieci Tora.
+Mapa jest w tej chwili niezbyt interaktywna i ma raczej słabą grafikę.
+Wolelibyśmy użyć widgetu Marble z KDE, który daje mapę lepszej jakości i
+umożliwia lepszą interaktywność, jak na przykład pozwalanie użytkownikowi na
+klikanie w poszczególne przekaźniki lub obwody, by wyświetlić dodatkowe
+informacje. Moglibyśmy też rozważyć dodanie możliwości klikania przez
+użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
+stwierdzenia "chcę, by moje połączenia do foo.com wychodziły stąd."
+<br />
+Podczas tego projektu, student najpierw zapozna się z Vidalią i API widgetu
+Marble. Potem zintegruje widget z Vidalią i zmieni go, by bardziej pasował
+do naszych zastosowań, np. można było klikać w obwody, zapisywać mapy we
+własnym katalogu Vidalii i dostosować część okien dialogowych widgetu.
+<br />
+Student podejmujący się tego projektu powinien dobrze znać C++.
+Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
+</li>
+
+<li>
 <b>Interfejs zdarzeń stanu kontrolera Tora</b>
 <br />
 Priorytet: <i>Średni</i>
@@ -265,33 +459,6 @@
 </li>
 
 <li>
-<b>Wiki do tłumaczenia</b>
-<br />
-Priorytet: <i>Wysoki</i>
-<br />
-Poziom wysiłku: <i>Średni</i>
-<br />
-Poziom umiejętności: <i>Średni</i>
-<br />
-Prawdopodobni prowadzący: <i>Jacob</i>
-<br />
-Potrzebujemy sposobu na edycję i tłumaczenie sekcji strony &mdash;
-z możliwością, że stworzy to łatę na oficjalne drzewo svn. Bieżący
-"koszt" publikacji zmian na stronie jest dość wysoki nawet dla
-anglojęzycznych użytkowników. Muszą oni pobierać pliki z szablonami,
-tłumaczyć je i przysyłać tłumaczenia nam. Jeśli trzeba zmienić pojedyncze słowo
-lub coś małego, strona może nigdy nie zostać poprawiona lub przetłumaczona.
-Dobrze byłoby mieć wiki nastawione specjalnie na tłumaczenia, które jakoś
-śledziłoby nowe (angielskie) wersje i pokazywałoby, kiedy potrzebne będzie
-świeże tłumaczenie, jak nasza aktualna <a href="<page translation-status>"
->strona ze stanem tłumaczenia</a>. Wydaje się to zadaniem głównie dla integratorów wiki
-lub twórców oprogramowania wiki. Z pewnością osoba powinna interesować się
-językami i tłumaczeniem. Powinna być choć minimalnie zaznajomiona z tym,
-co to jest Tor, ale nie musiałaby stykać się z samym oprogramowaniem,
-tylko z dokumentacją na stronie.
-</li>
-
-<li>
 <b>Ulepszenia naszego aktywnego testera konfiguracji przeglądarek</b> -
 <a href="https://check.torproject.org">https://check.torproject.org</a>
 <br />
@@ -380,41 +547,6 @@
 </li>
 
 <li>
-<b>Polepszanie naszych zdolności opierania się cenzurze</b>
-<br />
-Priorytet: <i>Wysoki</i>
-<br />
-Poziom wysiłku: <i>Wysoki</i>
-<br />
-Poziom umiejętności: <i>Średni do Wysokiego</i>
-<br />
-Prawdopodobni prowadzący: <i>Roger, inni</i>
-<br />
-Wersje 0.2.0.x Tora robią <a
-href="<svnsandbox>doc/design-paper/blocking.html">znaczne postępy</a> w opieraniu
-się narodowej i firmowej cenzurze. Ale Tor ciągle potrzebuje lepszych mechanizmów w
-niektórych częściach projektu anty-cenzurowania. Na przykład, bieżące wersje mogą
-nasłuchiwać połączeń tylko na jednym zestawie adres/port na raz. Istnieje
-<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">propozycja
-zajęcia się tą sprawą</a> i umożliwienia klientom łączenie się z danym Torem
-na wielu adresach i portach, ale wymaga to więcej pracy. Kolejny projekt
-przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie.
-W chwili obecnej ktokolwiek może zidentyfikować
-<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">mostki Tora</a>
-po prostu łącząc się z nimi, zgodnie z protokołem Tora, i sprawdzając,
-czy odpowiadają. By rozwiązać ten problem, mostki mogłyby
-<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">udawać serwery
-internetowe</a> (HTTP lub HTTPS), gdy łączą się z nimi programy do skanowania portów,
-a nie zachowywać się jak mostki do chwili, gdy użytkownik poda klucz specyficzny
-dla mostka.
-<br />
-Ten projekt zawiera wiele badań i projektowania. Jednym z większych wyzwać
-będzie zidentyfikowanie i umiejętne wykorzystanie rozwiązań, które oprą
-się atakom nawet po tym, jak atakujący pozna projekt, po czym równoważenie
-odporności na cenzurę z użytecznością i siłą.
-</li>
-
-<li>
 <b>Lepsza integracja Tora i Libevent</b>
 <br />
 Priorytet: <i>Średni</i>
@@ -613,139 +745,8 @@
 wymaga również dużo programowania.
 </li>
 
-<li>
-<b>Ulepszenie Skanera Wyjściowego Tora (Tor Exit Scanner)</b>
-<br />
-Priorytet: <i>Wysoki</i>
-<br />
-Poziom wysiłku: <i>Wysoki</i>
-<br />
-Poziom umiejętności: <i>Wysoki</i>
-<br />
-Prawdopodobni prowadzący: <i>Mike</i>
-<br />
-Skaner węzłów wyjściowych Tora, 'SoaT', część <a
-href="https://www.torproject.org/svn/torflow/">projektu Torflow</a>, jest
-w chwili obecnej napisany w chwiejnym Perlu i opiera się na sumach
-kontrolnych MD5 dla całych dokumentów w celu stwierdzenia, czy
-węzły wyjściowe zmieniają zawartość. Problem z tym składa się z 3 części:
-1) Perl jest do bani 2) skaner nie umie weryfikować stron dynamicznych, a
-atakujący mogą skupić się na umieszczaniu złośliwego oprogramowania
-tylko na stronach dynamicznych 3) strony zmieniają się raz na jakiś czas
-(lub opierając się na GeoIP) i zaczynają generować fałszywe pozytywne wyniki.
-<br />
-Najlepiej byłoby reimplementować soat.pl w jakimś normalnym języku z
-dobrą biblioteką do parsowania HTML (dobry byłby Python, jako że reszta Torflow
-jest w nim napisana, lecz nie jest to wymagane) i wyliczać sygnatury stron
-tylko dla znaczników i zawartości, która może stać się celem ataku (znaczniki
-skryptów, linki do obiektów, obrazki). Program powinien też działać dobrze
-w obliczu zewnętrznych w stosunku do Tora zmian zawartości, a docelowo nawet
-z lokalizowaną zawartością poprzez GeoIP.
-<br />
-Skaner ten prawdopodobnie byłby uruchamiany przez serwery katalogowe i
-zgłaszał swoje wyniki na port kontroli poprzez zmienną konfiguracji AuthDirBadExit.
-<br />
-</li>
 
 <li>
-<b>Ulepszenie Skanera Węzłów Tora (Tor Node Scanner)</b>
-<br />
-Priorytet: <i>Wysoki</i>
-<br />
-Poziom wysiłku: <i>Średni do Wysokiego</i>
-<br />
-Poziom umiejętności: <i>Średni do Wysokiego</i>
-<br />
-Prawdopodobni prowadzący: <i>Mike</i>
-<br />
-Podobnie do skanera wyjściowego (lub może nawet w czasie jego działania),
-można gromadzić statystyki odnośnie wiarygodności węzłów. Te węzły, które
-źle działają dla pewnej części swoich obwodów nie powinny być używane do
-statusu Strażnika, i być może powinny też mieć zmniejszoną swoją zgłaszaną
-przepustowość, lub po prostu być oznaczane jako Nieważne. Dodatkowo,
-węzły wykazujące bardzo niską średnią przepustowość strumienia,
-lecz zgłaszają bardzo wysoką, też mogą być oznaczone jako Nieważne.
-Większość zbierania statystyk już jest zrobiona, dane te muszą tylko
-zostać przetworzone na coś, co może być wysłane Serwerom Katalogowym,
-by ukarały/wyłączyły ze swoich list te węzły w taki sposób, że klienci
-się o tym dowiedzą.
-<br />
-Dodatkowo, te same statystyki mogą być zbierane odnośnie ruchu przechodzącego
-przez węzeł. Do <a
-href="https://www.torproject.org/svn/torctl/doc/howto.txt">Protokołu Kontroli
-Tora</a> można dodać zdarzenia mówiące, czy udaje się stworzyć obwód
-przechodzący przez ten węzeł, oraz można zbierać pasywne statystyki dotyczące
-zarówno przepustowości, jak i wiarygodności innych węzłów, poprzez oparty
-na węzłach program monitorujący takie zdarzenia. Taki skaner zgłaszałby też
-informacje o dziwnie zachowujących się węzłach do Serwerów Katalogowych,
-ale kanał łączności do tych celów jeszcze nie istnieje i też musiałby
-zostać stworzony.
-</li>
-
-<li>
-<b>Pomóż śledzić ogólny status Sieci Tora</b>
-<br />
-Priorytet: <i>Wysoki</i>
-<br />
-Poziom wysiłku: <i>Średni</i>
-<br />
-Poziom umiejętności: <i>Średni</i>
-<br />
-Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>
-<br />
-Byłoby wspaniale uruchomić automatyczny system śledzenia stanu sieci w czasie,
-wyświetlanie wykresów itp. Częścią tego projektu byłoby wynalezienie lepszych
-miary do oceny stanu i wzrostu sieci. Czy wzrasta średni czas działania sieci?
-Ile węzłów kwalifikuje się do bycia Strażnikami w tym miesiącu w porównaniu z
-ubiegłym? Jaka jest rotacja w sensie pojawiania się nowych węzłów i znikania
-starych? Okresowo ludzie gromadzą krótkie migawki stanu, ale to robi się naprawdę
-interesujące dopiero, gdy zaczynamy śledzić te dane w czasie.
-<br />
-Dane powinny być zbierane z powyższego narzędzia "Skaner Węzłów Tora", z
-deskryptorów serwerów, które są publikowane przez każdy przekaźnik i z innych
-źródeł. Wyniki w czasie mogłyby być zintegrowane z jedną ze stron opisujących
-<a href="https://torstatus.blutmagie.de/">Stan Tora</a> lub być trzymane osobno.
-Skoro mówimy o stronach stanu Tora, spójrzcie na
-<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">listę życzeń
-stanu Tora</a> napisaną przez Rogera.
-</li>
-
-<li>
-<b>Polepszenia w wybieraniu ścieżki przez Tora</b>
-<br />
-Priorytet: <i>Wysoki</i>
-<br />
-Poziom wysiłku: <i>Niski do Średniego</i>
-<br />
-Poziom umiejętności: <i>Wysoki</i>
-<br />
-Prawdopodobni prowadzący: <i>Roger, Nick, Mike</i>
-<br />
-Można dokonać pewnych prostych ulepszeń do algorytmu wyboru ścieżki przez Tora,
-by znacznie zwiększyć jego szybkość. Na przykład, kilka (nieoficjalnych)  <a
-href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Zaleceń
-Wydajności Tora</a> na wiki to zwiększenie liczby strażników i zmniejszenie
-CircuitBuildTimeout. Najlepiej by było, gdyby klient sam uczył się tych
-wartości poprzez zbieranie statystyk dotyczących czasu budowania obwodów
-(lub używać wartości uzyskanych z Torflow) i ustawiał czasy dość nisko, by
-wysoki procent (75%, 90%, 1-stddev?) obwodów uległ stworzeniu, lecz by
-strasznie wolne węzły były unikane. Wymagałoby to pewnego zbierania
-statystyk i podstawowych badań oraz pewnych zmian w kodzie Tora dotyczącym
-wyboru ścieżki.
-<br />
-Dodatkowo, by zwiększyć bezpieczeństwo ścieżek, można byłoby dołączyć niektóre
-elementy z <a
-href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt"
->Propozycji Ścieżek 2-Skokowych</a> (jako że będzie to i tak dotyczyć tego samego kodu),
-bez uwagi na to, czy ta Propozycja będzie przyjęta. W szczególności, klienci powinni
-unikać strażników, którzy zdają się mieć problem ze zbudowaniem znacznej części
-swoich obwodów, a klienci bez firewalli powinni pokazywać ostrzeżenia, że udało im
-się połączyć tylko z ograniczoną liczbą węzłów-strażników. Przeczytaj także
-<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">tę wiadomość
-na or-dev</a>.
-</li>
-
-<li>
 <b>Ulepszenia w Torbutton</b>
 <br />
 Priorytet: <i>Średni</i>

More information about the tor-commits mailing list