[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] remove the excess items.
Update of /home2/or/cvsroot/website
In directory moria:/home/arma/work/onion/cvs/website
Modified Files:
volunteer.html
Log Message:
remove the excess items.
perhaps we should fold these back into todo one day.
Index: volunteer.html
===================================================================
RCS file: /home2/or/cvsroot/website/volunteer.html,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- volunteer.html 22 Sep 2005 02:36:55 -0000 1.19
+++ volunteer.html 22 Sep 2005 02:37:39 -0000 1.20
@@ -254,134 +254,3 @@
</body>
</html>
-<li>Have NULL_REP_IS_ZERO_BYTES default to 1.</li>
-<li>Implement preservation of reputation through reboots for clients
-and dirservers.</li>
-<li>Add in support egd or other non-OS-integrated strong entropy sources.</li>
-<li>Implement a way to get autoconf to install things into ~/.tor.</li>
-<li>Change server descriptors to declare log level.</li>
-<li>Add in support for clients to avoid servers that are too loggy based upon user configuration of acceptable log level.</li>
-<li>Separate node discovery from routing to allow neat extensions. [Goodell?]
-
-<ul>
-<li>Add SetServerStatus control event to adjust verified/running status of nodes.</li>
-<li>Add NoDownload config option to prevent regular directory downloads from happening.</li>
-</ul>
-</li>
-
-<li>Use cpuworker for more heavy lifting.</li>
-<ul>
-<li>Signing (and verifying) hidserv descriptors</li>
-<li>Signing (and verifying) intro/rend requests</li>
-<li>Signing (and verifying) router descriptors</li>
-<li>Signing (and verifying) directories</li>
-<li>Doing TLS handshake (this is very hard to separate out, though)</li>
-</ul>
-
-<li>Buffer size pool: allocate a maximum size for all buffers, not a maximum size for each buffer. So we don't have to give up as quickly (and kill the thickpipe!) when there's congestion.</li>
-<li>Add alternative versions of crypto.c and tortls.c to use libnss or libgcrypt+gnutls.</li>
-
-Translation Examples: <a
-href="http://membres.lycos.fr/geolemalin/anonymat_garantit.htm";>French</a>,
-<a href="http://tor.freesuperhost.com/";>Persian</a>, and <a
-href="http://www.gamevn.com/forum/showthread.php?t=103346";>Vietnamese</a>.)</li>
-<li>If you know a question that should go on <a
-href="http://wiki.noreply.org/wiki/TheOnionRouter/TorFAQ";>the FAQ Wiki</a>, please
-add it and answer it.</li>
-<li>Document how to do exit node caching: tie into squid or other caching
-web proxy.</li>
-<li>Take a look at <a
-href="http://wiki.noreply.org/wiki/TheOnionRouter/SquidProxy";>Martin's
-Squid and Tor page</a>, and update it to reflect Tor's <a
-href="http://tor.eff.org/tor-manual.html";>RedirectExit</a> config option. </li>
-<li>Improve and clarify the wiki entry on <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerForFirewalledClients";>port forwarding</a>.</li>
-</ul>
-
-<h2>Testing Challenges</h2>
-<ul>
-<li>Test out why some of our tor servers have dns resolvers that resolve
-unknown addresses to 127.0.0.1.
-
-<ul>
-<li>Identify the servers that experience this issue. </li>
-<li>Identify how to cause and repair the issue in BIND, DJBDNS, or
-whatever daemon the misconfigured servers use.</li>
-</ul></li>
-
-<li>Figure out how to setup web proxy gateways to let normal people
-browse hidden services. (This has been done a few times, but nobody has
-sent us code.)</li>
-
-<h2>Misc</h2>
-<ul>
-<li> </li>
-</ul>
-
-
-
-<h2>Research Challenges</h2>
-<ul>
-<li>Arranging membership management for independence.
-
-<ul>
-<li>Sybil defenses without having a human bottleneck.</li>
-<li>How to gather random sample of nodes.</li>
-<li>How to handle nodelist recommendations.</li>
-<li>Consider incremental switches: a p2p tor with only 50 users has
-different anonymity properties than one with 10k users, and should be
-treated differently.</li>
-</ul></li>
-
-<li>Incentives to relay; incentives to exit.</li>
-<li>Allowing dissidents to relay through Tor clients.</li>
-<li>Experiment with mid-latency systems. How do they impact usability,
- how do they impact safety?</li>
-<li>Understand how powerful fingerprinting attacks are, and experiment
- with ways to foil them (long-range padding?).</li>
-<li>Attacking freenet-gnunet/timing-delay-randomness-arguments.</li>
-
-<ul>
-<li>Spec issue: if a resolve returns an IP4 and an IP6 address,
- which to use?</li>
-<li>Add to exit policy code</li>
-<li>Make tor_gethostbyname into tor_getaddrinfo</li>
-<li>Make everything that uses uint32_t as an IP address change to use
- a generalize address struct.</li>
-<li>Change relay cell types to accept new addresses.</li>
-<li>Add flag to serverdescs to tell whether IPv6 is supported.</li>
-</ul></li>
-
-<li>make freecap (or whichever) do what we want.</li>
-<li>scrubbing proxies for protocols other than http.</li>
-<li>We need better default privoxy configs to ship.</li>
-<li>We need a good scrubbing HTTP proxy; privoxy is unmaintained and
-sucky.</li>
-<li>A DNS proxy would let unmodified socks4/socks5 apps to work
-well.</li>
-<li>Add SOCKS support to more applications</li>
-<li>store hidden service information to disk: dirservers forget service
-descriptors when they restart; nodes offering hidden services forget
-their chosen intro points when they restart.</li>
-<li>Server CPU load is high because clients keep asking to make new
-circuits, which uses public key crypto. Possible defenses include: using
-helper nodes (fixed entry nodes); rate limiting the number of create
-cells handled per second; having clients retry failed extensions a few
-times; implementing ssl sessions; and using hardware crypto when
-available.</li>
-<li>We fear we might not work very well when servers have asymmetric
-bandwidth. Because Tor has separate TCP connections between each hop, if
-the incoming bytes are arriving just fine and the outgoing bytes are all
-getting dropped on the floor, the TCP push-back mechanisms don't really
-transmit this information back to the incoming streams. Perhaps Tor
-should detect when it's dropping a lot of outgoing packets, and
-rate-limit incoming streams to regulate this itself? We need somebody
-who's good with networks to simulate this and help design
-solutions.</li>
-<li>Right now the hidden service descriptors are being stored on the
-dirservers, but any reliable distributed storage system would do (for
-example, a DHT that allows authenticated updates). Can somebody figure
-out our best options and decide if they're good enough?</li>
-
-</ul>
-
-