clean up the volunteer page, remove commented sections, put torbutton back.
Andrew Lewman

Andrew Lewman commited on 2010-08-11 22:47:51
Zeige 1 geänderte Dateien mit 3 Einfügungen und 151 Löschungen.

... ...
@@ -238,64 +238,6 @@ resist an adversary even after the adversary knows the design, and
238 238
 then trading off censorship resistance with usability and robustness.
239 239
 </li>
240 240
 
241
-<!--<li>
242
-<b>Tuneup Tor!</b>
243
-<br />
244
-Priority: <i>Medium to High</i>
245
-<br />
246
-Effort Level: <i>Medium to High</i>
247
-<br />
248
-Skill Level: <i>High</i>
249
-<br />
250
-Likely Mentors: <i>Nick, Roger, Mike, Karsten</i>
251
-<br />
252
-Right now, Tor relays measure and report their own bandwidth, and Tor
253
-clients choose which relays to use in part based on that bandwidth.
254
-This approach is vulnerable to
255
-<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
256
-relays lie about their bandwidth</a>;
257
-to address this, Tor currently caps the maximum bandwidth
258
-it's willing to believe any relay provides.  This is a limited fix, and
259
-a waste of bandwidth capacity to boot.  Instead,
260
-Tor should possibly measure bandwidth in a more distributed way, perhaps
261
-as described in the
262
-<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
263
-Tor"</a> paper
264
-by Snader and Borisov. One could use current testing code to
265
-double-check this paper's findings and verify the extent to which they
266
-dovetail with Tor as deployed in the wild, and determine good ways to
267
-incorporate them into their suggestions Tor network without adding too
268
-much communications overhead between relays and directory
269
-authorities.
270
-</li>-->
271
-
272
-<li>
273
-<b>Improving Polipo on Windows</b>
274
-<br />
275
-Priority: <i>Medium to High</i>
276
-<br />
277
-Effort Level: <i>Medium</i>
278
-<br />
279
-Skill Level: <i>Medium</i>
280
-<br />
281
-Likely Mentors: <i>Chris</i>
282
-<br />
283
-Help port <a
284
-href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
285
-Windows. Example topics to tackle include:
286
-<ol><li> the ability to asynchronously query name servers, find the
287
-system nameservers, and manage netbios and dns queries.</li>
288
-<li> manage events and buffers natively (i.e. in Unix-like OSes,
289
-Polipo defaults to 25% of ram, in Windows it's whatever the config
290
-specifies).</li>
291
-<li> some sort of GUI config and reporting tool, bonus if it has a
292
-systray icon with right clickable menu options. Double bonus if it's
293
-cross-platform compatible.</li>
294
-<li> allow the software to use the Windows Registry and handle proper
295
-Windows directory locations, such as "C:\Program Files\Polipo"</li>
296
-</ol>
297
-</li>
298
-
299 241
 <li>
300 242
 <b>Tor Controller Status Event Interface for Vidalia</b>
301 243
 <br />
... ...
@@ -419,7 +361,7 @@ Likely Mentors: <i>Nathan</i>
419 361
 <b>Android OS/C/Linux work:</b> The port of Tor to Android is basically a straight cross-compile to Linux ARM. There has been no work done in looking the optimization of Tor within a mobile hardware environment, on the ARM processor or other Android hardware, or on mobile networks. It should be noted, that even without optimization, Tor is handling the mobile network environment very well, automatically detecting change in IP addresses, reconnecting circuits, etc across switching from 2G to 3G to Wifi, and so forth. 
420 362
 </li>
421 363
 
422
-<!--<li>
364
+<li>
423 365
 <b>New Torbutton Features</b>
424 366
 <br />
425 367
 Priority: <i>Medium</i>
... ...
@@ -451,7 +393,7 @@ features that could be added.
451 393
 This work would be independent coding in Javascript and the fun world of <a
452 394
 href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
453 395
 with not too much involvement in the Tor internals.
454
-</li>-->
396
+</li>
455 397
 
456 398
 <!-- <li>
457 399
 <b>New Thandy Features</b>
... ...
@@ -565,26 +507,6 @@ the outgoing mail that it sends. At some point we should start a new
565 507
 push to build a Thunderbird extension similar to Torbutton.
566 508
 </li>
567 509
 
568
-<!--<li>
569
-<b>Intermediate Level Network Device Driver</b>
570
-<br />
571
-Priority: <i>Low</i>
572
-<br />
573
-Effort Level: <i>High</i>
574
-<br />
575
-Skill Level: <i>High</i>
576
-<br />
577
-Likely Mentors: <i>Martin</i>
578
-<br />
579
-The WinPCAP device driver used by Tor VM for bridged networking does
580
-not support a number of wireless and non-Ethernet network adapters.
581
-Implementation of a intermediate level network device driver for win32
582
-and 64bit would provide a way to intercept and route traffic over such
583
-networks. This project will require knowledge of and experience with
584
-Windows kernel device driver development and testing. Familiarity with
585
-Winsock and Qemu would also be helpful.
586
-</li>-->
587
-
588 510
 <li>
589 511
 <b>Improve Tor Weather</b>
590 512
 <br />
... ...
@@ -665,77 +587,7 @@ distributions and their packaging mechanisms as well as some C++ development
665 587
 experience. Previous experience with Qt is helpful, but not required.
666 588
 </li>
667 589
 
668
-<!--<li>
669
-<b>Tor/Polipo/Vidalia Auto-Update Framework</b>
670
-<br />
671
-We're in need of a good authenticated-update framework.
672
-Vidalia already has the ability to notice when the user is running an
673
-outdated or unrecommended version of Tor, using signed statements inside
674
-the Tor directory information. Currently, Vidalia simply pops
675
-up a little message box that lets the user know they should manually
676
-upgrade. The goal of this project would be to extend Vidalia with the
677
-ability to also fetch and install the updated Tor software for the
678
-user. We should do the fetches via Tor when possible, but also fall back
679
-to direct fetches in a smart way. Time permitting, we would also like
680
-to be able to update other
681
-applications included in the bundled installers, such as Polipo and
682
-Vidalia itself.
683
-<br />
684
-To complete this project, the student will first need to first investigate
685
-the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate
686
-their strengths, weaknesses, security properties, and ability to be
687
-integrated into Vidalia. If none are found to be suitable, the student
688
-will design their own auto-update framework, document the design, and
689
-then discuss the design with other developers to assess any security
690
-issues. The student will then implement their framework (or integrate
691
-an existing one) and test it.
692
-<br />
693
-A person undertaking this project should have good C++ development
694
-experience. Previous experience with Qt is helpful, but not required. One
695
-should also have a good understanding of common security
696
-practices, such as package signature verification. Good writing ability
697
-is also important for this project, since a vital step of the project
698
-will be producing a design document to review and discuss
699
-with others prior to implementation.
700
-</li>-->
701
-
702 590
 <li>
703
-<b>Improving the Tor QA process: Continuous Integration for builds</b>
704
-<br />
705
-Priority: <i>Medium</i>
706
-<br />
707
-Effort Level: <i>Medium</i>
708
-<br />
709
-Skill Level: <i>Medium</i>
710
-<br />
711
-Likely Mentors: <i>Erinn</i>
712
-<br />
713
-It would be useful to have automated build processes for Windows and
714
-probably other platforms. The purpose of having a continuous integration
715
-build environment is to ensure that Windows isn't left behind for any of
716
-the software projects used in the Tor project or its accompanying.<br />
717
-Buildbot may be a good choice for this as it appears to support all of
718
-the platforms Tor does. See the
719
-<a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for
720
-buildbot</a>.<br />
721
-There may be better options and the person undertaking this task should
722
-evaluate other options. Any person working on this automatic build
723
-process should have experience or be willing to learn how to build all
724
-of the respective Tor related code bases from scratch. Furthermore, the
725
-person should have some experience building software in Windows
726
-environments as this is the target audience we want to ensure we do not
727
-leave behind. It would require close work with the Tor source code but
728
-probably only in the form of building, not authoring.<br />
729
-Additionally, we need to automate our performance testing for all platforms.
730
-We've got buildbot (except on Windows &mdash; as noted above) to automate
731
-our regular integration and compile testing already,
732
-but we need to get our network simulation tests (as built in torflow)
733
-updated for more recent versions of Tor, and designed to launch a test
734
-network either on a single machine, or across several, so we can test
735
-changes in performance on machines in different roles automatically.
736
-</li>
737
-
738
-<!--<li>
739 591
 <b>Usability testing of Tor</b>
740 592
 <br />
741 593
 Priority: <i>Medium</i>
... ...
@@ -750,7 +602,7 @@ Especially the browser bundle, ideally amongst our target demographic.
750 602
 That would help a lot in knowing what needs to be done in terms of bug
751 603
 fixes or new features. We get this informally at the moment, but a more
752 604
 structured process would be better.
753
-</li>-->
605
+</li>
754 606
 
755 607
 <li>
756 608
 <b>An authenticating IRC proxy</b>
757 609