re-arranged to new categories. Next steps are to rewrite all items to consistent voice and sub-categorize. (db86a2d0a)

new-contribute.html

@@ -40,59 +40,90 @@
 
 <!-- PUT CONTENT AFTER THIS TAG -->
 <pre>
-new stuff I don't have a plan for yet:
-
+    Six Easy Pieces:
+    - We need users like you to try Tor out, and let the Tor developers know about bugs you find or features you don't find.
+    - Please consider running a server to help the Tor network grow.
+    - We especially need people with Windows programming skills to run an exit server on Windows, to help us debug.
+    - Run a Tor hidden service and put interesting content on it.
+    - Tell your friends! Get them to run servers. Get them to run hidden services. Get them to tell their friends.
+    - Consider joining the Electronic Frontier Foundation. More EFF donations means more freedom in the world, including more Tor development.
+
+****coding challenges****
+	**easy**
+	**medium**
+	**hard**
   - use openssl aes when available
   - do the kernel buffer style design
-  - Server instructions for OSX and Windows operators.
-  - Improve and clarify the wiki entry on port forwarding.
-  - how do ulimits work on win32, anyway?  (We should handle WSAENOBUFS as
-    needed, look at the MaxConnections registry entry, look at the
-    MaxUserPort entry, and look at the TcpTimedWaitDelay entry. We may also
-    want to provide a way to set them as needed. See bug 98.)
+  - how do ulimits work on win32, anyway?  (We should handle WSAENOBUFS as needed, look at the MaxConnections registry entry, look at the MaxUserPort entry, and look at the TcpTimedWaitDelay entry. We may also want to provide a way to set them as needed. See bug 98.)
   - Implement reverse DNS (already specified)
-  - It would be nice to have a FirewalledIPs thing that works like
-    FirewallPorts.
+  - It would be nice to have a FirewalledIPs thing that works like FirewallPorts.
   - Make configure.in handle cross-compilation
     - Have NULL_REP_IS_ZERO_BYTES default to 1.
     - Make with-ssl-dir disable search for ssl.
-  - Packaging, docs, etc:
-   - Exit node caching: tie into squid or other caching web proxy.
-  - Have clients and dirservers preserve reputation info over
-    reboots.
+  - Have clients and dirservers preserve reputation info over reboots.
   - Support egd or other non-OS-integrated strong entropy sources
   - password protection for on-disk identity key
   - Possible to get autoconf to easily install things into ~/.tor?
-  - server descriptor declares min log level, clients avoid servers
-     that are too loggy.
+  - server descriptor declares min log level, clients avoid servers that are too loggy.
   - Separate node discovery from routing to allow neat extensions. [Goodell?]
-    - Add SetServerStatus control event to adjust verified/running status of
-      nodes.
-    - Add NoDownload config option to prevent regular directory downloads
-      from happening.
+    - Add SetServerStatus control event to adjust verified/running status of nodes.
+    - Add NoDownload config option to prevent regular directory downloads from happening.
   - Choosing exit node by meta-data, e.g. country.
-  - What info squeaks by Privoxy? Are other scrubbers better?
-  - web proxy gateways to let normal people browse hidden services.
-    (This has been done a few times, but nobody has sent us code.)
   - Use cpuworker for more heavy lifting.
     - Signing (and verifying) hidserv descriptors
     - Signing (and verifying) intro/rend requests
     - Signing (and verifying) router descriptors
     - Signing (and verifying) directories
     - Doing TLS handshake (this is very hard to separate out, though)
-  - 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.
-  - Congestion control. Is our current design sufficient once we have heavy
-    use? Need to measure and tweak, or maybe overhaul.
-  - Add alternative versions of crypto.c and tortls.c to use libnss or
-    libgcrypt+gnutls.
-  - If we have a trusted directory on port 80, optionally stop falling back
-    to forbidden ports when fascistfirewall blocks all good dirservers.
+  - 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.
+  - Congestion control. Is our current design sufficient once we have heavy use? Need to measure and tweak, or maybe overhaul.
+  - Add alternative versions of crypto.c and tortls.c to use libnss or libgcrypt+gnutls.
+  - If we have a trusted directory on port 80, optionally stop falling back to forbidden ports when fascistfirewall blocks all good dirservers.
+  - We're always looking for better Windows installers. Specifically, it would be great if somebody were to extend our NSIS-based windows installer to include FreeCap and Privoxy.
+    - Our OS X installer can't be uninstalled. Are there non-sucky OS X packagers that have uninstall capabilities? This is becoming an increasing bother.
+    - We need somebody to code up a GUI or other controller program, to do configuration, etc. See our control specification for details, and the rudimentary demonstration Python control script. No, we don't know what the interface should look like. You can use any license you want, but we'd recommend 3-clause BSD or maybe GPL; and we can only help out if your license conforms to the DFSG.
+    - Periodically people running servers tells us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. Perhaps it would run out of cron, or perhaps it would sleep until appropriate times and then do its tweak (that's probably more portable). Can somebody write one for us and we'll put it inside tor/contrib/?
+    - Does somebody want to do up a patch so we can be an NT service? Or so we can go in the system tray?
+    - A good (portable, fast, clean, BSD-free) asynchronous DNS library would be really handy, so we don't have to keep forking DNS worker threads to do gethostbyname.
+    - We're always looking for better Windows installers. Specifically, it would be great if somebody were to extend our NSIS-based windows installer to include FreeCap and Privoxy.
+    - Our OS X installer can't be uninstalled. Are there non-sucky OS X packagers that have uninstall capabilities? This is becoming an increasing bother.
+    - We need somebody to code up a GUI or other controller program, to do configuration, etc. See our control specification for details, and the rudimentary demonstration Python control script. No, we don't know what the interface should look like. You can use any license you want, but we'd recommend 3-clause BSD or maybe GPL; and we can only help out if your license conforms to the DFSG.
+    - Periodically people running servers tells us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. Perhaps it would run out of cron, or perhaps it would sleep until appropriate times and then do its tweak (that's probably more portable). Can somebody write one for us and we'll put it inside tor/contrib/?
+    - Does somebody want to do up a patch so we can be an NT service? Or so we can go in the system tray?
+    - A good (portable, fast, clean, BSD-free) asynchronous DNS library would be really handy, so we don't have to keep forking DNS worker threads to do gethostbyname.
+
+****documentation challenges****
+	**easy**
+	**medium**
+	**hard**
+
+  - Server instructions for OSX and Windows operators.
+  - Improve and clarify the wiki entry on port forwarding.
+   - Exit node caching: tie into squid or other caching web proxy.
+    - Does somebody want to help maintain this website, or help with documentation, or help with managing our TODO and handling bug reports?
+    - We may have too much documentation. It's spread out too far and duplicates itself in places. Can you help us consolidate?
+    - Please help translate the web page and documentation into other languages. See the translation guidelines if you want to help out. (Examples: French , Persian and Vietnamese.)
+    - Please fix up the FAQ Wiki, and if you know the answer to a question in the "unanswered FAQs" list, please answer it.
+    - Can somebody take a look at Martin's Squid and Tor page, and update it to reflect Tor's RedirectExit config option?
+
+****testing challenges****
+	**easy**
+	**medium**
+	**hard**
+
+  - web proxy gateways to let normal people browse hidden services.  (This has been done a few times, but nobody has sent us code.)
   - investigate privoxy vs. freecap for win32 clients
+    - We've got a list of potentially useful programs you might run with Tor here. We also have the Torify howto. Can somebody try them out, simplify the explanations, expand them where they need it, document them better, and make them all-around more useful?
+    - We need somebody to fuzz Tor. Are there good libraries out there for what we want? What are the first steps? Win fame by getting credit when we put out a new release because of you!
+    - Website volume fingerprinting attacks (Back et al, Hintz). Defenses include a large cell size, defensive dropping, etc. How well does each approach work?
+    - The end-to-end traffic confirmation attack. We need to study long-range dummies more, along with traffic shaping. How much traffic of what sort of distribution is needed before the adversary is confident he has won?
+    - What sensitive info squeaks by privoxy? Are other html scrubbers better?
 
+****research challenges****
+	**easy**
+	**medium**
+	**hard**
 
-Research projects: [Phobos moves these to contribute.html]
   - Arranging membership management for independence.
     Sybil defenses without having a human bottleneck.
     How to gather random sample of nodes.
@@ -130,59 +161,12 @@ Research projects: [Phobos moves these to contribute.html]
   - 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.
-
-Ongoing needs:
-
-    * We need users like you to try Tor out, and let the Tor developers know about bugs you find or features you don't find.
-    * Please consider running a server to help the Tor network grow.
-    * We especially need people with Windows programming skills to run an exit server on Windows, to help us debug.
-    * Run a Tor hidden service and put interesting content on it.
-    * Tell your friends! Get them to run servers. Get them to run hidden services. Get them to tell their friends.
-    * What else needs to be documented? What is mis-documented?
-    * Consider joining the Electronic Frontier Foundation. More EFF donations means more freedom in the world, including more Tor development.
-
-We also have many project-lets: short-term or self-contained tasks that would be really helpful for somebody to tackle so we can keep focusing on Tor.
-
-Writing project-lets:
-
-    * Does somebody want to help maintain this website, or help with documentation, or help with managing our TODO and handling bug reports?
-    * We may have too much documentation. It's spread out too far and duplicates itself in places. Can you help us consolidate?
-    * Please help translate the web page and documentation into other languages. See the translation guidelines if you want to help out. (Examples: French , Persian and Vietnamese.)
-    * Please fix up the FAQ Wiki, and if you know the answer to a question in the "unanswered FAQs" list, please answer it.
-
-Packaging project-lets:
-
-    * We're always looking for better Windows installers. Specifically, it would be great if somebody were to extend our NSIS-based windows installer to include FreeCap and Privoxy.
-    * Our OS X installer can't be uninstalled. Are there non-sucky OS X packagers that have uninstall capabilities? This is becoming an increasing bother.
-
-Organizational and application testing project-lets:
-
-    * We've got a list of potentially useful programs you might run with Tor here. We also have the Torify howto. Can somebody try them out, simplify the explanations, expand them where they need it, document them better, and make them all-around more useful?
-
-Programmer and developer project-lets:
-
-    * We need somebody to code up a GUI or other controller program, to do configuration, etc. See our control specification for details, and the rudimentary demonstration Python control script. No, we don't know what the interface should look like. You can use any license you want, but we'd recommend 3-clause BSD or maybe GPL; and we can only help out if your license conforms to the DFSG.
-    * Periodically people running servers tells us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. Perhaps it would run out of cron, or perhaps it would sleep until appropriate times and then do its tweak (that's probably more portable). Can somebody write one for us and we'll put it inside tor/contrib/?
-    * Does somebody want to do up a patch so we can be an NT service? Or so we can go in the system tray?
-    * A good (portable, fast, clean, BSD-free) asynchronous DNS library would be really handy, so we don't have to keep forking DNS worker threads to do gethostbyname.
-    * Can somebody take a look at Martin's Squid and Tor page, and update it to reflect Tor's RedirectExit config option?
-    * See the TODO and HACKING files in the Tor distribution for more ideas.
-
-Security project-lets: We need people to attack the implementation and clean it up, and also to attack the design and experiment with defenses.
-
-    * We need somebody to fuzz Tor. Are there good libraries out there for what we want? What are the first steps? Win fame by getting credit when we put out a new release because of you!
-    * Website volume fingerprinting attacks (Back et al, Hintz). Defenses include a large cell size, defensive dropping, etc. How well does each approach work?
-    * The end-to-end traffic confirmation attack. We need to study long-range dummies more, along with traffic shaping. How much traffic of what sort of distribution is needed before the adversary is confident he has won?
-    * It's not that hard to DoS Tor servers or dirservers. Are puzzles the right answer? What other practical approaches are there?
-    * What sensitive info squeaks by privoxy? Are other html scrubbers better?
-
-Designer project-lets:
-
-    * 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.
-    * 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.
-    * 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?
-    * How hard is it to patch bind or a DNS proxy to redirect requests to Tor via our tor-resolve socks extension? What about to convert UDP DNS requests to TCP requests and send them through Tor?
-    * Tor provides anonymous connections, but if you want to keep multiple pseudonyms in practice (say, in case you frequently go to two websites and if anybody knew about both of them they would conclude it's you), we don't support that well yet. We should find a good approach and interface for handling pseudonymous profiles in Tor. See this post and followup for details.
+  - It's not that hard to DoS Tor servers or dirservers. Are puzzles the right answer? What other practical approaches are there?
+    - 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.
+    - 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.
+    - 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?
+    - How hard is it to patch bind or a DNS proxy to redirect requests to Tor via our tor-resolve socks extension? What about to convert UDP DNS requests to TCP requests and send them through Tor?
+    - Tor provides anonymous connections, but if you want to keep multiple pseudonyms in practice (say, in case you frequently go to two websites and if anybody knew about both of them they would conclude it's you), we don't support that well yet. We should find a good approach and interface for handling pseudonymous profiles in Tor. See this post and followup for details.
 
 Drop by the #tor IRC channel at irc.oftc.net or email tor-volunteer@freehaven.net if you want to help out!
 


...	...	@@ -40,59 +40,90 @@
40	40
41	41	<!-- PUT CONTENT AFTER THIS TAG -->
42	42	<pre>
43		-new stuff I don't have a plan for yet:
44		-
	43	+ Six Easy Pieces:
	44	+ - We need users like you to try Tor out, and let the Tor developers know about bugs you find or features you don't find.
	45	+ - Please consider running a server to help the Tor network grow.
	46	+ - We especially need people with Windows programming skills to run an exit server on Windows, to help us debug.
	47	+ - Run a Tor hidden service and put interesting content on it.
	48	+ - Tell your friends! Get them to run servers. Get them to run hidden services. Get them to tell their friends.
	49	+ - Consider joining the Electronic Frontier Foundation. More EFF donations means more freedom in the world, including more Tor development.
	50	+
	51	+**coding challenges**
	52	+ easy
	53	+ medium
	54	+ hard
45	55	- use openssl aes when available
46	56	- do the kernel buffer style design
47		- - Server instructions for OSX and Windows operators.
48		- - Improve and clarify the wiki entry on port forwarding.
49		- - how do ulimits work on win32, anyway? (We should handle WSAENOBUFS as
50		- needed, look at the MaxConnections registry entry, look at the
51		- MaxUserPort entry, and look at the TcpTimedWaitDelay entry. We may also
52		- want to provide a way to set them as needed. See bug 98.)
	57	+ - how do ulimits work on win32, anyway? (We should handle WSAENOBUFS as needed, look at the MaxConnections registry entry, look at the MaxUserPort entry, and look at the TcpTimedWaitDelay entry. We may also want to provide a way to set them as needed. See bug 98.)
53	58	- Implement reverse DNS (already specified)
54		- - It would be nice to have a FirewalledIPs thing that works like
55		- FirewallPorts.
	59	+ - It would be nice to have a FirewalledIPs thing that works like FirewallPorts.
56	60	- Make configure.in handle cross-compilation
57	61	- Have NULL_REP_IS_ZERO_BYTES default to 1.
58	62	- Make with-ssl-dir disable search for ssl.
59		- - Packaging, docs, etc:
60		- - Exit node caching: tie into squid or other caching web proxy.
61		- - Have clients and dirservers preserve reputation info over
62		- reboots.
	63	+ - Have clients and dirservers preserve reputation info over reboots.
63	64	- Support egd or other non-OS-integrated strong entropy sources
64	65	- password protection for on-disk identity key
65	66	- Possible to get autoconf to easily install things into ~/.tor?
66		- - server descriptor declares min log level, clients avoid servers
67		- that are too loggy.
	67	+ - server descriptor declares min log level, clients avoid servers that are too loggy.
68	68	- Separate node discovery from routing to allow neat extensions. [Goodell?]
69		- - Add SetServerStatus control event to adjust verified/running status of
70		- nodes.
71		- - Add NoDownload config option to prevent regular directory downloads
72		- from happening.
	69	+ - Add SetServerStatus control event to adjust verified/running status of nodes.
	70	+ - Add NoDownload config option to prevent regular directory downloads from happening.
73	71	- Choosing exit node by meta-data, e.g. country.
74		- - What info squeaks by Privoxy? Are other scrubbers better?
75		- - web proxy gateways to let normal people browse hidden services.
76		- (This has been done a few times, but nobody has sent us code.)
77	72	- Use cpuworker for more heavy lifting.
78	73	- Signing (and verifying) hidserv descriptors
79	74	- Signing (and verifying) intro/rend requests
80	75	- Signing (and verifying) router descriptors
81	76	- Signing (and verifying) directories
82	77	- Doing TLS handshake (this is very hard to separate out, though)
83		- - Buffer size pool: allocate a maximum size for all buffers, not a maximum
84		- size for each buffer. So we don't have to give up as quickly (and kill
85		- the thickpipe!) when there's congestion.
86		- - Congestion control. Is our current design sufficient once we have heavy
87		- use? Need to measure and tweak, or maybe overhaul.
88		- - Add alternative versions of crypto.c and tortls.c to use libnss or
89		- libgcrypt+gnutls.
90		- - If we have a trusted directory on port 80, optionally stop falling back
91		- to forbidden ports when fascistfirewall blocks all good dirservers.
	78	+ - 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.
	79	+ - Congestion control. Is our current design sufficient once we have heavy use? Need to measure and tweak, or maybe overhaul.
	80	+ - Add alternative versions of crypto.c and tortls.c to use libnss or libgcrypt+gnutls.
	81	+ - If we have a trusted directory on port 80, optionally stop falling back to forbidden ports when fascistfirewall blocks all good dirservers.
	82	+ - We're always looking for better Windows installers. Specifically, it would be great if somebody were to extend our NSIS-based windows installer to include FreeCap and Privoxy.
	83	+ - Our OS X installer can't be uninstalled. Are there non-sucky OS X packagers that have uninstall capabilities? This is becoming an increasing bother.
	84	+ - We need somebody to code up a GUI or other controller program, to do configuration, etc. See our control specification for details, and the rudimentary demonstration Python control script. No, we don't know what the interface should look like. You can use any license you want, but we'd recommend 3-clause BSD or maybe GPL; and we can only help out if your license conforms to the DFSG.
	85	+ - Periodically people running servers tells us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. Perhaps it would run out of cron, or perhaps it would sleep until appropriate times and then do its tweak (that's probably more portable). Can somebody write one for us and we'll put it inside tor/contrib/?
	86	+ - Does somebody want to do up a patch so we can be an NT service? Or so we can go in the system tray?
	87	+ - A good (portable, fast, clean, BSD-free) asynchronous DNS library would be really handy, so we don't have to keep forking DNS worker threads to do gethostbyname.
	88	+ - We're always looking for better Windows installers. Specifically, it would be great if somebody were to extend our NSIS-based windows installer to include FreeCap and Privoxy.
	89	+ - Our OS X installer can't be uninstalled. Are there non-sucky OS X packagers that have uninstall capabilities? This is becoming an increasing bother.
	90	+ - We need somebody to code up a GUI or other controller program, to do configuration, etc. See our control specification for details, and the rudimentary demonstration Python control script. No, we don't know what the interface should look like. You can use any license you want, but we'd recommend 3-clause BSD or maybe GPL; and we can only help out if your license conforms to the DFSG.
	91	+ - Periodically people running servers tells us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. Perhaps it would run out of cron, or perhaps it would sleep until appropriate times and then do its tweak (that's probably more portable). Can somebody write one for us and we'll put it inside tor/contrib/?
	92	+ - Does somebody want to do up a patch so we can be an NT service? Or so we can go in the system tray?
	93	+ - A good (portable, fast, clean, BSD-free) asynchronous DNS library would be really handy, so we don't have to keep forking DNS worker threads to do gethostbyname.
	94	+
	95	+**documentation challenges**
	96	+ easy
	97	+ medium
	98	+ hard
	99	+
	100	+ - Server instructions for OSX and Windows operators.
	101	+ - Improve and clarify the wiki entry on port forwarding.
	102	+ - Exit node caching: tie into squid or other caching web proxy.
	103	+ - Does somebody want to help maintain this website, or help with documentation, or help with managing our TODO and handling bug reports?
	104	+ - We may have too much documentation. It's spread out too far and duplicates itself in places. Can you help us consolidate?
	105	+ - Please help translate the web page and documentation into other languages. See the translation guidelines if you want to help out. (Examples: French , Persian and Vietnamese.)
	106	+ - Please fix up the FAQ Wiki, and if you know the answer to a question in the "unanswered FAQs" list, please answer it.
	107	+ - Can somebody take a look at Martin's Squid and Tor page, and update it to reflect Tor's RedirectExit config option?
	108	+
	109	+**testing challenges**
	110	+ easy
	111	+ medium
	112	+ hard
	113	+
	114	+ - web proxy gateways to let normal people browse hidden services. (This has been done a few times, but nobody has sent us code.)
92	115	- investigate privoxy vs. freecap for win32 clients
	116	+ - We've got a list of potentially useful programs you might run with Tor here. We also have the Torify howto. Can somebody try them out, simplify the explanations, expand them where they need it, document them better, and make them all-around more useful?
	117	+ - We need somebody to fuzz Tor. Are there good libraries out there for what we want? What are the first steps? Win fame by getting credit when we put out a new release because of you!
	118	+ - Website volume fingerprinting attacks (Back et al, Hintz). Defenses include a large cell size, defensive dropping, etc. How well does each approach work?
	119	+ - The end-to-end traffic confirmation attack. We need to study long-range dummies more, along with traffic shaping. How much traffic of what sort of distribution is needed before the adversary is confident he has won?
	120	+ - What sensitive info squeaks by privoxy? Are other html scrubbers better?
93	121
	122	+**research challenges**
	123	+ easy
	124	+ medium
	125	+ hard
94	126
95		-Research projects: [Phobos moves these to contribute.html]
96	127	- Arranging membership management for independence.
97	128	Sybil defenses without having a human bottleneck.
98	129	How to gather random sample of nodes.
...	...	@@ -130,59 +161,12 @@ Research projects: [Phobos moves these to contribute.html]
130	161	- store hidden service information to disk: dirservers forget service
131	162	descriptors when they restart; nodes offering hidden services forget
132	163	their chosen intro points when they restart.
133		-
134		-Ongoing needs:
135		-
136		- * We need users like you to try Tor out, and let the Tor developers know about bugs you find or features you don't find.
137		- * Please consider running a server to help the Tor network grow.
138		- * We especially need people with Windows programming skills to run an exit server on Windows, to help us debug.
139		- * Run a Tor hidden service and put interesting content on it.
140		- * Tell your friends! Get them to run servers. Get them to run hidden services. Get them to tell their friends.
141		- * What else needs to be documented? What is mis-documented?
142		- * Consider joining the Electronic Frontier Foundation. More EFF donations means more freedom in the world, including more Tor development.
143		-
144		-We also have many project-lets: short-term or self-contained tasks that would be really helpful for somebody to tackle so we can keep focusing on Tor.
145		-
146		-Writing project-lets:
147		-
148		- * Does somebody want to help maintain this website, or help with documentation, or help with managing our TODO and handling bug reports?
149		- * We may have too much documentation. It's spread out too far and duplicates itself in places. Can you help us consolidate?
150		- * Please help translate the web page and documentation into other languages. See the translation guidelines if you want to help out. (Examples: French , Persian and Vietnamese.)
151		- * Please fix up the FAQ Wiki, and if you know the answer to a question in the "unanswered FAQs" list, please answer it.
152		-
153		-Packaging project-lets:
154		-
155		- * We're always looking for better Windows installers. Specifically, it would be great if somebody were to extend our NSIS-based windows installer to include FreeCap and Privoxy.
156		- * Our OS X installer can't be uninstalled. Are there non-sucky OS X packagers that have uninstall capabilities? This is becoming an increasing bother.
157		-
158		-Organizational and application testing project-lets:
159		-
160		- * We've got a list of potentially useful programs you might run with Tor here. We also have the Torify howto. Can somebody try them out, simplify the explanations, expand them where they need it, document them better, and make them all-around more useful?
161		-
162		-Programmer and developer project-lets:
163		-
164		- * We need somebody to code up a GUI or other controller program, to do configuration, etc. See our control specification for details, and the rudimentary demonstration Python control script. No, we don't know what the interface should look like. You can use any license you want, but we'd recommend 3-clause BSD or maybe GPL; and we can only help out if your license conforms to the DFSG.
165		- * Periodically people running servers tells us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. Perhaps it would run out of cron, or perhaps it would sleep until appropriate times and then do its tweak (that's probably more portable). Can somebody write one for us and we'll put it inside tor/contrib/?
166		- * Does somebody want to do up a patch so we can be an NT service? Or so we can go in the system tray?
167		- * A good (portable, fast, clean, BSD-free) asynchronous DNS library would be really handy, so we don't have to keep forking DNS worker threads to do gethostbyname.
168		- * Can somebody take a look at Martin's Squid and Tor page, and update it to reflect Tor's RedirectExit config option?
169		- * See the TODO and HACKING files in the Tor distribution for more ideas.
170		-
171		-Security project-lets: We need people to attack the implementation and clean it up, and also to attack the design and experiment with defenses.
172		-
173		- * We need somebody to fuzz Tor. Are there good libraries out there for what we want? What are the first steps? Win fame by getting credit when we put out a new release because of you!
174		- * Website volume fingerprinting attacks (Back et al, Hintz). Defenses include a large cell size, defensive dropping, etc. How well does each approach work?
175		- * The end-to-end traffic confirmation attack. We need to study long-range dummies more, along with traffic shaping. How much traffic of what sort of distribution is needed before the adversary is confident he has won?
176		- * It's not that hard to DoS Tor servers or dirservers. Are puzzles the right answer? What other practical approaches are there?
177		- * What sensitive info squeaks by privoxy? Are other html scrubbers better?
178		-
179		-Designer project-lets:
180		-
181		- * 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.
182		- * 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.
183		- * 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?
184		- * How hard is it to patch bind or a DNS proxy to redirect requests to Tor via our tor-resolve socks extension? What about to convert UDP DNS requests to TCP requests and send them through Tor?
185		- * Tor provides anonymous connections, but if you want to keep multiple pseudonyms in practice (say, in case you frequently go to two websites and if anybody knew about both of them they would conclude it's you), we don't support that well yet. We should find a good approach and interface for handling pseudonymous profiles in Tor. See this post and followup for details.
	164	+ - It's not that hard to DoS Tor servers or dirservers. Are puzzles the right answer? What other practical approaches are there?
	165	+ - 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.
	166	+ - 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.
	167	+ - 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?
	168	+ - How hard is it to patch bind or a DNS proxy to redirect requests to Tor via our tor-resolve socks extension? What about to convert UDP DNS requests to TCP requests and send them through Tor?
	169	+ - Tor provides anonymous connections, but if you want to keep multiple pseudonyms in practice (say, in case you frequently go to two websites and if anybody knew about both of them they would conclude it's you), we don't support that well yet. We should find a good approach and interface for handling pseudonymous profiles in Tor. See this post and followup for details.
186	170
187	171	Drop by the #tor IRC channel at irc.oftc.net or email tor-volunteer@freehaven.net if you want to help out!
188	172
189	173

tor-webwml.git