it/volunteer.wml (86929a088) - tor-webwml.git

volunteer.wml

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

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

<h2>Alcune cose che puoi fare subito:</h2>
<ol>
<li>Puoi <a href="<page docs/tor-doc-relay>">installare
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>Se condividi gli obiettivi di Tor, per favore <a href="<page donate>">fai una donazione
e sostieni lo sviluppo futuro di Tor</a>. Cerchiamo anche
pi&ugrave; sponsor &mdash; se conosci aziende, ONG, enti od
altre organizzazioni interessate ad anonimato / privacy / sicurezza delle
comunicazioni, fagli conoscere il nostro progetto.</li>
<li>Cerchiamo altri <a href="<page torusers>">buoni esempi sull'uso di Tor
e sui suoi utenti</a>. Se usi Tor in una situazione o per scopi non ancora
descritti su questa pagina e se sei disposto a condividere queste informazioni con noi, ci
piacerebbe sentire la tua storia.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
<ol>
<li>Servono dei migliori e nuovi 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>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>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="Advocacy"></a>
<h2><a class="anchor" href="#Advocacy">Divulgazione</a></h2>
<ol>
<li>Creare un logotipo sotto licenza Creative Commons che tutti possano usare e modificare</li>
<li>Creare una presentazione utilizzabile nei vari incontri e convegni di utenti in giro per il mondo</li>
<li>Creare un video sugli usi positivi di Tor. Ce ne sono gi&agrave; alcuni iniziati su Seesmic.</li>
<li>Creare un poster, od una serie di posters, attorno ad un tema, come "Tor per la libert&agrave;!"</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="<page vidalia/index>">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>

You may find some of these projects to be good <a href="<page
gsoc>">Google Summer of Code 2009</a> ideas. We have labelled each idea
with how useful it would be to the overall Tor project (priority), how
much work we expect it would be (effort level), how much clue you should
start with (skill level), and which of our <a href="<page
people>#Core">core developers</a> would be good mentors.
If one or more of these ideas looks promising to you, please <a
href="<page contact>">contact us</a> to discuss your plans rather than
sending blind applications. You may also want to propose your own project
idea which often results in the best applications.


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

<ol>

<li>
Tor Browser Bundle for Linux/Mac OS X
 
Priority: High
 
Effort Level: High
 
Skill Level: Medium
 
Likely Mentors: Steven, Andrew
 
The Tor Browser bundle incorporates Tor, Firefox, and the Vidalia user
interface (and optionally Pidgin IM). Components are pre-configured to
operate in a secure way, and it has very few dependencies on the
installed operating system. It has therefore become one of the most
easy to use, and popular, ways to use Tor on Windows.
 
However, there is currently no comparable package for Linux and Mac OS
X, so this project would be to implement Tor Browser Bundle for these
platforms. This will involve modifications to Vidalia (C++), possibly
Firefox (C) then creating and testing the launcher on a range of
operating system versions and configurations to verify portability.
 
Students should be familiar with application development on one or
preferably both of Linux and Mac OS X, and be comfortable with C/C++
and shell scripting.
 
Part of this project could be usability testing of Tor 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>
Translation wiki for our website
 
Priority: High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Jacob
 
The Tor Project has been working over the past year to set up web-based
tools to help volunteers translate our applications into other languages.
We finally hit upon Pootle, and we have a fine web-based translation engine
in place for Vidalia, Torbutton, and Torcheck. However, Pootle only
translates strings that are in the "po" format, and our website uses wml
files. This project is about finding a way to convert our wml files into po
strings and back, so they can be handled by Pootle.
</li>

<li>
Help track the overall Tor Network status
 
Priority: Medium to High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Karsten, Roger
 
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 Network Scanners in <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>, 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>
Improving Tor's ability to resist censorship
 
Priority: Medium to High
 
Effort Level: Medium
 
Skill Level: High
 
Likely Mentors: Nick, Roger, Steven
 
The Tor 0.2.0.x series makes <a
href="<svnprojects>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="<gitblob>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="<gitblob>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="<svnprojects>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>
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>
Improving Polipo on Windows
 
Priority: Medium to High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Martin
 
Help port <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
Windows. Example topics to tackle include:
1) the ability to asynchronously
query name servers, find the system nameservers, and manage netbios
and dns queries.
2) 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). 3) 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.
4) allow the software to use the Windows Registry and handle proper
Windows directory locations, such as "C:\Program Files\Polipo"
</li>

<li>
Implement a torrent-based scheme for downloading Thandy packages
 
Priority: Medium to High
 
Effort Level: High
 
Skill Level: Medium to High
 
Likely Mentors: Martin, Nick
 
<a
href="https://git.torproject.org/checkout/thandy/master/specs/thandy-spec.txt">Thandy</a>
is a relatively new software to allow assisted updates of Tor and related
software. Currently, there are very few users, but we expect Thandy to be
used by almost every Tor user in the future. To avoid crashing servers on
the day of a Tor update, we need new ways to distribute new packages
efficiently, and using libtorrent seems to be a possible solution. If you
think of other good ideas, great - please do let us know! 
We also need to investigate how to include our mirrors better. If possible,
there should be an easy way for them to help distributing the packages.
</li>

<li>
Tor Controller Status Event Interface
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Low to Medium
 
Likely Mentors: Matt
 
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 one is free to
suggest another approach.
 
A person 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>
Improve our unit testing process
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Nick, Roger
 
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 <a
href="https://svn.torproject.org/svn/torflow/trunk/README">TorFlow</a>)
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="<gitblob>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.
 
A prospective developer 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. One 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>
New Torbutton Features
 
Priority: Medium
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
There are several <a
href="https://bugs.torproject.org/flyspray/index.php?tasks=all&amp;project=5&amp;type=2">good
feature requests</a> on the Torbutton Flyspray section. In particular, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=523">Integrating
'New Identity' with Vidalia</a>,
<a href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=940">ways of
managing multiple cookie jars/identities</a>, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=637">preserving
specific cookies</a> when cookies are cleared,
<a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=524">better
referrer spoofing</a>, <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=564">correct
Tor status reporting</a>, and <a
href="https://bugs.torproject.org/flyspray/index.php?do=details&amp;id=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:
1) Integration of the <a
href="http://chandlerproject.org/Projects/MeTooCrypto">MeTooCrypto
Python library</a>
for authenticated HTTPS downloads. 2) 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.
3) 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>

<li>
Simulator for slow Internet connections
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Steven
 
Many users of Tor have poor-quality Internet connections, giving low
bandwidth, high latency, and high packet loss/re-ordering. User
experience is that Tor reacts badly to these conditions, but it is
difficult to improve the situation without being able to repeat the
problems in the lab.
 
This project would be to build a simulation environment which
replicates the poor connectivity so that the effect on Tor performance
can be measured. Other components would be a testing utility to
establish what are the properties of connections available, and to
measure the effect of performance-improving modifications to Tor.
 
The tools used would be up to the student, but dummynet (for FreeBSD)
and nistnet (for Linux) are two potential components on which this
project could be built. Students should be experienced with network
programming/debugging and TCP/IP, and preferably familiar with C and a
scripting language.
</li>
 
<li>
An Improved and More Usable Network Map in Vidalia
 
Priority: Low to Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Matt
 
One of Vidalia's existing features is a network map that shows the user
the approximate geographic location of relays in the Tor network and
plots the paths the user's traffic takes as it is tunneled through the
Tor network. The map is currently not very interactive and has rather
poor graphics. Instead, we implemented KDE's Marble widget such
that it gives us a better quality map and enables improved interactivity,
such as allowing the user to click on individual relays or circuits to
display additional information. We want to add the ability
for users to click on a particular relay or a country containing one or
more Tor exit relays and say, "I want my connections to exit
from here."
 
This project will first involve getting familiar with Vidalia
and the Marble widget's API. One will then integrate the widget
into Vidalia and customize Marble to be better suited for our application,
such as making circuits clickable, storing cached map data in Vidalia's
own data directory, and customizing some of the widget's dialogs.
 
A person undertaking this project should have good C++ development
experience. Previous experience with Qt and CMake is helpful, but not
required.
</li>

<li>
Bring moniTor to life
 
Priority: Low
 
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.
 
A person interested in this 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>
Torbutton equivalent for Thunderbird
 
Priority: Low
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
We're hearing from an increasing number of users that they want to use
Thunderbird with Tor. However, there are plenty of application-level
concerns, for example, by default Thunderbird will put your hostname in
the outgoing mail that it sends. At some point we should start a new
push to build a Thunderbird extension similar to Torbutton.
</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>
Improve Tor Weather
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Jake, Roger
 
<a href="https://weather.torproject.org/">Tor weather</a> is a tool
that allows signing up to receive notifications via email when the
tracked Tor relay is down. Currently, it isn't really useful for
people who use the hibernation feature of Tor, or for those who
have to shut down their relay regularly. During the project, Tor
weather could be extended to allow more flexible configurations.
Other enhancements are also possible: Weather could send out warnings
when your relay runs an out-of-date version of Tor, or when its
observed bandwith drops below a certain value. It might also be a
nice tool that allows for checking whether your relay has earned
you a <a href="<page tshirt>">T-Shirt</a>, or sending reminders to
directory authorities that
their keys are about to expire. Be creative, and consider how the
above project to track overall network status can help you get your job
done more quickly! See also its
<a href="https://svn.torproject.org/svn/weather/trunk/README">README</a>
and <a href="https://svn.torproject.org/svn/weather/trunk/TODO">TODO</a>.
</li>

<li>
Bring up new ideas!
 
Don't like any of these? Look at the <a
href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
roadmap</a> for more ideas.
Some of the <a href="<gittree>doc/spec/proposals/">current proposals</a>
might also be short on developers.
</li>

<!-- Is this still a useful project? If so, move it to another section.
<li>
Una migliore gestione dei pacchetti Debian/Ubuntu per Tor e Vidalia
 
Vidalia al momento non funziona bene su Debian e Ubuntu con i pacchetti
standard di Tor. Gli attuali pacchetti Tor fanno partire automaticamente Tor
come demone sotto l'utente debian-tor e (giustamente) senza una
<a href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> definita
del file torrc. Di conseguenza, Vidalia cerca di far 
partire il suo processo Tor, dato che non riesce a connettersi a un processo
Tor esistente, col risulato che il processo Tor di Vidalia termina con un messaggio di errore
che l'utente probabilmente non capisce, dato che non pu&ograve; collegarsi alle sue
porte in ascolto &mdash; che sono gi&agrave; utilizzate dal demone Tor originale.
 
La soluzione attuale prevede o di dire all'utente di fermare il demone
Tor esistente e farne partire uno da Vidalia, oppure di spiegare all'utente
come definire una port e una password nel file di configurazione
torrc. Su Debian una soluzione migliore sarebbe usare il ControlSocket di Tor,
che permetterebbe a Vidalia di parlare con Tor attraverso un Unix domain socket, e potrebbe
essere abilitata di default nei pacchetti Debian di Tor. Vidalia potrebbe 
quindi autenticarsi a Tor con una autenticazione basata sul filesystem (cookie),
usa Vidalia fa parte del gruppo debian-tor.
 
Questo progetto richiede di aggiungere a Vidalia il supporto per ControlSocket
di Tor. Lo studente svilupper&agrave; e tester&agrave; i pacchetti Vidalia
per Debian e Ubuntu in conformit&agrave; agli standard di pacchetto Debian,
e verificher&agrave; che essi funzionino bene con i pacchetti Tor esistenti. Possiamo anche
creare un repository apt per ospitare i nuovi pacchetti Vidalia.
 
Il prossimo passo sar&agrave; trovare un metodo intuitivo e facile perch&eacute; Vidalia
possa modificare la configurazione di Tor (torrc) anche se si trova
in <code>/etc/tor/torrc</code> ed &egrave; quindi non modificabile. Finora la cosa
migliore che abbiamo pensato &egrave; fornire a Tor una nuova configurazione tramite
il ControlSocket quando Vidalia si avvia, ma ha il difetto di far partire Tor
ad ogni boot con una configurazione diversa da quella desiderata dall'utente. L'alternativa
che
ci &egrave; venuta in mente &egrave; che Vidalia scriva un file torrc temporaneo
e chieda all'utente di spostarlo manualmente in <code>/etc/tor/torrc</code>,
ha il difetto di fare interagire l'utente direttamente con i file.
 
Le persone interessate a questo progetto dovrebbero conoscere bene il
Debian package management ed avere qualche esperienza di sviluppo in C++. Apprezzata,
ma non obbligatoria, dell'esperienza con Qt.
</li>

-->

<!-- Is Blossom development still happening?
<li>
Rework and extend Blossom
 
Rework and extend Blossom (a tool for monitoring and
selecting appropriate Tor circuits based upon exit node requirements
specified by the user) to gather data in a self-contained way, with
parameters easily configurable by the user. Blossom is presently
implemented as a single Python script that interfaces with Tor using the
Controller interface and depends upon metadata about Tor nodes obtained
via external processes, such as a webpage indicating status of the nodes
plus publically available data from DNS, whois, etc. This project has
two parts: (1) Determine which additional metadata may be useful and
rework Blossom so that it cleanly obtains the metadata on its own rather
than depend upon external scripts (this may, for example, involve
additional threads or inter-process communication), and (2) develop a
means by which the user can easily configure Blossom, starting with a
configuration file and possibly working up to a web configuration engine.
Knowledge of Tor and Python are important; knowledge of 
TCP, interprocess communication, and Perl will also be helpful. An
interest in network neutrality is important as well, since the
principles of evaluating and understanding internet inconsistency are at
the core of the Blossom effort.
</li>

<li>
Improve Blossom: Allow users to qualitatively describe exit nodes they desire
 
Develop and implement a means of affording Blossom
users the ability to qualitatively describe the exit node that they
want. The Internet is an inconsistent place: some Tor exit nodes see
the world differently than others. As presently implemented, Blossom (a
tool for monitoring and selecting appropriate Tor circuits based upon
exit node requirements specified by the user) lacks a sufficiently rich
language to describe how the different vantage points are different.
For example, some exit nodes may have an upstream network that filters
certain kinds of traffic or certain websites. Other exit nodes may
provide access to special content as a result of their location, perhaps
as a result of discrimination on the part of the content providers
themselves. This project has two parts: (1) develop a language for
describing characteristics of networks in which exit nodes reside, and
(2) incorporate this language into Blossom so that users can select Tor
paths based upon the description.
Knowledge of Tor and Python are important; knowledge of
TCP, interprocess communication, and Perl will also be helpful. An
interest in network neutrality is important as well, since the
principles of evaluating and understanding internet inconsistency are at
the core of the Blossom effort.
</li>
-->

<!-- not really suited for GSoC; integrated into TBB for Linux/Mac OS X
<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>

</ol>

<a id="OtherCoding"></a>
<h2><a class="anchor" href="#OtherCoding">Altre idee di sviluppo 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://svn.torproject.org/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="<page vidalia/index>">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. &Egrave; stato testato leggermente ed &egrave; verosimilmente pieno di bachi. Cerchiamo test pi&ugrave; rigorosi, analisi delle prestazioni e, idealmente, modifiche al codice di OpenSSL e Tor se necessario.</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="<gitblob>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>

<li>Ci serve un sistema per generare i diagrammi sul sito web (ad esempio, le immagini
How Tor Works" nella <a href="<page overview>">pagina di panoramica</a>
a partire daisorgenti, in modo da tradurli come testo UTF-8 invece di modificarli
a mano con Gimp. Potremmo integrare ci&ograve;
come file wml per i traduttori e generare cos&igrave; le immagine
in pi&ugrave; lingue quando risostruiamo il sito web.</li>

<li>Come possiamo rendere il <a
href="http://anonymityanywhere.com/incognito/">LiveCD Incognito</a>
pi&ugrave; facile da mantenere, migliorare e documentare?</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>Un altro problema collegato &egrave;: Creare un relay/bridge offre qualche 
protezione in pi&ugrave; contro questi timing attacks? Un avversario esterno che non pu&ograve;
leggere dentro i link TLS pu&ograve; riuscire a riconoscere i singoli flussi in modo affidabile?
La quantit&agrave; di traffico trasportato limita in qualche modo questa eventualit&agrave;? Cosa accadrebbe se
il client-relay ritardasse apposta il traffico upstream creando una coda
che potrebbe essere usata per simulare il timing dal client downstream cos&igrave; da fingere
che sia traffico relayed anch'esso? Questa stessa coda potrebbe essere usata per mascherare
i timing nel traffico upstream monte dai client con tecniche di <a
href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,
ma senza aver bisogno di traffico addizionale. Una simile miscela di
traffico upstream monte dal client potrebbe forse offuscare il timing per un avversario esterno? Questa strategia
deve essere modificata in caso di link asimmetrici? Ad esempio, su
link asimmentrici si riesce a distinguere il traffico del client dai
picchi naturali dovuti all'asimmetria della capacit&agrave; del link? Od &egrave; pi&ugrave;
facile sui link asimmetrici, per qualche altro motivo?</li>
<li>Ripetere l' <a
href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attacco da
Oakland 05</a> di Murdoch e Danezi sull'attuale rete Tor. Provare a capire perch&eacute;
funziona bene contro alcuni nodi e non su altri. /La mia teoria &egrave; che
i nodi veloci con capacit&agrave; aggiuntiva resistono meglio al'attacco) Se questo &egrave; vero
allora bisogna provare con le opzioni RelayBandwidthRate e RelayBandwidthBurst
per gestire un relay usato come client mentre si fa da relay al traffico
dell'attaccante: riducendo RelayBandwidthRate, forse l'attacco
diventa pi&ugrave; difficile? Quale &egrave; il rapporto ideale tra RelayBandwidthRate e
capacit&agrave; reale? Ma &egrave; poi un rapporto? Gi&agrave; che ci siamo, un numero
maggiore di potenziali relay aumenta forse il tasso di falsi positivi
o altri fattori complessi per l'attacco? (La rete Tor oggi &egrave; di quasi due
ordini di grandezza maggiore rispetto a quando fu scritto il paper.) Leggi anche
<a href="http://freehaven.net/anonbib/#clog-the-queue">Don't
Clog the Queue</a>.</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>Uno degli obiettivi per resistere alla censura &egrave; impedire
ad un attaccante che osservi il traffico Tor su una connessione di <a
href="<svnprojects>design-paper/blocking.html#sec:network-fingerprint">distinguerlo
dal normale traffico SSL</a>. Non possiamo ovviamente ottenere perfetta
steganografia e al contempo essere ancora utilizzabili, ma come primo passo ci
bloccare tutti quegli attacchi che funzionano solo osservando pochi pacchetti. Uno degli
altri attacchi che non abbiamo esaminato ancora a fondo &egrave; che le celle Tor sono di 512
byte, e quindi il traffico sulla connessione potrebbe essere di multipli di 512 byte.
Batching e overhead nei record TLS modificano questo dato sulla connessione?
Ci sono altre strategie di buffer flushing in Tor che influiscono su questo dato? Possiamo
aspettarci dei risultati usando un po' di padding, o si tratta di un attacco che dobbiamo accettare cos&igrave; com'&egrave;?</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>
<li>Programmi come <a
href="<page torbutton/index>">Torbutton</a> cercano di nascondere
la stringa UserAgent del tuo browser sostituendola con una risposta uniforme
per ogni utente Tor. In questo modo un attaccante non pu&ograve; ridurre l'anonymity set
in base a questo header. Torbutton cerca di usare una stringa comunemente usata anche
da utenti non-Tor in modo da non dare nell'occhio. Prima domanda: quanto
&egrave; dannoso aggiornare periodicamente la versione di Firefox che
Torbutton dichiara? Se la aggiorniamo troppo spessp suddividiamo da soli
l'anonymity set. se non l'aggiorniamo abbastanza spesso allora tutti gli
utenti di Tor spiccano dato che dichiarano una versione obsoleta di
Firefox. La risposta dipende probabilmente dalle versioni di Firefox osservabili
dal vivo. Seconda domanda: ci viene regolarmente chiesto di ruotare N stringhe
UserAgent invece di usarne una sola. &Egrave; un approccio utile, dannoso
o indifferente? Considera per esempio: uso di cookie e riconoscimento di utenti
Torbutton dai loro UserAgent; siti web maliziosi che attaccano solo certi
browser; e se le risposte alla domanda numero uno hanno in impatto sulla seconda domanda.
</li>
<li>Per ora i client Tor riutilizzano un circuito per dieci minuti
da quando &egrave; stato stabilito. Lo scopo &egrave; di evitare il sovraccarico
della rete con troppe operazioni di estensione di circuito, e di evitare al contempo
che i client usino lo stesso circuito troppo a lungo, tanto da permettere a un exit node
di realizzare un profilo pseudonimo utile su di essi. Purtroppo 10 minuti sono
troppo, specie se vengono fatte sullo stesso circuto connessioni per protocolli multipli (come IM e
web browsing). Se manteniamo fisso il numero totale di
circuit extend che la rete deve compiere, esistono altri metodi
pi&ugrave; efficienti o sicuri perch&eacute; i client allochino flussi ai circuiti,
o perch&eacute; i client costruiscano preventivamente dei circuiti? Forse un punto di partenza in
questa ricerca &egrave; la raccolta di informazioni su che genere di connessioni
vengono tipicamente lanciate dai client, in modo da disporre di un quadro realistico su cui lavorare.
</li>
<li>Quanti bridge relay occorre conoscere per mantenere una raggiungibilit&agrave;
ottimale? Bisognerebbe misurare il tasso di esaurimento dei nostri bridge. Se questo &egrave;
alto, ci sono dei modi per mantenere meglio connessi gli utenti dei
bridge?
</li>

</ol>

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

</div>

#include <foot.wmi>

tor-webwml.git

Now that the design paper was moved back to Subversion, fix links (see tor.git changeset f164a76 and svn revision r21665). Found by katoda