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

volunteer.wml

## translation metadata
# Based-On-Revision: 97509231
# 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>
<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>
</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 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 anche persone che aiutino
a mantenere le traduzioni esistenti in italiano, francese e svedese -
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</a>. Probabilmente dovremmo usare overlapped IO.
Una soluzione otrebbe essere fare usare a libevent overlapped IO
invece che select() su Windows, e 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
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. Meglio ancora se verifica ogni exit node
per scoprire con che indirizzo IP esce realmente.</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>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; 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>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>Per ora i descrittori dei hidden service sono contenuti in solo in
pochi directory server. &#200; uno svantaggio per la privacy e per la robustezza. Per
una maggiore robustezza dovremo rendere ancora meno privati i descrittori dei
hidden service dato che dovremo duplicarli in
molti mirror diversi. Idealmente vorremmo separare del tutto il sistema di storage/lookup dai
directory server Tor. Il primo problema &egrave; che occorre
disegnare un nuovo formato per i descrittori dei hidden service che a) sia ascii piuttosto che
binario, per praticit&agrave;; b) tenga criptata la lista degli introduction point
a meno di non conoscere l'indirizzo <tt>.onion</tt>, in modo che la directory
non possa conoscerli; e c) permetta alle directory di verificare il timestamp
e la firma su un descrittore di un hidden service in modo che non possano
rivelarne uno falso. In secondo luogo, va bene qualsiasi sistema affidabile
di storage distribuito, fintanto che permetta aggiornamenti automatici, ma per ora
pare che nessun codice DHT implementato supporta gli aggiornamenti automatici.</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/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>
</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>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 "help China" 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 la nostra <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">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

minor italian typos and fixes