TODO.external 7.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174
  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. - end of January
  45. NSE - Write first draft of research study for Paul's research problem.
  46. I - Periodic summaries of localization progress: both pootle and wml.
  47. - mid February
  48. S - Examine current load balancing issues and evaluate trade-offs
  49. associated with other methods.
  50. - For each potential routing improvement strategy...
  51. - Explain method, calculate theoretical impact, estimate likely
  52. impact, prioritize
  53. - Establish implementation work plan
  54. - Document strategy for metrics and evaluation
  55. - Highlight which items on your list are doable in 2009.
  56. N - Write a summary of progress toward Overlapped I/O on Windows.
  57. S - Write a summary of progress toward understanding risks to relays
  58. (and thus bridges) from letting attackers route traffic through
  59. them. Eg, if relays have 100KB/s but set relaybandwidthrate to
  60. 10KB/s, do your interference attacks still work?
  61. R - Revise and publish incentive draft paper
  62. - Write an explanation for its current flaws
  63. - Gather comments, search for new designs
  64. - Write up a summary of recommendations and next steps
  65. W - Download fewer descriptors
  66. - Summarize progress so far, on all the different approaches to
  67. reducing directory download overhead.
  68. - Measure/estimate impact of each improvement.
  69. - Build a plan and timeline for implementing the rest.
  70. N - Write a summary of progress toward "enumerating TLS fingerprint
  71. blocking risks and how we would overcome / respond to each".
  72. I - Email auto-responder
  73. - Document the design and spec.
  74. - Describe auto-responder "commands"
  75. - Describe DKIM requirement (and alternatives)
  76. - Describe how we're going to localize the text
  77. - Describe the workflow for a user that wants to know she's got
  78. the right file. Digitally signed installer? Feed it to the
  79. updater that recognizes signatures? Other options?
  80. - How do we better support users with limited email
  81. bandwidth? Multi-part download? Teach them how to reconnect
  82. their gmail? Does downloading your gmail work when your network
  83. keeps dying?
  84. K - Metrics.
  85. - Gather and document monthly usage metrics, by country
  86. - Using Roger's old method of counting users
  87. - Using Nick's new method of counting users
  88. - Start playing around with figuring out which one is more
  89. accurate, or how to combine them to get better guesses,
  90. or something.
  91. R - Roger should walk Karsten through applying (and maybe
  92. updating) the patch for each method, and write a summary
  93. of what we have tried/guessed so far.
  94. - Automatically collect and document or publish other monthly
  95. statistics
  96. - Total data over time
  97. - Number, availability and performance of relays
  98. - Advertised capacity
  99. - With Mike's help, use Torflow to start doing monthly rudimentary
  100. performance evaluations:
  101. - Circuit throughput and latency
  102. - Measure via Broadband and dialup
  103. - Make a few graphs of the most interesting public data
  104. - Publish a report addressing key long-term metrics questions:
  105. - What metrics should we present?
  106. - What data are available for these metrics?
  107. - What data are missing, and can collect them safely? Can we
  108. publish them safely?
  109. - What systems are available to present this data?
  110. E - Vidalia improvements
  111. - Implement Vidalia presentation of plaintext port warnings
  112. - Figure out a plan for presenting other Tor status warning events.
  113. - Move Polipo into the main Vidalia -dev bundle.
  114. - Vidalia displays by-country user summary for bridge operators
  115. R - Tor sends a status event or something so Vidalia knows what
  116. to display
  117. M - Network scanning and network health
  118. - Implement some initial automated scans.
  119. - Describe a roadmap for how to get from here to plausible,
  120. long-term security scanning tests for Tor network
  121. - Document a strategy for incorporating results into directory
  122. consensus documents. At what phases will we be ready to automate
  123. which parts? How will we recognize when we are ready?
  124. M - Torbutton development
  125. - Keep up with our bugfixes -- build a plan for (or resolve)
  126. every item in Flyspray, and other known issues.
  127. - Build a strategy for how Torbutton and Vidalia can
  128. communicate. E.g., what do we do with the 'new identity' button
  129. in Vidalia?
  130. - Make Torbutton happy on FF3, especially so TBB can drop FF2.
  131. C - Transparent interception of connections on Windows
  132. - Produce prototype, with screenshots for how to install and test.
  133. - Document open issues, future work, things users need to be aware
  134. of, etc.
  135. S - Tor Browser bundle work
  136. - Use native Vidalia (non-PortableFirefox) launcher for browser
  137. - Close Browser on clean Vidalia exit
  138. - Establish feasibility of simultaneous Firefox usage (also
  139. considering implications for (OpenVPN-style or other) system-wide
  140. Tor interception)
  141. - Switch Tor Browser Bundle to Firefox 3, once Torbutton is ready.
  142. - Continue analyzing "traces" left on host machine by use of
  143. Tor Browser. Write a summary of current progress, and what
  144. remains.
  145. - Decide whether TBB should use Torbutton's "lock" feature.
  146. http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
  147. I - Jake learns how to build the TBB and takes over doing new
  148. releases.
  149. I - Periodic summaries of localization progress: both pootle and wml.
  150. I - Collecting user stories
  151. I - Revise the 'Tor mirror page' so it doesn't list obsolete-looking
  152. timestamps. Just have two tables, "new enough" and "not new enough".