TODO.external 8.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187
  1. $Id: TODO 16258 2008-07-30 13:04:38Z nickm $
  2. Legend:
  3. SPEC!! - Not specified
  4. SPEC - Spec not finalized
  5. N - nick claims
  6. R - arma claims
  7. P - phobos claims
  8. S - Steven claims
  9. E - Matt claims
  10. M - Mike claims
  11. J - Jeff claims
  12. I - ioerror claims
  13. W - weasel claims
  14. K - Karsten claims
  15. C - coderman claims
  16. - Not done
  17. * Top priority
  18. . Partially done
  19. o Done
  20. d Deferrable
  21. D Deferred
  22. X Abandoned
  23. =======================================================================
  24. External constraints:
  25. - mid October
  26. W - Finish implementation of directory overhead changes: have a set
  27. of patches that you think work.
  28. - end of October
  29. - Auto update
  30. C * Get the MSI working and stable for Windows Tor installer.
  31. N o Come up with an interface to export the package/bundle gloss
  32. descriptions so Vidalia can display them.
  33. (Done; see thandy-client json2xml. Matt was fine with this,
  34. last I heard.)
  35. E * Vidalia calls Thandy, learns when to upgrade, requests the upgrade.
  36. ? - Teach our OSX installer to register its version on install
  37. - end of December
  38. I - Periodic summaries of localization progress: both pootle and wml.
  39. - mid January
  40. KS . Finish testing, debugging, unit testing, etc the hidden service
  41. changes. Have it in the development version and in use.
  42. W - Finish testing, debugging, unit testing, etc the directory overhead
  43. changes. Have it in the development version and in use.
  44. E - Implement KDE Marble into Vidalia. In order to improve the user
  45. interface for easier understanding of circuits and where traffic
  46. travels, replacing the current Vidalia map with KDE's Marble
  47. is desired. KDE’s Marble widget gives a better quality map and
  48. enables improved interactivity. This is the first step in allowing
  49. users to choose an exit country, or being able to interact with
  50. Tor circuits in new ways.
  51. - end of January
  52. NSE - Write first draft of research study for Paul's research problem.
  53. I - Periodic summaries of localization progress: both pootle and wml.
  54. - mid February
  55. S * Examine current load balancing issues and evaluate trade-offs
  56. associated with other methods.
  57. - For each potential routing improvement strategy...
  58. - Explain method, calculate theoretical impact, estimate likely
  59. impact, prioritize
  60. - Establish implementation work plan
  61. - Document strategy for metrics and evaluation
  62. - Highlight which items on your list are doable in 2009.
  63. N - Write a summary of progress toward Overlapped I/O on Windows.
  64. S - Write a summary of progress toward understanding risks to relays
  65. (and thus bridges) from letting attackers route traffic through
  66. them. Eg, if relays have 100KB/s but set relaybandwidthrate to
  67. 10KB/s, do your interference attacks still work?
  68. R * Revise and publish incentive draft paper
  69. - Write an explanation for its current flaws
  70. - Gather comments, search for new designs
  71. - Write up a summary of recommendations and next steps
  72. W - Download fewer descriptors
  73. - Summarize progress so far, on all the different approaches to
  74. reducing directory download overhead.
  75. - Measure/estimate impact of each improvement.
  76. - Build a plan and timeline for implementing the rest.
  77. N - TLS arms race: Produce a list of likely avenues for blocking,
  78. and for each avenue summarize a plan for how we should respond to
  79. get Tor unblocked again.
  80. I * Email auto-responder
  81. - Document the design and spec.
  82. - Describe auto-responder "commands"
  83. - Describe DKIM requirement (and alternatives)
  84. - Describe how we're going to localize the text
  85. - Describe the workflow for a user that wants to know she's got
  86. the right file. Digitally signed installer? Feed it to the
  87. updater that recognizes signatures? Other options?
  88. * How do we better support users with limited email
  89. bandwidth? Multi-part download? Teach them how to reconnect
  90. their gmail? Does downloading your gmail work when your network
  91. keeps dying?
  92. K - Metrics.
  93. * Gather and document monthly usage metrics, by country
  94. - Using Roger's old method of counting users
  95. - Using Nick's new method of counting users
  96. - Start playing around with figuring out which one is more
  97. accurate, or how to combine them to get better guesses,
  98. or something.
  99. R * Roger should walk Karsten through applying (and maybe
  100. updating) the patch for each method, and write a summary
  101. of what we have tried/guessed so far.
  102. * Automatically collect and document or publish other monthly
  103. statistics
  104. - Total data over time
  105. - Number, availability and performance of relays
  106. - Advertised capacity
  107. - With Mike's help, use Torflow to start doing monthly rudimentary
  108. performance evaluations:
  109. - Circuit throughput and latency
  110. - Measure via Broadband and dialup
  111. - Make a few graphs of the most interesting public data
  112. - Publish a report addressing key long-term metrics questions:
  113. - What metrics should we present?
  114. - What data are available for these metrics?
  115. - What data are missing, and can collect them safely? Can we
  116. publish them safely?
  117. - What systems are available to present this data?
  118. E - Vidalia improvements
  119. - Implement Vidalia presentation of plaintext port warnings
  120. - Figure out a plan for presenting other Tor status warning events.
  121. - Move Polipo into the main Vidalia -dev bundle.
  122. - Vidalia displays by-country user summary for bridge operators
  123. R * Tor sends a status event or something so Vidalia knows what
  124. to display
  125. M - Network scanning and network health
  126. - Implement some initial automated scans.
  127. - Describe a roadmap for how to get from here to plausible,
  128. long-term security scanning tests for Tor network
  129. - Document a strategy for incorporating results into directory
  130. consensus documents. At what phases will we be ready to automate
  131. which parts? How will we recognize when we are ready?
  132. M - Torbutton development
  133. - Keep up with our bugfixes -- build a plan for (or resolve)
  134. every item in Flyspray, and other known issues.
  135. - Build a strategy for how Torbutton and Vidalia can
  136. communicate. E.g., what do we do with the 'new identity' button
  137. in Vidalia?
  138. * Make Torbutton happy on FF3, especially so TBB can drop FF2.
  139. C - Transparent interception of connections on Windows
  140. - Produce prototype, with screenshots for how to install and test.
  141. - Document open issues, future work, things users need to be aware
  142. of, etc.
  143. S - Tor Browser bundle work
  144. - Use native Vidalia (non-PortableFirefox) launcher for browser
  145. - Close Browser on clean Vidalia exit
  146. - Establish feasibility of simultaneous Firefox usage (also
  147. considering implications for (OpenVPN-style or other) system-wide
  148. Tor interception)
  149. - Switch Tor Browser Bundle to Firefox 3, once Torbutton is ready.
  150. - Decide whether TBB should use Torbutton's "lock" feature.
  151. http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
  152. I . Jake learns how to build the TBB and takes over doing new
  153. releases.
  154. S - Continue analyzing "traces" left on host machine by use of
  155. Tor Browser, especially once we have our new launcher and have moved
  156. to FF3. Write a summary of current progress, and what remains. Try
  157. to solve some of the low-hanging fruit.
  158. I - Periodic summaries of localization progress: both pootle and wml.
  159. I - Collecting user stories
  160. I - Revise the 'Tor mirror page' so it doesn't list obsolete-looking
  161. timestamps. Just have two tables, "new enough" and "not new enough".
  162. I * Get Tor Weather up, stable, and in use by some relay operators.
  163. I - Get a relay operator mailing list going, with a plan and supporting
  164. scripts and so on.