Nick,<br><br>I have a suggestion. Automatic updates. <br>Here is my reason as to why I feel this is probably the most important feature you need to implement.<br>"<br>Mar 31 2008 08:27:52.240 [notice] Tor 0.1.2.9-rc opening new log file.<br>
....<br>"<br>That wasn't my tor log, but someone else. There are still clients out there that are still affected from the POC last year, EVEN after they updated to the new version. Check your torrc files folks.<br>
<br>Looking back on Defcon last year, wouldn't it have been nice to be able to issue an update and know that most of the users would have been updated within 24-48 hours? Look at the OpenSSL screwup from last week, wouldn't that have been nice to be able to issue an update then too (even though it wasn't your fault)?<br>
<br>I know that you and Roger don't like the in your face approach, but I still feel that security vulnerabilities/updates need to be brought to the users attention by displaying big, obvious, in your face alerts about problems. E-mail sometimes isn't fast enough. And simply making a notice or warning of it in the log file doesn't cut it. You wouldn't want to scare the user by telling them there is a problem with no solution, so having a big "Upgrade Now" button in the security alert window would be nice.<br>
<br>You never know what tomorrow brings, and how the face of security could change in the blink of an eye. ;-)<br><br>Best regards,<br>Kyle<br><br><div class="gmail_quote">On Mon, May 19, 2008 at 12:56 PM, Nick Mathewson <<a href="mailto:nickm@freehaven.net" target="_blank">nickm@freehaven.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, folks!<br>
<br>
It's time to start talking more about what goes into the next release<br>
of Tor, the 0.2.1.x series. I think this release's development will<br>
go much more smoothly if we have rough time windows in mind for when<br>
parts of its development need to be done.<br>
<br>
These are all rough targets. We can bend them if we have a big reason<br>
to do so, such as fixing a big security problem or interoperating<br>
right with an important external project. On the other hand, we<br>
shouldn't bend them unless we're willing to risk delaying the release<br>
by doing so. I've tried to include rationales inline.<br>
<br>
Here are the rough dates for the next release:<br>
<br>
==============================<br>
June 30: PROPOSAL CUTOFF.<br>
<br>
All feature proposals for consideration should be in and discussed<br>
before this date. In the meantime, we should already be implementing<br>
accepted proposals. Note also the "and discussed": complex proposals<br>
received on June 29 are unlikely to be adequately discussed by June<br>
30.<br>
<br>
Trivial proposals might be accepted after this date, if they are<br>
indeed trivial.<br>
<br>
July 15: ARCHITECTURE FREEZE.<br>
<br>
No major architectural changes should get made to Tor after this date.<br>
[I'm leaving "major architectural change" deliberately underdefined.<br>
It would definitely include switching how we use libevent buffers, or<br>
making big changes to our threading model.]<br>
<br>
August 15: FEATURE FREEZE.<br>
<br>
No new features should be added after this date. This is when we<br>
should move to pure testing and bugfixing.<br>
<br>
September 15: FIRST RELEASE CANDIDATE<br>
<br>
If we've not pushed the other deadlines too hard, we should be ready<br>
for release by now.<br>
==============================<br>
<br>
Note that the important thing to do now is to improve and discuss<br>
feature proposals, and write new ones.<br>
<br>
yrs,<br>
--<br>
<font color="#888888">Nick Mathewson<br>
</font></blockquote></div><br>