pl/volunteer.wml (84d70bcc6) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 19651
# Translation-Priority: 4-optional
# Last-Translator: bogdandr_at_op . pl

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

<h2>Kilka rzeczy, które każdy może zrobić już teraz:</h2>
<ol>
<li>Prosimy rozważyć <a href="<page docs/tor-doc-relay>">uruchomienie
 przekaźnika sieci Tor</a>, by wspomóc rozwój sieci Tora.</li>
<li>Rozpowiadaj o systemie Tor swoim znajomym. Spraw, by uruchomili przekaźniki sieci.
 Spraw, by uruchomili usługi ukryte. Spraw, by mówili o systemie Tor swoim znajomym.</li>
<li>Jeśli podobają ci się cele Tora,
 <a href="<page donate>">poświęć chwilę, by złożyć dotację, aby wspomóc przyszły rozwój Tora</a>.
 Szukamy też dalszych sponsorów &mdash;
 jeśli znasz jakieś firmy, organizacje pozarządowe, agencje lub inne organizacje, które
 są zainteresowane anonimowością / prywatnością / bezpieczną komunikacją, daj im znać o nas.</li>
<li>Szukamy więcej <a href="<page torusers>">dobrych przykładów użytkowników
 Tora i przypadków jego używania</a>. Jeśli używasz Tora w sposób jeszcze nie przedstawiony
 na tamtej stronie i nie masz nic przeciw podzieleniu się z nami tym sposobem, z chęcią
 przyjmiemy taką wiadomość.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Aplikacje Wspomagające</a></h2>
<ol>
 <li>Potrzebujemy więcej i lepszych sposobów na przechwytywanie żądań DNS, żeby nie
 "przeciekały" do lokalnych obserwatorów, podczas gdy chcemy zachować anonimowość.
 (Dzieje się tak, gdyż aplikacja wysyła żądanie DNS przed przejściem przez serwer
 Proxy SOCKS.)</li>
<li>Sprawy z Tsocks/dsocks:
 <ul>
<li>Powinniśmy załatać program "dsocks" Duga Songa, by używał komend
 mapaddress Tora z interfejsu kontroli, żeby nie marnować przejścia
 całej trasy w Torze, wykonując rozwiązywanie adresów przed połączeniem.</li>
<li>Musimy sprawić, by nasz skrypt torify 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>
<li>Ludzie, którzy uruchomili przekaźnik sieci Tora mówią nam, że chcą dać jedną
 przepustowość łącza dla Tora (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ść. Jest już po jednym skrypcie dla systemów
 Unix i Mac (korzystają z basha i crona), ale dalej potrzebne jest rozwiązanie
 dla użytkowników Windowsa.
 </li>
<li>A mówiąc o danych geolokacyjnych, ktoś powinien narysować mapę Ziemi z
 zaznaczonym każdym przekaźnikiem sieci Tora. Dodatkowe punkty, jeśli mapa będzie 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="Advocacy"></a>
<h2><a class="anchor" href="#Advocacy">Pokazanie się jako zwolennik Tora</a></h2>
<ol>
<li>Stwórz logo społeczności pod licencją Creative Commons, którego wszyscy będą mogli
używać i modyfikować</li>
<li>Stwórz prezentację, której będzie można używać na spotkaniach różnych grup na całym świecie</li>
<li>Stwórz film o Twoim pozytywnym wykorzystaniu Tora. Kilka już zaczęło na Seesmic.</li>
<li>Stwórz plakat, lub zestaw plakatów, skupionych na jakimś motywie, np. "Tor to Wolność!"</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
<ol>
<li>Proszę pomóc Mattowi Edmanowi z dokumentacją i dokumentami jak-to-zrobić do
 jego projektu Tor Controller i <a href="<page vidalia/index>">Vidalia</a>.</li>
<li>Przejrzyj i udokumentuj
 <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">naszą
 listę programów</a>, które można skonfigurować do współpracy z Torem.</li>
<li>Potrzebujemy lepszej dokumentacji do dynamicznego przechwytywania połączeń
 i wysyłania ich przez Tora. tsocks (Linux), dsocks (BSD),
 i freecap (Windows) zdają się być dobrymi kandydatami, jako że lepiej
 używałyby naszej nowej cechy TransPort.</li>
<li>Mamy ogromną listę <a
 href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">potencjalnie
 użytecznych programów, które współpracują z Torem</a>. 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 zwłaszcza tłumaczy na język
 arabski i Farsi dla wielu użytkowników Tora w cenzorowanych obszarach.</li>

</ol>

<a id="Coding"></a>
<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Dobre Projekty Programistyczne</a></h2>

Niektóre z tych projektów mogą być dobrymi pomysłami na <a
href="<page gsoc>">Google Summer of Code 2009</a>.
Opisaliśmy każdy z nich informacją, jak użyteczny byłby dla projektu Tor (priorytet),
ile pracy według nas wymaga (poziom wysiłku), z iloma informacjami powinno się
zaczynać (poziom umiejętności), i którzy z naszych <a href="<page
people>#Core">głównych deweloperów</a> byliby dobrymi opiekunami.
Jeśli jeden lub więcej z tych pomysłów wygląda dla Ciebie obiecująco, <a
href="<page contact>">skontaktuj się z nami</a>, by omówić Twoje plany zamiast wysyłać
zgłoszenia na ślepo. Możesz też zaproponować swój własny pomysł na projekt, co często
daje najlepsze programy.

<ol>

<li>
Paczka Tora z Przeglądarką dla Linux/Mac OS X
 
Priorytet: Wysoki
 
Poziom wysiłku: Wysoki
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Steven
 
Paczka Tora z Przeglądarką zawiera Tora, Firefoksa i interfejs użytkownika - Vidalię
(i opcjonalnie komunikator Pidgin). Komponenty te są prekonfigurowane do bezpiecznego
działania, a paczka ma małe wymagania co do systemu operacyjnego. Stała się więc
jednym z najprostszych i najbardziej popularnych sposobów używania Tora na Windows.
 
Nie ma jednak w chwili obecnej porównywalnej paczki dla Linuksa i Mac OS X, więc celem
tego projektu byłaby implementacja Paczki Tora z Przeglądarką dla tych systemów.
Będzie to pociągało zmiany w Vidalii (C++), być może w Firefoksie (C), po czym stworzenie
i testowanie programu uruchamiającego na różnych wersjach i konfiguracjach systemów operacyjnych,
by sprawdzić przenośność.
 
Studenci powinni być zaznajomieni z rozwojem aplikacji na jednym, lub najlepiej obu,
Linuksie i Mac OS X oraz czuć się swobodnie z C/C++ i pisaniem skryptów powłoki.
</li>

<li>
Wiki do tłumaczeń dla naszej strony
 
Priorytet: Wysoki
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Jacob
 
Projekt Tor pracował w ciągu ostatniego roku nad uruchomieniem opartych na sieci narzędzi,
by pomóc ochotnikom w tłumaczeniu naszych aplikacji na inne języki.
W końcu stanęliśmy na Pootle i mamy dobry mechanizm sieciowy do tłumaczeń dla programów
Vidalia, Torbutton i Torcheck. Ale Pootle tłumaczy tylko napisy w formacie "po", a
nasza strona korzysta z plików wml. Celem tego projektu jest znalezienie sposobu na
konwersję naszych plików wml na pliki "po" i z powrotem, by mogły być obsługiwane przez Pootle.
</li>

<li>
Pomóż śledzić ogólny status Sieci Tora
 
Priorytet: Średni do wysokiego
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Karsten, Roger
 
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.
 
Dane mogłyby być zbierane ze Skanerów Węzłów Tora w <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, 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>
Polepszanie naszych zdolności opierania się cenzurze
 
Priorytet: Średni do wysokiego
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Wysoki
 
Prawdopodobni opiekunowie: Nick, Roger, Steven
 
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.
 
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>
Tuneup Tor!
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni do wysokiego
 
Prawdopodobni opiekunowie: Nick, Roger, Mike
 
W chwili obecnej węzły Tora mierzą i zgłaszają własną przepustowość łącza,
a klienci Tora wybierają, których węzłów używać po części opierając się
na tej zgłaszanej przepustowości. To podejście jest podatne na
<a href="http://freehaven.net/anonbib/#bauer:wpes2007">ataki, w których węzły oszukują
na temat przepustowości swoich łączy</a>; by to zmienić, Tor aktualnie ogranicza
maksymalną przepustowość każdego węzła, w którą jest w stanie uwierzyć. To jest
ograniczone rozwiązanie i marnotrawienie przepustowości. Zamiast tego,
Tor powinien w miarę możliwości mierzyć przepustowość łączą w rozproszony sposób,
jak jest napisane w dokumencie
<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tuneup for Tor"</a> autorstwa
Snadera i Borisova. Można byłoby użyć bieżącego kodu testującego, by sprawdzić
odkrycia napisane w tym dokumencie i zweryfikować, w jakim stopniu opisują one
normalnie działającego Tora i określić dobre sposoby na wcielenie tych odkryć
do sieci Tora bez dodawania niepożądanego ruchu wielkości między węzłami a serwerami
katalogowymi.
</li>

<li>
Ulepszenie Polipo na Windows
 
Priorytet: Średni
 
Poziom wysiłku: Niski
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Martin
 
Pomóż przenieść <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na Windows.
1) zdolność do asynchronicznego wysyłania zapytań do
serwerów nazw. 2) natywna obsługa zdarzeń i buforów (tj. w
systemach uniksopodobnych Polipo domyślnie używa 25% pamięci RAM, a pod Windows
jest to cokolwiek wpisane w plik konfiguracyjny). 3) jakieś narzędzie z
graficznym interfejsem do konfiguracji i raportowania, dodatkowe punkty, jeśli
ma ikonkę w zasobniku z opcjami menu po kliknięciu prawym przyciskiem myszy.
Podwójny bonus, jeśli działa na wielu platformach.
4) umożliwienie programowi używania rejestru Windowsa i obsługiwania prawidłowych
ścieżek w Windowsie, np. "C:\Program Files\Polipo".
</li>

<li>
Zaimplementowanie opartego na torrencie sposobu pobierania paczek Thandy
 
Priorytet: Średni
 
Poziom wysiłku: Wysoki
 
Poziom umiejętności: Średni do wysokiego
 
Prawdopodobni opiekunowie: Martin, Nick
 
<a
href="https://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
jest względnie nowym oprogramowaniem, które umożliwia wspomagane aktualizacje Tora i
związanych z nim programów. W tej chwili użytkowników jest niewielu, ale oczekujemy, że
Thandy będzie w przyszłości używane przez prawie każdego użytkownika Tora. By uniknąć
padających serwerów w dniu aktualizacji Tora, potrzebujemy nowych sposobów na
wydajną dystrybucję nowych paczek, a wykorzystanie libtorrent zdaje się być
możliwym rozwiązaniem. Jeśli myślisz o innych dobrych pomysłach, to wspaniale
- proszę dać nam znać! 
Musimy też zbadać, jak lepiej dołączyć nasze mirrory. Jeśli to możliwe, powinien
znaleźć się łatwy sposób na to, by łatwo pomogły w dystrybucji paczek.
</li>

<li>
Interfejs zdarzeń stanu kontrolera Tora
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Niski do średniego
 
Prawdopodobni opiekunowie: Matt
 
Jest pewna liczba zmian stanu, o których użytkownik powinien być może być
informowany. Na przykład, jeśli użytkownik chce uruchomić przekaźnik sieci Tor,
a Tor stwierdzi, że nie jest on osiągalny z zewnątrz, użytkownik powinien zostać
o tym poinformowany. W tej chwili wszystko, co dostaje użytkownik, to kilka
wiadomości w "dzienniku wiadomości" Vidalii, których pewnie nie zobaczy, gdyż
nie dostaje informacji, że coś poszło nie tak. Nawet jeśli użytkownik spojrzy na
zapis logów, większość wiadomości będzie miała mały sens dla początkującego.
 
Tor ma możliwość informowania Vidalii o wielu takich zmianach stanu, a ostatnio
zaimplementowaliśmy obsługę kilku takich zdarzeń. Jednak jest wiele więcej
zdarzeń, o których użytkownik powinien być informowany i potrzebujemy
lepszego interfejsu użytkownika do wyświetlania takich wiadomości.
 
Celem tego projektu jest zaprojektowanie i zaimplementowanie interfejsu
użytkownika do wyświetlania wiadomości o stanie Tora. Na przykład, można
byłoby umieścić mały znaczek na ikonie Vidalii w zasobniku, który alarmowałby
użytkownika o nowych zmianach stanu, którym powinien się przyjrzeć.
Podwójne kliknięcie tej ikonki pokazywałoby okienko dialogowe podsumowujące
ostatnie zmiany stanu prostymi słowami i może sugerujące rozwiązania
do negatywnych wiadomości, jeśli mogą one być naprawione przez użytkownika.
Oczywiście to tylko przykład i można zaproponować inne podejście.
 
Osoba podejmująca się tego projektu powinna dobrze znać projektowanie i
tworzenie interfejsu użytkownika i mieć trochę doświadczenia z C++.
Uprzednie doświadczenie z Qt i Qt Designer będzie przydatne, ale nie jest wymagane.
Przydatne mogą być też pewne umiejętności w pisaniu po angielsku, gdyż
ten projekt prawdopodobnie będzie wymagał napisania małej ilości dokumentacji
pomocniczej, która powinna być zrozumiała dla nie-technicznych użytkowników.
Dodatkowe punkty za jakiś projekt graficzny /Photoshop fu, gdyż moglibyśmy
chcieć/potrzebować nowych ikonek.
</li>

<li>
Polepszenie procesu testów jednostkowych
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Nick, Roger
 
Tor musi zostać znaczniej bardziej przetestowany. To jest projekt wieloczęściowy.
Na początek, nasze testy jednostkowe powinny znacznie się wzbogacić, zwłaszcza
w obszarach poza funkcjami narzędziowymi. Będzie to wymagało poważnych zmian
niektórych części Tora, aby oddzielić jak najwięcej programu od zmiennych
globalnych. 
Ponadto, musimy zautomatyzować nasze testy wydajności dla wszystkich systemów.
Mamy już buildbota do automatyzacji naszej zwyczajnej integracji i kompilacji testów
(ale potrzebujemy osoby do uruchomienia tego pod Windows), ale
musimy zaktualizować nasze testy symulacji sieci (takie, jak w <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
do nowszych wersji Tora i zaprojektować je tak, by uruchamiać sieci testowe
albo na jednej maszynie, albo na kilku, abyśmy mogli automatycznie
badać zmiany wydajności na maszynach pełniących różne zadania.
</li>

<li>
Pomóż wznowić niezależną implementację klienta Tora
 
Priorytet: Średni
 
Poziom wysiłku: Wysoki
 
Poziom umiejętności: Średni do wysokiego
 
Prawdopodobni opiekunowie: Karsten, Nick
 
Reanimuj jedno z podejść do implementacji klienta Tora w Javie, np.
<a href="http://onioncoffee.sourceforge.net/">projekt OnionCoffee</a>
i spraw, by działał pod <a href="http://code.google.com/android/">Androidem</a>.
Pierwszym krokiem byłoby przeniesienie istniejącego kodu i uruchomienie go
w środowisku Android. Potem kod powinien zostać zaktualizowany, by obsługiwać
nowsze wersje protokołu Tora, jak na przykład
<a href="<svnsandbox>doc/spec/dir-spec.txt">protokół katalogowy w wersji 3</a>.
Poza tym, obsługa żądań lub choćby dostarczania usług ukrytych Tora byłaby fajna,
choć nie wymagana. 
 Perspektywiczny deweloper powinien rozumieć i umieć pisać nowy kod w Javie, łącznie
z korzystaniem z kryptograficznego API Javy. Umiejętność czytania kodu w C
też byłaby przydatna. Powinno się mieć chęć do czytania istniejącej dokumentacji,
implementacji kodu w oparciu o nią oraz, jeśli będzie to potrzebne, poprawiać
dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu z
pisania kodu i w mniejszym - z projektowania.
</li>

<li>
Nowe funkcjonalności Torbuttona
 
Priorytet: Średni
 
Poziom wysiłku: Wysoki
 
Poziom umiejętności: Wysoki
 
Prawdopodobni opiekunowie: Mike
 
Jest kilka <a
href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">dobrych
próśb o nowe funkcjonalności</a> w sekcji Flyspray Torbuttona. W szczególności, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integracja
'Nowej Tożsamości' z Vidalią</a>,
<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">sposoby
zarządzania wieloma plikami z ciasteczkami/tożsamościami</a>, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">zachowywanie
określonych ciasteczek</a> gdy ciasteczka są usuwane,
<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">lepsza
podmiana odnośnika wstecznego</a>, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">prawidłowe
zgłaszanie stanu Tora</a>, i <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=462">adresy "tor://"
i "tors://"</a> są interesującymi cechami, które można byłoby dodać.
 
Ta praca byłaby niezależnym programowaniem w Javascripcie i przyjemnym świecie <a
href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>, z
niewielkim zaangażowaniem w wewnętrzne sprawy Tora.
</li>

<li>
Nowe funkcjonalności Thandy
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni do wysokiego
 
Prawdopodobni opiekunowie: Martin
 
Potrzebujemy dodatkowych funkcjonalności do wspomaganych aktualizacji całego
oprogramowania związanego z Torem na Windows i innych systemach operacyjnych.
Niektóre funkcjonalności do rozważenia to:
1) Integracja <a
href="http://chandlerproject.org/Projects/MeTooCrypto">biblioteki Pythona MeTooCrypto</a>
do uwierzytelnianych pobierań przez HTTPS. 2) Dodanie poziomu niezależności między
sygnaturami czasowymi a plikami załączonymi w aktualizacji. Przeczytaj wątek
"Thandy attacks / suggestions" na or-dev.
3) Obsługa specyficznych dla lokalizacji instalacji i konfiguracji wspomaganych
aktualizacji w oparciu o ustawienia języka według preferencji, hosta lub konta użytkownika.
Znajomość stron kodowych Windows, unikodu i innych zestawów znaków będzie pomocna,
jak również ogólne doświadczenie w programowaniu win32 i POSIX API oraz biegłość w Pythonie.
</li>

<li>
Symulator wolnych połączeń internetowych
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Steven
 
Wielu użytkowników Tora ma łącza internetowe niskiej jakości, dające niską przepustowość,
długie czasy trwania operacji i wysoki współczynnik utraty lub przekładania pakietów.
Z doświadczeń użytkowników wiemy, że Tor źle reaguje na te warunki, ale ciężko jest
poprawić tę sytuację bez możliwości powtórzenia tych problemów w laboratorium.
 
Celem tego projektu byłoby zbudowania środowiska symulacyjnego, które replikowałoby
tę słabą łączność, by można było zmierzyć jej działanie na wydajność Tora. Innymi
komponentami byłby program testujący, w celu określenia dostępnych parametrów połączenia
i mierzenia wpływu zmian polepszających wydajność Tora.
 
Wybór narzędzi zależałby od studenta/ki, ale dummynet (dla FreeBSD) i
nistnet (pod Linux) są dwoma potencjalnymi komponentami, na których można byłoby zbudować ten
projekt. Studenci powinni mieć doświadczenie w programowaniu i debugowaniu sieciowym i TCP/IP
oraz najlepiej znać C i język skryptowy.
</li>

<li>
Poprawiona i bardziej użyteczna mapa sieci w programie Vidalia
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Matt
 
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ę.
Zamiast tego, zaimplementowaliśmy widget 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. Chcemy też dodaće możliwość klikania przez
użytkownika na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
stwierdzenia "chcę, by moje połączenia do wychodziły stąd."
 
Podczas tego projektu, osoba 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.
 
Osoba podejmująca się tego projektu powinna dobrze znać C++.
Uprzednie doświadczenie z Qt i CMake będzie przydatne, ale nie jest wymagane.
</li>

<li>
Ożywienie projektu moniTor
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Niski do średniego
 
Prawdopodobni opiekunowie: Karsten, Jacob
 
Zaimplementuj narzędzie <a href="http://www.ss64.com/bash/top.html">podobne do top</a>
dla przekaźników siei Tora. Celem takiego narzędzia byłoby monitorowanie lokalnego przekaźnika
sieci poprzez jego port kontrolny i dołączanie użytecznych informacji systemowych
samej maszyny. Podczas działania, narzędzie to dynamicznie aktualizowałoby
swoje informacje, tak jak program top robi to dla procesów linuksowych.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">Ta
wiadomość na or-dev</a> może być dobrą lekturą na początek. 
 Obsoba powinna znać lub
być chętną do nauki administrowania przekaźnikiem Tora i konfigurowania go
za pomocą portu kontroli. Jako że wstępny prototyp jest napisany w Pythonie,
pewna wiedza na temat pisania programów w tym języku też byłaby przydatna.
Ten projekt z jednej strony opiera się na określeniu wymagań dla takiego
narzędzia i zaprojektowania dla niego interfejsu, a z drugiej strony
wymaga również dużo programowania.
</li>

<li>
Odpowiednik Torbuttona dla Thunderbirda
 
Priorytet: Średni
 
Poziom wysiłku: Wysoki
 
Poziom umiejętności: Wysoki
 
Prawdopodobni opiekunowie: Mike
 
Od ciągle powiększającej się grupy użytkowników słyszymy, że chcą używać Thunderbirda z
Torem. Jest jednak wiele spraw na poziomie aplikacji, na przykład to, że Thunderbird
domyślnie umieści Twoją nazwę hosta w wysyłanej przez siebie poczcie. W pewnym momencie
powinniśmy zapoczątkować nowe działania mające na celu stworzenie rozszerzenia dla
Thunderbirda, podobnego do Torbuttona.
</li>

<li>
Sterownik Pośredniego Poziomu Sieci
 
Priorytet: Niski
 
Poziom wysiłku: Wysoki
 
Poziom umiejętności: Wysoki
 
Prawdopodobni opiekunowie: Martin
 
Sterownik WinPCAP używany przez Tor VM do działań sieciowych nie obsługuje sporej
liczby kart bezprzewodowych i nie-ethernetowych. Zaimplementowanie sterownika
pośredniego poziomu sieciowego dla win32 i 64-bitowego dałoby możliwość przechwytywania
i przekierowywania ruchu w takich sieciach. Ten projekt wymaga znajomości i doświadczenia
z pisaniem i testowaniem sterowników poziomu jądra Windows. Znajomość Winsock i Qemu
też byłaby pomocna.
</li>

<li>
Ulepszenie Pogody Tora
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Średni
 
Prawdopodobni opiekunowie: Jake, Roger
 
<a href="https://weather.torproject.org/">Pogoda Tora</a> jest narzędziem, które
umożliwia zapisanie się do otrzymywania powiadomień pocztą e-mail, gdy obserwowany przekaźnik
sieci Tora nie działa. W chwili obecnej nie jest to zbyt użyteczne dla osób używających
hibernacji Tora i dla tych, którzy muszą regularnie wyłączać swoje przekaźniki.
W czasie tego projektu, Pogoda Tora mogłaby być rozszerzona o bardziej elastyczne możliwości
konfiguracji. Możliwe są też inne udoskonalenia: mogłaby wysyłać ostrzeżenia, gdy Twój
przekaźnik używa przestarzałej wersji Tora, lub gdy jego zaobserwowana przepustowość
spadnie poniżej pewnego poziomu. To może być też przydatne narzędzie do sprawdzania, czy
Twój przekaźnik zarobił dla Ciebie <a href="<page tshirt>">T-Shirt</a> lub do przesyłania
przypomnień do serwerów katalogowych, że ich klucze się wkrótce przedawnią. Bądźcie
twórczy i pomyślcie, jak powyższy projekt śledzenia ogólnego stanu sieci Tora mógłby
Wam pomóc w szybszym ukończeniu zadania! Przeczytajcie też pliki
<a href="https://svn.torproject.org/svn/weather/trunk/README">README</a> i
<a href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.
</li>

<li>
Przynieś nowe pomysły!
 
<li>Nie podoba Ci się żaden z tych pomysłów? Sięgnij do <a
 href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">planu rozwoju Tora</a> po więcej
 pomysłów.
 Niektórym z <a href="<svnsandbox>doc/spec/proposals/">bieżących propozycji</a>
 też może brakować deweloperów.</li>

<!-- Is Blossom development still happening?
<li>
Zmiana i rozszerzenie Blossom
 
Należy zmienić i rozszerzyć Blossom (narzędzie do monitorowania i wybierania
właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane
przez użytkownika) do zbierania danych własnym sposobem, z łatwymi do zmiany
przez użytkownika parametrami. Blossom jest aktualnie zaimplementowany
jako pojedynczy skrypt Pythona, który łączy się z Torem używając interfejsu
Kontrolera i opiera się na danych zbieranych o węzłach Tora przez zewnętrzne
procesy takiej jak strona www pokazująca status węzłów wraz z publicznymi
danymi z DNSów, whois itp. Ten projekt ma 2 części: (1) Określenie, jakie jeszcze
dane mogą być potrzebne i przerobić Blossom tak, by sam zbierał dane zamiast polegać
na zewnętrznych skryptach (to może, oczywiście, wprowadzić dodatkowe wątki i
komunikację międzyprocesową) i (2) stworzenie metody łatwej konfiguracji Blossom
przez użytkownika, zaczynając od pliku konfiguracyjnego i być może kończąc na
konfiguracji przez przeglądarkę. Ważna jest znajomość Tora i Pythona; znajomość
TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie
neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie
niespójności Internetu są podstawą projektu Blossom.
</li>

<li>
Ulepszenie Blossom: pozwolenie użytkownikom na jakościowy opis węzłów wyjściowych,
z których chcą korzystać
 
Należy zaprojektować i zaimplementować możliwość dania użytkownikom programu Blossom
opisania węzła wyjściowego, z którego chcą korzystać. Internet jest niespójnym
miejscem: niektóre węzły wyjściowe Tora widzą świat inaczej niż inne. W bieżącej
implementacji Blossom (narzędzie do monitorowania i wybierania
właściwych obwodów Tora w oparciu o wymagania co do węzła wyjściowego podane
przez użytkownika) nie ma dość bogatego języka, by opisać, jak bardzo różne
są różne punkty widzenia. Na przykład, niektóre węzły wyjściowe mogą być w
sieciach filtrujących pewne rodzaje ruchu lub strony. Inne węzły mogą dawać dostęp
do specjalnej zawartości w związku ze swoją lokalizacją, być może jako rezultat
dyskryminacji ze strony samych dostawców treści. Ten projekt składa się z 2 części:
(1) stworzenie języka do opisywania charakterystyk sieci, w której znajdują się
węzły, oraz (2) wprowadzenie tego języka do Blossom, by użytkownicy mogli
wybierać ścieżki Tora w oparciu o ten opis.
Ważna jest znajomość Tora i Pythona; znajomość
TCP, komunikacji międzyprocesowej i Perla też może się przydać. Zainteresowanie
neutralnością sieci też jest ważne, gdyż zasady ewolucji i zrozumienie
niespójności Internetu są podstawą projektu Blossom.
</li>
-->

<!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X
<li>
Badania używalności Tora
 
Priorytet: Średni
 
Poziom wysiłku: Średni
 
Poziom umiejętności: Niski do średniego
 
Prawdopodobni opiekunowie: Andrew
 
Zwłaszcza paczki z przeglądarką, najlepiej wśród docelowego przekroju ludności.
To by bardzo pomogło w dowiedzeniu się, co musi zostać zrobione w dziedzinie poprawek
błędów lub nowych funkcjonalności. W tej chwili dostajemy to nieformalnie, ale lepszy
byłby bardziej strukturalny proces.
</li>

</ol>

<a id="OtherCoding"></a>
<h2><a class="anchor" href="#OtherCoding">Inne pomysły związane z programowaniem i projektowaniem</a></h2>

<ol>

<li>Przekaźniki sieci Tora nie działają zbyt dobrze na Windows XP. Pod systemem Windows Tor
 używa standardowej funkcji systemowej <tt>select()</tt>, która zużywa miejsce
 w niestronicowanym obszarze pamięci. Znaczy to, że średnich rozmiarów
 przekaźnik sieci Tora zapełni dostępną przestrzeń, <a
 href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">będąc
 przyczyną dziwnych zachowań i padów systemu</a>. Powinniśmy raczej używać
 nakładającego IO. Jednym z rozwiązań byłoby nauczenie biblioteki <a
 href="http://www.monkey.org/~provos/libevent/">libevent</a>, jak używać nakładającego IO
 zamiast select() pod Windows, po czym zaadaptować Tora do nowego interfejsu.
 Christian King zrobił
 <a href="https://svn.torproject.org/svn/libevent-urz/trunk/">pierwszy dobry
 krok</a> lata roku 2007.</li>

<li>Musimy zacząć budować nasz <a href="<page
 documentation>#DesignDoc">projekt odporny na blokowanie</a>. Wchodzi w to
 przemyślenie projektu, zmiana wielu różnych elementów Tora, zaadaptowanie
 <a href="<page vidalia/index>">Vidalii</a>, by obsługiwała nowe cechy i
 planowanie rozpowszechniania.</li>

<li>Potrzebujemy elastycznego frameworka symulacji do badania ataków potwierdzenia
 ruchu od nadawcy do odbiorcy (end-to-end). Wielu ludzi szybko wyciągnęło/napisało doraźne
 symulatory odpowiadające ich intuicji, że albo ataki znakomicie się udają, albo
 że obrona działa dobrze. Czy możemy zbudować symulator, który jest dobrze udokumentowany
 i dość otwarty, by wszyscy wiedzieli, że daje rozsądną odpowiedź? To zacznie wiele nowych
 badań. Spójrz na wpis <a href="#Research">poniżej</a> o atakach potwierdzenia po szczegóły
 strony badawczej tego zadania &mdash; kto wie, może gdy będzie skończone, pomożesz nam też
 napisać dokumentację.</li>

<li>Tor 0.1.1.x i późniejsze zawiera obsługę sprzętowych akceleratorów kryptograficznych,
 poprzez OpenSSL. Zostało to trochę przetestowane i prawdopodobnie ma dużo błędów.
 Czekamy na bardziej rygorystyczne testy, analizy wydajności i najlepiej poprawki
 kodu do OpenSSL i Tora, jeśli będzie trzeba.</li>

<li>Dokonać analizy bezpieczeństwa Tora 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>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="https://wiki.torproject.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/spec/proposals/100-tor-spec-udp.txt">specyfikację dla Tora 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>

<li>
Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład, obrazków
"Jak działa Tor" na <a href="<page overview>">stronie wprowadzenia</a>
ze źródeł, byśmy mogli je tłumaczyć
jako tekst w UTF-8 zamiast edytować je ręcznie za pomocą GIMPa.
Należy zintegrować to z plikiem WML, by tłumaczenie było proste, a obrazki
generowane w wielu językach w czasie publikacji strony.
</li>

<li>Jak można uczynić <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
łatwiejszym w utrzymaniu, ulepszaniu i dokumentowaniu?</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 Tora. 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 Tora 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 przyjmuje 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 danych),
 które spowolniłyby atak? Czy jakieś dopełnienia transmisji lub inne sposoby
 kształtowania działają lepiej od innych?
 </li>

<li>Powiązane pytanie brzmi: Czy prowadzenie przekaźnika/mostka daje dodatkową
ochronę przed atakami opartymi na czasie? Czy ktoś z zewnątrz, kto nie może
przeczytać linków zaszyfrowanych przez TLS, dalej jest w stanie prawidłowo rozpoznać
poszczególne strumienie danych? Czy ilość ruchu jakoś zmniejsza tę możliwość?
A co, jeśli klient-przekaźnik celowo opóźnia wychodzący ruch, by stworzyć kolejkę,
która mogłaby być używana do udawania czasów pobierania danych przez klienta tak,
by wyglądało, że ten ruch też jest przekierowany? Ta sama kolejka mogłaby być używana do
maskowania czasów w ruchu wychodzącym, korzystając z technik <a
href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptacyjnego dopełniania</a>,
ale bez potrzeby dodatkowego ruchu (wysyłania dodatkowych danych). Czy takie
przeplatanie prawdziwych danych popsułoby mierzenie czasów u atakujących? Czy strategie
te musiałyby by zmienione dla asymetrycznych łączy? Na przykład, czy jest możliwe
na łączu asymetrycznym odróżnienie ruchu klienta od naturalnego wzmożenia ruchu ze
względu na ich asymetryczną pojemność? Czy jest to jednak łatwiejsze niż dla łączy
symetrycznych z innych przyczyn?</li>

<li>Powtórzcie <a
href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">atak z
Oakland 05</a> Murdocha i Danezisa na bieżącej sieci Tora. Sprawdźcie, czy możecie
dowiedzieć się, czemu działa on dobrze na niektórych węzłach, a gorzej na innych.
(Moja teoria mówi, że szybkie węzły mające trochę wolnego pasma lepiej opierają się
atakowi.) Jeśli to prawda, poeksperymentujcie z opcjami RelayBandwidthRate i
RelayBandwidthBurst prowadząc węzeł używany jako klient do przekierowywania
ruchu atakującego: jeśli zmniejszamy RelayBandwidthRate, czy atak jest trudniejszy?
Jaki jest najwłaściwszy stosunek RelayBandwidthRate do rzeczywistej szybkości
łącza? Czy to w ogóle jest jakiś stosunek? Skoro już przy tym jesteśmy, czy znacznie
większy zbiór węzłów kandydujących zwiększa odsetek fałszywych wyników pozytywnych
lub innych trudności dla tego rodzaju ataku? (Sieć Tora jest teraz większa o prawie
dwa rzędy wielkości niż wtedy, gdy napisano ten dokument.) Przeczytaj też
<a href="http://freehaven.net/anonbib/#clog-the-queue">Nie zapychaj kolejki</a>.</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 rzeczywistoś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>Inne pytania badawcze dotyczące różnorodności geograficznej rozpatrują
 kompromis między wybieraniem obwodu wydajnego a losowego. Spójrz na <a
 href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">dokument o
 pozycjach</a> Stephena Rollysona na temat tego, jak odrzucać szczególnie wolne
 możliwości bez zbytniej utraty anonimowości. Ta argumentacja wymaga więcej pracy i
 myślenia, ale wygląda bardzo obiecująco.</li>

<li>Tor nie działa za dobrze, gdy przekaźnik sieci ma 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>Nasze cele w opieraniu się cenzurze to m.in. zapobieganie temu, by napastnik
podglądający ruch Tora mógł <a
href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint"
>odróżnić go od normalnego ruchu SSL</a>. Oczywiście, nie możemy osiągnąć idealnej
steganografii i dalej mieć użyteczną i działającą sieć, ale w pierwszym kroku
chcielibyśmy blokować jakiekolwiek ataki, które mogą się udać po obserwacji tylko
kilku pakietów. Jednym z pozostałych ataków, którego nie zbadaliśmy za bardzo,
polega na tym, że komórki Tora mają 512 bajtów, więc ruch w sieci może mieć długość
będącą wielokrotnością 512 bajtów. Jak bardzo wkładanie nowych danych
w nagłówkach TLS rozmywa ten fakt w transmisji? Czy inne strategie opróżniania bufora
w Torze mają na to wpływ? Czy trochę dokładania może bardzo pomóc, czy jest o atak,
z którym musimy żyć?</li>

<li>Obwody Tora 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 przekaźnik sieci 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 inne będą jeszcze dłuższe.
 Musimy zbadać ten kompromis wydajność/bezpieczeństwo.
 </li>
<li>Nie jest trudno wykonać atak DoS na przekaźniki sieci Tora lub centra 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 Tora.</li>
<li>Programy takie jak <a href="<page torbutton/index>">Torbutton</a>
 mają na celu ukrycie pola UserAgent przeglądarki, zastępując je jednakową odpowiedzią
 dla każdego użytkownika Tora. W ten sposób napastnik nie może złamać anonimowości
 Tora, patrząc na ten nagłówek. Aby się nie wyróżniać, program próbuje wybrać nazwy
 przeglądarek często używanych także przez tych, którzy nie używają Tora.
 Pytanie numer jeden: jak bardzo szkodzimy sami sobie, okresowo zwiększając
 wersję Firefoksa, za którego podaje się Torbutton? Jeśli aktualizujemy zbyt często,
 sami łamiemy swoją anonimowość. Jeśli za rzadko, to wszyscy użytkownicy Tora się
 wyróżniają ze względu na to, że twierdzą, iż używają starych wersji Firefoksa.
 Tutaj odpowiedź zależy pewnie na tym, które wersje Firefoksa są spotykane.
 Pytanie numer dwa: raz na jakiś czas ludzie pytają nas, byśmy krążyli po N
 nazwach UserAgent, zamiast trzymać się jednej. Czy to podejście pomaga, przeszkadza,
 czy nic nie wnosi? Weź pod uwagę: ciaseczka i rozpoznawanie użytkowników Tora poprzez
 ich zmieniające się nagłówki UserAgent, złe strony atakujące tylko określone
 przeglądarki; oraz to, czy odpowiedź na pytanie 1 wpływa na tę odpowiedź.
</li>
<li>W chwili obecnej klienci Tora mogą używać tego samego obwodu w ciągu dziesięciu
minut od jego pierwszego użycia. Celem tego jest uniknięcie przeładowania sieci
zbyt wielką liczbą operacji przedłużania obwodów, równocześnie unikając używania
obwodu tak długo, że węzeł wyjściowy mógłby stworzyć przydatny profil pseudonimowy
użytkownika. Dziesięć minut to jednak prawdopodobnie znacznie za dużo, zwłaszcza
gy przez ten sam obwód prowadzone sa połączenia różnych protokołów (np. IM i przeglądanie
sieci). Jeśli nie zmienimy całkowitej liczby obwodów, które należy utrzymywać, to czy
będą jakieś wydajniejsze lub bezpieczniejsze metody alokcaji strumieni do obwodów,
lub do tworzenia wywłaszczających obwodów? Być może ten temat badań powinien być rozpoczęty
poprzez zebranie śladów, jakie połączenia typowy użytkownik otwiera, by mieć coś
realistycznego do optymalizacji.
</li>
<li>Ile przekaźników mostkowych potrzeba, by utrzymać osiągalność? Powinniśmy zmierzyć
zajętość w naszych mostkach. Jeśli jest duża, czy są jakieś sposoby na zwiększenie
szans użytkowników mostków na pozostanie połączonymi?
</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

Mainetance/polish translation update.