performance

New releases, new hires, new funding

Bruce Leidl joins to work on developing Tor in Java. Bruce will write a fully functional Tor in Java in order to provide a solid foundation for other java-based projects; such as Tor on mobile platforms like Maemo and Android.

On November 2nd we released Vidalia 0.2.6. https://blog.torproject.org/blog/vidalia-026-released

On November 20th, we released Tor Browser Bundle 1.2.10. https://blog.torproject.org/blog/tor-browser-bundle-1210-released

On November 19th, we released Tor 0.2.2.6-alpha. https://blog.torproject.org/blog/tor-0226-alpha-released

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

Roger met with his class at KAIST working on bridge deployment strategies. A few teams developed some creative strategies. Roger is continuing to work with the leading teams to further refine their ideas before publishing. read more »

Congratulations to Chrisd for assuming maintainership of the Polipo codebase from Juliusz. The full announcement is available at the mailing list archives.

Why Chris?

Chrisd was a 2009 Google Summer of Code for Tor/EFF. His project was Polipo Portability Enhancements. Chris has proven himself to be a very competent coder and able to design and implement features as needed. He even wrote a SOCKS layer fix for Firefox bugs, https://bugzilla.mozilla.org/show_bug.cgi?id=280661.

What does this mean to Tor?

It means we have a fantastic new coder maintaining the polipo codebase. Bugfixes, features, and more frequent releases should help improve polipo beyond where it is today.

Is Tor going to control Polipo? read more »

A while ago there was a thread on OR-TALK that devolved into

"why does Tor still ship ancient privoxy?"

and

"why are you shipping polipo with the Tor Browser Bundle instead of current privoxy?"

For those interested, the thread is here, http://archives.seul.org/or/talk/Jul-2009/msg00063.html.

Scott had a good argument for why we should update the bundles to the latest privoxy, and I agree, we should. But then I started thinking about why we needed a proxy at all. Almost all browsers support socks5 direct, isn't that faster than a middleman proxy?

This got me thinking about why polipo is in the TBB, but not the other packages. The TBB "feels faster" when using Tor than using the installed Tor, Vidalia, and Privoxy. However, I couldn't find any actual testing of performance of polipo vs. privoxy vs. socks5 direct. read more »

Jake, Mike, Karsten, Sebastian, and I attended Hacking at Random last week in The Netherlands. I did a talk on Tor performance challenges — basically walking through the key pieces of the "Why Tor is Slow" document that we wrote in March.

As usual with European hacking cons, they produced a really well-done video just days after my talk. So if you want to get the highlights on what we're doing to speed up Tor and what roadblocks remain, take a look at the video and also the slides that come with it.

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: read more »

Like Karsten, I too am presenting at HotPETS in Seattle in August. My presentation will cover my work with my TorFlow suite - a python library and utility set to assist measuring and adjusting performance on the Tor network, and to scan the network for malfunctioning and misbehaving exits. read more »

On this year's HotPETs workshop (August 5-7 in Seattle, WA, USA) I'm going to present some results on Measuring the Tor Network from Public Directory Information. The main idea is to observe trends in the Tor network without having to measure any data other than public directory information. These data are there anyway as they are required for clients to make good path selection decisions and build circuits. The results of this paper reveal problems in the current Tor network that need to be addressed, e.g., by lowering requirements for assigning certain flags, facilitating the upgrade process, improving support for dynamic IP addresses, possibly calculating bandwidth capacity more reliably, and clarifying legal issues for running relays in view of data retention laws. The next step in understanding the problems of the Tor network requires an extension of network measurements to improve performance and blocking-resistance of Tor.

The Tor network has grown to more than one thousand relays and millions of casual users over the past few years. We are proud of our network's popularity, but with growth has come increasing performance problems and attempts by some countries to block access to the Tor network. In order to address these problems, we need to learn more about the Tor network. In this post, I describe the current state of network measurements in Tor and some proposed additions to help us understand the network better. read more »

I've just finished writing up an explanation of all the various reasons why the Tor network is slow, and what we can do about each. Part of it comes down to design flaws; some of it is that a handful of users are overloading the network; and there's also simply not enough capacity to go around.

Specifically, we've identified six categories of problems to address, and laid out some steps to resolve each of them.

You can read the pdf here:
https://svn.torproject.org/svn/tor/trunk/doc/roadmaps/2009-03-11-performance.pdf

Andrew has also put together a real live press release to go with it.

Now all that remains is to do everything. So if you want to help, or especially if you know any organizations that can help with funding, please help us make this happen! read more »

A growing number of people want to use Tor in low-bandwidth contexts (e.g. modems or shared Internet cafes in the Middle East) and mobile contexts (start up a Tor client, use it for a short time, and then stop it again). Currently Tor is nearly unusable in these situations, because it spends too many bytes fetching directory info. This post summarizes the steps we've taken so far to reduce directory overhead, and explains the steps that are coming next.

First, what do I mean by "directory info"? Part of the Tor design is the _discovery_ component: how clients learn about the available Tor relays, along with their keys, locations, exit policies, and so on. Tor's solution so far uses a few trusted directory authorities that sign and distribute official lists of the relays that make up the Tor network. read more »