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

volunteer.wml

## translation metadata
# Based-On-Revision: 10121 10723
# Last-Translator: jan@seul.org

#include "head.wmi" TITLE="Partecipa"

<h2>Tre cose che puoi fare subito:</h2>
<ol>
<li>Puoi <a href="<page docs/tor-doc-server>">realizzare
un server</a> per aiutare a far crescere la rete Tor.</li>
<li>Parla coi tuoi amici! Fagli realizzare un server. 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="http://wiki.noreply.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>
</li>
</ul>
<li>Chi gestisce un server ci dice spesso che vorrebbe avere un certo BandwidthRate
in certe ore del giorno e un diverso BandwidthRate in altre.
Invece di programmare questa funzione in Tor, si potrebbe fare un piccolo
script che dialoghi con la <a href="<page gui/index>">Tor Controller Interface</a>,
e faccia un setconf per cambiare la banda disponibile. Potrebbe girare con
cron, o magari attivarsi solo al momento giusto per fare
la sua configurazione (probabilmente cos&igrave; &egrave; pi&ugrave; portabile). Qualcuno pu&ograve; scrivercelo
cos&igrave; lo mettiamo in <a href="<svnsandbox>contrib/">contrib/</a>?
Questa &egrave; una buona prova per il <a href="<page gui/index>">concorso per una GUI
Tor</a>.

</li>
<li>Tor pu&ograve; <a
href="http://wiki.noreply.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 server 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>Sappiamo che l'anonimato degli utenti Tor pu&ograve; essere attaccato da
javascript, java, activex, flash, etc, se non vengono disabilitati.
Ci sono dei plugin (come NoScript per Firefox) che possono aiutare
gli utenti a gestire questo rischio? E di che rischio si tratta esattamente?</li>
<li>Esiste una suite completa di plugin che sostituisca tutte le funzioni di Privoxy
per Firefox 1.5+? Sappiamo che Tor &egrave; molto pi&ugrave; veloce senza
Privoxy.</li>
<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="http://wiki.noreply.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="http://wiki.noreply.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
tradurre</a> se vuoi dare una mano. Servono persone che aiutino
a mantenere le traduzioni esistenti in francese e svedese e a migliorare questa versione in italiano -
vedi lo <a href="<page translation-status>">stato delle
traduzioni</a>.</li>
<li>Puoi aiutarci a usare
<a href="http://www.cacert.org/">cacert</a> per il nostro
<a href="<page documentation>#Developers">SVN repository</a>SSL?</li>

</ol>

<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Programmazione e design</a></h2>
<ol>
<li>I server 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="http://wiki.noreply.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.</li>
<li>Poich&eacute; i server Tor devono fare store-and-forward di ogni cella che gestiscono
i server Tor a banda larga consumano molta memoria solo come
buffer. Serve migliore conoscenza di quando restringere o espandere i
buffer. Forse lo si potrebbe modellare seguendo il design buffer nel kernel
Linux, in cui vi sono molto buffer pi&ugrave; piccoli linkati l'un l'altro,
invece di un buffer monolitico.</li>
<li>Serve un sito centrale per rispondere a domande come "Questo indirizzo IP &egrave; un
exit server Tor?". Il sito dovrebbe avere varie interfacce, compresa una interfaccia
web e una interfaccia simile a DNSBL. Pu&ograve; fornire le risposte pi&ugrave;
aggiornate tenendo un mirror locale delle informazioni di directory
Tor. Essere un exit server per&ograve; non &egrave; una condizione
booleana: la domanda i realt&agrave; 6egrave; "Questo indirizzo IP &egrave; un exit
server Tor in grado di collegarsi all'indirizzo:porta IP di destinazione?" L' interfaccia DNSBL
ricever&agrave; probabilmente centinaia di richieste al minuto, per cui occorre
qualche algoritmo efficiente. Bonus se effettua dei test attivi su
ciascun exit node per scoprire da quale indirrizzo IP esce realmente.
<a href="<svnsandbox>doc/contrib/torbl-design.txt">Leggi qui per approfondire</a>.</li>
<li>Talvolta i server Tor vanno in crash o i computer su cui sono escono dalla
rete, o capita qualche incidente. Alcuni gestori Tor si sono detti interessati
a un servizio di notifica che verifichi periodicamente
lo stato dei propri server Tor ed invii una email in caso di problemi.
C'&egrave; qualcuno che vuole scrivere qualche script cgi, delle pagine web
e mettere in piedi un hack con wget oppure qualcosa di pi� complsso come <a
href="http://nagios.org/">Nagios</a> per il monitoraggio? La versione iniziale
potrebbe controllare solo la directory port, ovvero leggere la pagina in cache
con il network-status alla ricerca degli indirizzi Ip e delle porte per poi richiedere
la pagina "/tor/server/authority".</li>
<li>Sarebbe bello avere un CD live contenente le versioni
pi&ugrave; recenti di Tor, Polipo o Privoxy, Firefox, Gaim+OTR, etc. Ci sono
due problemi: il primo consiste nel documentare il sistema e le opzioni con chiarezza
tale da permettere a chi si occupa di sicurezza di esprimere un giudizio sulla
sua sicurezza complessiva; il secondo problema &egrave; trovare un modo per renderlo di facile manutenzione,
cos&igrave; da non divenire obsoleto rapidamente come AnonymOS. Meglio ancora se
l'immagine CD sta su un mini-D.</li>
<li>A proposito di immagini CD live, ci vorrebbe una immagine USB per Tor e le applicazioni di supporto
che sia intuitiva, sicura e ben documentata. Il grosso delle
difficolt&agrave; &egrave; decidere quali sono le configurazioni sicure,
documentare queste scelte e creare qualcosa di facile da
mantenere in futuro.</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>Abbiamo bisogno di uno studio quantitativo che confronti <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
con <a href="http://www.privoxy.org/">Privoxy</a>. Polipo &egrave; veramente
pi&ugrave; veloce anche contando il rallentamento dato da Tor? I risultati
sono gli stessi su Linux e Windows? Inoltre Polipo gestisce bene un maggior
numero di siti web di Privoxy, o viceversa? Ci sono problemi di
stabilit&agrave; sulle piattaforme pi&ugrave; comuni, come, Windows?</li>
<li>A questo proposito ti piacerebbe aiutare a portare <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> in modo che
sia stabile ed efficiente su Windows?</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="http://tor.eff.org/svn/torflow/">TorFlow</a>
(<a href="http://tor.eff.org/svn/torflow/TODO">TODO</a>):
&egrave una libreria in pythonche usa il <a
href="http://tor.eff.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="http://wiki.noreply.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>
<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-2007.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 server 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="http://wiki.noreply.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 server 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 server o ai dirserver. 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

update italian website pages