November 2009 Progress Report

by phobos | December 14, 2009

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.

Improved our email autoresponder, get-tor, to handle non-english character sets. Implemented gettor+(language)@ addressing to allow users to request tor browser bundle packages in their native language. Added support for languages with a right to left orientation, such as farsi.

Grow the Tor network and user base. Outreach.

Bridge relay and bridge authority work.
We distributed bridge addresses to networks of people in China and Iran to let Tor users continue to work without issues.

Karsten worked to remove sensitive data from collected meta-data about bridges. We can publish our bridge data archives to http://archive.torproject.org soon. This data could help understand bridge quantity, usage of bridges around the world, and other information from possible data analysis.

Scalability, load balancing, directory overhead, efficiency.

Included in the Tor 0.2.2.6-alpha release is the beginning of microdescriptors.

Directory authorities can now agree on and publish small summaries of router information that clients can use in place of regular server descriptors. This transition will eventually allow clients to use far less bandwidth for downloading information about the network. Begins the implementation of Proposal 158: ”Clients
download consensus + microdescriptors”.

More reliable (e.g. split) download mechanism.

Continuing to update the email autoresponder, get-tor, to handle split downloads on request. Split Tor Browser Bundles work well. Creation and maintenance of Mac OS X split dmgs is due in December 2009.

Translation work, ultimately a browser-based approach.

  • Pushed live Runa’s work on integrating the website to our translation portal, https://translation.torproject.org/.
  • Runa fine tuned the translation portal to website scripts.
  • Runa updated the documentation for translators to reflect these tor translation portal updates.
  • Added our email autoresponder, get-tor, to the translation portal.
  • Began live testing of website translations through the Tor Translation Portal.
  • 28 updated Polish website translations.
  • 15 updated Chinese website translations.
  • 11 updated Italian website translations.
  • 1 French translation of get-tor.
  • Full Norwegian translation of tor browser bundle.
  • Full Norwegian translation of the website.
  • Full Burmese translation of the website.
  • Full Burmese translation of torcheck.
  • Updated Spanish torbutton translations.
  • Updated Chinese torbutton translations.
  • Updated Chinese torcheck translations.
  • 18 updated German website translations.
Tags
progress report
translation
censorship circumvention
performance
advocacy
tor in java
Anonymous

Anonymous (not verified) said:

December 15, 2009

Permalink

A quick question about twitter and youtube:

Hey,

Thank you for your great work. I'm also suffering from the GFW in China, and Tor is really an excellent tool for me.

But, recently I found that twitter and youtube are not accessible with Tor, while other blocked web sites are still available. Could you please help me to find out the reason of such problem?

Thank you vert much.

Regards, Yan

Anonymous

Anonymous (not verified) said:

December 16, 2009

Permalink

i guess some China User (or other censored country)
try to set himself as Tor Relay
because they believe this can help Tor Network better.

the methods is using Vidalia
1) the user turnon 'my ISP block Tor' checkbox and put bridge IP
2) use bridge IP to connect to Tor successful
3) the user turnoff 'my ISP block Tor' checkbox
4) set Tor 'Run as Tor Relay'

but what this behavior actually make to Tor network is
make Tor Network see this china's node is Tor Exit and use it.

unfortunately, such of this Exit is dead end!

it will not work. and in this way, the second hand data going through their up stream bridge got bloated by encryption. so it's not going to help this network. and others connecting to those relays going through GFW got unnecessarily high latency. He must have taken tor as a P2P program.

i am in china, i can't browse facebook or any censor site for 3 days now.
but i can browse normal website via Tor (which mean GFW can't block Tor yet)

so this assumption is very high potential.

what should Tor do to solve such Dead End Exit Relay problem??

Anonymous

Anonymous (not verified) said:

December 17, 2009

Permalink

another assumption is GFW now known Tor packet pattern already
they allow Tor connect packet but block Tor data packet.

Although Tor can connect to Tor network
but can't send/receive data anymore

As Tor OpenSource on Oct.
i think china government already get Tor source code
and everything is easier for them than ever!

they can create Tor Bridge Relay Emulator to retrieve many of Bridge IP then block it
or give GFW learn how to decrypt Tor packet and block it.

Tor has been open source for nearly nine years. Tor continues to work around the world. An adversary doesn't need to create a bridge relay emulator, they can just setup a bridge relay and record the IP addresses that connect to it. Tor supports using any open proxy as a first hop to get to the public Tor Network. You don't have to use a bridge to bypass a block.

Our testing shows China continues to do a simple IP address and TCP Port combination block. It's the simplest way to do it. The GFW is well tuned for these types of blocks, so why invent more sophisticated ways and spend resources unnecessarily?

Thank you for your reply.

My situation is Vidalia have green icon and said 'Connnected to the Tor Network'
but i can't browse facebook/youtube website for a week now.
FireFox always said 'connection timed out'
However, i still can browse normal website with Tor.
so strange!?!
--------
oh, as i try to use Tor to download Freegate from author's website today.
It is ok with fine speed!!!

it seem current Tor problem effect only on Social Network website
facebook/hi5/twitter youtube etc. but not on freegate's website

so i think this problem may not concerned with GFW.
as political perspective, Freegate should be the 1st enemy of GFW.

Hello,

Is it possible to update ''tor-win32-mingw-creation.txt" (https://git.torproject.org/checkout/tor/master/doc/tor-win32-mingw-crea…) to MinGW-5.1.6 and OpenSSL 0.9.8l and make it work?

Thanks.

We're slowly working away from mingw altogether. The two largest issues with mingw are that they don't sign their packages and if you build a binary from source on the same system twice, you get different binary hashes.

We're moving towards Microsoft System Installer, and therefore Visual C. Mingw was always a stopgap for us on Windows. As we get people with more development experience in Windows system coding, using Visual C and the MSI is native to Windows, everything else is a bit foreign.

We've generally tried to use the native system package management system on each operating system. For Apple, this is dmg. Redhat/CentOS/Fedora, this is rpm. Debian and Ubuntu, this is debs.

We'd like to get a network installer working for all OSes, so all you have to do is to download a tiny bit of code, select the packages you want (tor, polipo, privoxy, vidalia, torbutton, etc) and let it just work. This network installer should also work over Tor using our secure updater framework.

This is a long way of saying, we're rather not update the mingw directions in favor of going with native tools on Windows operating systems.

I've used Tor's bridge feature several times and noticed some nodes like "moria" appearing with a duplicate called "bridge" with a different IP. Was this an attack? Are bridges safe to use? Normally I add 12 or more to the torrc file.

Another problem with bridges: sometimes there's a jam in transmission, a bottleneck, with one bridge going down and packets piling up and a slowdown occurs, why does this happen and take so many minutes to resolve?

any future auto-update feature should be opt-in only, we have a right to be paranoid. "It's open source!" does not apply to binaries which most people install.

Of course it's opt-in. The user should receive a prompt with "new version of (tor|vidalia|polipo|privoxy|torvm) available and let the user choose ignore, download, download and install, autoupdate".

We don't intend to force updates on anyone. If you're sufficiently paranoid, compile your own after reading all the diffs between versions and don't use any auto-updater at all.

"""We're moving towards Microsoft System Installer, and therefore Visual C. Mingw was always a stopgap for us on Windows. As we get people with more development experience in Windows system coding, using Visual C and the MSI is native to Windows, everything else is a bit foreign."""

I use MinGW on Windows. Its cumbersome compiling with this system, but if you use Eclipse for C and C++ you can create 'External Programs' that can effectively invoke the make commands for you, with any options required. This method reduces compiling to a few clicks in the environment, with no interaction with shells (and their associated commands) required.

At present, everything I use to get the job done is OpenSource. It takes one click to launch the dev environment and then one more to compile Tor, which means I can rapidly build a new version for testing.

I'm worried that if a move to Visual C is made, I will be required to use proprietary tools to compile Tor.

Will I have to go out and buy Visual C just to compile Tor ?

Frankly, we don't like this situation either. If MinGW signed their packages and releases, we'd feel much more comfortable continuing to use it. However, it will still be alien to the Windows world. MSI lets you upgrade individual components, which works well for the planned secure update infrastructure.

Another option is cygwin, but including the cygwin.dll with the bundles may raise interesting licensing issues. Until someone can do more research into it, we've been advised to not use cygwin.

You could publish instructions in replicating your build environment. I'm sure others would appreciate a "click to build tor" configuration.

Thanks you so much for a quick reply.

I am happy to publish details of the dev environment, but not sure where I should publish them ?

If you can give me a place to do so and a format that you'd like, i'll invest the time and try and bring this to the community.

If a move to Visual C is made, then my dev environment becomes obsolete I think.

Great idea though !!!

You could dump them in a comment here. Subscribe to and send an email to or-dev, email me at tor-assistants and I'll publish them somewhere in a document.

thanks again... im on the case...

The document is now complete and available here for general download.

http://docs.google.com/leaf?id=0B6YAzYus3pVYZWQ0MzVhOWItNjgwYi00NWYxLTk…

Please post in here if there are any questions, or criticisms.

Regards.

I have updated the document to reflect building Tor 0.2.2.7 under automake v2.6.x.

There is a specific section on how to update automake from the vanilla MinGWv5.16 install with MSYSv1.0.0.11 and MSysDTKv1.0.1.

I'll upload the document if its likely to be of any use... ?

I strictly recommend not to hold back until you earn big sum of cash to buy goods! You can get the loans or just secured loan and feel fine