TODO.external 7.2 KB

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