tor-webwml.git

@@ -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 @@ deweloperzy na pełen etat latem 2007.

 <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 @@ Musisz być zmotywowany i móc pracować samodzielnie. Mamy rosnącą grupę

 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>

@@ -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,63 +113,154 @@ Poziom wysiłku: <i>Wysoki</i>

 <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 />

+Skaner ten prawdopodobnie byłby uruchamiany przez serwery katalogowe i

+zgłaszał swoje wyniki na port kontroli poprzez zmienną konfiguracji AuthDirBadExit.

 <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>

+<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 —

+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>

@@ -221,6 +312,109 @@ mieć trochę doświadczenia z C++. Uprzednie doświadczenie z Qt będzie przyda

 ale nie jest wymagane.

 </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 />

@@ -264,33 +458,6 @@ Dodatkowe punkty za jakiś projekt graficzny /Photoshop fu, gdyż moglibyśmy

 chcieć/potrzebować nowych ikonek.

 </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 —

-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>

@@ -379,41 +546,6 @@ problemu lub skierować go na właściwe kanały wsparcia. Osoba wykonująca pow

 dobrze znać Tora i to, jak zapobiegać wyciekom.

 </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 />

@@ -613,137 +745,6 @@ narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony

 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>