Measuring Tor and Iran (Part two)

karsten — Wed, 01 Jul 2009 11:25:51 -0700

Two weeks ago we posted early measurements about the growth of Tor usage in Iran. Since then we have improved our math, and used more data sources. This work is part of our metrics project, where we're learning about the Tor network to improve its availability and performance while keeping our users safe.

The first graph shows the estimated number of new and returning Tor clients per day coming from China and Iran. So for example, there were around 7800 new and returning Iranian Tor users on June 24. By "returning", we mean Tor clients that were off for at least several days, so they didn't have cached directory information. We added China as a comparison for the Iran numbers: you can see the results of the recent Green Dam fiasco and attempts to block Google services. Many more details and math are here.

The second graph shows the growth in bridge users coming from Iran and China. Bridges are like normal relays except that they are not listed in a public directory and therefore they're harder to block. We show "growth compared to June 1" because we don't yet have a good estimate of the absolute number of bridge users. The number is probably an order of magnitude smaller than the number of "regular" Tor users. But still, we can say that bridge usage from Iran has boosted to 950% as compared to June 1. For more information on these numbers see this report.

While it is great to see that so many people in Iran find the Tor network useful, we should continue our attempts to make Tor even better. Your contribution could be to set up a bridge or relay as many others recently did. You might also consider setting up an exit relay, possibly with the help of these instructions. But middle nodes and bridges are helping as well!

On the Recent Growth of the Tor Network

karsten — Mon, 22 Jun 2009 18:07:03 -0700

In the past few days the Tor network is seeing a lot of new users coming from Iran. At the same time we have heard from many people who want to support the Tor network by setting up more relays and bridges. Now we wanted to know, are these just promises, or did the network really grow? Here are the results:

The number of relays has grown by 359 or 24% to now 1827 relays within only one week to the highest number of relays the network has ever seen. Likewise, the number of bridges has increased by an incredible 69 % from 255 to 432 within one week. Awesome!

So, does this mean everything is taken care of and no more relays or bridges are needed? Not at all! As you may know, Tor has some performance issues that are, among other things, the result of too few bandwidth capacity for too many clients. If you can, go setup more relays and/or bridges and keep them running even when the conflicts in the world do not hit the headlines. Be sure that your support is much appreciated!

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