it/volunteer.wml (f4870485a) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 13989
# Last-Translator: jan at seul dot org

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

<h2>Tre cose che puoi fare subito:</h2>
<ol>
<li>Puoi <a href="<page docs/tor-doc-relay>">realizzare
un relay</a> per aiutare a far crescere la rete Tor.</li>
<li>Parla coi tuoi amici! Fagli realizzare un relay. Fagli aprire degli hidden
services. Falli parlare di Tor coi loro amici.</li>
<li>Cerchiamo finanziamenti e sponsor. Se ne apprezzi gli obiettivi, per favore
 <a href="<page donate>">fai una donazione per sostenere
lo sviluppo di Tor</a>. Se conosci qualche azienda, ente o
associazione che ha bisogno di sicurezza nelle
comunicazioni, fagli conoscere il progetto Tor.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
<ol>
<li>Servono altri buoni metodi per intercettare le richieste DNS in modo che non siano svelate
a un osservatore locale mentre cerchiamo di essere anonimi. (Ci&ograve;
succede se l'applicazione esegue la risoluzione DNS prima di rivolgersi
al proxy SOCKS.)</li>
<li>Tsocks/dsocks:
<ul>
<li>C'&egrave; bisogno di <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">applicare
tutte le nostre patch a tsocks</a> e mantenerne un nuovo fork. Lo possiamo ospitare sul
nostro server se vuoi.</li>
<li>Bisognerebbe applicate le patch al programma "dsocks" di Dug Song in modo che usi
i comandi mapaddress di Tor dall'interfaccia di controllo, cos&igrave;
da non sprecare un intero ciclo in Tor per fare la risoluzione prima di
connettersi.</li>
<li>Dobbiamo fare in modo che il nostro script torify distingua se siano installati tsocks o
dsocks, e li chiami di conseguenza. Ci&ograve; significa probabilemnte
unificarne le interfacce e potrebbe essere necessario condividere del codice tra di essi
o scartarne uno direttamente.</li>
</ul>
</li>
<li>Chi gestisce un relay spesso vuole avere un BandwidthRate
durante parte della giornata, e un altro BandwidthRate nell'altra
parte del giorno. Invece di programmarlo dentro Tor, sarebbe bello avere
un piccolo script che parla tramite la <a href="<page gui/index>">Tor
Controller Interface</a> e fa un setconf per modificare la banda disponibile.
Ce n'&egrave; gi&agrave; uno per Unix e Mac (usa bash e cron),
ma gli utenti Windows hanno ancora bisogno di una soluzione.
</li>
<li>Tor pu&ograve; <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">uscire dalla
rete Tor network da un particolare exit node</a>, ma dovremmo riuscire a
specificare solo una certa nazione e fare scegliere l'exit node automaticamente. La
cosa migliore sembra prendere la directory Blossom e usare un client Blossom
locale che recuperi la directory in modo sicuro (via Tor e verificandone la
firma), intercetti i <tt>.country.blossom</tt> hostname, e faccia
la cosa giusta.</li>
<li>A proposito di geolocalizzazione, qualcuno potrebbe disegnare un mappamondo
indicante tutti i relay Tor. Un premio se si aggiorna man mano che
la rete cresce e cambia. Purtroppo la maniera pi&ugrave; semplice per farlo implica
inviare tutti i dati a Google che disegni la mappa per te. Che
conseguenze ha per la privacy? Ci sono altre buone soluzioni?</li>

</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentazione</a></h2>
<ol>
<li>Aiuta Matt Edman con la documentazione e con le guide del suo
Tor controller,
<a href="http://vidalia-project.net/">Vidalia</a>.</li>
<li>Analizzare e documentare
<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">la
nostra lista di programmi</a> configurabili per essere usati con Tor.</li>
<li>Abbiamo bisogno di una documentazione migliore per intercettare dinamicamente
le connessioni e inviarle via Tor. tsocks (Linux), dsocks (BSD),
e freecap (Windows) sembrano dei buoni candidati, come pure un miglior uso
della nosta nuova funzione TransPort.</li>

<li>C'&egrave; una lista immensa di <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">programmi potenzialmente
utili che si interfacciano con Tor</a>. In quali situazioni sono utili?
Aiutaci a testarli e a documentare i risultati.</li>
<li>Aiuta a tradurre e migliorare le pagine web e la documentazione in altre
lingue. Vedi le <a href="<page translation>">linee guida per
la traduzione</a> se vuoi dare una mano. Servono in particolare traduzioni in
Arabo e Farsi, per i tanti utenti Tor in aree dove vige la censura.
Serve anche aiuto per correggere e migliorare questa traduzione italiana.</li>
</ol>

<a id="Coding"></a>
<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Progetti di siluppo software</a></h2>

Alcuni di questi progetti potrebbero essere dei buoni candidati per <a href="<page
+gsoc>">Google Summer of Code 2008</a>. Abbiamo classificato ogni idea
secondo l'utilit&agrave; complessiva al progetto Tor
(priorit&agrave;), quanto lavoro stimiamo sia necessario (livello d'impegno), quante
conoscenze servono per iniziare (livello di competenze), e quali dei nostri <a href="<page
+people>#Core">principali programmatori</a> potrebbero essere dei buoni mentori.


(NdT: Le schede di alcuni progetti sono in inglese e verranno tradotte man mano.)

<ol>

<li>
Framework per l'aggiornamento automatico di Tor/Polipo/Vidalia Framework
 
Priorit&agrave;: Alta
 
Impegno: Alto
 
Competenze: Alte
 
Possibili mentori: Matt, Jacob
 
Ci seve un buon framework per l'aggiornamento autenticato.
Vidalia si accorge gi&agrave; se l'utente ha una versione obsoleta
o deprecata di Tor, tramite dei signed statement nelle informazioni
di directory Tor. Al momento Vidalia manda una semplice
finestra di avviso che informa l'utente che dovrebbe aggiornare manualmente.
Lo scopo del progetto &egrave; di estendere Vidalia aggiungendo la
possibilit&agrave; di scaricare e installare il software Tor aggiornato al
posto dell'utente. Il download dovrebbe avenire via Tor quando possibile, con un buon
meccanismo di fall back al download diretto. Tempo permettendo sarebbe bello
potere aggiornare altre applicazioni
contenute nei pacchetti di installazione, come Polipo e
Vidalia stessa.
 
Per portare a termine il progetto, lo studente dovr&agrave; anzitutto studiare
il framework di auto-update esistente (ad es., Sparkle su OS X) per valutarne
vantaggi, debolezze, fattori di sicurezza e possibilit&agrave; di venire
integrato in Vidalia. Se non se ne trovano di adatti, lo studente
disegner&agrave; uno proprio frameword di auto aggiornamento, documentando il disegno e
discutendolo con altri sviluppatori per verificarne gli aspetti di sicurezza.
Lo studente realizzer&agrave; poi il framework (o lo integrer&agrave; con
uno esistente) e lo sottoporr6agrave; a test.
 
Gli studenti interessati a questo progetto devono avere una buona esperienza di sviluppo
in C++. Utili, ma non obbligatorie, esperienze di Qt. Occorre anche
una buona comprensione delle comuni pratiche di sicurezza,
come la package signature verification. Importanti per il progetto anche buone
capacit&agrave; di comunicazione scritta, poich&eacute; una fase cruciale
sar&agrave; la produzione di un design document che altri valuteranno e discuteranno
con lo studente prima della realizzazione.
</li>

<li>
Una Network Map per Vidalia migliore e pi&ugrave; usabile
 
Priorit&agrave;: Media
 
Impegno: Medio
 
Competenze: Medio-alte
 
Possibili mentori: Matt
 
Vidalia ha una carta della rete che mostra all'utente la posizione
geografica approssimata dei nodi nella rete Tor e che
disegna il percorso del traffico dell'utente attraverso i tunnel stabiliti nella
rete Tor. The mappa per ora non &egrave; molto interattiva ed ha una grafica
spartana. Ci piacerebbe usare il widget KDE Marble che
crea mappe di miglior qualit&agrave; ed offre maggior einterattivit&agrave;,
permettendo all'utente di fare clic su singoli nodi o circuiti per ottenere
maggiori informazioni. Potremmo anche permettere all'utente di fare
clic su un particolare nodo o su un paese contenente uno o pi&ugrave;
Tor exit relay e dire, ad esempio: "Voglio che le mie connessioni a pippo.com
escano da qui."
 
Questo progetto richiede anzitutto che lo studente si familiarizzi con Vidalia
e le API del widget Marble. Lo studente integrer&agrave; poi il widget
in Vidalia e personalizzer&agrave; Marble per adattarlo meglio ai nostri bisogni,
ad esempio rendendo cliccabili i circuiti, memorizzando i dati di cache nella
data directory di Vidalia, e personalizzando alcuni messaggi di dialogo del widget.
 
Gli studenti impegnati in questo progettp devono avere una buona esperienza
di sviluppo C++. Utile, ma non obbligatorio, avere avuto esperienza con Qt e
Cmake.
</li>

<li>
Better Debian Packaging for Tor+Vidalia
 
Priority: High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Peter, Matt
 
Vidalia currently doesn't play nicely on Debian and Ubuntu with the
default Tor packages. The current Tor packages automatically start Tor
as a daemon running as the debian-tor user and (sensibly) do not have a
<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
in the default torrc. Consequently, Vidalia will try
to start its own Tor process since it could not connect to the existing
Tor, and Vidalia's Tor process will then exit with an error message
the user likely doesn't understand since Tor cannot bind its listening
ports &mdash; they're already in use by the original Tor daemon.
 
The current solution involves either telling the user to stop the
existing Tor daemon and let Vidalia start its own Tor process, or
explaining to the user how to set a control port and password in their
torrc. A better solution on Debian would be to use Tor's ControlSocket,
which allows Vidalia to talk to Tor via a Unix domain socket, and could
possibly be enabled by default in Tor's Debian packages. Vidalia can
then authenticate to Tor using filesystem-based (cookie) authentication
if the user running Vidalia is also in the debian-tor group.
 
This project will first involve adding support for Tor's ControlSocket
to Vidalia. The student will then develop and test Debian and Ubuntu
packages for Vidalia that conform to Debian's packaging standards and
make sure they work well with the existing Tor packages. We can also
set up an apt repository to host the new Vidalia packages.
 
The next challenge would be to find an intuitive usable way for Vidalia
to be able to change Tor's configuration (torrc) even though it is
located in <code>/etc/tor/torrc</code> and thus immutable. The best
idea we've come up with so far is to feed Tor a new configuration via
the ControlSocket when Vidalia starts, but that's bad because Tor starts
each boot with a different configuration than the user wants. The second
best idea
we've come up with is for Vidalia to write out a temporary torrc file
and ask the user to manually move it to <code>/etc/tor/torrc</code>,
but that's bad because users shouldn't have to mess with files directly.
 
A student undertaking this project should have prior knowledge of
Debian package management and some C++ development experience. Previous
experience with Qt is helpful, but not required.
</li>

<li>
Tor Controller Status Event Interface
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Matt, Roger
 
There are a number of status changes inside Tor of which the user may need
to be informed. For example, if the user is trying to set up his Tor as a
relay and Tor decides that its ports are not reachable from outside
the user's network, we should alert the user. Currently, all the user
gets is a couple log messages in Vidalia's 'message log' window, which they
likely never see since they don't receive a notification that something
has gone wrong. Even if the user does actually look at the message log,
most of the messages make little sense to the novice user.
 
Tor has the ability to inform Vidalia of many such status changes, and
we recently implemented support for a couple of these events. Still,
there are many more status events the user should be informed of and we
need a better UI for actually displaying them to the user.
 
The goal of this project then is to design and implement a UI for
displaying Tor status events to the user. For example, we might put a
little badge on Vidalia's tray icon that alerts the user to new status
events they should look at. Double-clicking the icon could bring up a
dialog that summarizes recent status events in simple terms and maybe
suggests a remedy for any negative events if they can be corrected by
the user. Of course, this is just an example and the student is free to
suggest another approach.
 
A student undertaking this project should have good UI design and layout
and some C++ development experience. Previous experience with Qt and 
Qt's Designer will be very helpful, but are not required. Some
English writing ability will also be useful, since this project will
likely involve writing small amounts of help documentation that should
be understandable by non-technical users. Bonus points for some graphic
design/Photoshop fu, since we might want/need some shiny new icons too.
</li>

<li>
Translation Wiki
 
Priority: High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Jacob
 
We need a way to edit and translate sections of the website. Currently
the website is made up of a bunch of <a href="<svnsandbox>website/en/">wml
files</a>, and <a href="<page translation>">translators</a> fetch these
wml files, translate them in an editor, and either send us the translation
or use svn to commit them back. The current "cost" of publication of
website changes is quite high even for English language users. For a
single word change or any type of
minor change, the page may never be corrected or translated. It would
be nice to have a wiki that was specifically geared towards translation
and would somehow track the upstream (English) versions to indicate when
a fresh translation is needed, like our current
<a href="<page translation-status>">translation status page</a>. This
seems mostly like a job for a wiki
integrator or wiki software author. Certainly the person would need to
be interested in human languages and translation. They should at least
be minimally familiar with what Tor is; but they would not have to interact
with the software, only the documentation and the website.
</li>

<li>
Improvements on our active browser configuration tester - 
<a href="https://check.torproject.org/">https://check.torproject.org/</a>
 
Priority: Medium
 
Effort Level: Low
 
Skill Level: Low to Medium
 
Likely Mentors: Jacob, Steven
 
We currently have a functional web page to detect if Tor is working. It
has a few places where it falls short. It requires improvements with
regard to default languages and functionality. It currently only responds
in English. In addition, it is a hack of a perl script that should have
never seen the light of day. It should probably be rewritten in python
with multi-lingual support in mind. It currently uses the <a
href="http://exitlist.torproject.org/">Tor DNS exit list</a>
and should continue to do so in the future. It currently result in certain
false positives and these should be discovered, documented, and fixed
where possible. Anyone working on this project should be interested in
DNS, basic perl or preferably python programming skills, and will have
to interact minimally with Tor to test their code.
 
If you want to make the project more exciting
and involve more design and coding, take a look at <a
href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
131-verify-tor-usage.txt</a>.
</li>

<li>
Improvements on our DNS Exit List service - 
<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
 
Priority: Medium
 
Effort Level: Low
 
Skill Level: Low
 
Likely Mentors: Jacob, Tup
 
The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
is written by our fabulous anonymous
contributer Tup. It's a DNS server written in Haskell that supports part of our <a
href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist
design document</a>. Currently, it is functional and it is used by
check.torproject.org and other users. The issues that are outstanding
are mostly aesthetic. This wonderful service could use a much better
website using the common Tor theme. It would be best served with better
documentation for common services that use an RBL. It could use more
publicity. A person working on this project should be interested in DNS,
basic RBL configuration for popular services, and writing documentation.
The person would require minimal Tor interaction &mdash; testing their
own documentation at the very least. Furthermore, it would be useful
if they were interested in Haskell and wanted to implement more of the
torel-design.txt suggestions.
</li>

<li>
Testing integration of Tor with web browsers for our end users
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Jacob, Mike, Greg
 
The Tor project currently lacks a solid test suite to ensure that a
user has a properly and safely configured web browser. It should test for as
many known issues as possible. It should attempt to decloak the
user in any way possible. Two current webpages that track these
kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
with their proof of concept code, bug issues, etc</a>. HD Moore runs
the <a href="http://metasploit.com/research/projects/decloak/">metasploit
decloak website</a>. A student interested in defending Tor could start
by collecting as many workable and known methods for decloaking a
Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
be helpful as a start.) The student should be familiar with the common
pitfalls but
possibly have new methods in mind for implementing decloaking issues. The
website should ensure that it tells a user what their problem is. It
should help them to fix the problem or direct them to the proper support
channels. The student should be closely familiar with using Tor and how
to prevent Tor information leakage.
</li>

<li>
Improving Tor's ability to resist censorship
 
Priority: High
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Nick
 
The Tor 0.2.0.x series makes <a
href="<svnsandbox>doc/design-paper/blocking.html">significant
improvements</a> in resisting national and organizational censorship.
But Tor still needs better mechanisms for some parts of its
anti-censorship design. For example, current Tors can only listen on a
single address/port combination at a time. There's
<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
proposal to address this limitation</a> and allow clients to connect
to any given Tor on multiple addresses and ports, but it needs more
work. Another anti-censorship project (far more difficult) is to try
to make Tor more scanning-resistant. Right now, an adversary can identify
<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
just by trying to connect to them, following the Tor protocol, and 
seeing if they respond. To solve this, bridges could
<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
and not act like bridges until the user provides a bridge-specific key.
 
This project involves a lot of research and design. One of the big
challenges will be identifying and crafting approaches that can still
resist an adversary even after the adversary knows the design, and
then trading off censorship resistance with usability and robustness.
</li>
 
<li>
Libevent and Tor integration improvements
 
Priority: Medium
 
Effort Level: High
 
Skill Level: Medium to High
 
Likely Mentors: Nick
 
Tor should make better use of the more recent features of Niels
Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
library. Tor already uses Libevent for its low-level asynchronous IO
calls, and could also use Libevent's increasingly good implementations
of network buffers and of HTTP. This wouldn't be simply a matter of
replacing Tor's internal calls with calls to Libevent: instead, we'll
need to refactor Tor to use Libevent calls that do not follow the
same models as Tor's existing backends. Also, we'll need to add
missing functionality to Libevent as needed &mdash; most difficult likely
will be adding OpenSSL support on top of Libevent's buffer abstraction.
Also tricky will be adding rate-limiting to Libevent.
</li>

<li>
Tuneup Tor!
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Nick, Roger, Mike
 
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. A student 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>
Improve our unit testing process
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Nick
 
Tor needs to be far more tested. This is a multi-part effort. To start
with, our unit test coverage should rise substantially, especially in
the areas outside the utility functions. This will require significant
refactoring of some parts of Tor, in order to dissociate as much logic
as possible from globals.
 
Additionally, we need to automate our performance testing. We've got
buildbot to automate our regular integration and compile testing already
(though we need somebody to set it up on Windows),
but we need to get our network simulation tests (as built in TorFlow: see
the "Tor Node Scanner improvements" item)
updated for more recent versions of Tor, and designed to launch a test
network either on a single machine, or across several, so we can test
changes in performance on machines in different roles automatically.
</li>
 
<li>
Help revive an independent Tor client implementation
 
Priority: Medium
 
Effort Level: High
 
Skill Level: Medium to High
 
Likely Mentors: Karsten, Nick
 
Reanimate one of the approaches to implement a Tor client in Java,
e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
project</a>, and make it run on <a
href="http://code.google.com/android/">Android</a>. The first step
would be to port the existing code and execute it in an Android
environment. Next, the code should be updated to support the newer Tor
protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
directory protocol</a>. Further, support for requesting or even
providing Tor hidden services would be neat, but not required.
 
The student should be able to understand and write new Java code, including
a Java cryptography API. Being able to read C code would be helpful,
too. The student should be willing to read the existing documentation,
implement code based on it, and refine the documentation
when things are underdocumented. This project is mostly about coding and
to a small degree about design.
</li>

<li>
Automatic system tests and automatically starting private Tor networks
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Karsten, Nick, Roger
 
Write a tool that runs automatic system tests in addition
to the existing unit tests. The Java-based Tor simulator <a
href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
might be a good start for starting up a private Tor network, using it
for a while, and verifying that at least parts of it are working. This
project requires to conceive a blueprint for performing system tests
of private Tor networks, before starting to code. Typical types of
tests range from performing single requests over the private network to
manipulating exchanged messages and see if nodes handle corrupt messages
appropriately.
 
The student should be able to obtain a good understanding
of how Tor works and what problems and bugs could arise to design good
test cases. Understanding the existing Tor code structure and documentation is
vital. If PuppeTor is used, the student should also be able to understand
and possibly extend an existing Java application. This project is partly
about design and partly about coding.
</li>

<li>
Bring moniTor to life
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Low to Medium
 
Likely Mentors: Karsten, Jacob
 
Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
management tool for Tor relays. The purpose of such a tool would be
to monitor a local Tor relay via its control port and include useful
system information of the underlying machine. When running this tool, it
would dynamically update its content like top does for Linux processes.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
or-dev post</a> might be a good first read.
 
The student should be familiar
with or willing to learn about administering a Tor relay and configuring
it via its control port. As an initial prototype is written in Python,
some knowledge about writing Python code would be helpful, too. This
project is one part about identifying requirements to such a
tool and designing its interface, and one part lots of coding.
</li>

<li>
Tor Exit Scanner improvements
 
Priority: High
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
The Tor exit node scanner 'SoaT', part of the <a
href="<svnsandbox>torflow/">Torflow project</a>, makes connections out
of each Tor exit node and compares the content it gets back with what it
"should" get back. The goal is to notice misconfigured, broken, and even
malicious exit relays. Alas, the code is
currently written in rather rickety perl and relies on MD5sums of
entire documents in order to determine if exit nodes are modifying
content. The problem with this is threefold: 1) Perl sucks at life.
2) The scanner can't verify pages that are dynamic, and attackers can
focus malicious content injection on only those dynamic pages. 3)
Pages change after a while (or based on GeoIP) and begin generating
false positives.
 
Ideally, soat.pl would be reimplemented in a sane language with a
robust html parser library (since the rest of Torflow is in Python
that would be nice, but it is not required), and calculate signatures only for
tags and content likely to be targeted by a malicious attacker (script
tags, object links, images, css). It should also be robust in the face of
changes to content outside of Tor, and ultimately even GeoIP localized
content.
 
This scanner would likely be run by the Directory Authorities and
report its results to the control port via the AuthDirBadExit config
setting.
 
</li>

<li>
Tor Node Scanner improvements
 
Priority: High
 
Effort Level: Medium to High
 
Skill Level: Medium to High
 
Likely Mentors: Mike
 
Similar to the exit scanner (or perhaps even during exit scanning),
statistics can be gathered about the reliability of nodes. Nodes that
fail too high a percentage of their circuits should not be given
Guard status. Perhaps they should have their reported bandwidth
penalized by some ratio as well, or just get marked as Invalid. In
addition, nodes that exhibit a very low average stream capacity but
advertise a very high node bandwidth can also be marked as Invalid.
Much of this statistics gathering is already done, it just needs to be
transformed into something that can be reported to the Directory
Authorities to blacklist/penalize nodes in such a way that clients
will listen.
 
In addition, these same statistics can be gathered about the traffic
through a node. Events can be added to the <a
href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
Protocol</a> to
report if a circuit extend attempt through the node succeeds or fails, and
passive statistics can be gathered on both bandwidth and reliability
of other nodes via a node-based monitor using these events. Such a
scanner would also report information on oddly-behaving nodes to
the Directory Authorities, but a communication channel for this
currently does not exist and would need to be developed as well.
</li>

<li>
Help track the overall Tor Network status
 
Priority: High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Roger, Nick, Mike
 
It would be great to set up an automated system for tracking network
health over time, graphing it, etc. Part of this project would involve
inventing better metrics for assessing network health and growth. Is the
average uptime of the network increasing? How many relays are qualifying
for Guard status this month compared to last month? What's the turnover
in terms of new relays showing up and relays shutting off? Periodically
people collect brief snapshots, but where it gets really interesting is
when we start tracking data points over time.
 
Data could be collected from the "Tor Node Scanner" item above, from
the server descriptors that each relay publishes, and from other
sources. Results over time could be integrated into one of the <a
href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
kept separate. Speaking of the Tor Status pages, take a look at Roger's
<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
Status wish list</a>.
</li>

<li>
Tor path selection improvements
 
Priority: High
 
Effort Level: Low to Medium
 
Skill Level: High
 
Likely Mentors: Roger, Nick, Mike
 
Some simple improvements can be made to Tor's path selection to vastly
improve Tor speed. For instance, some of the (unofficial) <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
Performance Recommendations</a> on the wiki are to increase the number of
guards and decrease the CircuitBuildTimeout. Ideally, the client would
<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
these values by gathering statistics on circuit construction
time</a> (and/or using values gained from Torflow), and set the timeouts
low enough such that some high percentile (75%, 90%, 1-stddev?) of
circuits succeed, yet extremely slow nodes are avoided. This would
involve some statistics gathering+basic research, and some changes to 
Tor path selection code.
 
In addition, to improve path security, some elements from the <a
href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
Hop Paths proposal</a> could be done as part of this (since it will
likely touch the same code anyways), regardless of the adoption of
that proposal. In particular, clients probably should avoid guards that
seem to fail an excessive percentage of their circuits through them,
and non-firewalled clients should issue a warning if they are only able
to connect to a limited set of guard nodes. See also
<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
or-dev post</a>.
</li>

<li>
Torbutton improvements
 
Priority: Medium
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
Torbutton has a number of improvements that can be made in the post-1.2
timeframe. Most of these are documented as feature requests in the <a
href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5">Torbutton
flyspray section</a>. Good examples include: stripping off node.exit on http
headers, more fine-grained control over formfill blocking, improved referrer
spoofing based on the domain of the site (a-la <a
href="http://addons.mozilla.org/firefox/addon/4513">refspoof extension</a>),
tighter integration with Vidalia for reporting Tor status, a New Identity
button with Tor integration and multiple identity management, and anything
else you might think of.
 
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>
Porting Polipo to Windows
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Andrew, Steven, Roger
 
Help port <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
Windows. Example topics to tackle include:
1) handle spaces in path names and understand the filesystem
namespace &mdash; that is, where application data, personal data,
and program data typically reside in various versions of Windows. 2) the
ability to handle ipv6 communications. 3) the ability to asynchronously
query name servers, find the system nameservers, and manage netbios
and dns queries. 4) use native regex capabilities of Windows, rather
than using 3rd party GNU regex libraries. 5) manage events and buffers
natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
Windows it's whatever the config specifies). 6) some sort of GUI config
and reporting tool, bonus if it has a systray icon with right clickable
menu options. Double bonus if it's cross-platform compatible.
</li>

<li>
Make our diagrams beautiful and automated
 
Priority: Medium
 
Effort Level: Low
 
Skill Level: Low
 
Likely Mentors: Andrew
 
We need a way to generate the website diagrams (for example, the "How
Tor Works" pictures on the <a href="<page overview>">overview page</a>
from source, so we can translate them as UTF-8 text rather than edit
them by hand with Gimp. We might want to
integrate this as an wml file so translations are easy and images are
generated in multiple languages whenever we build the website. See the
"Translation Wiki" idea above.
</li>

<li>
Improve the LiveCD offerings for the Tor community
 
Priority: Low
 
Effort Level: Low
 
Skill Level: Medium to High
 
Likely Mentors: Anonym, Jacob, Roger
 
How can we make the <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
easier to maintain, improve, and document?
</li>

<li>
Contribuisci con delle nuove idee!
 
Nessuna di queste proposte ti piace? Dai un'occhiata alla <a
href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
roadmap</a> per avere altri spunti.
</li>

</ol>

<h2><a class="anchor" href="#Coding">Programmazione e design</a></h2>
<ol>
<li>I relay Tor non funzionano bene su Windows XP. Su
Windows, Tor usa la normale chiamata di sistema <tt>select()</tt>,
che usa spazio nel pool non-page. Ci&ograve; significa
che un server Tor di medie dimensioni esaurir&agrave; il non-page pool, <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">causando
confusione e crash del sistema</a>. Probabilmente dovremmo usare overlapped IO.
Una soluzione sarebbe far usare a <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> l'
overlapped IO invece di select() su Windows, per poi adattare Tor
alla nuova interfaccia libevent. Christian King ha dato un
<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">buon inizio
al lavoro</a> nell'estate 2007.</li>
<li>Dobbiamo iniziare a realizzare il nostro <a href="<page
documentation>#DesignDoc">blocking-resistance design</a>. Occorre
ideare il design, modificare varie parti di Tor, adattare
<a href="http://vidalia-project.net/">Vidalia</a> perch&eacute; supporti le
nuove funzionalit&agrave; e progettarne lo sviluppo.</li>
<li>Serve un framework flessibile di simulazione per studiare gli attacchi
end-to-end di conferma del traffico. Molti ricercatori hanno creato dei sumulatori
ad hoc a sostegno delle loro intuizioni sul funzionamento degli attacchi
o di certe difese e contromisure. Possiamo costruire un simulatore
ben documentato e aperto che possa fornire a ciascuno risposte
adeguare? Questo potrebbe contribuire a molte nuove ricerche.
Vedi la voce <a href="#Research">qui sotto</a> sui confirmation attack per
maggior dettagli sulla ricerca in questo campo &mdash; chiss&agrave; forse al
termine potresti scrivere qualche paper sull'argomento.</li>
<li>Tor 0.1.1.x e successivi includono il supporto per acceleratori crittografici hardware
tramite OpenSSL. Nessuno tuttavia lo ha ancora testato. C'&egrave; qualcuno che vuole
prendere una scheda e farci sapere come va?</li>
<li>Effettuare una analisi di sicurezza di Tor con <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determinare
se esistono delle buone librerie di fuzzing adatte al nostro scopo. Guadagnati la fama
e il credito quando potremo fare una nuova release grazie a te!</li>
<li>Tor usa TCP per il trasporto e TLS per la cifratura del
collegamento. Funziona ed &egrave; semplice, ma significa che se un pacchetto
viene scartato tutte le cellule di un collegamento subiscono un ritardo; inoltre
significa che possiamo ragionrvolmente supportare solo flussi TCP. Abbiamo una <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">lista
di motivi per evitare il trasporto UDP</a>, ma sarebbe bello accorciare
questa lista. Abbiamo proposto anche delle <a
href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">specifiche
per Tor e
UDP</a> &mdash; facci sapere se presentano dei problemi.</li>
<li>Non ci manca molto per avere supporto IPv6 per indirizzi destinazione
(sugli exit node). Se per te IPv6 &egrave; molto importante, questo &egrave;
il punto da cui cominciare.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Ricerca</a></h2>
<ol>
<li>Attacco di tipo "website fingerprinting": fai un elenco di quanche
centinaio di siti famosi, scaricane le pagine, crea una serie di
"signature" per ciascun sito. Poi osserva il traffico di un client Tor. Mentre
riceve dati, potresti indovinare se e quale di questi siti
il client sta visitando. Per prima cosa, che possibilit&agrave; di successo
ha questo attacco sull'installato Tor attuale? Poi, cerca delle difese
possibili: ad esempio, potremmo cambiare le dimensioni delle cellule Tor da 512
byte a 1024 byte, potremmo usare tecniche di padding come <a
href="http://freehaven.net/anonbib/#timing-fc2004">il defensive dropping</a>,
o potremmo aggiungere ritardi nel traffico. Che impatto avrebbe,
che conseguenze avrebbe sull'usabilit&agrave; (con un metro di riferimento adeguato)
l'uso di difese efficaci in ciascuno di questi casi?</li>
<li>Attacco di tipo "end-to-end traffic confirmation":
osservando il traffico dal lato di Alice e di Bob, si possono <a
href="http://freehaven.net/anonbib/#danezis:pet2004">confrontare
le signature del traffico e dedurre che si sta osservando lo stesso
flusso</a>. Finora Tor si rassegna ad accettare questa situazione, assumendo
che in ogni caso questo attacco &egrave; triviale. Ma &egrave; davvero cos&igrave;? Quanto
 e quale traffico &egrave; necessario perch&eacute; un aversario
sia certo di aver vinto? Ci sono situazioni che rallentano l'attacco (es. trasmissioni modeste)?
Il traffic padding o il traffic shaping
funzionano meglio di altri sistemi?</li>
<li>Attacco di tipo "routing zones": gli studi attuali considerano
il percorso di rete tra Alice e il suo entry node (e tra
l'exit node e Bob) come un singolo collegamento in un grafico. In realt&agrave;
invece il percorso attraversa diversi autonomous system (AS), e <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">non &egrave; infrequente che
lo stesso AS appaia sia nell'entry path che nell'exit path</a>.
Purtroppo, per calcolare se una certa configurazione tra Alice, entry,
exit e Bob sia pericolosa occorre scaricare una intera
routing zone Internet ed effettuare su di essa molte operazioni. Ci sono dei
rimedi pratici approssimativi, come ad esempio evitare gli indirizzi IP nella stessa rete /8?</li>
<li>Nella ricerca su Tor vi sono altre questioni riguardo la diversit&agrave; geografica:
considera il costo tra scegliere un circuito client efficienteicient e sceglierne uno
casuale. Leggi il <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">position
paper</a> di Stephen Rollyson per come scartare alcuni circuiti particolarmente lenti senza ledere
"troppo" l'anonimato. Su questa linea di ricerca serve pi&ugrave; lavoro,
ma pare assai promettente.</li>
<li>Tor funziona male quando un relay dispone di banda asimmetrica
(come via cavo o DSL). Siccome Tor usa connessioni TCP separate per
ogni nodo, se i bye in arrivo giungono regolarmente e quelli in uscita
vengono tutti persi, il meccanismo di push-back del TCP non
ritrasmette questa informazione ai flussi in entrata.
Tor potrebbe rilevare se sta perdendo molti pacchetti in uscita ed eseguire
un rate-limit sui flussi in ingresso per autoregolarsi? Ho in mente
un sistema di accumulo e scarico in cui si sceglie un rate-limit prudente e
lo si incrementa lentamente finch&eacute; non si perdono pacchetti, poi si decrementa etc.
Ci serve qualcuno esperto di reti per simulare il meccanismo e aiutarci a disegnare
una soluzione; oppure dovremmo capire quanto ne vengono degradate le
prestazioni, e decidere se riconsiderare il trasporto UDP.</li>
<li>Un argomento simile &egrave; il controllo delle congestioni. Il nostro sistema attuale
sar&agrave; sufficiente quando avremo un uso molto intenso?
Potremmo sperimentare finestre di ampiezza variabile, invece
di finestre di ampiezza fissa? Questo sembrava funzionare bene in un <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">esperimento
di throughput ssh</a>. Dovremmo misurare e provare, e forse applicare il metodo
se i risultati fossero soddisfacenti.</li>
<li>Per permettere ai dissidenti in tutto il mondo di usare Tor senza essere
bloccati dai firewall del loro paese, serve un sistema per avere decine di migliaia
di relay, non qualche centinaio. Potremmo immaginare la GUI di un client Tor con
un pulsante "Tor for Freedom" che apre una porta e fa il relay di pochi
KB/s di traffico verso la rete Tor. (Pochi KB/s non dovrebbero essere un problema,
e ci sarebbero pochi abusi, dato che non sarebbero degli exit
node.) Ma come si fa a distribuire automaticamente ai dissidenti
la lista di questi client volontari ed ad impedire ai firewall nazionali di
intercettarli ed enumerarli? Forse si dovrebbe lavorare a livello di
fiducia personale. Vedi il nostro <a href="<page documentation>#DesignDoc">early
blocking-resistance design document</a> e la nostra <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">FAQ
</a> sull'argomento e poi leggi la <a
href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sezione
di anonbib sulla resistenza alla censura</a>.</li>
<li>I circuiti Tor si stabiliscono un nodo alla volta, per cui potremmo
fare uscire alcuni flussi dal secondo nodo, altri dal terzo e cos&igrave; via.
Sembra una buona idea, dato che riduce i flussi in uscita
che ciascun relay pu&ograve; vedere. Se per&ograve; vogliamo assicurare la sicurezza di ciascun flusso,
il percorso pi&ugrave; breve dovrebbe essere almeno di tre nodi, secondo i criteri correnti, e
gli altri dovrebbero essere anche pi&ugrave; lunghi. Dobbiamo valutare questo compromesso tra
sicurezza e prestazioni.</li>
<li>Non &egrave; difficile effettuare un DoS ai Tor relay o alle autorit&agrave di directory. I client
puzzle sono la soluzione giusta? Quali altri approcci pratici esistono? Un premio
se sono compatibili col protocollo Tor attuale.</li>
</ol>

<a href="<page contact>">Facci sapere</a> se hai fatto progressi in qualcuno di
questi campi!

</div>

#include <foot.wmi>