pl/volunteer.wml (89d822f26) - tor-webwml.git

volunteer.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 4-optional
#include "head.wmi" TITLE="Tor: Volunteer" CHARSET="UTF-8"
<div class="main-column">

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

Tor ma <a href="<page open-positions>">dwa wolne etaty</a>, prosimy <a
href="<page contact>">skontaktuj się z nami</a>, jeśli masz kwalifikacje!

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Dokumentacja</a></h2>
<ol>
<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>
<li>Evaluate and document <a
href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO">our
list of programs</a> that can be configured to use Tor.</li>
<li>We have a huge list of <a
href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/SupportPrograms">potentially
useful programs that interface to Tor</a>. Which ones are useful in which
situations? Please help us test them out and document your results.</li>
</ol>

<a id="Advocacy"></a>
<h2><a class="anchor" href="#Advocacy">Pokazanie się jako zwolennik Tora</a></h2>
<ol>
<li>Create a <a
href="https://trac.torproject.org/projects/tor/wiki/CommunityLogos">community
logo</a> under a Creative Commons license that all can use and modify</li>
<li>Stwórz prezentację, której będzie można używać na spotkaniach różnych grup
na całym świecie</li>
<li>Create a video about the positive uses of Tor, what Tor is, or how to use
it. Some have already started on <a
href="http://media.torproject.org/video/">Tor's Media server</a>, <a
href="http://www.howcast.com/videos/90601-How-To-Circumvent-an-Internet-Proxy">Howcast</a>,
and <a href="http://www.youtube.com/thetorproject">Youtube</a>.</li> 
<li>Stwórz plakat, lub zestaw plakatów, skupionych na jakimś motywie, np. "Tor
to Wolność!"</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 2010</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 &mdash; co
często daje najlepsze programy.

<ol>

<li>
Paczka Tora z Przeglądarką dla Mac OS X Priorytet:
Wysoki Poziom wysiłku: Wysoki Poziom
umiejętności: Średni Prawdopodobni opiekunowie: Steven,
Erinn, Andrew, Jacob Paczka Tora z Przeglądarką zawiera Tora,
Firefoksa, Polipo i interfejs użytkownika - Vidalię (i opcjonalnie
komunikator <a href="http://pidgin.im/">Pidgin</a>). 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 działającej paczki dla Mac OS X, więc celem tego projektu byłaby
implementacja Paczki Tora z Przeglądarką dla OS X. 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ść. Część pracy w tym temacie
została wykonana w czasie Google Summer of Code 2009. Kolejną częścią
projektu będzie zidentyfikowanie wszystkich śladów pozostawionych na
komputerze przez korzystanie z Paczki Tora z Przeglądarką na Linuksie lub
Mac OS X. Rozwijanie sposobów na powstrzymanie, przeciwdziałanie lub
usuwanie tych śladów będzie ostatnim krokiem. 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. 
Częścią tego projektu byłoby testowanie użyteczności Paczki Tora z
Przeglądarką, najlepiej pośród naszej widowni docelowej. To pomogłoby w
dowiedzeniu się, co musi zostać zrobione w kontekście usuwania błędów lub
dodawania nowych funkcjonalności. W tej chwili dostajemy to nieformalnie, a
lepszy byłby proces mający strukturę. Wersja beta Paczki Tora z
Przeglądarką została wydana dla systemu GNU/Linux, ale wymagane jest więcej
pracy w Paczce Tora z Przeglądarką i IM. Prace trwają też już dla wersji Mac
OS X. Jeśli chcesz pomóc w rozszerzeniu, przeprowadzać audyty bezpieczeństwa
(lub obie te rzeczy), skontaktuj się z Erinn.
</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>
Rewrite TorDNSEL, this time with a spec! Priority: High
 Effort Level: Medium Skill Level: Medium 
Likely Mentors: Mike, Roger, Sebastian, Damian The <a
href="<page tordnsel/index>">Tor DNS Exit List</a> is an unmaintained
Haskell program that serves three purposes. First, it provides an rbl-style
DNS interface for people to look up whether a given IP address is (or has
recently been) a Tor exit relay. Second, it actively builds circuits over
the Tor network and connects back to itself, to learn the actual exit IP
address of each relay &mdash; some Tor relays exit from a different address
than they advertise in their descriptor. Third, it exports a <a
href="http://exitlist.torproject.org/exitAddresses">set of conclusions</a>
so that <a href="https://check.torproject.org/">check.torproject.org</a> can
guess for you whether your browser is configured to point to Tor. 
This project would make use of <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, a
set of Python scripts to interact with Tor, to figure out how our Tor Exit
Checker should actually work, and then build it &mdash; probably in Python
since Torflow is in Python. The main goal is to reduce false positives as
much as possible, by making sure that it learns about new relays as soon as
possible, making sure that the testing phase concludes quickly, and making
sure the answers get passed to the Check script quickly. As a bonus, we
should standardize (specify) the format of the exitAddresses file, and
rewrite the <a
href="https://svn.torproject.org/svn/check/trunk/cgi-bin/TorBulkExitList.py">Tor
Bulk Exit List</a> script to use that file rather than its current <a
href="https://trac.torproject.org/projects/tor/ticket/1019">horrible DNS
hacks</a>. As an extra bonus, we should work with Freenode, OFTC, and/or
other IRC networks to make sure that the scripts we offer are actually the
scripts they want, in terms of accurately identifying which of their users
are coming from the Tor network. You can fetch the <a
href="git://git.torproject.org/git/tordnsel">latest tordnsel</a> via git.
</li>

<li>
Polepszanie naszych zdolności opierania się cenzurze 
Priorytet: Średni do wysokiego Poziom wysiłku: Średni do
wysokiego Poziom umiejętności: Wysoki Prawdopodobni
opiekunowie: Nick, Roger, Steven Wersje 0.2.1.x Tora robią <a
href="<svnprojects>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. Jedną z dużych kategorii jest dodawanie funkcjonalności do naszej usługi
<a href="http://gitweb.torproject.org//bridgedb.git?a=tree">bridgedb</a>
(Python). Tor chce dawać <a href="<page bridges>">adresy przekaźników
mostkowych</a> użytkownikom nie mogącym bezpośrednio połączyć się z siecią
Tora, ale trwa wyścig zbrojeń między algorytmami dystrybucji adresów a
algorytmami do zbierania i blokowania adresów. Przeczytaj <a
href="https://blog.torproject.org/blog/bridge-distribution-strategies">nasz
wpis o tym na blogu</a> jako wprowadzenie, a potem spójrz na <a
href="http://archives.seul.org/or/dev/Dec-2009/msg00000.html">post Rogera na
or-dev</a> z grudnia, by poznać nowsze pomysły &mdash; pozostało do
zrobienia wiele pracy projektowej. Jeśli chcesz wejść bardziej we
wnętrze samego Tora (C), pomniejszym problemem, którym powinniśmy się zająć
jest to, że bieżące wersje mogą nasłuchiwać połączeń tylko na jednym
zestawie adres/port na raz. Istnieje <a
href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">propozycja
zajęcia się tą sprawą</a> i umożliwienia klientom łączenią się z danym Torem
na wielu adresach i portach, ale wymaga to więcej pracy. 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!
 
Priority: Medium to High
 
Effort Level: Medium to High
 
Skill Level: High
 
Likely Mentors: Nick, Roger, Mike, Karsten
 
Right now, Tor relays measure and report their own bandwidth, and Tor
clients choose which relays to use in part based on that bandwidth.
This approach is vulnerable to
<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
relays lie about their bandwidth</a>;
to address this, Tor currently caps the maximum bandwidth
it's willing to believe any relay provides. This is a limited fix, and
a waste of bandwidth capacity to boot. Instead,
Tor should possibly measure bandwidth in a more distributed way, perhaps
as described in the
<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
Tor"</a> paper
by Snader and Borisov. One could use current testing code to
double-check this paper's findings and verify the extent to which they
dovetail with Tor as deployed in the wild, and determine good ways to
incorporate them into their suggestions Tor network without adding too
much communications overhead between relays and directory
authorities.
</li>-->
<li>
Ulepszenie Polipo na Windows Priorytet: Średni do
Wysokiego Poziom wysiłku: Średni Poziom
umiejętności: Średni Prawdopodobni opiekunowie: Chris
 Pomóż przenieść <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> na
Windows. Przykładowe tematy to:
<ol><li> zdolność do asynchronicznego wysyłania zapytań do serwerów nazw, znajdowania
systemowych serwerów nazw i zarządzanie zapytaniami NetBIOS i DNS.</li>
<li> 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).</li>
<li> 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.</li>
<li> umożliwienie programowi używania rejestru Windowsa i obsługiwania
prawidłowych ścieżek w Windowsie, np. "C:\Program Files\Polipo".</li>
</ol>
</li>

<li>
Interfejs zdarzeń stanu kontrolera Tora dla programu Vidalia 
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ć 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,
Erinn 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óż w niezależnych implementacjach klienta Tora Priorytet:
Średni Poziom wysiłku: Wysoki Poziom
umiejętności: Średni do wysokiego Prawdopodobni opiekunowie:
Karsten, Nick Pracujemy w tej chwili nad klientami Tora dla
środowisk Java, Android i Maemo. Pierszym krokiem byłoby zapoznanie się z
bieżacym stanem projektu, któremu chcesz pomóc; <a
href="http://github.com/brl/JTor">Tor dla Javy</a>, <a
href="https://svn.torproject.org/svn/projects/android/trunk/">Android/Orbot
lub <a href="<page docs/N900>">Tor dla Maemo</a>. Pobierz repozytorium i
zapoznaj się z kodem źródłowym. Ponadto, 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, poprawiać
dokumentację, jeśli jest niejasna. Ten projekt składa się w dużym stopniu
pisania kodu i w mniejszym - z projektowania.
</li>
<li>
Więcej o Orbocie i rozwoju specyficznym dla systemu Android Priorytet: Średni Poziom wysiłku: Wysoki 
Poziom umiejętności: Średni do Wysokiego Prawdopodobni
opiekunowie: Nathan Praca z interfejsem użytkownika w Javie
na Androidzie: Lepszy ekran powitalny, by pokazywać lepsze statystyki o
transferze danych (wysyłanie/odbieranie), liczbie podłączonych obwodów,
jakości połączenia i tak dalej. Aplikacja "Tether Wifi" na Androida jest
dobrym modelem do naśladowania w tym, jak pokazuje w czasie rzeczywistym
ilość wysłanych i odebranych bajtów, jak również powiadomienia o połączeniu
klienta wifi. Ponadto, lepsze wyświetlanie/załatwianie wiadomości
systemowych lub o błędach Tora też byłoby bardzo pomocne. W końcu dodanie
kreatora lub przewodnika dla początkujących użytkowników, by wyjaśnić im, co
jest, a co nie jest anonimizowane lub chronione, bardzo zwiększyłoby
prawdopodobieństwo, że będą używać Orbota prawidłowo. Praca z
systemem w Javie/wnętrzem aplikacji: Lepszy wskaźnik systemowy, poprzez
pasek powiadomień, okna dialogowe "Toast" lub inny mechanizm, że dane
aplikacji są rzeczywiście przekazywane przez Orbota/Tora. Na przykład, teraz
musisz najpierw wejść na usługę torcheck, by upewnić się, że Twoja
przeglądarka przechodzi przez Tora. Orbot powinien móc powiadamiać Cię, że
obwody są otwierane, używane itd. Wspomniane wcześniej śledzenie transferu
danych też mogłoby dostarczać tego typu uświadamiania. Praca z
biblioteką Javy w Androidzie/Zasięgiem w społeczeństwie Potrzebujemy
mieć paczkę z prostą biblioteką do wykorzystania z aplikacjami innych
producentów, by łatwo umożliwić im "Toryfikację" na nie-głównych
urządzeniach (bez przezroczystego proxy) Ta biblioteka powinan zwierać
owijkę na bibliotekę Apache HTTPClient, klasę narzędziową do sprawdzenia
stanu połączenia Orbota i inne istotne/przydatne rzeczy, których aplikacja
na Androida może potrzebować do zanonimizowania się. Ta praca powinna
składać się ze stworzenia biblioteki, dokumentacji i przykładowego
kodu. Wychodzenie z tym projektem lub podjęcie wysiłku implementacji
biblioteki w innych otwartych aplikacjach byłoby następnym
krokiem. Praca Android OS/C/Linux przeniesienie Tora na
Androida jest w zasadzie prostą kompilacją na Linux ARM. Nie została
wykonana żadna praca odnośnie optymalizacji Tora w środowisku sprzętu
przenośnego na prcesorze ARM lub innym sprzęcie z Androidem lub w sieciach
mobilnych. Należy zauważyć, że nawet bez optymalizacji, Tor bardzo dobrze
radzi sobie ze środowiskiem sieci mobilnych, automatycznie wykrywając zmiany
adresu IP, ponownie łącząc obwody itd, przełączając się z 2G na 3G i Wifi i
tak dalej. 
</li>

<!--<li>

New Torbutton Features
 
Priority: Medium
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
There are several <a
href="https://trac.torproject.org/projects/tor/report/14">good
feature requests</a> on the Torbutton Trac section. In particular, <a
href="https://trac.torproject.org/projects/tor/ticket/523">Integrating
'New Identity' with Vidalia</a>,
<a href="https://trac.torproject.org/projects/tor/ticket/940">ways of
managing multiple cookie jars/identities</a>, 
<a href="https://trac.torproject.org/projects/tor/ticket/637">preserving
specific cookies</a> when cookies are cleared,
<a
href="https://trac.torproject.org/projects/tor/ticket/524">better
referrer spoofing</a>, <a
href="https://trac.torproject.org/projects/tor/ticket/564">correct
Tor status reporting</a>, and <a
href="https://trac.torproject.org/projects/tor/ticket/462">"tor://"
and "tors://" urls</a> are all interesting
features that could be added.
 
This work would be independent coding in Javascript and the fun world of <a
href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
with not too much involvement in the Tor internals.
</li>-->
<!-- <li>

New Thandy Features
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Martin
 
Additional capabilities are needed for assisted updates of all the Tor
related software for Windows and other operating systems. Some of the
features to consider include:
<ol>
<li> Integration of the <a
href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
Python library</a>
for authenticated HTTPS downloads.</li>
<li> Adding a level of indirection
between the timestamp signatures and the package files included in an
update. See the "Thandy attacks / suggestions" thread on or-dev.</li>
<li> Support locale specific installation and configuration of assisted
updates based on preference, host, or user account language settings.
Familiarity with Windows codepages, unicode, and other character sets
is helpful in addition to general win32 and posix API experience and
Python proficiency.</li>
</ol>
</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ć użytkownikowi możliwość
klikania na dany przekaźnik lub kraj z co najmniej jednym przekaźnikiem i
stwierdzenia "chcę, by moje połączenia 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>
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>

Intermediate Level Network Device Driver
 
Priority: Low
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Martin
 
The WinPCAP device driver used by Tor VM for bridged networking does
not support a number of wireless and non-Ethernet network adapters.
Implementation of a intermediate level network device driver for win32
and 64bit would provide a way to intercept and route traffic over such
networks. This project will require knowledge of and experience with
Windows kernel device driver development and testing. Familiarity with
Winsock and Qemu would also be helpful.
</li>-->
<li>
Ulepszenie Pogody Tora Priorytet: Średni Poziom
wysiłku: Średni Poziom umiejętności: Średni 
Prawdopodobni opiekunowie: Christian, Roger, Damian <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>
Poprawa interakcji dla Tora+Vidalii na platformach Linux/Unix 
Priorytet: Średni Poziom wysiłku: Średni Poziom
umiejętności: Średni Prawdopodobni opiekunowie: Erinn,
Peter Vidalia w chwili obecnej nie działa dobrze z Torem na
platformach Linux iUnix. W chili obecnej na Debianie i Ubuntu jest mechanizm
konfiguracji, który pozwala Vidalii na obejście zdolności Tora do
uruchamiania się przy starcie systemu (poprzez wykonanie
<code>/etc/default/tor.vidalia</code>, który ustawia
<code>RUN_DAEMON=no</code> na żądanie użytkownika), ale ciągle wymagana jest
pełna implementacja komunikacji z <a
href="<gitblob>doc/spec/control-spec.txt">ControlPort</a>. Lepszym
rozwiązaniem na platformach Linux i Unix byłoby wykorzystanie ControlSocket
Tora, który umożliwia Vidalii komunikowanie się z Torem poprzez gniazdo
domeny Unix, i który mógłby być domyślnie włączony w paczkach
dystrybucyjnych Tora. Vidalia może się wtedy uwierzytelniać z Torem,
korzystajac z uwierzytelniania opartego na systemie plików (ciasteczka),
jeśli użytkownik, który uruchamia Vidalię jest też w specyficznej dla
dystrybucji grupie tor. Ten projekt najpierw będzie wymagał dodania
obsługi ControlSocket Tora do Vidalii. Student potem rozwinie i sprawdzi tę
obsługę na różnych dystrybucjach, by upewnić się, że działa w sposób
przewidywalny i spójny na nich wszystkich. Kolejnym wyzwaniem byłoby
znalezienie użytecznego i intuicyjnego sposobu na to, by Vidalia mogła
zmieniać konfigurację Tora (torrc), mimo iż jest umieszczona w
<code>/etc/tor/torrc</code> i przez to niezmienna. Na Debianie i Ubuntu
zajmujemy się tym poprzez wspomniany wcześniej
<code>/etc/default/tor.vidalia</code>, ale ta funkcjonalność mogłaby (lub
powinna) być mniej zależna od dystrybucji. Najlepszy jak dotąd pomysł
jest taki, aby przekazywać Torowi nową konfigurację poprzez ControlSocket w
czasie startu Vidalii, ale jest to złe rozwiazanie, gdyż jeśli użytkownik
nie korzysta z najnowszysch paczek dla Debiana/Ubuntu, mógł nie wyłączyć
możliwości Tora do uruchamiania się w czasie startu systemu, co skończy się
tym, że będzie mieć konfigurację inną niż ta, którą chciał. Drugi najlepszy
jak dotąd pomysł jest taki, by Vidalia tworzyła tymczasowy plik torrc i
prosiła użytkownika, aby ręcznie przeniósł go do
<code>/etc/tor/torrc</code>, ale to jest złe rozwiązanie, gdyż użytkownicy
nie powinni musieć grzebać w katalogach z plikami. Osoba podejmująca
się tego projektu powinna mieć wiedzę o różnych dystrybucjach Linuksa i ich
mechanizmach paczek, jak również trochę doświadczenia z pisaniu w
C++. Uprzednie doświadczenie z Qt będzie przydatne, ale nie jest wymagane.
</li>

<!--<li>

Tor/Polipo/Vidalia Auto-Update Framework
 
We're in need of a good authenticated-update framework.
Vidalia already has the ability to notice when the user is running an
outdated or unrecommended version of Tor, using signed statements inside
the Tor directory information. Currently, Vidalia simply pops
up a little message box that lets the user know they should manually
upgrade. The goal of this project would be to extend Vidalia with the
ability to also fetch and install the updated Tor software for the
user. We should do the fetches via Tor when possible, but also fall back
to direct fetches in a smart way. Time permitting, we would also like
to be able to update other
applications included in the bundled installers, such as Polipo and
Vidalia itself.
 
To complete this project, the student will first need to first investigate
the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
their strengths, weaknesses, security properties, and ability to be
integrated into Vidalia. If none are found to be suitable, the student
will design their own auto-update framework, document the design, and
then discuss the design with other developers to assess any security
issues. The student will then implement their framework (or integrate
an existing one) and test it.
 
A person undertaking this project should have good C++ development
experience. Previous experience with Qt is helpful, but not required. One
should also have a good understanding of common security
practices, such as package signature verification. Good writing ability
is also important for this project, since a vital step of the project
will be producing a design document to review and discuss
with others prior to implementation.
</li>-->
<li>
Polepszenie procesu QA Tora: Ciągła integracja dla paczek 
Priorytet: Średni Poziom wysiłku: Średni Poziom
umiejętności: Średni Prawdopodobni opiekunowie: Erinn
 Przydałby się automatyczny system tworzenia paczek dla Windows i być
może innych systemów. Celem posiadania środowiska ciągłej integracji jest
upewnienie się, że Windows nie zostanie w tyle z żadnym z projektów
używanych lub związanych z projektem Tor. Buildbot może być dobrym
rozwiązaniem, gdyż zdaje się obsługiwać te same platformy, co
Tor. Przeczytaj (po angielsku) <a
href="http://en.wikipedia.org/wiki/BuildBot">wpis na Wikipedii dotyczący
Buildbota</a>. Może jednak są lepsze rozwiązania, więc osoba
podejmująca się tego zadania powinna rozważyć inne opcje. Jakakolwiek osoba
pracująca nad tym systemem automatycznego budowania powinna mieć
doświadczenie lub chęć do nauczenia się tego, jak buduje się wszystkie
odpowiednie elementy Tora od zera. Ponadto, ta osoba powinna mieć jakieś
doświadczenie w kompilowaniu programów w Windows, jako że to jest ta część
użytkowników, których nie chcemy zostawiać w tyle. Zadanie będzie wymagała
bliskiej pracy z kodem Tora, ale prawdopodobnie tylko od strony kompilacji,
nie pisania. Ponadto, musimy zautomatyzować nasze testy wydajności dla
wszystkich systemów. Mamy już buildbota (za wyjątkiem Windows &mdash; jak
napisane powyżej) do automatyzacji naszej zwyczajnej integracji i kompilacji
testów, ale musimy zaktualizować nasze testy symulacji sieci (takie, jak w
torflow) 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>

Usability testing of Tor
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Low to Medium
 
Likely Mentors: Andrew
 
Especially the browser bundle, ideally amongst our target demographic.
That would help a lot in knowing what needs to be done in terms of bug
fixes or new features. We get this informally at the moment, but a more
structured process would be better.
</li>-->
<li>
Uwierzytelniające proxy dla IRC Priorytet: Niski 
Poziom wysiłku: Średni do Wysokiego Poziom umiejętności:
Średni do Wysokiego Prawdopodobni opiekunowie: Sebastian,
Weasel, Roger Świat potrzebuje uwierzytelniającego serwera
pośredniczącego (proxy) dla IRC. Jak przypomina się na okresowo w komiksie
internetowym Penny Arcade, "Użytkownik Internetu + anonimowość =
pacan". Odnoścnie stron internetowych, dobrze się sprawujemy, gdyż strony
mogą zmusić swoich użytkowników do logowania i użyuwać innych podejść do
uwierzytelniania na poziomie aplikacji. Ale serwery IRC są znacznie gorsze,
gdyż kod większości serwerów IRC jest źle napisany: trudny w utrzymaniu,
jeszcze trudniejszy w zmienianiu. Wiele sieci IRC blokuje teraz połączenia z
Tora, zostaliśmy praktycznie na dwóch przyczółkach (OFTC i Freenode). Ten
stan rzeczy oznacza, że wielu ludzi na świecie myśli "Mówiłem, że tak
będzie" o anonimowości on-line, podczas gdy w rzeczywistości problemem jest
brak technologii, które umożliwiłyby zarządzanie tym problemem. Musimy mieć
jakiś sposób na umożliwienie sieciom IRC rozróżnianie, którzy użytkownicy
wyrobili sobie reputację nie bycia pacanami, by mogli traktować te dwie
grupy osobno. Są jakieś naprawdę fajne projekty badawcze jak <a
href="http://www.cs.dartmouth.edu/~nymble/">Nymble</a>, których celem jest
umozliwienie stronom internetowym wpisywanie użytkowników na czarną listę
bez wiedzy, kim oni są. Ale Nymble opiera się na interakcjach ze stronami
internetowymi. Musimy stworzyć klej wokół protokołu IRC, który umożliwiłby
nam włożenie projektu taiego jak Nymble (lub na początek jakiegoś
prostszego, jako dowód działania). Jednym ze sposobów na zrobienie tego
byłoby zbudowanie proxy dla IRC, które wiedziałoby, jak rozmawiać z
klientami i serwerami i posiadałoby dodatkową warstwę, która wymaga
uwierzytelnienia od użytkowników. Trochę pracy w tym temacie zostało
wykonane przez innych wolontariuszy, zobacz ich postęp na <a
href="http://github.com/anonirc/orc">http://github.com/anonirc/orc</a>.
</li>

<li>
Więcej pracy nad torsocks/dsocks na OS X Priorytet:
Średni Poziom wysiłku: Średni Poziom
umiejętności: Średni Prawdopodobni opiekunowie: ? <a href="http://code.google.com/p/torsocks/">Torsocks</a> i <a
href="http://code.google.com/p/dsocks/">dsocks</a> są owijkami, które
uruchamiają aplikacje, przechwytują ich wychodzące połaczenia sieciowe i
wysyłają je przez Tora. Celem jest obsługa aplikacji, które nie obsługują
serwerów pośredniczących (lub obsługują je słabo). By to działało dobrze,
musimy przechwytywać wiele wywołań systemowych. Funkcje systemowe, które
trzeba przechwytywać na Linuksie różnią się znacznie od tych na BSD. Dlatego
Torsocks działa dobrze na Linuksie, dsocks działa dobrze na BSD (choć zdaje
się, że mniej osób się nim zajmuje, więc może mu brakować niektórych funkcji
systemowych), a nic nie działa dobrze na obu. Po pierwsze, powinniśmy
załatać dsocks, by używał komend mapaddress Tora z jego interfejsu
kontrolera, byśmy nie marnowali całego przejścia przez Tora, robiąc
rozwiązanie nazw przed połączeniem. Po drugie, powinniśmy sprawić, by nasz
skrypt torify wykrywał, który z torsocks lub dsocks jest
zainstalowany i wywoływać je odpowiednio. To prawdopodobnie oznacz
unifikację ich interfejsów i może oznaczać współdzielenie kodu między nimi
lub całkowite odrzucenie jednego.
</li>

<li>
Przynieś nowe pomysły! Nie podoba Ci się żaden z tych pomysłów?
Sięgnij do <a href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">planu
rozwoju Tora</a> po więcej pomysłów lub po prostu wypróbuj Tora, Vidalię,
Torbutton i dowiedz się, co Twoim zdaniem wymaga poprawy. Niektórym z <a
href="<gittree>doc/spec/proposals/">bieżących propozycji</a> też może
brakować deweloperów.
</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>Tor relays don't work well on Windows XP. On Windows, Tor uses the standard
<tt>select()</tt> system call, which uses space in the non-page pool. This
means that a medium sized Tor relay will empty the non-page pool, <a
href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/WindowsBufferProblems">causing
havoc and system crashes</a>. We should probably be using overlapped IO
instead. One solution would be to teach <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use
overlapped IO rather than select() on Windows, and then adapt Tor to the new
libevent interface. Christian King made a <a
href="https://svn.torproject.org/svn/libevent-urz/trunk/">good start</a> on
this in the summer of 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 uses TCP for transport and TLS for link encryption. This is nice and
simple, but it means all cells on a link are delayed when a single packet
gets dropped, and it means we can only reasonably support TCP streams. We
have a <a
href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.">list
of reasons why we haven't shifted to UDP transport</a>, but it would be
great to see that list get shorter. We also have a proposed <a
href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification for
Tor and UDP</a> &mdash; please let us know what's wrong with it.</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ć różne systemy LiveCD/USB łatwiejszym w utrzymaniu,
ulepszaniu i dokumentowaniu? Jednym z przykładów jest <a
href="http://anonymityanywhere.com/incognito/">(Amnesic) Incognito Live
System</a>
</li>

<li>
Kolejny projekt przeciw cenzurze to próba uczynienia Tora bardziej odpornym
na skanowanie. W chwili obecnej ktokolwiek może zidentyfikować <a
href="<gitblob>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="<svnprojects>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. Na początek, sprawdź<a
href="http://dl.dropbox.com/u/37735/index.html">pracę i prototyp</a>Shane'a
Pope.
</li>

</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Badania</a></h2>
<ol>
<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="<svnprojects>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. Czy 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 gdy 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

new and updated translations for the website