January 2011 Progress Report

by phobos | February 8, 2011

New releases

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

Architecture and technical design docs for Tor enhancements
related to blocking-resistance.

Hide Tor's network signature.

Grow the Tor network and user base. Outreach.

Bridge relay and bridge authority work.

  • Karsten did some work to publish sanitized bridge pool assignments. We're
    going to publish the information which distribution pool a bridge is assigned
    to. The distribution pool defines whether we're giving out bridges via HTTP,
    via email, or not at all (reserved pool). The plan is to remove all sensitive
    information from bridge pool assignments before making them available on
    https://metrics.torproject.org/data.html. The discussion was started on
    the or-dev list
    at http://archives.seul.org/or/dev/Jan-2011/msg00033.html.

Scalability, load balancing, directory overhead, efficiency.

  • We released an updated version of Tor
    Weather, https://weather.torproject.org. Tor Weather is a web application used
    to allow tor relay operators to sign up for notices when their relay is offline,
    drops below a threshold of bandwidth served, and receive notifications when a
    new version of tor is released. This version of the web application was written
    by the Wesleyan University Humantarian Free and Open Source Software (HFOSS)
    team working on Tor for their summer project, http://hfoss.wesleyan.edu/.
  • Karsten started improving metrics-db performance, so that it can scale to
    five years of data with 10K relays and 5K bridges. This included a few tricks
    to avoid parsing the same data twice. Also changed the database schema to use
    SQL arrays to store bandwidth histories, which is apparently a less used part of
    PostgreSQL, because he found a confirmed bug in PostgreSQL 8.2 (released
    2006-12-05).
  • Karsten found two major, if not blocking, bugs in Torouter when run on the
    suggested Buffalo hardware. The Excito hardware does not have these problems.
    The bug numbers are 2334,
    https://trac.torproject.org/projects/tor/ticket/2334, and 2376,
    https://trac.torproject.org/projects/tor/ticket/2376.
  • Karsten found and fixed a problematic bridge sanitizer bug that made us
    keep original IP addresses in reject lines. Updated metrics-db and sanitized
    all bridge descriptors since May 2008 once again. The latter kept two of our
    computers busy for 2.5 weeks.
  • Karsten started with exporting bridge pool assignments and restarted
    discussion about preserving hashed IP addresses in bridge descriptors.
  • Karsten upgraded Torperfs to output information about which circuits they
    used for measuring download times. Made data available on metrics website.
    Added new graphs combining all Torperf sources and showing the fraction of
    timeouts and failures. Started Torperfs with custom entry guard selection
    strategies.
  • Karsten talked to Björn Scheuermann and Florian Tschorsch about
    performance improvements in Tor. Working on a patch with them to be included in
    Tor 0.2.3.x.
  • Karsten improved graphs on metrics-web by adding more countries and by
    allowing users to customize the graph image resolution.

More reliable download mechanism.

  • Sebastian and Erinn started to tackle Thandy and Hudson work. They solved
    the Hudson issue on Windows and made a good deal of progress on getting Thandy
    set up, understanding the different roles and responsibilities of each in the
    Thandy system. Installing files by copying into the right place works, but the
    packaging db that would be required for TBB is not yet working.

Translations

  • Updated translations for the following languages: af ak am arn ast be bg bn
    bn_IN csb cy dz eo eu fil fur ga gl gun ha he hi ht hu is it km kn kw lb ln lo
    lt lv mg mi mk ml mn mr ms mt nah nap ne nn nso oc pa pap pms ps sco son sw ta
    te tg th ti tk uk ur ve wa zh_HK zu.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

February 10, 2011

Permalink

TOR Browser bundle in Linux is a nice thing, but when i close the browser, the TOR control panel also closes........I need an option to avoid that so that i can use TOR on my own browser.....Linux means being customizable.... :P

Anonymous (not verified) said:

February 13, 2011

Permalink

Not sure if you are working on this or where to ask about this but FYI:

(1) It is extremely difficult for the average user to set up there own node. If you connect to the internet through a router, you have to configure the router's firewall to let tor traffic through. This is something that is not at all obvious how to do and I tried at several different times over a number of years to set up a tor node to no avail because I didn't realize that the problem was not the software firewall on my computer, but the router. The easier something is to set up, the more people you'll get who are willing to run the software. I have never had to do deal with the router's firewall for any other program on my computer. So if you made tor such that it could easily operate behind a router, that would get you a lot more nodes.

(2) The easier you make help with getting a node set up, the more nodes you get. I know there is an email available for help, but guess what? I didn't use it. Setting up the node didn't work and so I just moved on. Call me lazy, but I'm not alone. What I would have used is an instant chat in the browser with a volunteer who could help me troubleshoot why I couldn't get the node to work.

(3) My Tor node takes hours to start getting a decent volume of traffic and even then the traffic level is no where near what my internet connection can handle (yes, bandwidth limiting is off). You advice people to constantly run their node, but the reality is that the average person does not leave their computer on 24/7/365 (I have a laptop for instance), so you would get more bandwidth from the nodes if Tor could use new nodes faster.

Second, when you do first get your node running, there is an initial feeling of, "well what was the point of all this hard work to get the node running if it's only going to transfer 10mb in an hour?" The quicker new nodes are used not only will more bandwidth be available through Tor in the short run, but the more people who will continue to operate nodes in the long run.

Anonymous (not verified) said:

February 15, 2011

Permalink

I think you people do more in a month than most other projects and companies do in a year. keep it up. hopefully you're getting paid well for this.

Anonymous (not verified) said:

February 16, 2011

Permalink

In response to Feb 13th commment, my guess would be it is not so much ordinary relay nodes that are in short supply but exit nodes.

Running an exit node is something that only the brave (or naive) do, at least that is my impression from having read a number of scary accounts from volunteers who set up exit nodes and were harrassed by the authorities.

When I click on the world map in Vidalia I see the same exit nodes handling my traffic very often. They don't know where my traffic is coming from but unless I happen to be connected to a server via https (which I make sure to enable whenever the server is equipped to do so) they can read it.

It bothers me that so much of the time, my traffic is handled by the same exit nodes. I have a sneaking suspicion that a significant portion are not ordinary, idealistic volunteers.

Anonymous (not verified) said:

February 20, 2011

Permalink

@ Feb 16th: I think you're right that exit nodes are in much shorter supply, but I think they are still at least 1 in 3 nodes in most countries. Even if there is not one exit per two relays, having additional relays can increase the anonymity of the network.

What I would like to see is something like what is proposed in this paper:

http://freehaven.net/anonbib/papers/incentives-fc10.pdf

If users had incentives to run nodes, far more would (note everyone could still use the network and the speed for the non-node user would likely improve even though they would be given a lower priority).

Right now, a lot of tor's bandwidth is eaten up by bittorrent. I think it would be cool if Tor developed a file sharing program that shared files across the tor network, a sort of bittorrent.onion. A user would have a strong incentive to run a node (or an exit node for an even faster connection) if they wanted to download large files. I see this as killing two birds with one stone. 1) it anatomizes file sharing and 2) it does so using the file sharers' desire for faster download speeds to share their bandwidth with Tor web users and thus actually speed up tor's current service.

O.K., I read your paper. While overall it appears to be an excellent treatment of a thorny subject, this on page 5 stuck out like a sore thumb to me:

"Since there are enough exit relays currently, the design
and analysis in this paper focuses on incentives for relayed traffic."

I am not so sure that there are enough exit nodes. It may well be true that currently, exist nodes are capable of handling the traffic thrown at them.

However, and there is no need to name names here, but when I see one exit node operator maintaining no fewer than twelve separate exit nodes, all running at bandwidths of 5 megabytes per second and up, I begin to wonder who is paying for this... and why.

This particular exit node is in the U.S. Another cluster of exit nodes with high bandwidth is in Germany. Just these two clusters account for a significant portion of all my Tor traffic going out from exit nodes over extended periods of time.

Is it a problem? I don't know... but I'd feel less worried if there were more diversity among exit nodes, quite apart from traffic and throughput considerations.

I have an idea for a solution but it is neither cost-free nor devoid of personal risk:

Set up a legal defense fund for one (1) exit node operator on every continent, e,g,, U.S., Brazil, Australia, Japan, South Africa, an EU member state.

Make an agreement with a private individual to indemnify her/him for the cost of defending against any and all civil and criminal charges arising out of the operation, within Torproject.org rules, of an exit node, up to and including the highest court in the land.

With that precedent in hand, normal people can then feel safe in operating their own exit nodes and sign up in large numbers, ensuring "security by diversity".

Where would the money come from? Perhaps a fund-raising drive...

How long would it take? Years, obviously.

I'm afraid I can't think of anything better.

Anonymous (not verified) said:

February 20, 2011

Permalink

Is possible ti use skype IM to transport tor?
skype usualy is not blocked.

Tor working in Bahraim, Egipt etc?