translations

January 2010 Progress Report

phobos — Sat, 13 Feb 2010 08:00:04 -0800

New releases, new hires, new funding
On January 19, 2010 we released the latest in the -stable series, Tor 0.2.1.22-stable.
Tor 0.2.1.22 fixes a critical privacy problem in bridge directory authorities -- it would tell you its whole history of bridge descriptors if you make the right directory request. This stable update also rotates two of the seven v3 directory authority keys and locations.
Directory authority changes:

Rotate keys (both v3 identity and relay identity) for moria1 and gabelmoo.

Major bugfixes:

Stop bridge directory authorities from answering dbg-stability.txt directory queries, which would let people fetch a list of all bridge identities they track. Bugfix on 0.2.1.6-alpha.

On January 19, 2010, we released the latest in the -alpha series, Tor 0.2.2.7-alpha.
Tor 0.2.2.7-alpha fixes a huge client-side performance bug, as well as laying the groundwork for further relay-side performance fixes. It also starts cleaning up client behavior with respect to the EntryNodes, ExitNodes, and StrictNodes config options. This release also rotates two directory authority keys, due to a security breach of some of the Torproject servers.
Directory authority changes:

Rotate keys (both v3 identity and relay identity) for moria1 and gabelmoo.

Major features (performance):

We were selecting our guards uniformly at random, and then weighting which of our guards we’d use uniformly at random. This imbalance meant that Tor clients were severely limited on throughput (and probably latency too) by the first hop in their circuit. Now we select guards weighted by currently advertised bandwidth. We also automatically discard guards picked using the old algorithm. Fixes bug 1217; bugfix on 0.2.1.3-alpha. Found by Mike Perry.
When choosing which cells to relay first, relays can now favor circuits that have been quiet recently, to provide lower latency for low-volume circuits. By default, relays enable or disable this feature based on a setting in the consensus. You can override this default by using the new "CircuitPriorityHalflife" config option. Design and code by Ian Goldberg, Can Tang, and Chris Alexander.
Add separate per-conn write limiting to go with the per-conn read limiting. We added a global write limit in Tor 0.1.2.5-alpha, but never per-conn write limits.
New consensus params "bwconnrate" and "bwconnburst" to let us rate-limit client connections as they enter the network. It’s controlled in the consensus so we can turn it on and off for experiments. It’s starting out off. Based on proposal 163.

Major features (relay selection options):

Switch to a StrictNodes config option, rather than the previous "StrictEntryNodes" / "StrictExitNodes" separation that was missing a "StrictExcludeNodes" option.

If EntryNodes, ExitNodes, ExcludeNodes, or ExcludeExitNodes change during a config reload, mark and discard all our origin circuits. This fix should address edge cases where we change the config options and but then choose a circuit that we created before the change.

If EntryNodes or ExitNodes are set, be more willing to use an unsuitable (e.g. slow or unstable) circuit. The user asked for it, they get it.

Make EntryNodes config option much more aggressive even when StrictNodes is not set. Before it would prepend your requested entrynodes to your list of guard nodes, but feel free to use others after that. Now it chooses only from your EntryNodes if any of those are available, and only falls back to others if a) they’re all down and b) StrictNodes is not set.

Now we refresh your entry guards from EntryNodes at each consensus fetch -- rather than just at startup and then they slowly rot as the network changes.

Major bugfixes:

Stop bridge directory authorities from answering dbg-stability.txt directory queries, which would let people fetch a list of all bridge identities they track. Bugfix on 0.2.1.6-alpha.

Minor features:

Log a notice when we get a new control connection. Now it’s easier for security-conscious users to recognize when a local application is knocking on their controller door. Suggested by bug 1196.
New config option "CircuitStreamTimeout" to override our internal timeout schedule for how many seconds until we detach a stream from a circuit and try a new circuit. If your network is particularly slow, you might want to set this to a number like 60.
New controller command "getinfo config-text". It returns the contents that Tor would write if you send it a SAVECONF command, so the controller can write the file to disk itself.
New options for SafeLogging to allow scrubbing only log messages generated while acting as a relay.
Ship the bridges spec file in the tarball too.
Avoid a mad rush at the beginning of each month when each client rotates half of its guards. Instead we spread the rotation out throughout the month, but we still avoid leaving a precise timestamp in the state file about when we first picked the guard. Improves over the behavior introduced in 0.1.2.17.

Minor bugfixes (compiling):

Fix compilation on OS X 10.3, which has a stub mlockall() but hides it. Bugfix on 0.2.2.6-alpha.
Fix compilation on Solaris by removing support for the DisableAllSwap config option. Solaris doesn’t have an rlimit for mlockall, so we cannot use it safely. Fixes bug 1198; bugfix on 0.2.2.6-alpha.

Minor bugfixes (crashes):

Do not segfault when writing buffer stats when we haven’t observed a single circuit to report about. Found by Fabian Lanze. Bugfix on 0.2.2.1-alpha.
If we’re in the pathological case where there’s no exit bandwidth but there is non-exit bandwidth, or no guard bandwidth but there is non-guard bandwidth, don’t crash during path selection. Bugfix on 0.2.0.3-alpha.
Fix an impossible-to-actually-trigger buffer overflow in relay descriptor generation. Bugfix on 0.1.0.15.

Minor bugfixes (privacy):

Fix an instance where a Tor directory mirror might accidentally log the IP address of a misbehaving Tor client. Bugfix on 0.1.0.1-rc.
Don’t list Windows capabilities in relay descriptors. We never made use of them, and maybe it’s a bad idea to publish them. Bugfix on 0.1.1.8-alpha.

Minor bugfixes (other):

Resolve an edge case in path weighting that could make us misweight our relay selection. Fixes bug 1203; bugfix on 0.0.8rc1.
Fix statistics on client numbers by country as seen by bridges that were broken in 0.2.2.1-alpha. Also switch to reporting full 24-hour intervals instead of variable 12-to-48-hour intervals.
After we free an internal connection structure, overwrite it with a different memory value than we use for overwriting a freed internal circuit structure. Should help with debugging. Suggested by bug 1055.
Update our OpenSSL 0.9.8l fix so that it works with OpenSSL 0.9.8m too.

Removed features:

Remove the HSAuthorityRecordStats option that version 0 hidden service authorities could have used to track statistics of overall hidden service usage.

On January 19, 2010, we released an updated Tor Browser Bundle, version 1.3.1.

update Firefox to 3.5.7
update Pidgin to 2.6.5
update Tor to 0.2.1.22

On January 25, 2010, we released Vidalia 0.2.7.

Remove the explicit palette set for the configuration dialog that prevented the dialog from inheriting colors from the user’s current system theme. (Ticket #485. Patch from mkirk.)
Correct the path to the badge pixmap used in time skew warning messages. (Ticket #537. Patch from mkirk.)
Fix compilation on Debian GNU/kFreeBSD. Patch from dererk.
Clean up a couple status event messages related to dangerous port warnings.
Change the vidalia_ru.nsh output encoding from KOI8-R to Windows-1251. (Ticket #527)
Add an option for building an OS X 10.4 compatible binary.

On January 26, 2010, we released an updated -alpha, Tor 0.2.2.8-alpha.
Major bugfixes:

Fix a memory corruption bug on bridges that occured during the inclusion of stats data in extra-info descriptors. Also fix the interface for geoip_get_bridge_stats* to prevent similar bugs in the future. Diagnosis by Tas, patch by Karsten and Sebastian. Fixes bug 1208; bugfix on 0.2.2.7-alpha.

Minor bugfixes:

Ignore OutboundBindAddress when connecting to localhost. Connections to localhost need to come _from_ localhost, or else local servers (like DNS and outgoing HTTP/SOCKS proxies) will often refuse to listen.

Design, develop, and implement enhancements that make Tor a better tool for users in censored countries.
Submitted Proposal 169. A backward-compatible change to the Tor connection establishment protocol to avoid the use of TLS renegotiation. In response to others using TLS renegotiation incorrectly, vendors are pulling support for TLS renegotiation. As TLS renegotiation disappears from the Internet, Tor’s use of it will stand out. In order to blend in with the crowd, we need to remove TLS renegotiation from the Tor protocol. The full spec can be found at http://gitweb.torproject.org//tor.git?a=blob;f=doc/spec/proposals/169-el....

Architecture and technical design docs for Tor enhancements related to blocking-resistance.
Submitted Proposal 169. A backward-compatible change to the Tor connection establishment protocol to avoid the use of TLS renegotiation. In response to others using TLS renegotiation incorrectly, vendors are pulling support for TLS renegotiation. As TLS renegotiation disappears from the Internet, Tor’s use of it will stand out. In order to blend in with the crowd, we need to remove TLS renegotiation from the Tor protocol. The full spec can be found at http://gitweb.torproject.org//tor.git?a=blob;f=doc/spec/proposals/169-el....

Hide Tor’s network signature.
Submitted Proposal 169. A backward-compatible change to the Tor connection establishment protocol to avoid the use of TLS renegotiation. In response to others using TLS renegotiation incorrectly, vendors are pulling support for TLS renegotiation. As TLS renegotiation disappears from the Internet, Tor’s use of it will stand out. In order to blend in with the crowd, we need to remove TLS renegotiation from the Tor protocol. The full spec can be found at http://gitweb.torproject.org//tor.git?a=blob;f=doc/spec/proposals/169-el....

Grow the Tor network and user base. Outreach.

Paul, Karsten, and Roger attended Financial Cryptography and Data Security 2010 Conference. Roger Dingledine presented a paper he had written with Tsuen-Wan Ngan and Dan Wallach on “Building Incentives into Tor”. This paper won Best Paper Award at the conference. Learn more at http://fc10.ifca.ai/.
Karsten and Roger attended the Workshop on Ethics in Computer Security Research, http://www.cs.stevens.edu/~spock/wecsr2010/. They presented “A Case Study on Measuring Statistical Data in the Tor Anonymity Network.”
Andrew attended the Internet Freedom speech by Secretary of State Clinton, http://www.state.gov/secretary/rm/2010/01/135519.htm.
Roger and Jacob discussed Tor with the Pirate Party of Sweden.
Jacob met with NorduNet to discuss their bandwidth authority and how to help Tor grow in the NorduNet, http://www.nordu.net.
Jacob and Wikileaks people met with policymakers in Iceland to discuss freedom of speech, freedom of press, and that online privacy should be a fundamental right.
Roger, Karen, and Andrew met with CDT, Internews, and BBG to discuss various topics.
Andrew was interviewed for 90 minutes by vbs.tv about Tor, online anonymity and privacy, and the increasing usage of Tor as a censorship circumvention tool. vbs.tv will release the interview in 2010.

Preconfigured privacy (circumvention) bundles for USB or LiveCD.

On January 19, 2010, we released an updated Tor Browser Bundle, version 1.3.1.

update Firefox to 3.5.7
update Pidgin to 2.6.5
update Tor to 0.2.1.22

Bridge relay and bridge authority work.
From the Tor 0.2.2.8-alpha release notes;
Fix a memory corruption bug on bridges that occurred during the inclusion of stats data in extra-
info descriptors. Also fix the interface for geoip get bridge stats to prevent similar bugs in the
future. Diagnosis by Tas, patch by Karsten and Sebastian. Fixes bug 1208; bugfix on 0.2.2.7-
alpha.
Roger and Christian defined a roadmap for bridgedb updates, scalability, and bugfixes. The plan can be found at http://gitweb.torproject.org//bridgedb.git?a=blob_plain;f=TODO;hb=HEAD

Scalability, load balancing, directory overhead, efficiency.
From the 0.2.2.7-alpha release notes:
We were selecting our guards uniformly at random, and then weighting which of our guards we’duse uniformly at random. This imbalance meant that Tor clients were severely limited on throughput (and probably latency too) by the first hop in their circuit. Now we select guards weighted by currently advertised bandwidth. We also automatically discard guards picked using the old algorithm. Fixes bug 1217; bugfix on 0.2.1.3-alpha. Found by Mike Perry.
When choosing which cells to relay first, relays can now favor circuits that have been quiet recently, to provide lower latency for low-volume circuits. By default, relays enable or disable this feature based on a setting in the consensus. You can override this default by using the new “CircuitPriorityHalflife” configuration option. Design and code by Ian Goldberg, Can Tang, and Chris Alexander.
Mike Perry implemented consensus parameters for the Circuit Build Times constants and found good defaults based on experimentation on a few simulated links. The simulations seem to indicate that tor does really poorly on links with greater than 1 second of latency. Mike wrote up his findings at http://archives.seul.org/or/dev/Jan-2010/msg00012.html. Mike’s work on circuit build times should improve tor client performance as the clients pick new guard nodes and learn better circuit build times.

More reliable (e.g. split) download mechanism.
Enhanced get-tor to handle Apple OS X split files.

Translation work, ultimately a browser-based approach.
Updated translations via the translation portal for Chinese, Norwegian, Russian, Dutch, French,
Polish, Swedish, Italian, German, Spanish, Burmese, and Turkish languages.

December 2009 Progress Report

phobos — Sat, 13 Feb 2010 07:35:12 -0800

New releases, new hires, new funding
Erinn Clark joins Tor to develop, enhance, and upgrade our package build system. Her initial goals are to configure, maintain, and automate builds of tor and vidalia for Windows, OS X, ubuntu, debian, centos, fedora, and opensuse systems. Secondary goals are to develop a builtbot system that includes as many disparate operating systems as possible, including Apple OS X and Microsoft
Windows flavors.
On December 2, 2009, we released torbutton 1.2.3. This is the first release that addresses the
Firefox 3.5.x codebase. It contains the following changes:

bugfix: bug 950: Preserve useragent and download settings across toggle
bugfix: bug 1014: Fix XML Parsing Error on XHTML sites in Tor mode
bugfix: bug 1041: Preserve tab history in FF3.5
bugfix: bug 1047: Fix spurious user agent change notice
bugfix: bug 1053: Partial fix for ’TypeError: browser is undefined’ error
bugfix: bug 1084: Preserve HTTP accept language for Non-Tor usage
bugfix: bug 1085: Fix test settings issues with dead privoxy
bugfix: bug 1088: Clean up some namespace issues in the main chrome window
bugfix: bug 1091: Fix a lockup when ’Ask Every Time’ cookie pref is set
bugfix: bug 1093: Fix cert acceptance dialogs in Firefox 3.5
bugfix: bug 1146: Fixes for properly handling tab restore in FF3.5
bugfix: bug 1152: Close tabs on toggle prevents toggling in FF3.5”
bugfix: bug 1154: Clarify ”Last Tor test failed” message
misc: Disable geolocation in FF3.5 during Tor mode
misc: Disable DNS prefetch in FF3.5 in Tor mode and for Tor-loaded tabs
misc: Disable offline app cache during Tor mode
misc: Disable specific site zoom settings during Tor mode
new: Transfer Google cookies between country-code domains. This should make it such that captchas only need to be solved once per Tor session, as opposed to for each country.

On December 16, 2009, we released Torbutton 1.2.4. This fixes a number of bugs found after two weeks of live testing by users. It contains the following changes:

bugfix: bug 1169: Fix blank popup conflict with Google Toolbar
bugfix: bug 1171: Properly store and set network.dns.disablePrefetch
bugfix: bug 1165: Fix an exception on toggle in FF3.6
bugfix: bug 1163: Fix history loss in FF3.6
bugfix: Fix a typo error during logging
bugfix: Properly handle session restore in FF3.6
misc: Kill a warning message about missing properties in window-mapper.js
new: Add a new pref to disable Livemark updates during Tor usage (FF3.5+)

On December 21, 2009, we released an update to the -stable Tor branch, Tor 0.2.1.21. It fixes compatibility with newer OpenSSL libraries that work around the renegotiation bug. The full changelog is:
Tor 0.2.1.21 fixes an incompatibility with the most recent OpenSSL library. If you use Tor on Linux / Unix and you’re getting SSL renegotiation errors, upgrading should help. We also recommend an upgrade if you’re an exit relay.
Major bugfixes:

Work around a security feature in OpenSSL 0.9.8l that prevents our handshake from working unless we explicitly tell OpenSSL that we are using SSL renegotiation safely. We are, of course, but OpenSSL 0.9.8l won’t work unless we say we are.
Avoid crashing if the client is trying to upload many bytes and the circuit gets torn down at the same time, or if the flip side happens on the exit relay. Bugfix on 0.2.0.1-alpha; fixes bug 1150.

Minor bugfixes:

Do not refuse to learn about authority certs and v2 networkstatus documents that are older than the latest consensus. This bug might have degraded client bootstrapping. Bugfix on 0.2.0.10-alpha. Spotted and fixed by xmux.
Fix a couple of very-hard-to-trigger memory leaks, and one hard-to- trigger platform-specific option misparsing case found by Coverity Scan.
Fix a compilation warning on Fedora 12 by removing an impossible-to- trigger assert. Fixes bug 1173.

On December 31, 2009, we released Tor Browser Bundle 1.3.0. The major change was the upgrade of Firefox to the 3.5 branch. The full changelog is:

upgrade Firefox to 3.5.6
update Pidgin to 2.6.4
update Torbutton to 1.2.4
upgrade Tor to 0.2.1.21

Design, develop, and implement enhancements that make
Tor a better tool for users in censored countries.
Updated the get-tor email autoresponder to better handle translations into non-English languages. Also updated to better handle split downloads of torbrowser bundle and mac os x vidalia bundles.
Mike finished his six week analysis of the Firefox 3.5 code base for privacy and anonymity leaks. The notes from the audit are documented in https://www.torproject.org/torbutton/design/FF35_AUDIT.

Grow the Tor network and user base. Outreach.

Jacob presented at the Arab Bloggers Conference in Beirut, Lebanon. http://www.arabloggers.com/
Jacob met with Al Jazeera in Doha, Qatar. http://www.aljazeera.net/
Jacob met with Rainbow House in Amman, Jordan.
Andrew and Roger attended a circumvention technology workshop in California.
Jacob, Roger, Karsten, Steven, and others attended 26C3 in Berlin, Germany. http://events.ccc.de/congress/2009/wiki/index.php/Main_Page. Jacob and Roger presented on ”Tor and censorship: lessons learned”, http://events.ccc.de/congress/2009/Fahrplan/events/3554.en.html. We mirrored the video and slides at https://blog.torproject.org/blog/tor-and-censorship-lessons-learned.

Preconfigured privacy (circumvention) bundles for USB or LiveCD.
On December 31, 2009, we released Tor Browser Bundle 1.3.0. The major change was the upgrade of Firefox to the 3.5 branch. The full changelog is:

upgrade Firefox to 3.5.6
update Pidgin to 2.6.4
update Torbutton to 1.2.4
upgrade Tor to 0.2.1.21

Mike, Roger, and Andrew met with the Chrome team at Google to discuss integration of Tor into Chrome’s ”incognito mode”. We need some APIs to make the integration smoother, and to be able to scale the Tor Network to handle the expected traffic from Chrome users.

Scalability, load balancing, directory overhead, efficiency.

We did a one weekend test of the performance impact of changing circuit package window from 1000 cells to 101. The test and numbers are based on research by Csaba Kiraly. ”Effectof Tor window size on performance. Email to or-dev@freehaven.net, February 2009. http://archives.seul.org/or/dev/Feb-2009/msg00000.html”. The test appeared to be a null operation, it didn’t help nor hurt performance of the network as a whole.
Karsten continues to work on metrics about the Tor Network. We have a new metrics portal, http://metrics.torproject.org/ that shows the output, raw data, process for the collection, and the statistical analysis performed. Currently, our basic process is to collect, collate, and transform the data into graphs with R. Two organizations have offered to take the raw data from http://archives.torproject.org/ and import it into their data analysis products. We’re continuing to work on both tactics at this time.

More reliable (e.g. split) download mechanism.
OS X split dmg files will be available with each release going forward. The split dmg files are a native format for OS X 10.3 (Panther) and above; so users on low bandwidth connections should easily be able to work with these.

Translation work, ultimately a browser-based approach.

Hundreds of updated translations for torbutton, tor website, vidalia, torcheck, and get-tor in the following languages: Swedish, Brazillian Portugese, Polish, Russian, Spanish, Norwegian, Burmese, Chinese, Farsi, Arabic, Portugese, Ukranian, German, Spanish, French, Finnish, Italian, Dutch, and Turkish.
Runa applied updates to the process of syncing between the translation portal and live website. And she continues to maintain the translation portal.
Carolyn found translators for Russian, Ukrainian, and Burmese languages. She’s currently working on finding translators for Arabic, Farsi, and Spanish languages.

May 2009 Progress Report

phobos — Wed, 10 Jun 2009 11:41:55 -0700

New releases
On May 25, we released Tor 0.2.1.15-rc.
On May 17, we released Tor VM 0.0.2.
On May 25, we released Vidalia 0.1.13 containing

Remove an old warning on the relay settings page that running a bridge
relay requires Tor 0.2.0.8-alpha or newer.
Add a workaround for a bug that prevented Vidalia's tray icon from
getting added to the system notification area on Gnome when Vidalia was
run on system startup. Patch by Steve Tyree. (Ticket #247)
Fix a bug that prevented the control panel from displaying when
running on the Enlightenment window manager. Patch by Steve Tyree.
Rename the CMake variables used to store the location of Qt's lupdate
and lrelease executables. Recent versions of CMake decided to use the
same variable name, which was stomping on mine, resulting in the wrong
lupdate and lrelease executables being used.
Use the TorProcess subclass of QProcess for launching Tor when hashing
a control password so we can take advantage of its PATH+=:/usr/sbin
trick on Debian there too.
If a RouterDescriptor object is empty, don't try to display it in the
router descriptor details viewer. (Ticket #479)
Wait until Vidalia has registered for log events via the control port
before ignoring Tor's output on stdout. Previously we would start
ignoring Tor's stdout after successfully authenticating, but before
registering for log events which, in some cases, could lead to
messages not appearing in the message log.
Update many translations and remove others than are no longer
up-to-date enough to be useful.

On May 25th, we released Tor Browser Bundle 1.2.0 containing

Switch to launching Firefox directly from Vidalia to
allow multiple instances of Firefox
Update Firefox to 3.0.10
Update to Qt 4.5.1
Update Firefox prefs.js to stop scanning for plugins
Update libevent to 1.4.11
Include the Tor geoip database
Update Vidalia to 0.1.13
Update Tor to 0.2.1.15-rc

Design, develop, and implement enhancements that make Tor a better
tool for users in censored countries.

Matt added "fetch bridges" features to Vidalia 0.2.x. This provides a link to automatically request bridges from https://bridges.torproject.org for users.

Architecture and technical design docs for Tor enhancements
related to blocking-resistance.
Proposal 160 aims to let authorities modify the bandwidth they put in
the consensus for each relay. This step will allow us to adjust the
weights we advertise for clients, once the measurements from TorFlow
start giving us better weights.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/160-ba...

Proposal 161 describes how node bandwidth ratios are
computed and how they can be produced in parallel.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/161-co...

Proposal 162 describes "consensus flavors": the size of the networkstatus
consensus is critical, since every user fetches it every few hours. So
we need a way to add new fields -- and remove old fields -- in a way
that lets old clients continue to use the consensus. The current plan
is to build and distribute several different versions at once, so each
client can fetch the one with the format they expect.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/162-co...

Proposal 163 starts to consider the problem of clients using relays as
single-hop proxies. If many clients start doing this (say, to improve
their own performance), it puts additional risk on the relays, since now
an attacker can expect to discover both client origins and destinations
by attacking the relay. Our current strategy for forcing clients to use
more than one hop is quite fragile, and it looks like we will soon need
more robust strategies.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/163-de...

Proposal 164 suggests ways to make it easier for relay operators to
discover why they are not listed in the networkstatus consensus. We have
a handle of people each week ask us on IRC why their relay isn't listed,
and currently the only way to answer is to have a competent directory
authority operator go dig around in various files in his datadirectory.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/164-re...

Proposal 165 focuses on simplifying the steps required to add a new
directory authority. The current approach requires manual work from every
directory authority operator within a space of several hours. As the
number of authorities grows, this synchronization is becoming impractical
-- and that's causing us to leave the number of authorities small, which
makes us vulnerable to other attacks. Once this proposal is finalized
and deployed, we'll hopefully be able to add new authorities more
smoothly.
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/165-si...

Grow the Tor network and user base. Outreach.
Jacob attended CONFidence in Krakow, Poland as a keynote speaker. http://2009.confidence.org.pl/

Andrew and Jacob attended the Soul of a New Machine conference in Berkeley, CA. http://hrc.berkeley.edu/events/newmachineconference/

Roger and Andrew attended the 7th Annual Chinese Internet Research Conference in Philadelphia, PA. http://www.global.asc.upenn.edu/index.php?page=167

Karsten attended SIGINT 09 in Cologne.

Mike gave a presentation on TorFlow at CodeCon.

Roger met with Nick, Paul Syverson and Aaron Johnson at Yale to work more on Paul's research question: if we trust some Tor relays differently than others, how should we select our paths to be safe, and how do we analyze how safe the paths are?

Roger did a talk for about 15 OSI people in Budapest, Hungary.

Preconfigured privacy (circumvention) bundles for USB or LiveCD
The two large changes were the ability to run multiple instances of Firefox at once, such that a user's personal firefox shouldn't share data with the firefox from our bundle. The other change is the ability to stop TBB firefox from scanning the system for potential plugins, like Windows Media, Java, etc.

Started work on a hardened branch of Incognito live CD to help protect users from possible bugs in the programs running.

Scalability, load balancing, directory overhead, efficiency.

We documented the metrics we collect to help us determine the best ways to scale the Tor network. http://blog.torproject.org/blog/performance-measurements-and-blockingres... A number of nodes are now collecting this information to assist our network-wide measurements.

Much progress on torctl and torflow tools being used to measure real and potential performance of nodes in the public tor network.

Mike wrote proposal 161 describing how node bandwidth ratios are
computed and how they can be produced in parallel. The proposal can be found at http://git.torproject.org/checkout/tor/master/doc/spec/proposals/161-com...

Karsten finished a first patch to dump statistics about local queues to disk every 15 minutes. A first impression of how these data could be evaluated can be found in http://freehaven.net/~karsten/volatile/bufferstats-2009-05-25.pdf. The goal is to see if our buffer allocation algorithms are sufficient or need tweaking.

More reliable (e.g. split) download mechanism.
Developed the ability to split Apple OS X bundles into 1.44MB chunks. The functionality is native to OS X versions 10.4 and newer. It will not work in versions 10.3.9 or earlier releases.

Translation work, ultimately a browser-based approach
11 Polish updates
4 German updates
Portugese torbutton updates
Danish torbutton updates
Romanian torbutton updates
11 Italian updates
3 Chinese updates

January 2009 Progress Report

phobos — Sun, 22 Feb 2009 17:23:37 -0800

New releases, new hires, new funding

Tor 0.2.1.10-alpha (released January 6) fixes two major bugs in bridge
relays (one that would make the bridge relay not so useful if it had
DirPort set to 0, and one that could let an attacker learn a little bit
of information about the bridge's users), and a bug that would cause your
Tor relay to ignore a circuit create request it can't decrypt (rather
than reply with an error). It also fixes a wide variety of other bugs.
http://archives.seul.org/or/talk/Jan-2009/msg00078.html

Tor 0.2.1.11-alpha (released Jan 20) finishes fixing the "if your Tor is
off for a week it will take a long time to bootstrap again" bug. It also
fixes an important security-related bug reported by Ilja van Sprundel. You
should upgrade. (We'll send out more details about the bug once people
have had some time to upgrade.)
http://archives.seul.org/or/talk/Jan-2009/msg00171.html

Tor 0.2.0.33 (released Jan 21) fixes a variety of bugs that were making
relays less useful to users. It also finally fixes a bug where a relay or
client that's been off for many days would take a long time to bootstrap.
http://archives.seul.org/or/announce/Jan-2009/msg00000.html

Tor Browser Bundle 1.1.8 (released Jan 22) updates Tor to 0.2.1.11-alpha
(security update), updates OpenSSL to 0.9.8j (security update), updates
Firefox to 3.0.5, updates Pidgin to 2.5.4, and updates libevent to 1.4.9.
https://svn.torproject.org/svn/torbrowser/trunk/README

This month we also hired three new people: Martin Peck is working on
Tor VM, a new way of packaging Tor on Windows that will let people use
Youtube safely again; Mike Perry is working on Torbutton maintenance
and development and on Torflow, a set of scripts to do measurements on
the Tor network; and Andrew Lewman is our new executive director.

Enhancements
Major bugfixes in the Tor 0.2.1.10-alpha and 0.2.0.33 releases:
- If the cached networkstatus consensus is more than five days old,
discard it rather than trying to use it. In theory it could be useful
because it lists alternate directory mirrors, but in practice it just
means we spend many minutes trying directory mirrors that are long
gone from the network. Helps bug 887 a bit; bugfix on 0.2.0.x.

Tor 0.2.1.10-alpha contains cleanups that let Tor build on Google's
Android phone:
- Change our header file guard macros to be less likely to conflict
with system headers. Adam Langley noticed that we were conflicting
with log.h on Android.

Major bugfixes in the Tor 0.2.1.11-alpha and 0.2.0.33 releases:
- Discard router descriptors as we load them if they are more than
five days old. Otherwise if Tor is off for a long time and then
starts with cached descriptors, it will try to use the onion
keys in those obsolete descriptors when building circuits. Bugfix
on 0.2.0.x. Fixes bug 887.

Security bugfixes in the Tor 0.2.1.11-alpha and 0.2.0.33 releases:
- Fix a heap-corruption bug that may be remotely triggerable on
some platforms. Reported by Ilja van Sprundel.

Circuit-building speedups in Tor 0.2.1.10-alpha:
- When a relay gets a create cell it can't decrypt (e.g. because it's
using the wrong onion key), we were dropping it and letting the
client time out. Now actually answer with a destroy cell. Fixes
bug 904. Bugfix on 0.0.2pre8.

Scalability fixes from the Tor 0.2.0.33 ChangeLog:
- Clip the MaxCircuitDirtiness config option to a minimum of 10 seconds,
and the CircuitBuildTimeout to a minimum of 30 seconds. Warn the user if
lower values are given in the configuration. These fixes prevent a user
from rebuilding circuits too often, which can be a denial-of-service
attack on the network.
- When a stream at an exit relay is in state "resolving" or
"connecting" and it receives an "end" relay cell, the exit relay
would silently ignore the end cell and not close the stream. If
the client never closes the circuit, then the exit relay never
closes the TCP connection. Bug introduced in Tor 0.1.2.1-alpha;
reported by "wood".
- When sending CREATED cells back for a given circuit, use a 64-bit
connection ID to find the right connection, rather than an addr:port
combination. Now that we can have multiple OR connections between
the same ORs, it is no longer possible to use addr:port to uniquely
identify a connection.

Bootstrapping speedups in Tor 0.2.1.11-alpha:
- When our circuit fails at the first hop (e.g. we get a destroy
cell back), avoid using that OR connection anymore, and also
tell all the one-hop directory requests waiting for it that they
should fail. Bugfix on 0.2.1.3-alpha.

Architecture
Proposal 158 ("Clients download consensus + microdescriptors") suggests a
new way forward for reducing directory overhead for clients, and replaced
part of proposal 141. Rather than modifying the circuit-building protocol
to fetch a server descriptor inline at each circuit extend, we instead put
all of the information that clients need either into the consensus itself,
or into a new set of data about each relay called a microdescriptor.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-microdes...

From the 0.2.0.33 ChangeLog:
- Never use OpenSSL compression: it wastes RAM and CPU trying to compress
cells, which are basically all encrypted, compressed, or both. It also
made us stand out from other applications on the wire.

Advocacy
Jillian York continued blogging for us about the good uses of Tor:
http://www.knightpulse.org/blog/tor

"Federico Heinz advocates anonymous browsing in Argentina", Jan 8
http://www.knightpulse.org/blog/09/01/08/federico-heinz-advocates-anonym...

"Human Rights Organizations in Argentina welcome anonymous browsing", Jan 25
http://www.knightpulse.org/blog/09/01/25/human-rights-organizations-arge...

"Watch how you get around", Jan 30
http://www.knightpulse.org/blog/09/01/30/watch-how-you-get-around

Pre-configured bundles
Tor Browser Bundle 1.1.8 (released Jan 22) updates Tor to 0.2.1.11-alpha
(security update), updates OpenSSL to 0.9.8j (security update), updates
Firefox to 3.0.5, updates Pidgin to 2.5.4, and updates libevent to 1.4.9.
https://svn.torproject.org/svn/torbrowser/trunk/README

We continued work on Vidalia features to support where we want Tor
Browser Bundle to go. In particular, we're changing it to be able to
launch Firefox natively, rather than use the "PortableFirefox" pile of
complex scripts. We hope this change will also let users run a normal
Firefox alongside TBB. More on that in February.

We also continued work on Tor VM, a new way of packaging Tor on
Windows that will (among other things) let people use Youtube safely
again. Hopefully we'll have some simple instructions up about that in
February too.

Bridges
Major bugfixes in the Tor 0.2.1.10-alpha and 0.2.0.33 releases:
- Bridge relays that had DirPort set to 0 would stop fetching
descriptors shortly after startup, and then briefly resume
after a new bandwidth test and/or after publishing a new bridge
descriptor. Bridge users that try to bootstrap from them would
get a recent networkstatus but would get descriptors from up to
18 hours earlier, meaning most of the descriptors were obsolete
already. Reported by Tas; bugfix on 0.2.0.13-alpha.
- Prevent bridge relays from serving their 'extrainfo' document
to anybody who asks, now that extrainfo docs include potentially
sensitive aggregated client geoip summaries. Bugfix on
0.2.0.13-alpha.

Bugfixes in the Tor 0.2.1.10-alpha release:
- When we made bridge authorities stop serving bridge descriptors over
unencrypted links, we also broke DirPort reachability testing for
bridges. So bridges with a non-zero DirPort were printing spurious
warns to their logs. Bugfix on 0.2.0.16-alpha. Fixes bug 709.

New feature in Tor 0.2.1.10-alpha:
- New controller event "clients_seen" to report a geoip-based summary
of which countries we've seen clients from recently. Now controllers
like Vidalia can show bridge operators that they're actually making
a difference.
Vidalia will add support for this feature in February.

Alternate download methods
Our "gettor" email auto-responder is up and working:
https://svn.torproject.org/svn/projects/gettor/README
https://www.torproject.org/finding-tor#Mail

Thandy itself is working smoothly at this point too -- it can contact
the central repository, check all the keys, look in the registry and
compare the currently installed version to the new choices, fetch the
right packages, check all the signatures, and launch the install.

As of December we only had a new MSI-based installer for Tor, but not for
Vidalia, Torbutton, or Polipo. Now we do, though it's still in testing:
https://data.peertech.org/torbld

Translations
Our translation server is up and online:
https://translation.torproject.org/
https://www.torproject.org/translation-portal

We continued enhancements to the Chinese and Russian Tor website
translations. Our Farsi translation from this summer is slowly becoming
obsolete; we should solve that at some point.

November 2008 Progress Report

phobos — Wed, 24 Dec 2008 20:29:44 -0800

Bug Fixes

Tor 0.2.1.7-alpha (released November 8) fixes a major security problem in Debian and Ubuntu packages (and maybe other packages) noticed by Theo de Raadt, fixes a smaller security flaw that might allow an attacker to access local services, adds better defense against DNS poisoning attacks on exit relays, further improves hidden service performance, and fixes a variety of other issues.
http://archives.seul.org/or/talk/Nov-2008/msg00229.html

Tor 0.2.0.32 (released November 20) fixes a major security problem in Debian and Ubuntu packages (and maybe other packages) noticed by Theo de Raadt, fixes a smaller security flaw that might allow an attacker to access local services, further improves hidden service performance, and fixes a variety of other issues.
http://archives.seul.org/or/announce/Dec-2008/msg00000.html

Vidalia 0.1.10 (released November 2) fixes some presentation bugs and some bugs in the Windows installer.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.10/CHAN...

In the Vidalia 0.1.10 stable release:
- Add a prettier dialog for prompting people for their control port password that also includes a checkbox for whether the user wants Vidalia to remember the entered password, a Help button, and a Reset button (Windows only).
- Fix a crash bug that occurred when the user clicks 'Clear' in the message log toolbar followed by 'Save All'.
- Uncheck the Torbutton options by default in the Windows bundle installer if Firefox is not installed.
- Add a Windows bundle installer page that warns the user that they should install Firefox, if it looks like they haven't already done so.

Security fixes in the Tor 0.2.1.7-alpha release:
- The "ClientDNSRejectInternalAddresses" config option wasn't being consistently obeyed: if an exit relay refuses a stream because its exit policy doesn't allow it, we would remember what IP address the relay said the destination address resolves to, even if it's an internal IP address. Bugfix on 0.2.0.7-alpha; patch by rovv.
- The "User" and "Group" config options did not clear the supplementary group entries for the Tor process. The "User" option is now more robust, and we now set the groups to the specified user's primary group. The "Group" option is now ignored. For more detailed logging on credential switching, set CREDENTIAL_LOG_LEVEL in common/compat.c to LOG_NOTICE or higher. Patch by Jacob Appelbaum and Steven Murdoch. Bugfix on 0.0.2pre14. Fixes bug 848.

Design Work
We have a preliminary proposal that suggests we use only one destination port per circuit. This came out of a discussion between Roger and Robert Hogan about how making an AIM connection through your circuit, and then also web browsing through it, can link the web browsing to your AIM login and you may not want that.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/ideas/xxx-se...

We picked up the "proposal 141, clients do less directory downloading" design discussion again:
http://archives.seul.org/or/dev/Nov-2008/msg00000.html
http://archives.seul.org/or/dev/Nov-2008/msg00001.html
http://archives.seul.org/or/dev/Nov-2008/msg00007.html
It looks like we have a plausible new direction to go, but nobody to write up the design proposal or implement it. I'm going to do the first go at the next design proposal in January, and hopefully somebody will have time to build it from there.

We continued extensive work on Thandy this month.

We have a Thandy repository up at
http://updates.torproject.org/thandy/
and its keys and location ship with the thandy client.

(The current repository is still for testing only, and we'll discard the keys and generate new ones when we want to put it up for real. We'll also get an ssl cert for it.)

The client-side of Thandy (teaching it how to decide which packages and bundles are out of date, and teaching it to download new files and check all the right signatures) exists now too. It supports download resuming, doing the download over Tor, etc.

The big picture is that thandy will remember what versions of each package and bundle are installed. Vidalia will periodically launch thandy-client so it can check for updates. When there are new packages, thandy will tell Vidalia (via stdout currently, since Vidalia launched it). Then when the time is right, Vidalia will launch thandy-client with a --install option, and thandy will know how to run the installers for each type of package (currently "rpm", "win32", and "none" are supported):
https://svn.torproject.org/svn/updater/trunk/doc/interface.txt

The long-term plan is to have every platform have a package system that is capable of answering "What version of the software is installed?" On Windows, that would either be the new MSI installer file we're working on:
https://svn.vidalia-project.net/svn/vidalia/trunk/pkg/win32/vidalia.wxs....
or our current NSI installer, with a new registry key patch we're working on.

If an upgrade attempt fails (due to a broken package, broken system, sudden power loss, etc), thandy will try again the next time you tell it to install. With luck, it will work later, or an upgraded version of the package that _does_ work will come to be, and thandy will fetch and install that one instead.

We're working on patching our current Windows installer so it knows how to answer what version is installed. Then it will be easier for all the components to work together.

In short: many more components of our auto updater are coming together, but they aren't all together yet.

We've started to think about moving the Tor Browser Bundle from Firefox 2 to Firefox 3. This will mean we should measure new traces. We'll do it once Torbutton is known to be more stable on Firefox 3, which should happen in early 2009

Translation
We have our translation server up and online:
https://translation.torproject.org/
https://www.torproject.org/translation-portal

We now have a Romanian translation.

We continued enhancements to the Chinese and Russian Tor website translations. Our Farsi translation from this summer is slowly becoming obsolete; we should solve that at some point.

October 2008 Progress Report

phobos — Mon, 01 Dec 2008 16:43:12 -0800

Design
We continued enhancements to the Chinese and Russian Tor website translations. We also have a second Chinese translator for the website now, so hopefully we will get more prompt translations there. Our Farsi translation from this summer is slowly becoming obsolete; we should solve that at some point.

We added a new "30 second summary" web page for Tor:
https://www.torproject.org/30seconds
and a new "easy download" page since the original is so complex:
https://www.torproject.org/easy-download

In the upcoming Vidalia 0.2.0 development release:
- Support changing UI languages without having to restart Vidalia.
- Updated Czech, Polish, Romanian and Turkish translations.

In the upcoming Vidalia 0.1.10 stable release:
- Add a prettier dialog for prompting people for their control port password that also includes a checkbox for whether the user wants Vidalia to remember the entered password, a Help button, and a Reset button (Windows only).
- Fix a crash bug that occurred when the user clicks 'Clear' in the message log toolbar followed by 'Save All'.
- Uncheck the Torbutton options by default in the Windows bundle installer if Firefox is not installed.
- Add an Windows bundle installer page that warns the user that they should install Firefox, if it looks like they haven't already done so.

It looks like Australia is soon to be joining the ranks of countries with a nationwide filtering regime:
http://arstechnica.com/news.ars/post/20081016-net-filters-required-for-a...

Proposals
We finished the first iteration of our auto-updater spec:
https://svn.torproject.org/svn/updater/trunk/specs/thandy-spec.txt
We detail our current auto-updater progress below.

Proposal 156 (Tracking blocked ports on the client side) moves us closer to having clients be able to automatically detect which ports are blocked by their local firewall, so they can bootstrap faster and avoid picking entry guards that aren't reachable for them. The the next steps here are to a) decide if this overall approach is the right approach, and b) revise the patch to be more memory-friendly.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/156-tracking...

Advocacy
Roger started a "Brainstorming about Tor, Germany, and data retention" thread on or-dev:
http://archives.seul.org/or/dev/Oct-2008/msg00001.html
which eventually turned into a blog post:
https://blog.torproject.org/blog/tor%2C-germany%2C-and-data-retention
as well as a (rejected) 25C3 submission. While I had originally been thinking of the issue in terms of what the ISP of a Tor relay might do, the discussion also came up about what responsibilities a Tor relay operator has with respect to the vague new data retention laws:
http://archives.seul.org/or/talk/Oct-2008/threads.html#00126
The ultimate result was a clarified perspective on logging inside Tor:
http://archives.seul.org/or/talk/Oct-2008/msg00274.html

We finally tracked down and solved the mysterious DoS attacks on some of the Tor directory authorities:
http://archives.seul.org/or/talk/Oct-2008/msg00056.html

We started chatting with Aaron about his "tor2web" proxy idea for letting non-Tor users access hidden service content:
http://tor.theinfo.org/
Somebody should follow up on that more to encourage him to keep at it.

Announced Joel Reardon's thesis on or-talk, and followed up with him to point him to some pieces of anonbib he needs to read more, to tell him about 25C3, and to remind him to publish his new measurement tools lest they become lost to time.

Roger and Karsten got the patches from proposal 155 into svn, and ultimately into the upcoming 0.2.1.7-alpha release. These were the bulk of the October progress for that NLnet project:
https://www.torproject.org/projects/hidserv.html.en#Oct08

Mike deleted the router-stability file for his directory authority (ides), which should provide temporary relief from bug 696 (which was causing most of the Stable flags to be assigned wrong, and in turn was causing instant messaging and related connections over Tor to be way more flaky than they should be):
https://bugs.torproject.org/flyspray/index.php?do=details&id=696
If his router-stability file gets corrupted again, we will have learned something.

Roger, Jacob, and Mike went to the Google Summer of Code Mentor Summit on Oct 24-26 in Mountain View, where we met with a few hundred other GSoC mentors and generally shared information about Tor and how to make good use of summer students working on free software tools.

We also went to dinner with Niels Provos while we were there, to talk about options for the "Google gives you a captcha if you're using Tor" problem. It looks like the right answer there will be for Torbutton to automate some workaround.

Andrew started working with Jillian York, so she can start blogging about the great uses of Tor. More news in November, e.g.
https://blog.torproject.org/blog/knight-pulse%2C-jillian%2C-and-tor

Matt Edman printed Vidalia T-shirts, and sent them out to the folks who have helped work on Vidalia lately. He is also working with a volunteer to clean up the Vidalia website, make new logos, clean up the installer graphics, etc.

Andrew wrote a blog post about anonymity in South Korea:
https://blog.torproject.org/blog/online-anonymity-debate-south-korea

Distribution
Work on the Tor VM project continues. We have a working prototype available now with a walk-through and screenshots:
http://peertech.org/files/demo/testinfo.html

We plan to release a more public alpha installer in November.

Scalability
From the Tor 0.2.1.7-alpha ChangeLog:
"The "ClientDNSRejectInternalAddresses" config option wasn't being consistently obeyed: if an exit relay refuses a stream because its exit policy doesn't allow it, we would remember what IP address the relay said the destination address resolves to, even if it's an internal IP address. Bugfix on 0.2.0.7-alpha; patch by rovv."

Packaging
We changed our auto update design from code-name Glider to code-name Thandy, since there's a World of Warcraft cheat program named Glider and it might be a problem for WoW players that try to use Tor.

We've got the PKI and server-side for the auto updater in place. We wrote up a howto walking through how to set up the server-side for the updater, including how to assign roles and generate keys:
https://svn.torproject.org/svn/updater/trunk/doc/HOWTO

We've also decided that Python should work fine for the client-side too. Mike found some techniques to include only exactly the python libs we need, rather than the whole mess of python libs:
http://www.py2exe.org/index.cgi/BetterCompression
and Martin has been messing with saving some additional space by sharing the openssl lib between Tor and Thandy.

The next steps for November are:
- Roger is going to figure out what PKI we want for the first round of testing (what roles, which keys, how many, who, etc), and deploy a Thandy server so we can put some basic packages on it for testing.
- Nick is going to finish the client-side of Thandy, in terms of teaching it how to decide which packages and bundles are out of date, and teaching it to download new files and check all the right signatures.
- Martin is going to package Thandy plus all the right python libs in an easy Windows exe that hopefully isn't too big.
- Matt Edman is going to add a simple interface to Vidalia for client-side Thandy configuration: stuff like a GUI for telling the user that new updates have appeared and letting the user click "yes, please update me now", etc.
- Nick and Matt are going to brainstorm more about the interface between Vidalia and Thandy. For example, which program should keep state about the versions of each package that are installed, which program should be responsible for noticing if an install or upgrade attempt fails, etc.

All the steps but the last I think are going to be pretty straightforward. This last step has the most potential pitfalls in it, since we're trying to keep Thandy general and platform-independent yet *something* (either Thandy or Vidalia, or something in between) has to tackle all the crazy Windows-specific pieces.

It also looks like we should move the Tor packages and bundles from NSIS (Nullsoft installer) to MSI installer, as MSI can handle versioning and automatic installs (and uninstalls!) more gracefully. It's not yet clear yet if we're going to try to squeeze that installer shift into the November development timeframe.

Tor Browser Bundle
We've started to think about moving the Tor Browser Bundle from Firefox 2 to Firefox 3. This will mean we should measure new traces. We'll do it once Torbutton is known to be more stable on Firefox 3, which should happen in early 2009.

August 2008 Progress Report

phobos — Sun, 21 Sep 2008 16:05:39 -0700

Releases

Vidalia 0.1.7 (released August 2) fixes a bug that caused Vidalia to not recognize Tor's version correctly in Tor 0.2.0.x, adds an "nsh2po" tool that helps Pootle translate the Vidalia bundle installer strings, adds "TZ=UTC" to the BrowserExecutable's environment variables when launched via Vidalia, and updates the Czech, French, and German translations.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.7/CHANG...

Incognito 2008.1 (released August 2) is a Gentoo-based Tor LiveCD. This new release adds a "walkthrough" which will launch on startup; adds language support for Arabic, Green, Hebrew, Russian, and Swedish; improves the support for Chinese and Japanese fonts; adds support for VMWare and partial support for VirtualBox; switches to Tor 0.2.0.30 and Torbutton 1.2.0; and adds some new privacy-supporting software and removes some applications that are too likely to leak private information.
https://svn.torproject.org/svn/incognito/trunk/ChangeLog

Tor 0.2.1.3-alpha (released August 3) implements most of the pieces to prevent infinite-length circuit attacks (see proposal 110); fixes a bug that might cause exit relays to corrupt streams they send back; allows address patterns (e.g. 255.128.0.0/16) to appear in ExcludeNodes and ExcludeExitNodes config options; and fixes a big pile of bugs.
http://archives.seul.org/or/talk/Aug-2008/msg00039.html

Tor 0.2.1.4-alpha (released August 4) fixes a pair of crash bugs in 0.2.1.3-alpha.
http://archives.seul.org/or/talk/Aug-2008/msg00039.html

Tor Browser Bundle 1.1.2 (released August 9) updates Vidalia to version 0.1.6, updates Firefox to 2.0.0.16, updates Tor to 0.2.1.4-alpha, updates Torbutton to 1.2.0, and disables the TZ=UTC environment variable trick since Vidalia 0.1.7 now handles that for us.
https://svn.torproject.org/svn/torbrowser/trunk/README

Vidalia 0.1.8 (released August 17) makes the bandwidth graph window look better for languages like Farsi, includes ssleay32.dll in the Windows packages so Vidalia won't crash when it finds an incompatible version of ssleay32.dll in the user's $PATH, makes "escape" and "return" shortcuts for the settings window, and fixes a variety of other bugs.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.8/CHANG...

Tor 0.2.0.30 (released July 15, announced August 21) switches to a more efficient directory distribution design, adds features to make connections to the Tor network harder to block, allows Tor to act as a DNS proxy, adds separate rate limiting for relayed traffic to make it easier for clients to become relays, fixes a variety of potential anonymity problems, and includes the usual huge pile of other features and bug fixes.
http://archives.seul.org/or/announce/Aug-2008/msg00000.html

Tor Browser Bundle 1.1.3 (released August 22) fixes a bug in the 0.1.2 release that messed up translations in the homepage, adds "small=1" to the homepage URL so it doesn't show the huge green onion by default, and updates Vidalia to 0.1.8.
https://svn.torproject.org/svn/torbrowser/trunk/README

Tor 0.2.1.5-alpha (released August 31) moves us closer to handling IPv6 destinations, puts in a lot of the infrastructure for adding authorization to hidden services, lays the groundwork for having clients read their load balancing information out of the networkstatus consensus rather than the individual router descriptors, addresses two potential anonymity issues, and fixes a variety of smaller issues.
http://archives.seul.org/or/talk/Sep-2008/msg00072.html

Blocking resistance
The Tor 0.2.1.3-alpha and 0.2.1.4-alpha releases include more fixes for hidden service performance and robustness, have slightly improved bootstrap status event behavior, and start hunting down a horrible bug that looks like it could leak private information:
https://bugs.torproject.org/flyspray/index.php?do=details&id=779

Now that the Tor 0.2.0.30 release has been declared stable, ordinary users will finally get bridge features, the new harder-to-block network protocol, and other features by default.

Core Development
We're working on a draft for a new "automatic software update" protocol, code-named Glider, that incorporates the previous proposals 153 and 154 but is easier to extend to other packages, and is easier to implement and maintain on the server side. We hope to have this new draft out as an actual proposal document, along with some early prototypes of the server side, in September.
https://svn.torproject.org/svn/updater/trunk/specs/glider-spec.txt
Part of the ongoing development question is how to write the client side of this auto update engine in a convenient and easy language like Python, yet have it still be extremely compact on the client side -- since Windows doesn't include Python by default, shipping a Python interpreter with the auto updater could add 10MB to the package size.

Roger sent the list of "research directions we should look at" to or-dev, so more people could look at it:
http://archives.seul.org/or/dev/Aug-2008/msg00031.html
We are working these items into a more comprehensive research and development roadmap; stay tuned.

Advocacy
We answered a lot of press organizations about Tor and the Olympics this month. Our main goal was to explain to technical people how bridges work, what they're for, and explain that in most countries right now Tor works just fine out of the box, so bridges are the backup plan for later down the arms race. The CCC (and others) succeeded in making some good press articles, e.g.
http://www.rsf.org/article.php3?id_article=27991
http://www.guardian.co.uk/technology/2008/aug/07/censorship.hacking
http://www.guardian.co.uk/commentisfree/2008/aug/05/china.censorship

Roger attended Black Hat and Defcon. His Defcon talk was:
"Attacks/Vulnerabilities on Tor: past, present, future"
Slides are at http://freehaven.net/~arma/slides-dc08.pdf
He had a packed room of 500+ people. Lucky Green summarized his take-away from the talk as "we would love to work with you if you find any problems with Tor, and we have a good track record of working well with the community." That sounds like what we were aiming for. We're still waiting for the video to come out so we can link to it from the documentation page.

We also talked a lot with the Mozilla people about privacy-impacting bugs in Firefox. We have a list now:
https://www.torproject.org/torbutton/design/#FirefoxBugs
and should start looking for good Firefox developers to fix them and funding to incent them to do so.

We put up our mid-August NLnet reports:
https://www.torproject.org/projects/hidserv#Aug08
https://www.torproject.org/projects/lowbandwidth#Aug08

Jacob spent a long week of hacking in Argentina, for DebConf 8 (the yearly Debian Conference). Lots of Tor advocacy. Another box of Tor stickers applied to many many laptops. Lots of people were interested in Tor and many many people installed Tor on both laptops and servers. This advocacy resulted in at least two new high bandwidth nodes that he helped the administrators configure. The first is in Japan. The second is our first major high bandwidth node in New Zealand.

Coverity (coverity.com) is now scanning Tor. It found a bunch of minor memory leaks, a few false positives, and some other miscellaneous bugs. Nick fixed almost all of the bugs in a quick afternoon, excepting some testing code that has some resource leaks. Jacob is going to work on getting other Tor related projects into Coverity.

Mike Perry has been working lately on publicity for moving more high-profile websites to use SSL correctly. Last year at Defcon he reported a bug in how many sites (including GMail) handle their cookies: he basically described an easy way for anybody in Starbucks to steal your GMail cookie and log into your gmail account, even if you are always very careful to only use "https" when logging in to your gmail account. The attack works because cookies *can* be set with an "only present this cookie on an SSL connection" flag when they're created, but no sites actually set this flag because they are concerned about usability. This attack is easy to perform as a Tor exit relay too. This year, Mike presented an actual tool that performs this attack on a local wireless network in an automated way. Some high-profile sites are slowly moving to use more secure login approaches.

Matt Edman finished running the "Vidalia logo design contest". The contest resulted in 76 entries. There were a lot of questionable submissions (Vidalia ninjas?!), but there were also a few great ones. He is tending towards this entry as his choice for the new Vidalia logo:
http://www.worth1000.com/view.asp?entry=479229

Usability
Incognito 2008.1 (released August 2) is a Gentoo-based Tor LiveCD. This new release adds a "walkthrough" which will launch on startup; adds language support for Arabic, Green, Hebrew, Russian, and Swedish; improves the support for Chinese and Japanese fonts; adds support for VMWare and partial support for VirtualBox; switches to Tor 0.2.0.30 and Torbutton 1.2.0; and adds some new privacy-supporting software and removes some applications that are too likely to leak private information.
https://svn.torproject.org/svn/incognito/trunk/ChangeLog

Incognito now comes with much more thorough documentation about which software packages are included, and how they are configured:
http://www.browseanonymouslyanywhere.com/incognito/uploadfiles/docs.html

Incognito's next step is to work on a "hardened" option that uses a more secure kernel and other applications. The goal is to keep the same usability but be even less vulnerable to application-level and kernel-level attacks that could be used to gain access to the system and then try to unveil the user.

Tor Browser Bundle 1.1.2 (released August 9) updates Vidalia to release 0.1.6, updates Firefox to 2.0.0.16, updates Tor to 0.2.1.4-alpha, updates Torbutton to 1.2.0, and disables the TZ=UTC environment variable trick since Vidalia 0.1.7 now handles that for us.
https://svn.torproject.org/svn/torbrowser/trunk/README

We're working on a new branch of Vidalia that can be used in Tor Browser Bundle, for launching Firefox directly without needing the extra installer scripts called "Firefox Portable". If we get this working, then we can hopefully make progress on running multiple Firefoxes at once (one used for Tor launched by TBB, and one used for non-Tor).
http://trac.vidalia-project.net/browser/vidalia/branches/alt-launcher

The German CCC organization put together a version of the Tor Browser Bundle called the "Freedom Stick" for use in teaching the media about the Chinese firewall and the Olympics:
http://chinesewall.ccc.de/freedomstick-en.html

Scalability
From the Tor 0.2.1.5-alpha ChangeLog:
"More progress toward proposal 141: Network status consensus documents and votes now contain bandwidth information for each router and a summary of that router's exit policy. Eventually this will be used by clients so that they do not have to download every known descriptor before building circuits."

We're worked on getting "Tor Weather" back up and working:
https://weather.torproject.org/
Weather is a service to let relay operators get notified when their relay is unreachable for an extended period of time. It's still in its early experimental stages, but it's already proved useful to its early testers. It's also using SSL as its base URL now.

Jacob has also been working on a Tor network map, to visualize where our relays are. Using all of the known descriptors, it maps each node with some GeoIP code and plot it onto a map. You can interact with the data to see the IP address of each node, the node name and the city/country information if we could find it. Sadly, it *will* lock your browser up for one or two minutes, as there's a lot of data to parse:
http://freehaven.net/~ioerror/maps/v3-tormap.html

June 2008 Progress Report

phobos — Tue, 22 Jul 2008 20:25:34 -0700

Torbutton 1.2.0rc1 (released June 1), the first release candidate for the next stable series of the security-enhanced Torbutton Firefox extension, features functional support for Firefox 3. However, this support has not been extensively tested. In particular, timezone masking does not work at all. The workaround is to manually set the environment variable 'TZ' to 'UTC' before starting Firefox. This works on both Linux and Windows:
http://archives.seul.org/or/talk/Jun-2008/msg00044.html

Tor 0.2.0.27-rc (released June 3) adds a few features we left out of the earlier release candidates. In particular, we now include an IP-to-country GeoIP database, so controllers can easily look up what country a given relay is in, and so bridge relays can give us some sanitized summaries about which countries are making use of bridges. (See proposal 126-geoip-fetching.txt for details.)
http://archives.seul.org/or/talk/Jun-2008/msg00055.html

Torbutton 1.2.0rc2 (released June 8) features a fix for an annoying bug on MacOS, and adds much clamored for options to start Firefox in a specific Tor state:
http://archives.seul.org/or/talk/Jun-2008/msg00103.html

Tor 0.2.0.28-rc (released June 13) fixes an anonymity-related bug, fixes a hidden-service performance bug, and fixes a bunch of smaller bugs.
http://archives.seul.org/or/talk/Jun-2008/msg00165.html

Tor 0.2.1.1-alpha (released June 13) fixes a lot of memory fragmentation problems that were making the Tor process bloat especially on Linux; makes our TLS handshake blend in better; sends "bootstrap phase" status events to the controller, so it can keep the user informed of progress (and problems) fetching directory information and establishing circuits; and adds a variety of smaller features. http://archives.seul.org/or/talk/Jun-2008/msg00185.html

Vidalia 0.1.4 (released June 13) adds a bootstrap progress bar, UPnP support, a new set of freely licensed GUI icons, and fixes a few bugs.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.4/CHANG...

The Tor Browser Bundle 1.1.0 (released June 13) replaces startup batch script with application (RelativeLink) so there is a helpful icon, optionally installs Pidgin (for Tor IM Browser Bundle), optionally uses WinRAR to produce a self-extracting split bundle, and includes upgraded versions of Tor, Vidalia, and Torbutton.
https://svn.torproject.org/svn/torbrowser/trunk/README

Tor 0.2.1.2-alpha (released June 20) includes a new "TestingTorNetwork" config option to make it easier to set up your own private Tor network; fixes several big bugs with using more than one bridge relay; fixes a big bug with offering hidden services quickly after Tor starts; and uses a better API for reporting potential bootstrapping problems to the controller.
http://archives.seul.org/or/talk/Jun-2008/msg00247.html

Vidalia 0.1.5 (released June 21) switches Vidalia's internal string representation so it can use the new Pootle-based translation system.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.5/CHANG...

Torbutton 1.2.0rc3 and 1.2.0rc4 (both released June 27) provide improved addon compatibility, better preservation of Firefox preferences that we touch, fixing issues with Tor toggle breaking for some option combos, and an improved 'Restore Defaults' button.
https://torbutton.torproject.org/dev/CHANGELOG

We finally got around to writing down the details of many of our architecture and technical design changes:

Proposal 137 ("Keep controllers informed as Tor bootstraps") modifies Tor so it keeps Vidalia informed of each "bootstrap phase" -- that is, progress Tor makes at learning directory information, making connections to the network, etc. Now Vidalia has a progress bar on Tor startup that explains what's going on. Further, Tor reports "bootstrap problems" when it believes it's having troubles starting up correctly, and Vidalia can now tell the user. All of this is in as of the Tor 0.2.1.2-alpha release (June 20).
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/137-bootstra...

Proposal 138 ("Remove routers that are not Running from consensus documents") modifies the directory "networkstatus consensus" documents so they no longer list relays that are believed to be unusable. They used to list these relays so clients could decide for themselves, but in practice clients just ignored them. This change saves 30% to 40% in download bandwidth for consensus documents. It is included in the 0.2.1.2-alpha release (June 20).
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-d...

Proposal 139 ("Download consensus documents only when it will be trusted") tries to make Tor clients better handle the case when new directory authorities have been added to the system, or when directory authorities have changed (for example, this could happen if we have another bug like the one in May that caused us to change keys for half the directory authorities). Now clients specify which directory authorities they trust, so the directory mirrors can give them a consensus document they'll be willing to use. This change is included in Tor 0.2.1.1-alpha, and a bugfix on it was included in Tor 0.2.1.2-alpha.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/139-conditio...

Proposal 140 ("Provide diffs between consensuses") is still under development, but is scheduled to be included in the Tor 0.2.1.x tree. The idea is that most parts of the consensus document don't change from one hour to the next, so we can give clients a diff on the previous one rather than a whole new document, changing the size of the document every client must download every few hours from 92KB on average to 13KB on average.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensu...

Proposal 141 ("Download server descriptors on demand") is still under discussion, and may not be ready until for inclusion until Tor 0.2.2.x. This is the more detailed version of our "grand scaling plan" first mentioned in April. The idea is to have clients download networkstatus consensus documents as they do now, but rather than preemptively fetching every relay descriptor just in case, they fetch descriptors "just in time" only when they need them. The trick is to keep the bandwidth overhead low while not introducing too many new anonymity attacks e.g. due to leaking which relays you're picking.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-d...

We've instrumented a Tor client to collect stats on how much bandwidth we use now for directory overhead and how much we'd save with this new approach:
http://archives.seul.org/or/dev/Jun-2008/msg00024.html

Proposals 142 ("Combine Introduction and Rendezvous Points") and 143 ("Improvements of Distributed Storage for Tor Hidden Service Descriptors") are still in the discussion phase. Their goal is to improve the experience for clients accessing Tor hidden services, both by making the handshake faster and by making hidden service reachability more reliable and more robust.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/142-combine-...
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/143-distribu...

The "spoofing Firefox cipher suites and extensions" features are now in the Tor 0.2.1.1-alpha release, meaning they're in the Tor Browser Bundle 1.1.0 release also. From the 0.2.1.1-alpha ChangeLog:
"More work on making our TLS handshake blend in: modify the list of ciphers advertised by OpenSSL in client mode to even more closely resemble a common web browser. We cheat a little so that we can advertise ciphers that the locally installed OpenSSL doesn't know about."

We've done some initial security auditing (though there's always room for more, and we plan to do some more concrete auditing in July).

Nick also wrote some early thoughts on doing pass-through to an Apache server to improve scanning resistance:
http://archives.seul.org/or/dev/Jun-2008/msg00014.html

We also looked into running two Firefoxes in parallel:
https://svn.torproject.org/svn/torbrowser/trunk/docs/two-firefox.txt
and we even hacked in some Torbutton fixes that will come out in version 1.2.0rc3 that should get us closer:
http://archives.seul.org/or/cvs/Jun-2008/msg00213.html

Speaking of which, we also hacked in another feature in Torbutton 0.1.2rc2, to add a "locked" mode so Tor Browser Bundle can start Torbutton and not fear that the user will click and disable Tor. I believe TBB 1.1.0 doesn't use this feature yet though.
http://archives.seul.org/or/cvs/Jun-2008/msg00186.html

From the Tor 0.2.1.2-alpha ChangeLog:
"If you have more than one bridge but don't know their digests, you would only learn a request for the descriptor of the first one on your list. (Tor considered launching requests for the others, but found that it already had a connection on the way for $0000...0000 so it didn't open another.) Bugfix on 0.2.0.x."
"If you have more than one bridge but don't know their digests, and the connection to one of the bridges failed, you would cancel all pending bridge connections. (After all, they all have the same digest.) Bugfix on 0.2.0.x."
"If you're using bridges, generate "bootstrap problem" warnings as soon as you run out of working bridges, rather than waiting for ten failures -- which will never happen if you have less than ten bridges."

We put up a new webpage to describe bridges, how to fetch bridge relay addresses, etc:
https://www.torproject.org/bridges

We also modified the BridgeDB database (that is, the server that runs https://bridges.torproject.org/ and answers mail to bridges@torproject.org) to autodetect if the address hitting https://bridges.torproject.org/ is currently a Tor exit relay, and if so to treat it specially -- that is, we reserve a set of bridge addresses and give those out only to folks coming in over Tor.

The updated BridgeDB version now makes sure to give out at least one bridge that's listed as Stable in the bridge authority's networkstatus document, and at least one bridge that listens on port 443. The goal here is to increase the odds that at least one of the bridges we give the user will be usable even if he's in a tightly firewalled situation.

From the Tor 0.2.0.27-rc ChangeLog:
"Include an IP-to-country GeoIP file in the tarball, so bridge relays can report sanitized summaries of the usage they're seeing."

We finished work on a patch for OpenSSL that will make it keep less buffer space around. Currently fast Tor relays use (waste) as much as 100M of memory in OpenSSL's buffers. This patch was accepted and included in the main OpenSSL tree in June:
http://marc.info/?l=openssl-cvs&m=121246471627426&w=2

The Vidalia 0.1.4 release has folded the UPnP library and GUI changes into the main Vidalia tree, along with a "test" button to try speaking UPnP at the local router and tell the user whether it worked; these features will be available by default in the 0.2.0.x stable release.

We've put a lot of effort into reducing Tor's memory footprint again. The main issue was a "memory fragmentation" problem in Linux's memory allocator, which was causing Tor servers on Linux to slowly grow without bound. As of Tor 0.2.1.2-alpha, the issue appears to be substantially better. Many more details are here:
http://archives.seul.org/or/dev/Jun-2008/msg00001.html

From the Tor 0.2.1.2-alpha ChangeLog:
"New TestingTorNetwork config option to allow adjustment of previously constant values that, while reasonable, could slow bootstrapping. Implements proposal 135. Patch from Karsten Loesing."
"When building a consensus, do not include routers that are down. This will cut down 30% to 40% on consensus size. Implements proposal 138."

We've added clear user-oriented instructions for the Tor Browser Bundle split-download page:
https://www.torproject.org/torbrowser/split.html.en

We're starting work on a "gettor" email auto-responder script that will let people mail gettor@torproject.org and retrieve a copy of Tor from their mailbox. More info forthcoming in July.

More generally, we have a new https://www.torproject.org/finding-tor page that describes various mechanisms such as mirrors.

In July we plan to deploy a more automated mechanism for tracking which Tor mirrors are up-to-date.

We have our translation server up and online:
https://translation.torproject.org/

We have imported the strings from Vidalia, Torbutton, and Torcheck, and we currently have active translations for Spanish, French, German, Italian, Polish, Romanian, Swedish, Turkish, Finnish, Russian, Chinese, and Arabic.

We have a more useful overall translation tutorial here:
https://www.torproject.org/translation-portal

And we have internal documentation here for how to deal with the translation stuff behind the scenes:
https://svn.torproject.org/svn/tor/trunk/doc/translations.txt

In July we plan to add the strings for Vidalia's installer; the challenge is that we need to write a script to convert from the "nsh" (nullscript installer language) format to the "po" (preferred by Pootle) format and back.

In July we also expect to see the first version of our "wml to po and back" conversion tool, that will allow us to start putting our website pages into the translation server.