pl/volunteer.wml (e9e7dfaaf) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 8183
# Last-Translator: bogdandr_at_op . pl

#include "head.wmi" TITLE="Wolontariusze" CHARSET="UTF-8"

<h2>Cztery rzeczy, które każdy może zrobić już teraz:</h2>
<ol>
<li>Prosimy rozważyć <a href="<page docs/tor-doc-server>">uruchomienie
 serwera</a>, by wspomóc rozwój sieci Tor'a.</li>
<li>Spójrz na <a href="<page gui/index>">Konkurs na GUI dla Tor'a</a> i
 daj swój wkład w uczynienie interfejsu i używalności lepszymi. Darmowa koszulka za
 każdy wkład!</li>
<li>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili serwer.
 Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.</li>
<li>Szukamy funduszy i sponsorów. Jeśli podobają ci się cele Tor'a,
  <a href="<page donate>">poświęć chwilę, by złożyć dotację, by wspomóc przyszły rozwój Tor'a</a>.
  Jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
  są zainteresowane bezpieczną komunikacją, daj im znać o nas.</li>
</ol>

<a id="Bugs"></a>
<h2><a class="anchor" href="#Bugs">Błędy krytyczne</a></h2>
<ol>
<li>Serwery Tor'a nie są aktualnie stabilne na Windows XP, gdyż próbujemy uzywać
 setek gniazd, a zdaje się, że jądro Windowsa nie jest w stanie tyle obsłużyć. <a
 href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Prosimy,
 pomóż nam rozwiązać ten problem!</a> Prawdopodobnie najlepszym rozwiązaniem jest
 nauczyć bibliotekę libevent, jak używać nakładającego się I/O zamiast select() w
 Windows, a potem przystosować Tor'a do nowego interfejsu libevent.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
<ol>
 <li>Potrzebujemy dobrych sposobów na przechwytywanie żądań DNS, żeby nie
 "przeciekały" do lokalnych obserwatorów, podcza gdy my chcemy zachować anonimowość.
 (Dzieje się tak, gdyż aplikacja wysyła żądanie DNS przed przejściem przez serwer
 Proxy SOCKS.)</li>
<ul>
<li>Musimy <a
 href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">zastosować
 nasze wszystkie łaty tsocks do kodu</a> i utrzymywać nową gałąź. Możemy ją hostować, jeśli chcesz.</li>
<li>Powinniśmy załatać program "dsocks" Dug'a Song'a, by używał komend
 <i>mapaddress</i> Tor'a z interfejsu kontroli, żeby nie marnować przejścia
 całej trasy w Torze, robiąc rozwiązywanie adresów przed połączeniem.</li>
<li>Musimy sprawić, by nasz skrypt <i>torify</i> wykrywał, który z programów
 tsocks lub dsocks jest zainstalowany, i odpowiednio je uruchamiał. To
 prawdopodobnie oznacza zunifikowanie ich interfejsów i w grę może wchodzić
 dzielenie kodu między nimi lub całkowita rezygnacja z jednego z nich.</li>
</ul>
<li>Ludzie, którzy uruchomili serwer Tor'a mówią nam, że chcę dać jedną
 przepustowość łącza dla Tor'a (BandwidthRate) w czasie pewnej części dnia,
 a inną w innych częściach dnia. Zamiast programować to w Torze, powinniśmy mieć
 mały skrypt, który łączy się przez <a href="<page gui/index>">Tor Controller Interface</a>,
 i wykonuje SETCONF by zmienić przepustowość. Być może ten skrypt byłby uruchamiany
 z cron'a, a może byłby uśpiony aż do właściwego momentu i wtedy wykonywał swoją
 pracę (to by raczej było bardziej przenośne). Czy ktoś mógłby napisać taki
 skrypt za nas, a my byśmy go umieścili w katalogu <a href="<svnsandbox>contrib/">contrib/</a>?
 To byłby dobry wkład w <a href="<page gui/index>">Konkurs na GUI dla Tor'a</a>.</li>
<li>Tor może <a
 href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">wychodzić
 z sieci Tor'a z podanego węzła</a>, ale powinniśmy móc podać tylko kraj i mieć coś,
 co automatycznie za nas wybierze węzeł. Najlepszym kandydatem jest pobranie także
 katalogu Blossom i uruchomienie lokalnego klienta Blossom, który pobrałby swój katalog w
 sposób bezpieczny (poprzez Tor i sprawdzając jego podpis), przechwycałby nazwy
 hostów <tt>.country.blossom</tt>  i robił to, co trzeba.</li>
<li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z
 zaznaczonym każdym serwerem Tor'a. Dodatkowe punkty, jeśli mapa bęzdie się
 aktualizować w miarę jak sieć rośnie i się zmienia. Niestety, łatwy sposób na
 dokonanie tego to wysłanie wszystkich danych do Google, w celu narysowania
 przez nich taj mapy. Jak bardzo to uderza w prywatność i czy mamy jakieś inne
 dobre wyjścia?</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
<ol>
<li>Słyszeliśmy, że użytkownicy Tor'a mogą paść ofiarami ataków
 łamiących ich anonimowość ze strony JavaScript'u, Javy, ActiveX'a, Flash'a itp.,
 jeśli ich nie wyłączą. Czy są jakieś wtyczki/rozszerzenia (jak NoScript dla
 Firefox'a), które ułatwiają panowanie nad tym ryzykiem? Jakie to dokładnie ryzyko?
 </li>
<li>Czy istnieje kompletny zestaw wtyczek/rozszerzeń, który zastąpi całą
 funkcjonalność Privoxy w Firefoksie 1.5+? Podobno Tor jest o wiele szybszy, gdy
 nie używa się Privoxy.</li>
<li>Proszę pomóc Matt'owi Edman'owi z dokumentacją i dokumentami jak-to-zrobić do
 jego projektu <a href="http://vidalia-project.net/">Tor Controller</a>.</li>
<li>Przejrzyj i udokumentuj
 <a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">naszą
 listę programów</a>, które można skonfigurować do współpracy z Tor'em.</li>
<li>Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń
 i wysyłania ich przez Tor'a. tsocks (Linux), dsocks (BSD),
 i freecap (Windows) zdają się być dobrymi kandydatami.</li>
<li>Mamy ogromną listę <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">potencjalnie
 użytecznych programów, które współpracują z Tor'em. Które z nich są
 przydatne w jakich sytuacjach? Proszę pomóż nam je testować i zapisuj
 swoje wyniki.</li>
<li>Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na
 <a href="<page translation>">wskazówki do
 tłumaczenia</a>, jeśli chcesz pomóc. Potrzebujemy też ludzi do opieki nad
 istniejącymi tłumaczeniami: włoskim, francuskim i szwedzkim - zobacz
 <a href="<page translation-status>">stan tłumaczeń</a>.</li>
</ol>

<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Programowanie i Projektowanie</a></h2>
<ol>
<li>W tej chwili deskryptory usług ukrytych są przechowywane na zaledwie
 kilku serwerach katalogowych. To źle dla prywatności i wydajności. By to
 polepszyć, będziemy musieli uczynić deskryptory usług ukrytych jeszcze
 mniej prywatnymi, gdyż będziemy musieli je skopiować w wiele miejsc.
 Idealnie byłoby całkowicie oddzielić system przechowywania/pobierania od
 serwerów katalogowych Tor'a. Pierwszą rzeczą jest to, że musimy zaprojektować
 nowy format deskryptora usługi ukrytej tak, by a) dla wygody był w postaci ASCII,
 a nie binarnej b) przechowywać listę punktów przedstawiania w postaci zaszyfrowanej,
 chyba że zna się adres <tt>.onion</tt>, by katalog nie mógł ich pobrać, c)
 pozwolić katalogom na weryfikację znacznika czasu i podpisu na deskryptorze
 usługi ukrytej, żeby nie mogły zostać oszukane poprzez podanie im fałszywych.
 Po drugie, każdy wiarygodny system przechowywania sprawdzi się, dopóki
 umożliwia autentyfikowane aktualizacje, ale według naszych informacji,
 żaden zaimplementowany kod typu DHT (z dystrybuowaną tablicą haszowaną) nie
 obsługuje autentyfikowanych aktualizacji.</li>
<li>Serwery wyjściowe z sieci Tor muszą wysyłać wiele żądań DNS w sposób
 równoległy. Ale funkcja gethostbyname() jest słabo zaprojektowana --- zatrzymuje
 działanie programu dopóki nie skończy przetwarzać żądania --- wymaga więc
 osobnego wątku lub procesu. Dlatego Tor jest zmuszany uruchamiać wiele
 wątków wyłącznie dla DNS. Istnieją jakieś asynchroniczne biblioteki DNS, ale
 zawierają one błędy i zostały porzucone. Czy są wśród nich jakieś stabilne,
 szybkie, łatwe i będące wolnym oprogramowaniem? (Pamiętaj, że Tor używa
 OpenSSL, a OpenSSL jest (prawdopodobnie) niezgodny z GPL, więc biblioteki na
 licencji GPL odpadają.) Jeśli tak (lub jeśli możemy to sprawić), powinniśmy
 zintegrować je do Tor'a. Spójrz na <a
 href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">wiadomość
 Agl'a</a>, by poznać jedno potencjalne podejście. Zobacz też
 <a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> i
 <a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.
</li>
<li>Tor 0.1.1.x zawiera obsługę sprzętowych akcelelatorów kryptograficznych,
 poprzez OpenSSL. Ale nikt tego jeszcze nie przetestował. Czy ktoś chce
 zdobyć kartę i powiadomić nas, jak to działa?</li>
<li>Ponieważ serwer Tor'a muszą przechować i podać dalej każdą komórkę,
 którą obsługują, serwery o wysokiej przepustowości używają wiele
 megabajtów pamięci na same bufory. Potrzebujemy lepszej heurystyki do
 określenia, kiedy skurczyć/rozszerzyć bufory. Może to powinno być zaprojektowane
 podobnie jak bufory w jądrze Linuksa, gdzie jest wiele mniejszych buforów, które
 łączą się wzajemnie, zamiast używać monolitycznych buforów?</li>
<li>Zaimplementować żądania odwrotne DNS wewnątrz Tor'a (już podane w
 Sekcji 5.4 pliku <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
<li>Dokonać analizy bezpieczeństwa Tor'a z <a
 href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Sprawdzić, czy
 istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę
 gdy wydamy nową wersję dzięki Tobie!</li>
<li>Jak trudno jest zmienić bind'a lub serwer Proxy DNS tak, by kierował swoje
 żądania do Tor'a poprzez nasz <a
 href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">rozszerzenie
 socks - tor-resolve</a>? dsocks już to robi na BSD. A może konwertować zapytania
 do DNS z UDP na TCP i wysyłać je przez Tor'a?</li>
<li>Tor używa TCP do transportu i TLS do szyfrowania transmisji. To jest
 ładne i proste, ale oznacza to, że wszystkie komórki na łączu zostają
 opóźnione, gdy pojedynczy pakiet zostanie utracony, co oznacza, że rozsądnie
 obsługiwać możemy tylko strumienie TCP. Mamy <a
 href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">listę
 powodów, dla których nie przenieśliśmy się na UDP</a>, ale byłoby dobrze
 skrócić tę listę. Mamy też proponowaną <a
 href="<svnsandbox>doc/tor-spec-udp.txt">specyfikację dla Tor'a i
 UDP</a> &mdash; proszę dać znać, co z nią jest nie tak.</li>
<li>Jesteśmy wcale niedaleko od obsługi adresów IPv6 jako docelowych (na węzłach
 wyjściowych). Jeśli mocno ci zależy na IPv6, to jest to chyba najlepszy punkt
 startu.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Badania</a></h2>
<ol>
<li>"Atak na odciski palców stron WWW" (website fingerprinting attack): sporządź listę kilkuset
 popularnych stron WWW, ściągnij ich strony i zrób listę "podpisów"
 dla każdej z nich. Potem obserwuj ruch sieciowy klienta Tor'a. Jak
 patrzysz na odbierane przez niego dane, szybko zgadujesz, którą
 (jeśli w ogóle) on odbiera. Po pierwsze, jak bardzo ten atak jest
 efektywny? Potem zacznij badać sposoby obrony: na przykład, moglibyśmy
 zmienić rozmiar komórki Tor'a z 512 na 1024 bajty, moglibyśmy użyć
 technik dopełniających, jak <a
 href="http://freehaven.net/anonbib/#timing-fc2004">odrzucanie obronne (defensive dropping)</a>,
 lub moglibyśmy dodać opóźnienia w ruchu. Jak wielki wpływ mają te
 rozwiązania i jak wielki wpływ na używalność (używając odpowiedniego
 sposobu mierzenia) ma udana obrona w każdym z przypadków?
</li>
<li>"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack):
 obserwując ruch od Alicji do Boba, możemy <a
 href="http://freehaven.net/anonbib/#danezis:pet2004">porównać
 sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych</a>.
 Jak na razie, Tor przyjmoje to jako pewnik i zakłada, że ten atak jest
 trywialny we wszystkich przypadkach. Po pierwsze, czy tak rzeczywiście jest?
 Jak wiele ruchu/danych o jakim rozkładzie jest potrzebne, by przeciwnik
 upewnił się, że wygrał? Czy są jakieś sytuacje (np. nie wysyłanie wiele daych),
 które spowolniłyby atak? Czy jakieś dopełenienia transmisji lub inne sposoby
 kształtowania działają lepiej od innych?
 </li>
<li>"Atak stref trasowania" (routing zones attack): większość literatury
 mówi o ścieżce sieciowej między Alicją a jej węzłem wejściowym (i między
 węzłem wyjściowym a Bobem) jako o pojedynczej ścieżce na jakimś grafie.
 W rzeczywisctości, ścieżka przemierza wiele systemów autonomicznych (SA), i <a
 href="http://freehaven.net/anonbib/#feamster:wpes2004">często zdarza się, że
 ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej</a>.
 Niestety, by dokładnie przewidzieć, czy podany czworobok
 Alicja-wejście-wyjście-Bob jest niebezpieczny, musielibyśmy ściągnąć
 całą strefę trasowania internetu i dokonać na niej czasochłonnych operacji.
 Czy są jakieś praktyczne aproksymacje, jak np. unikanie adresów IP z tej
 samej sieci /8?
 </li>
<li>Tor nie działa za dobrze, gdy serwery mają asymetryczne łącze
 (np. kablówka czy DSL). Ponieważ Tor wykonuje oddzielne połączenia między
 każdym skokiem, jeśli przychodzące bajty są przysyłane dobrze, a wychodzące
 są wyrzucane, mechanizmy push-back w TCP nie transmitują tej informacji
 z powrotem do strumienia przychodzącego. Być może Tor powinien odkryć, gdy
 wyrzuca dużo pakietów wychodzących, i ograniczyć strumienie przychodzące,
 by sam tym regulować? Można sobie wyobrazić schemat działania, w którym
 najpierw wybieramy niski limit przepustowości, powoli go zwiększając aż do
 chwili w której zaczęlibyśmy tracić pakiety - wtedy nastąpiłoby cofnięcie się.
 Potrzebujemy kogoś dobrze znającego sieci by to zasymulował i pomógł
 zaprojektować rozwiązania; musimy zrozumieć stopień degradacji wydajności i
 użyć tego argumentu jako motywacji do ponownego rozpatrzenia transportu UDP.
 </li>
<li>Powiązanym tematem jest kontrola zatorów. Czy nasz dotychczasowy projekt
 okaże się wystarczający, gdy będziemy mieli duży ruch? Może powinniśmy
 poeksperymentować z oknami o zmiennym rozmiarze zamiast z oknami o stałym?
 To zdawało się działać nieźle w <a
 href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">eksperymencie
 przepustowości SSH</a>. Będziemy musieli mierzyć i podkręcać, i być może
 wykonać poprawki, jeśli wyniki okażą się dobre.
 </li>
<li>Aby umożliwić dysydentom w innych krajach używanie Tor'a bez bycia
 zablokowanym przez zaporę ogniową w ich kraju, potrzebujemy sposobu na
 zdobycie dziesiątek tysięcy serwerów pośredniczących, nie zaledwie kilkuset.
 Wyobrażamy sobie GUI klienta Tor'a, które na górze ma przycisk "Pomóż Chinom",
 który otwiera port i przekierowuje kilka kB/s ruchu do sieci Tor. (Kilka kB/s
 nie powinno być dużym kłopotem i nie będzie wiele spraw o nadużycia, gdyż
 nie będą to węzły wyjściowe.) Ale jak rozpowszechniać listę tych
 klientów-wolontariuszy do dobrych dysydentów automatycznie w taki sposób, który
 nie pozwoli krajowym zaporom ogniowym przechwycić i zliczyć ich? To prawdopodobnie
 musi działać poziomie zaufania ludzkiego. Spójrz na nasz <a
 href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">wpis w FAQ</a>
 o tym, a potem przeczytaj <a
 href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sekcję w anonbib o
 przeciwstawianiu się cenzurze</a>.</li>
<li>Obwody Tor'a są budowane po jednym elemencie na raz, więc teoretycznie
 możemy uczynić, aby część strumieni wychodziła z drugiego węzła, część z
 trzeciego itd. To wydaje się dobre, bo ogranicza zbiór strumieni wychodzących,
 które dany serwer może zobaczyć. Ale jeśli chcemy by każdy strumień był
 bezpieczny, "najkrótsza" ścieżka powinna, według naszego bieżącego rozumowania,
 składać się z co najmniej 3 elementów, więc reszta będzie jeszcze dłuższa.
 Musimy zbadać ten kompromis wydajność/bezpieczeństwo.
 </li>
<li>Nie jest trudno wykonać atak DoS na serwery Tor'a lub serwery katalogowe.
 zagadki dla klientów (?) (client puzzles) są właściwą odpowiedzią? Jakie są
 inne praktyczne podejścia? Dodatkowe punkty, jeśli są zgodne wstecz z
 bieżącym protokołem Tor'a.</li>
</ol>

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

</div>

#include <foot.wmi>

tor-webwml.git

Polish translation update