work on italian volunteer page adding all GSoC project candidates, the first ones I translated, the remaining are left in english; I'll translate them all gradually, but wanted to quickly spread the info about GSoC to italian coders, universities and the like. Added a note explaining that some section is in english.
Jan Reister

Jan Reister commited on 2008-03-12 15:40:43
Zeige 1 geänderte Dateien mit 793 Einfügungen und 24 Löschungen.

... ...
@@ -1,5 +1,5 @@
1 1
 ## translation metadata
2
-# Based-On-Revision: 13843
2
+# Based-On-Revision: 13989
3 3
 # Last-Translator: jan at seul dot org
4 4
 
5 5
 #include "head.wmi" TITLE="Tor: partecipa" CHARSET="UTF-8"
... ...
@@ -23,7 +23,7 @@ comunicazioni, fagli conoscere il progetto Tor.</li>
23 23
 <a id="Usability"></a>
24 24
 <h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
25 25
 <ol>
26
-<li>Serve un buon sistema per intercetare le richieste DNS in modo che non siano svelate
26
+<li>Servono altri buoni metodi per intercettare le richieste DNS in modo che non siano svelate
27 27
 a un osservatore locale mentre cerchiamo di essere anonimi. (Ci&ograve;
28 28
 succede se l'applicazione esegue la risoluzione DNS prima di rivolgersi
29 29
 al proxy SOCKS.)</li>
... ...
@@ -92,6 +92,794 @@ Serve anche aiuto per correggere e migliorare questa traduzione italiana.</li>
92 92
 </ol>
93 93
 
94 94
 <a id="Coding"></a>
95
+<a id="Summer"></a>
96
+<a id="Projects"></a>
97
+<h2><a class="anchor" href="#Projects">Progetti di siluppo software</a></h2>
98
+
99
+<p>
100
+Alcuni di questi progetti potrebbero essere dei buoni candidati per <a href="<page
101
++gsoc>">Google Summer of Code 2008</a>. Abbiamo classificato ogni idea
102
+secondo l'utilit&agrave; complessiva al progetto Tor
103
+(priorit&agrave;), quanto lavoro stimiamo sia necessario (livello d'impegno), quante
104
+conoscenze servono per iniziare (livello di competenze), e quali dei nostri <a href="<page
105
++people>#Core">principali programmatori</a> potrebbero essere dei buoni mentori.
106
+</p>
107
+<p>
108
+(NdT: Le  schede di alcuni progetti sono in inglese e verranno tradotte man mano.)
109
+</p>
110
+<ol>
111
+
112
+<li>
113
+<b>Framework per l'aggiornamento automatico di Tor/Polipo/Vidalia Framework</b>
114
+<br />
115
+Priorit&agrave;: <i>Alta</i>
116
+<br />
117
+Impegno: <i>Alto</i>
118
+<br />
119
+Competenze: <i>Alte</i>
120
+<br />
121
+Possibili mentori: <i>Matt, Jacob</i>
122
+<br />
123
+Ci seve un buon framework per l'aggiornamento autenticato.
124
+Vidalia si accorge gi&agrave; se l'utente ha una versione obsoleta
125
+o deprecata di Tor, tramite dei signed statement nelle informazioni
126
+di directory Tor. Al momento Vidalia manda una semplice
127
+finestra di avviso che informa l'utente che dovrebbe aggiornare manualmente.
128
+Lo scopo del progetto &egrave; di estendere Vidalia aggiungendo la
129
+possibilit&agrave; di scaricare e installare il software Tor aggiornato al
130
+posto dell'utente. Il download dovrebbe avenire via Tor quando possibile, con un buon
131
+meccanismo di fall back al download diretto. Tempo permettendo sarebbe bello
132
+potere aggiornare altre applicazioni
133
+contenute nei pacchetti di installazione, come Polipo e
134
+Vidalia stessa.
135
+<br />
136
+Per portare a termine il progetto, lo studente dovr&agrave; anzitutto studiare
137
+il framework di auto-update esistente (ad es., Sparkle su OS X) per valutarne
138
+vantaggi, debolezze, fattori di sicurezza e possibilit&agrave; di venire
139
+integrato in Vidalia. Se non se ne trovano di adatti, lo studente
140
+disegner&agrave; uno proprio frameword di auto aggiornamento, documentando il disegno e
141
+discutendolo con altri sviluppatori per verificarne gli aspetti di sicurezza.
142
+Lo studente realizzer&agrave; poi il framework (o lo integrer&agrave; con
143
+uno esistente) e lo sottoporr6agrave; a test.
144
+<br />
145
+Gli studenti interessati a questo progetto devono avere una buona esperienza di sviluppo
146
+in C++. Utili, ma non obbligatorie, esperienze di Qt. Occorre anche
147
+una buona comprensione delle comuni pratiche di sicurezza,
148
+come la package signature verification. Importanti per il progetto anche buone
149
+capacit&agrave; di comunicazione scritta, poich&eacute; una fase cruciale
150
+sar&agrave; la produzione di un design document che altri valuteranno e discuteranno
151
+con lo studente prima della realizzazione.
152
+</li>
153
+
154
+<li>
155
+<b>Una Network Map per Vidalia migliore e pi&ugrave; usabile</b>
156
+<br />
157
+Priorit&agrave;: <i>Media</i>
158
+<br />
159
+Impegno: <i>Medio</i>
160
+<br />
161
+Competenze: <i>Medio-alte</i>
162
+<br />
163
+Possibili mentori: <i>Matt</i>
164
+<br />
165
+Vidalia ha una carta della rete che mostra all'utente la posizione
166
+geografica approssimata dei nodi nella rete Tor e che
167
+disegna il percorso del traffico dell'utente attraverso i tunnel stabiliti nella
168
+rete Tor. The mappa per ora non &egrave; molto interattiva ed ha una grafica
169
+spartana. Ci piacerebbe usare il widget KDE Marble che
170
+crea mappe di miglior qualit&agrave; ed offre maggior einterattivit&agrave;,
171
+permettendo all'utente di fare clic su singoli nodi o circuiti per ottenere
172
+maggiori informazioni. Potremmo anche permettere all'utente di fare
173
+clic su un particolare nodo o su un paese contenente uno o pi&ugrave;
174
+Tor exit relay e dire, ad esempio: "Voglio che le mie connessioni a pippo.com
175
+escano da qui."
176
+<br />
177
+Questo progetto richiede anzitutto che lo studente si familiarizzi con Vidalia
178
+e le API del widget Marble. Lo studente integrer&agrave; poi il widget
179
+in Vidalia e personalizzer&agrave; Marble per adattarlo meglio ai nostri bisogni,
180
+ad esempio rendendo cliccabili i circuiti, memorizzando i dati di cache nella
181
+data directory di Vidalia, e personalizzando alcuni messaggi di dialogo del widget.
182
+<br />
183
+Gli studenti impegnati in questo progettp devono avere una buona esperienza
184
+di sviluppo C++. Utile, ma non obbligatorio, avere avuto esperienza con Qt e
185
+Cmake.
186
+</li>
187
+
188
+<li>
189
+<b>Better Debian Packaging for Tor+Vidalia</b>
190
+<br />
191
+Priority: <i>High</i>
192
+<br />
193
+Effort Level: <i>Medium</i>
194
+<br />
195
+Skill Level: <i>Medium</i>
196
+<br />
197
+Likely Mentors: <i>Peter, Matt</i>
198
+<br />
199
+Vidalia currently doesn't play nicely on Debian and Ubuntu with the
200
+default Tor packages. The current Tor packages automatically start Tor
201
+as a daemon running as the debian-tor user and (sensibly) do not have a
202
+<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined
203
+in the default torrc. Consequently, Vidalia will try
204
+to start its own Tor process since it could not connect to the existing
205
+Tor, and Vidalia's Tor process will then exit with an error message
206
+the user likely doesn't understand since Tor cannot bind its listening
207
+ports &mdash; they're already in use by the original Tor daemon.
208
+<br />
209
+The current solution involves either telling the user to stop the
210
+existing Tor daemon and let Vidalia start its own Tor process, or
211
+explaining to the user how to set a control port and password in their
212
+torrc. A better solution on Debian would be to use Tor's ControlSocket,
213
+which allows Vidalia to talk to Tor via a Unix domain socket, and could
214
+possibly be enabled by default in Tor's Debian packages. Vidalia can
215
+then authenticate to Tor using filesystem-based (cookie) authentication
216
+if the user running Vidalia is also in the debian-tor group.
217
+<br />
218
+This project will first involve adding support for Tor's ControlSocket
219
+to Vidalia. The student will then develop and test Debian and Ubuntu
220
+packages for Vidalia that conform to Debian's packaging standards and
221
+make sure they work well with the existing Tor packages. We can also
222
+set up an apt repository to host the new Vidalia packages.
223
+<br />
224
+The next challenge would be to find an intuitive usable way for Vidalia
225
+to be able to change Tor's configuration (torrc) even though it is
226
+located in <code>/etc/tor/torrc</code> and thus immutable. The best
227
+idea we've come up with so far is to feed Tor a new configuration via
228
+the ControlSocket when Vidalia starts, but that's bad because Tor starts
229
+each boot with a different configuration than the user wants. The second
230
+best idea
231
+we've come up with is for Vidalia to write out a temporary torrc file
232
+and ask the user to manually move it to <code>/etc/tor/torrc</code>,
233
+but that's bad because users shouldn't have to mess with files directly.
234
+<br />
235
+A student undertaking this project should have prior knowledge of
236
+Debian package management and some C++ development experience. Previous
237
+experience with Qt is helpful, but not required.
238
+</li>
239
+
240
+<li>
241
+<b>Tor Controller Status Event Interface</b>
242
+<br />
243
+Priority: <i>Medium</i>
244
+<br />
245
+Effort Level: <i>Medium</i>
246
+<br />
247
+Skill Level: <i>Medium</i>
248
+<br />
249
+Likely Mentors: <i>Matt, Roger</i>
250
+<br />
251
+There are a number of status changes inside Tor of which the user may need
252
+to be informed. For example, if the user is trying to set up his Tor as a
253
+relay and Tor decides that its ports are not reachable from outside
254
+the user's network, we should alert the user. Currently, all the user
255
+gets is a couple log messages in Vidalia's 'message log' window, which they
256
+likely never see since they don't receive a notification that something
257
+has gone wrong. Even if the user does actually look at the message log,
258
+most of the messages make little sense to the novice user.
259
+<br />
260
+Tor has the ability to inform Vidalia of many such status changes, and
261
+we recently implemented support for a couple of these events. Still,
262
+there are many more status events the user should be informed of and we
263
+need a better UI for actually displaying them to the user.
264
+<br />
265
+The goal of this project then is to design and implement a UI for
266
+displaying Tor status events to the user. For example, we might put a
267
+little badge on Vidalia's tray icon that alerts the user to new status
268
+events they should look at. Double-clicking the icon could bring up a
269
+dialog that summarizes recent status events in simple terms and maybe
270
+suggests a remedy for any negative events if they can be corrected by
271
+the user. Of course, this is just an example and the student is free to
272
+suggest another approach.
273
+<br />
274
+A student undertaking this project should have good UI design and layout
275
+and some C++ development experience. Previous experience with Qt and 
276
+Qt's Designer will be very helpful, but are not required. Some
277
+English writing ability will also be useful, since this project will
278
+likely involve writing small amounts of help documentation that should
279
+be understandable by non-technical users. Bonus points for some graphic
280
+design/Photoshop fu, since we might want/need some shiny new icons too.
281
+</li>
282
+
283
+<li>
284
+<b>Translation Wiki</b>
285
+<br />
286
+Priority: <i>High</i>
287
+<br />
288
+Effort Level: <i>Medium</i>
289
+<br />
290
+Skill Level: <i>Medium</i>
291
+<br />
292
+Likely Mentors: <i>Jacob</i>
293
+<br />
294
+We need a way to edit and translate sections of the website. Currently
295
+the website is made up of a bunch of <a href="<svnsandbox>website/en/">wml
296
+files</a>, and <a href="<page translation>">translators</a> fetch these
297
+wml files, translate them in an editor, and either send us the translation
298
+or use svn to commit them back. The current "cost" of publication of
299
+website changes is quite high even for English language users. For a
300
+single word change or any type of
301
+minor change, the page may never be corrected or translated. It would
302
+be nice to have a wiki that was specifically geared towards translation
303
+and would somehow track the upstream (English) versions to indicate when
304
+a fresh translation is needed, like our current
305
+<a href="<page translation-status>">translation status page</a>. This
306
+seems mostly like a job for a wiki
307
+integrator or wiki software author. Certainly the person would need to
308
+be interested in human languages and translation. They should at least
309
+be minimally familiar with what Tor is; but they would not have to interact
310
+with the software, only the documentation and the website.
311
+</li>
312
+
313
+<li>
314
+<b>Improvements on our active browser configuration tester</b> - 
315
+<a href="https://check.torproject.org/">https://check.torproject.org/</a>
316
+<br />
317
+Priority: <i>Medium</i>
318
+<br />
319
+Effort Level: <i>Low</i>
320
+<br />
321
+Skill Level: <i>Low to Medium</i>
322
+<br />
323
+Likely Mentors: <i>Jacob, Steven</i>
324
+<br />
325
+We currently have a functional web page to detect if Tor is working. It
326
+has a few places where it falls short. It requires improvements with
327
+regard to default languages and functionality. It currently only responds
328
+in English. In addition, it is a hack of a perl script that should have
329
+never seen the light of day. It should probably be rewritten in python
330
+with multi-lingual support in mind. It currently uses the <a
331
+href="http://exitlist.torproject.org/">Tor DNS exit list</a>
332
+and should continue to do so in the future. It currently result in certain
333
+false positives and these should be discovered, documented, and fixed
334
+where possible. Anyone working on this project should be interested in
335
+DNS, basic perl or preferably python programming skills, and will have
336
+to interact minimally with Tor to test their code.
337
+<br />
338
+If you want to make the project more exciting
339
+and involve more design and coding, take a look at <a
340
+href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
341
+131-verify-tor-usage.txt</a>.
342
+</li>
343
+
344
+<li>
345
+<b>Improvements on our DNS Exit List service</b> - 
346
+<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
347
+<br />
348
+Priority: <i>Medium</i>
349
+<br />
350
+Effort Level: <i>Low</i>
351
+<br />
352
+Skill Level: <i>Low</i>
353
+<br />
354
+Likely Mentors: <i>Jacob, Tup</i>
355
+<br />
356
+The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
357
+is written by our fabulous anonymous
358
+contributer Tup. It's a DNS server written in Haskell that supports part of our <a
359
+href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist
360
+design document</a>. Currently, it is functional and it is used by
361
+check.torproject.org and other users. The issues that are outstanding
362
+are mostly aesthetic. This wonderful service could use a much better
363
+website using the common Tor theme. It would be best served with better
364
+documentation for common services that use an RBL. It could use more
365
+publicity. A person working on this project should be interested in DNS,
366
+basic RBL configuration for popular services, and writing documentation.
367
+The person would require minimal Tor interaction &mdash; testing their
368
+own documentation at the very least. Furthermore, it would be useful
369
+if they were interested in Haskell and wanted to implement more of the
370
+torel-design.txt suggestions.
371
+</li>
372
+
373
+<li>
374
+<b>Testing integration of Tor with web browsers for our end users</b>
375
+<br />
376
+Priority: <i>Medium</i>
377
+<br />
378
+Effort Level: <i>Medium</i>
379
+<br />
380
+Skill Level: <i>Medium</i>
381
+<br />
382
+Likely Mentors: <i>Jacob, Mike, Greg</i>
383
+<br />
384
+The Tor project currently lacks a solid test suite to ensure that a
385
+user has a properly and safely configured web browser. It should test for as
386
+many known issues as possible. It should attempt to decloak the
387
+user in any way possible. Two current webpages that track these
388
+kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
389
+href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
390
+with their proof of concept code, bug issues, etc</a>. HD Moore runs
391
+the <a href="http://metasploit.com/research/projects/decloak/">metasploit
392
+decloak website</a>. A student interested in defending Tor could start
393
+by collecting as many workable and known methods for decloaking a
394
+Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
395
+be helpful as a start.) The student should be familiar with the common
396
+pitfalls but
397
+possibly have new methods in mind for implementing decloaking issues. The
398
+website should ensure that it tells a user what their problem is. It
399
+should help them to fix the problem or direct them to the proper support
400
+channels. The student should be closely familiar with using Tor and how
401
+to prevent Tor information leakage.
402
+</li>
403
+
404
+<li>
405
+<b>Improving Tor's ability to resist censorship</b>
406
+<br />
407
+Priority: <i>High</i>
408
+<br />
409
+Effort Level: <i>High</i>
410
+<br />
411
+Skill Level: <i>High</i>
412
+<br />
413
+Likely Mentors: <i>Nick</i>
414
+<br />
415
+The Tor 0.2.0.x series makes <a
416
+href="<svnsandbox>doc/design-paper/blocking.html">significant
417
+improvements</a> in resisting national and organizational censorship.
418
+But Tor still needs better mechanisms for some parts of its
419
+anti-censorship design.  For example, current Tors can only listen on a
420
+single address/port combination at a time.  There's
421
+<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
422
+proposal to address this limitation</a> and allow clients to connect
423
+to any given Tor on multiple addresses and ports, but it needs more
424
+work.  Another anti-censorship project (far more difficult) is to try
425
+to make Tor more scanning-resistant.  Right now, an adversary can identify
426
+<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
427
+just by trying to connect to them, following the Tor protocol, and 
428
+seeing if they respond.  To solve this, bridges could
429
+<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
430
+webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
431
+and not act like bridges until the user provides a bridge-specific key.
432
+<br />
433
+This project involves a lot of research and design. One of the big
434
+challenges will be identifying and crafting approaches that can still
435
+resist an adversary even after the adversary knows the design, and
436
+then trading off censorship resistance with usability and robustness.
437
+</li>
438
+ 
439
+<li>
440
+<b>Libevent and Tor integration improvements</b>
441
+<br />
442
+Priority: <i>Medium</i>
443
+<br />
444
+Effort Level: <i>High</i>
445
+<br />
446
+Skill Level: <i>Medium to High</i>
447
+<br />
448
+Likely Mentors: <i>Nick</i>
449
+<br />
450
+Tor should make better use of the more recent features of Niels
451
+Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
452
+library.  Tor already uses Libevent for its low-level asynchronous IO
453
+calls, and could also use Libevent's increasingly good implementations
454
+of network buffers and of HTTP.  This wouldn't be simply a matter of
455
+replacing Tor's internal calls with calls to Libevent: instead, we'll
456
+need to refactor Tor to use Libevent calls that do not follow the
457
+same models as Tor's existing backends. Also, we'll need to add
458
+missing functionality to Libevent as needed &mdash; most difficult likely
459
+will be adding OpenSSL support on top of Libevent's buffer abstraction.
460
+Also tricky will be adding rate-limiting to Libevent.
461
+</li>
462
+
463
+<li>
464
+<b>Tuneup Tor!</b>
465
+<br />
466
+Priority: <i>Medium</i>
467
+<br />
468
+Effort Level: <i>Medium</i>
469
+<br />
470
+Skill Level: <i>Medium to High</i>
471
+<br />
472
+Likely Mentors: <i>Nick, Roger, Mike</i>
473
+<br />
474
+Right now, Tor relays measure and report their own bandwidth, and Tor
475
+clients choose which relays to use in part based on that bandwidth.
476
+This approach is vulnerable to
477
+<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
478
+relays lie about their bandwidth</a>;
479
+to address this, Tor currently caps the maximum bandwidth
480
+it's willing to believe any relay provides.  This is a limited fix, and
481
+a waste of bandwidth capacity to boot.  Instead,
482
+Tor should possibly measure bandwidth in a more distributed way, perhaps
483
+as described in the
484
+<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
485
+Tor"</a> paper
486
+by Snader and Borisov. A student could use current testing code to
487
+double-check this paper's findings and verify the extent to which they
488
+dovetail with Tor as deployed in the wild, and determine good ways to
489
+incorporate them into their suggestions Tor network without adding too
490
+much communications overhead between relays and directory
491
+authorities.
492
+</li>
493
+
494
+<!--
495
+<li>
496
+<b>Improving the Tor QA process: Continuous Integration for Windows builds</b>
497
+<br />
498
+Priority: <i>High</i>
499
+<br />
500
+Effort Level: <i>Medium</i>
501
+<br />
502
+Skill Level: <i>Medium</i>
503
+<br />
504
+Likely Mentors: <i>Jacob, Andrew</i>
505
+<br />
506
+It would be useful to have automated build processes for Windows and
507
+probably other platforms. The purpose of having a continuous integration
508
+build environment is to ensure that Windows isn't left behind for any of
509
+the software projects used in the Tor project or its accompanying.<br />
510
+Buildbot may be a good choice for this as it appears to support all of
511
+the platforms Tor does. See the 
512
+<a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
513
+buildbot</a>.<br />
514
+There may be better options and the person undertaking this task should
515
+evaluate other options. Any person working on this automatic build
516
+process should have experience or be willing to learn how to build all
517
+of the respective Tor related code bases from scratch. Furthermore, the
518
+person should have some experience building software in Windows
519
+environments as this is the target audience we want to ensure we do not
520
+leave behind. It would require close work with the Tor source code but
521
+probably only in the form of building, not authoring.<br />
522
+Additionally, we need to automate our performance testing for all platforms.
523
+We've got buildbot (except on Windows &mdash; as noted above) to automate 
524
+our regular integration and compile testing already,
525
+but we need to get our network simulation tests (as built in torflow)
526
+updated for more recent versions of Tor, and designed to launch a test
527
+network either on a single machine, or across several, so we can test
528
+changes in performance on machines in different roles automatically.
529
+</li>
530
+-->
531
+
532
+<li>
533
+<b>Improve our unit testing process</b>
534
+<br />
535
+Priority: <i>Medium</i>
536
+<br />
537
+Effort Level: <i>Medium</i>
538
+<br />
539
+Skill Level: <i>Medium</i>
540
+<br />
541
+Likely Mentors: <i>Nick</i>
542
+<br />
543
+Tor needs to be far more tested. This is a multi-part effort. To start
544
+with, our unit test coverage should rise substantially, especially in
545
+the areas outside the utility functions. This will require significant
546
+refactoring of some parts of Tor, in order to dissociate as much logic
547
+as possible from globals.
548
+<br />
549
+Additionally, we need to automate our performance testing. We've got
550
+buildbot to automate our regular integration and compile testing already
551
+(though we need somebody to set it up on Windows),
552
+but we need to get our network simulation tests (as built in TorFlow: see
553
+the "Tor Node Scanner improvements" item)
554
+updated for more recent versions of Tor, and designed to launch a test
555
+network either on a single machine, or across several, so we can test
556
+changes in performance on machines in different roles automatically.
557
+</li>
558
+ 
559
+<li>
560
+<b>Help revive an independent Tor client implementation</b>
561
+<br />
562
+Priority: <i>Medium</i>
563
+<br />
564
+Effort Level: <i>High</i>
565
+<br />
566
+Skill Level: <i>Medium to High</i>
567
+<br />
568
+Likely Mentors: <i>Karsten, Nick</i>
569
+<br />
570
+Reanimate one of the approaches to implement a Tor client in Java,
571
+e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
572
+project</a>, and make it run on <a
573
+href="http://code.google.com/android/">Android</a>. The first step
574
+would be to port the existing code and execute it in an Android
575
+environment. Next, the code should be updated to support the newer Tor
576
+protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
577
+directory protocol</a>. Further, support for requesting or even
578
+providing Tor hidden services would be neat, but not required.
579
+<br />
580
+The student should be able to understand and write new Java code, including
581
+a Java cryptography API. Being able to read C code would be helpful,
582
+too. The student should be willing to read the existing documentation,
583
+implement code based on it, and refine the documentation
584
+when things are underdocumented. This project is mostly about coding and
585
+to a small degree about design.
586
+</li>
587
+
588
+<li>
589
+<b>Automatic system tests and automatically starting private Tor networks</b>
590
+<br />
591
+Priority: <i>Medium</i>
592
+<br />
593
+Effort Level: <i>Medium</i>
594
+<br />
595
+Skill Level: <i>Medium</i>
596
+<br />
597
+Likely Mentors: <i>Karsten, Nick, Roger</i>
598
+<br />
599
+Write a tool that runs automatic system tests in addition
600
+to the existing unit tests. The Java-based Tor simulator <a
601
+href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
602
+might be a good start for starting up a private Tor network, using it
603
+for a while, and verifying that at least parts of it are working. This
604
+project requires to conceive a blueprint for performing system tests
605
+of private Tor networks, before starting to code. Typical types of
606
+tests range from performing single requests over the private network to
607
+manipulating exchanged messages and see if nodes handle corrupt messages
608
+appropriately.
609
+<br />
610
+The student should be able to obtain a good understanding
611
+of how Tor works and what problems and bugs could arise to design good
612
+test cases. Understanding the existing Tor code structure and documentation is
613
+vital. If PuppeTor is used, the student should also be able to understand
614
+and possibly extend an existing Java application. This project is partly
615
+about design and partly about coding.
616
+</li>
617
+
618
+<li>
619
+<b>Bring moniTor to life</b>
620
+<br />
621
+Priority: <i>Medium</i>
622
+<br />
623
+Effort Level: <i>Medium</i>
624
+<br />
625
+Skill Level: <i>Low to Medium</i>
626
+<br />
627
+Likely Mentors: <i>Karsten, Jacob</i>
628
+<br />
629
+Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
630
+management tool for Tor relays. The purpose of such a tool would be
631
+to monitor a local Tor relay via its control port and include useful
632
+system information of the underlying machine. When running this tool, it
633
+would dynamically update its content like top does for Linux processes.
634
+<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
635
+or-dev post</a> might be a good first read.
636
+<br />
637
+The student should be familiar
638
+with or willing to learn about administering a Tor relay and configuring
639
+it via its control port. As an initial prototype is written in Python,
640
+some knowledge about writing Python code would be helpful, too. This
641
+project is one part about identifying requirements to such a
642
+tool and designing its interface, and one part lots of coding.
643
+</li>
644
+
645
+<li>
646
+<b>Tor Exit Scanner improvements</b>
647
+<br />
648
+Priority: <i>High</i>
649
+<br />
650
+Effort Level: <i>High</i>
651
+<br />
652
+Skill Level: <i>High</i>
653
+<br />
654
+Likely Mentors: <i>Mike</i>
655
+<br />
656
+The Tor exit node scanner 'SoaT', part of the <a
657
+href="<svnsandbox>torflow/">Torflow project</a>, makes connections out
658
+of each Tor exit node and compares the content it gets back with what it
659
+"should" get back. The goal is to notice misconfigured, broken, and even
660
+malicious exit relays. Alas, the code is
661
+currently written in rather rickety perl and relies on MD5sums of
662
+entire documents in order to determine if exit nodes are modifying
663
+content. The problem with this is threefold: 1) Perl sucks at life.
664
+2) The scanner can't verify pages that are dynamic, and attackers can
665
+focus malicious content injection on only those dynamic pages. 3)
666
+Pages change after a while (or based on GeoIP) and begin generating
667
+false positives.
668
+<br />
669
+Ideally, soat.pl would be reimplemented in a sane language with a
670
+robust html parser library (since the rest of Torflow is in Python
671
+that would be nice, but it is not required), and calculate signatures only for
672
+tags and content likely to be targeted by a malicious attacker (script
673
+tags, object links, images, css). It should also be robust in the face of
674
+changes to content outside of Tor, and ultimately even GeoIP localized
675
+content.
676
+<br />
677
+This scanner would likely be run by the Directory Authorities and
678
+report its results to the control port via the AuthDirBadExit config
679
+setting.
680
+<br />
681
+</li>
682
+
683
+<li>
684
+<b>Tor Node Scanner improvements</b>
685
+<br />
686
+Priority: <i>High</i>
687
+<br />
688
+Effort Level: <i>Medium to High</i>
689
+<br />
690
+Skill Level: <i>Medium to High</i>
691
+<br />
692
+Likely Mentors: <i>Mike</i>
693
+<br />
694
+Similar to the exit scanner (or perhaps even during exit scanning),
695
+statistics can be gathered about the reliability of nodes. Nodes that
696
+fail too high a percentage of their circuits should not be given
697
+Guard status. Perhaps they should have their reported bandwidth
698
+penalized by some ratio as well, or just get marked as Invalid. In
699
+addition, nodes that exhibit a very low average stream capacity but
700
+advertise a very high node bandwidth can also be marked as Invalid.
701
+Much of this statistics gathering is already done, it just needs to be
702
+transformed into something that can be reported to the Directory
703
+Authorities to blacklist/penalize nodes in such a way that clients
704
+will listen.
705
+<br />
706
+In addition, these same statistics can be gathered about the traffic
707
+through a node. Events can be added to the <a
708
+href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
709
+Protocol</a> to
710
+report if a circuit extend attempt through the node succeeds or fails, and
711
+passive statistics can be gathered on both bandwidth and reliability
712
+of other nodes via a node-based monitor using these events. Such a
713
+scanner would also report information on oddly-behaving nodes to
714
+the Directory Authorities, but a communication channel for this
715
+currently does not exist and would need to be developed as well.
716
+</li>
717
+
718
+<li>
719
+<b>Help track the overall Tor Network status</b>
720
+<br />
721
+Priority: <i>High</i>
722
+<br />
723
+Effort Level: <i>Medium</i>
724
+<br />
725
+Skill Level: <i>Medium</i>
726
+<br />
727
+Likely Mentors: <i>Roger, Nick, Mike</i>
728
+<br />
729
+It would be great to set up an automated system for tracking network
730
+health over time, graphing it, etc. Part of this project would involve
731
+inventing better metrics for assessing network health and growth. Is the
732
+average uptime of the network increasing? How many relays are qualifying
733
+for Guard status this month compared to last month? What's the turnover
734
+in terms of new relays showing up and relays shutting off? Periodically
735
+people collect brief snapshots, but where it gets really interesting is
736
+when we start tracking data points over time.
737
+<br />
738
+Data could be collected from the "Tor Node Scanner" item above, from
739
+the server descriptors that each relay publishes, and from other
740
+sources. Results over time could be integrated into one of the <a
741
+href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
742
+kept separate. Speaking of the Tor Status pages, take a look at Roger's
743
+<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
744
+Status wish list</a>.
745
+</li>
746
+
747
+<li>
748
+<b>Tor path selection improvements</b>
749
+<br />
750
+Priority: <i>High</i>
751
+<br />
752
+Effort Level: <i>Low to Medium</i>
753
+<br />
754
+Skill Level: <i>High</i>
755
+<br />
756
+Likely Mentors: <i>Roger, Nick, Mike</i>
757
+<br />
758
+Some simple improvements can be made to Tor's path selection to vastly
759
+improve Tor speed. For instance, some of the (unofficial) <a
760
+href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
761
+Performance Recommendations</a> on the wiki are to increase the number of
762
+guards and decrease the CircuitBuildTimeout. Ideally, the client would
763
+<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
764
+these values by gathering statistics on circuit construction
765
+time</a> (and/or using values gained from Torflow), and set the timeouts
766
+low enough such that some high percentile (75%, 90%, 1-stddev?) of
767
+circuits succeed, yet extremely slow nodes are avoided. This would
768
+involve some statistics gathering+basic research, and some changes to 
769
+Tor path selection code.
770
+<br />
771
+In addition, to improve path security, some elements from the <a
772
+href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
773
+Hop Paths proposal</a> could be done as part of this (since it will
774
+likely touch the same code anyways), regardless of the adoption of
775
+that proposal. In particular, clients probably should avoid guards that
776
+seem to fail an excessive percentage of their circuits through them,
777
+and non-firewalled clients should issue a warning if they are only able
778
+to connect to a limited set of guard nodes. See also
779
+<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
780
+or-dev post</a>.
781
+</li>
782
+
783
+<li>
784
+<b>Torbutton improvements</b>
785
+<br />
786
+Priority: <i>Medium</i>
787
+<br />
788
+Effort Level: <i>High</i>
789
+<br />
790
+Skill Level: <i>High</i>
791
+<br />
792
+Likely Mentors: <i>Mike</i>
793
+<br/>
794
+Torbutton has a number of improvements that can be made in the post-1.2
795
+timeframe. Most of these are documented as feature requests in the <a
796
+href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5">Torbutton
797
+flyspray section</a>. Good examples include: stripping off node.exit on http
798
+headers, more fine-grained control over formfill blocking, improved referrer
799
+spoofing based on the domain of the site (a-la <a
800
+href="http://addons.mozilla.org/firefox/addon/4513">refspoof extension</a>),
801
+tighter integration with Vidalia for reporting Tor status, a New Identity
802
+button with Tor integration and multiple identity management, and anything
803
+else you might think of.
804
+<br />
805
+This work would be independent coding in Javascript and the fun world of <a
806
+href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
807
+with not too much involvement in the Tor internals.
808
+</li>
809
+
810
+<li>
811
+<b>Porting Polipo to Windows</b>
812
+<br />
813
+Priority: <i>Medium</i>
814
+<br />
815
+Effort Level: <i>Medium</i>
816
+<br />
817
+Skill Level: <i>Medium to High</i>
818
+<br />
819
+Likely Mentors: <i>Andrew, Steven, Roger</i>
820
+<br />
821
+Help port <a
822
+href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
823
+Windows. Example topics to tackle include:
824
+1) handle spaces in path names and understand the filesystem
825
+namespace &mdash; that is, where application data, personal data,
826
+and program data typically reside in various versions of Windows. 2) the
827
+ability to handle ipv6 communications. 3) the ability to asynchronously
828
+query name servers, find the system nameservers, and manage netbios
829
+and dns queries. 4) use native regex capabilities of Windows, rather
830
+than using 3rd party GNU regex libraries. 5) manage events and buffers
831
+natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
832
+Windows it's whatever the config specifies). 6) some sort of GUI config
833
+and reporting tool, bonus if it has a systray icon with right clickable
834
+menu options. Double bonus if it's cross-platform compatible.
835
+</li>
836
+
837
+<li>
838
+<b>Make our diagrams beautiful and automated</b>
839
+<br />
840
+Priority: <i>Medium</i>
841
+<br />
842
+Effort Level: <i>Low</i>
843
+<br />
844
+Skill Level: <i>Low</i>
845
+<br />
846
+Likely Mentors: <i>Andrew</i>
847
+<br />
848
+We need a way to generate the website diagrams (for example, the "How
849
+Tor Works" pictures on the <a href="<page overview>">overview page</a>
850
+from source, so we can translate them as UTF-8 text rather than edit
851
+them by hand with Gimp. We might want to
852
+integrate this as an wml file so translations are easy and images are
853
+generated in multiple languages whenever we build the website. See the
854
+"Translation Wiki" idea above.
855
+</li>
856
+
857
+<li>
858
+<b>Improve the LiveCD offerings for the Tor community</b>
859
+<br />
860
+Priority: <i>Low</i>
861
+<br />
862
+Effort Level: <i>Low</i>
863
+<br />
864
+Skill Level: <i>Medium to High</i>
865
+<br />
866
+Likely Mentors: <i>Anonym, Jacob, Roger</i>
867
+<br />
868
+How can we make the <a
869
+href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
870
+easier to maintain, improve, and document?
871
+</li>
872
+
873
+<li>
874
+<b>Contribuisci con delle nuove idee!</b>
875
+<br />
876
+Nessuna di queste proposte ti piace? Dai un'occhiata alla <a
877
+href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
878
+roadmap</a> per avere altri spunti.
879
+</li>
880
+
881
+</ol>
882
+
95 883
 <h2><a class="anchor" href="#Coding">Programmazione e design</a></h2>
96 884
 <ol>
97 885
 <li>I relay Tor non funzionano bene su Windows XP. Su
... ...
@@ -105,13 +893,7 @@ href="http://www.monkey.org/~provos/libevent/">libevent</a> l'
105 893
 overlapped IO invece di select() su Windows, per poi adattare Tor
106 894
 alla nuova interfaccia libevent. Christian King ha dato un
107 895
 <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">buon inizio
108
-al lavoro</a> la scorsa estate.</li>
109
-<li>Come possiamo fare in modo che l'<a
110
-href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
111
-sia pi&ugrave; facile da mantenere, migliorare e documentare?</li>
112
-<li>Il front-end grafico a Tot che preferiamo,
113
-<a href="http://vidalia-project.net/">Vidalia</a>, ha bisogno di vari
114
-lavori di sviluppo.</li>
896
+al lavoro</a> nell'estate 2007.</li>
115 897
 <li>Dobbiamo iniziare a realizzare il nostro <a href="<page
116 898
 documentation>#DesignDoc">blocking-resistance design</a>. Occorre
117 899
 ideare il design, modificare varie parti di Tor, adattare
... ...
@@ -126,16 +908,6 @@ adeguare? Questo potrebbe contribuire a molte nuove ricerche.
126 908
 Vedi la voce <a href="#Research">qui sotto</a> sui confirmation attack per
127 909
 maggior dettagli sulla ricerca in questo campo &mdash; chiss&agrave; forse al
128 910
 termine  potresti scrivere qualche paper sull'argomento.</li>
129
-<li>Ci serve un framework di testing distribuito. Abbiamo unit tests,
130
-ma sarebbe bello avere uno script che avvii una rete Tor, la usi per
131
-un po' e verifichi che almeno una parte di essa funzioni.</li>
132
-<li>Dai una mano a Mike Perry per la sua libreria <a
133
-href="https://torproject.org/svn/torflow/">TorFlow</a>
134
-(<a href="https://torproject.org/svn/torflow/TODO">TODO</a>):
135
-&egrave; una libreria in pythonche usa il <a
136
-href="https://torproject.org/svn/torctl/doc/howto.txt">Tor controller
137
-protocol</a> per fare costruire a Tor dei circuiti in vari modi,
138
-per poi misurarne le prestazioni e rilevarne le anomalie.</li>
139 911
 <li>Tor 0.1.1.x e successivi includono il supporto per acceleratori crittografici hardware
140 912
 tramite OpenSSL. Nessuno tuttavia lo ha ancora testato. C'&egrave; qualcuno che vuole
141 913
 prendere una scheda e farci sapere come va?</li>
... ...
@@ -156,11 +928,6 @@ UDP</a> &mdash; facci sapere se presentano dei problemi.</li>
156 928
 <li>Non ci manca molto per avere supporto IPv6 per indirizzi destinazione
157 929
 (sugli exit node). Se per te IPv6 &egrave; molto importante, questo &egrave;
158 930
 il punto da cui cominciare.</li>
159
-<li>Se nessuno dei punti qui sopra &egrave; di tuo gusto, dai un'occhiata alla <a
160
-href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development
161
-roadmap</a> per ulteriori spunti.</li>
162
-<li>Se non vedi elencata qui la tua idea, forse &egrave; comunque importante e ne abbiamo bisogno! Contattaci
163
-e scoprilo.</li>
164 931
 </ol>
165 932
 
166 933
 <a id="Research"></a>
... ...
@@ -251,8 +1018,10 @@ puzzle sono la soluzione giusta? Quali altri approcci pratici esistono? Un premi
251 1018
 se sono compatibili col protocollo Tor attuale.</li>
252 1019
 </ol>
253 1020
 
1021
+<p>
254 1022
 <a href="<page contact>">Facci sapere</a> se hai fatto progressi in qualcuno di
255 1023
 questi campi!
1024
+</p>
256 1025
 
257 1026
   </div><!-- #main -->
258 1027
 
259 1028