Tor: Volunteer

Kilka rzeczy, które każdy może zrobić już teraz:

Prosimy rozważyć uruchomienie przekaźnika sieci Tor, by wspomóc rozwój sieci Tora.
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.
Jeśli podobają ci się cele Tora, poświęć chwilę, by złożyć dotację, aby wspomóc przyszły rozwój Tora. Szukamy też dalszych sponsorów — 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.
Szukamy więcej dobrych przykładów użytkowników Tora i przypadków jego używania. 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ść.

Tor ma dwa wolne etaty, prosimy skontaktuj się z nami, jeśli masz kwalifikacje!

Dokumentacja

Pomóż przetłumaczyć stronę WWW i dokumentację na inne języki. Spójrz na wskazówki do tłumaczenia, 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.
Evaluate and document our list of programs that can be configured to use Tor.
We have a huge list of potentially useful programs that interface to Tor. Which ones are useful in which situations? Please help us test them out and document your results.

Pokazanie się jako zwolennik Tora

Create a community logo under a Creative Commons license that all can use and modify
Stwórz prezentację, której będzie można używać na spotkaniach różnych grup na całym świecie
Create a video about the positive uses of Tor, what Tor is, or how to use it. Some have already started on Tor's Media server, Howcast, and Youtube.
Stwórz plakat, lub zestaw plakatów, skupionych na jakimś motywie, np. "Tor to Wolność!"

Dobre Projekty Programistyczne

Niektóre z tych projektów mogą być dobrymi pomysłami na Google Summer of Code 2010. 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 głównych deweloperów byliby dobrymi opiekunami. Jeśli jeden lub więcej z tych pomysłów wygląda dla Ciebie obiecująco, skontaktuj się z nami, 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.

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 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 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.
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 TorFlow, 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 Stan Tora lub być trzymane osobno. Skoro mówimy o stronach stanu Tora, spójrzcie na listę życzeń stanu Tora napisaną przez Rogera.
Rewrite TorDNSEL, this time with a spec!
Priority: High
Effort Level: Medium
Skill Level: Medium
Likely Mentors: Mike, Roger, Sebastian, Damian
The Tor DNS Exit List 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 — some Tor relays exit from a different address than they advertise in their descriptor. Third, it exports a set of conclusions so that check.torproject.org can guess for you whether your browser is configured to point to Tor.
This project would make use of TorFlow, a set of Python scripts to interact with Tor, to figure out how our Tor Exit Checker should actually work, and then build it — 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 Tor Bulk Exit List script to use that file rather than its current horrible DNS hacks. 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 latest tordnsel via git.
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ą znaczne postępy 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 bridgedb (Python). Tor chce dawać adresy przekaźników mostkowych 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 nasz wpis o tym na blogu jako wprowadzenie, a potem spójrz na post Rogera na or-dev z grudnia, by poznać nowsze pomysły — 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 propozycja zajęcia się tą sprawą 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łą.
Ulepszenie Polipo na Windows
Priorytet: Średni do Wysokiego
Poziom wysiłku: Średni
Poziom umiejętności: Średni
Prawdopodobni opiekunowie: Chris
Pomóż przenieść Polipo na Windows. Przykładowe tematy to:
1. zdolność do asynchronicznego wysyłania zapytań do serwerów nazw, znajdowania systemowych serwerów nazw i zarządzanie zapytaniami NetBIOS i DNS.
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".
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.
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 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.
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; Tor dla Javy, Android/Orbot lub Tor dla Maemo. 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.
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.
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.
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.
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.
Ulepszenie Pogody Tora
Priorytet: Średni
Poziom wysiłku: Średni
Poziom umiejętności: Średni
Prawdopodobni opiekunowie: Christian, Roger, Damian
Pogoda Tora 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 T-Shirt 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 README i TODO.
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 /etc/default/tor.vidalia, który ustawia RUN_DAEMON=no na żądanie użytkownika), ale ciągle wymagana jest pełna implementacja komunikacji z ControlPort.
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 /etc/tor/torrc i przez to niezmienna. Na Debianie i Ubuntu zajmujemy się tym poprzez wspomniany wcześniej /etc/default/tor.vidalia, 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 /etc/tor/torrc, 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.
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) wpis na Wikipedii dotyczący Buildbota.
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 — 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.
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 Nymble, 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 http://github.com/anonirc/orc.
Więcej pracy nad torsocks/dsocks na OS X
Priorytet: Średni
Poziom wysiłku: Średni
Poziom umiejętności: Średni
Prawdopodobni opiekunowie: ?
Torsocks i dsocks 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.
Przynieś nowe pomysły!
Nie podoba Ci się żaden z tych pomysłów? Sięgnij do planu rozwoju Tora po więcej pomysłów lub po prostu wypróbuj Tora, Vidalię, Torbutton i dowiedz się, co Twoim zdaniem wymaga poprawy. Niektórym z bieżących propozycji też może brakować deweloperów.

Inne pomysły związane z programowaniem i projektowaniem

Tor relays don't work well on Windows XP. On Windows, Tor uses the standard select() system call, which uses space in the non-page pool. This means that a medium sized Tor relay will empty the non-page pool, causing havoc and system crashes. We should probably be using overlapped IO instead. One solution would be to teach libevent how to use overlapped IO rather than select() on Windows, and then adapt Tor to the new libevent interface. Christian King made a good start on this in the summer of 2007.
Musimy zacząć budować nasz projekt odporny na blokowanie. Wchodzi w to przemyślenie projektu, zmiana wielu różnych elementów Tora, zaadaptowanie Vidalii, by obsługiwała nowe cechy i planowanie rozpowszechniania.
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 poniżej o atakach potwierdzenia po szczegóły strony badawczej tego zadania — kto wie, może gdy będzie skończone, pomożesz nam też napisać dokumentację.
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.
Dokonać analizy bezpieczeństwa Tora z "fuzz". Sprawdzić, czy istnieją jakieś dobre biblioteki "fuzz", których nam potrzeba. Zdobądź sławę gdy wydamy nową wersję dzięki Tobie!
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 list of reasons why we haven't shifted to UDP transport, but it would be great to see that list get shorter. We also have a proposed specification for Tor and UDP — please let us know what's wrong with it.
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.
Potrzebujemy sposobu na generowanie diagramów na stronie (na przykład, obrazków "Jak działa Tor" na stronie wprowadzenia 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.
Jak można uczynić różne systemy LiveCD/USB łatwiejszym w utrzymaniu, ulepszaniu i dokumentowaniu? Jednym z przykładów jest (Amnesic) Incognito Live System
Kolejny projekt przeciw cenzurze to próba uczynienia Tora bardziej odpornym na skanowanie. W chwili obecnej ktokolwiek może zidentyfikować mostki Tora 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 udawać serwery internetowe (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źpracę i prototypShane'a Pope.

Badania

"Atak potwierdzenia w ruchu nadawca-odbiorca" (end-to-end traffic confirmation attack): obserwując ruch od Alicji do Boba, możemy porównać sygnatury ruchu i przekonać się, że obserwujemy ciągle ten sam strumień danych. 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?
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 adaptacyjnego dopełniania, 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?
Powtórzcie atak z Oakland 05 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ż Nie zapychaj kolejki.
"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 często zdarza się, że ten sam SA pojawia się zarówno na ścieżce wejściowej i wyjściowej. 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?
Inne pytania badawcze dotyczące różnorodności geograficznej rozpatrują kompromis między wybieraniem obwodu wydajnego a losowego. Spójrz na dokument o pozycjach 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.
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.
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 eksperymencie przepustowości SSH. Będziemy musieli mierzyć i podkręcać, i być może wykonać poprawki, jeśli wyniki okażą się dobre.
Nasze cele w opieraniu się cenzurze to m.in. zapobieganie temu, by napastnik podglądający ruch Tora mógł odróżnić go od normalnego ruchu SSL. 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ć?
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.
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.
Programy takie jak Torbutton 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ź.
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.
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?

Daj nam znać, jeśli poczyniłeś postępy nad którąkolwiek z tych rzeczy!