it/volunteer.wml (6e46dd567) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 13843
# 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>Serve un buon sistema per intercetare 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 <i>mapaddress</i> 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 <i>torify</i> 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>
<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> la scorsa estate.</li>
<li>Come possiamo fare in modo che l'<a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
sia pi&ugrave; facile da mantenere, migliorare e documentare?</li>
<li>Il front-end grafico a Tot che preferiamo,
<a href="http://vidalia-project.net/">Vidalia</a>, ha bisogno di vari
lavori di sviluppo.</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>Ci serve un framework di testing distribuito. Abbiamo unit tests,
ma sarebbe bello avere uno script che avvii una rete Tor, la usi per
un po' e verifichi che almeno una parte di essa funzioni.</li>
<li>Dai una mano a Mike Perry per la sua libreria <a
href="https://torproject.org/svn/torflow/">TorFlow</a>
(<a href="https://torproject.org/svn/torflow/TODO">TODO</a>):
&egrave; una libreria in pythonche usa il <a
href="https://torproject.org/svn/torctl/doc/howto.txt">Tor controller
protocol</a> per fare costruire a Tor dei circuiti in vari modi,
per poi misurarne le prestazioni e rilevarne le anomalie.</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>
<li>Se nessuno dei punti qui sopra &egrave; di tuo gusto, dai un'occhiata alla <a
href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
roadmap</a> per ulteriori spunti.</li>
<li>Se non vedi elencata qui la tua idea, forse &egrave; comunque importante e ne abbiamo bisogno! Contattaci
e scoprilo.</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>

tor-webwml.git

italian website updates: trim down volunteer and fix donate