vidalia

Tor Browser Bundle 1.1.11 Released

phobos — Tue, 31 Mar 2009 12:19:52 -0700

An updated Tor Browser Bundle is released to address the Firefox 3.0.7 security issues. It includes:

Update Firefox to 3.0.8
Add Italian language bundles
Update Torbutton to 1.2.1
Update Vidalia to 0.1.12

This updated TBB can be downloaded from https://www.torproject.org/easy-download as the "zero install bundle".

Technology Preview: Marble and Vidalia-0.2.0

phobos — Sat, 28 Mar 2009 18:21:39 -0700

One of the most requested upgrades to Vidalia is a better map of the world. We looked into a few different technologies and decided on KDE's Marble interface. Marble enables an accurate mapping of nodes according to their geolocation, allows for future enhancements such as "click a country to start or end your Tor circuit", and plugins for extra data views. This also gives us the ability to use Qt's Webkit browser to display custom information about nodes, circuits, or anything else in a pop-up window. An anonymous funder covered the costs involved in developing this feature. We thank them for their support.

I've attached some screenshots to this blog post. You can download the relevant packages from the Vidalia website. If you want marble-enabled Vidalia, look for -marble- in the file name. Please report bugs on Vidalia's Bug Tracker.

As of this release, there are now two branches of Vidalia, stable and alpha. The first release of the alpha branch is Vidalia 0.2.0. The stable branch is at Vidalia 0.1.12.

One last big change for OS X users is the drag and drop installer. There is no migration of old settings to new, nor do we clean up the old installs in /Library/Tor, /Library/Vidalia, /Library/Torbutton, /Library/Privoxy, etc. Follow these instructions for how to remove the old vidalia-tor bundles from your computer if you want to completely test this alpha branch of Vidalia. We will figure out a better way to do this in the near future.

Remember, this is a technology preview. However, OS X installs are migrating to drag and drop. I've solely used Vidalia 0.2.0 and drag-and-drop installer for 3 months now. I even previously blogged about it.

Additional changes in alpha Vidalia 0.2.0:

Qt 4.5.0 is used for Win32 and OS X Universal packages.
We've switched from the Nullsoft Installer to the Microsoft System Installer (msi) for better integration with Microsoft Windows.
There are non-Marble and Marble-enabled packages for Win32 and OS X Universal. OS X PowerPC based on OS X 10.3.9 isn't supported by Qt 4.5.x, therefore Marble-enabled Vidalia is not available
Add support for changing UI languages without having to restart Vidalia.
Add preliminary support for using the KDE Marble widget for the network map. It's currently a compile-time option and is disabled by default.
Add support for displaying Tor's plaintext port warnings. Also gives the user the option to disable future warnings.
Add an interface for displaying the geographic distribution of clients who have recently used a bridge operator's relay.
Add tooltips to tree items in the help browser's table of contents. Some of the help topic labels are a bit long.
Switch to a simpler About dialog and move the license information to a separate HTML-formatted display.
Switch to a simpler drag-and-drop installer in the OS X bundles.
Switch to an MSI-based installer on Windows.
Clear the list of default CA certificates used by QSslSocket before adding the only one we care about. Suggested by coderman.
Support building with Visual Studio again.
Add a Debian package structure from dererk.
Updated Albanian, Czech, Finnish, Polish, Portuguese, Romanian, Swedish, Turkish and many other translations.

Tor Browser Bundle 1.1.9 Released

phobos — Wed, 18 Feb 2009 21:21:58 -0800

Tor Browser Bundle 1.1.9 is released.

It includes the following changes:

Update Tor to 0.2.1.12-alpha
Update Firefox to 3.0.6
Update Vidalia to 0.1.11

It's available at https://www.torproject.org/torbrowser/

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.

September 2008 Progress Report

phobos — Tue, 14 Oct 2008 17:07:12 -0700

Releases
Vidalia 0.1.9 (released September 2) fixes a big pile of bugs and inconveniences in the earlier releases. This new release marks the first "stable" release of Vidalia, in that we have now branched into a stable (0.1.x) branch and a development (0.2.x) branch.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.9/CHANG...

Tor 0.2.0.31 (released September 3) addresses two potential anonymity issues, starts to fix a big bug we're seeing where in rare cases traffic from one Tor stream gets mixed into another stream, and fixes a variety of smaller issues.
http://archives.seul.org/or/announce/Sep-2008/msg00000.html

Tor 0.2.1.6-alpha (released September 30) further improves performance and robustness of hidden services, starts work on supporting per-country relay selection, and fixes a variety of smaller issues.
http://archives.seul.org/or/talk/Oct-2008/msg00093.html

Circumvention Enhancements
From the Vidalia 0.1.9 ChangeLog:
"Correct the location of the simplified Chinese help files so they will actually load again."

From the Tor 0.2.1.6-alpha ChangeLog:
"Start work to allow node restrictions to include country codes. The syntax to exclude nodes in a country with country code XX is "ExcludeNodes {XX}". Patch from Robert Hogan. It still needs some refinement to decide what config options should take priority if you ask to both use a particular node and exclude it."
This feature should allow users in China to specify that they don't want to enter (and/or exit) in China, which in theory could provide stronger security for them.

From the Tor 0.2.1.6-alpha ChangeLog:
"Allow ports 465 and 587 in the default exit policy again. We had rejected them in 0.1.0.15, because back in 2005 they were commonly misconfigured and ended up as spam targets. We hear they are better locked down these days."
This feature lets people use GMail with Tor in more flexible ways. This approach is especially important for people trying to send email in certain configurations when their network wants to block or monitor them.

From the Tor 0.2.1.6-alpha ChangeLog:
"Provide circuit purposes along with circuit events to the controller."
This change will allow Vidalia to mark circuits in its graphical interface, so users don't get confused about why Tor is building strange circuits in the background when it's really just doing encrypted directory updates.

Matt and Andrew fixed a bug in the Vidalia bundle installer where it tried to detect if Firefox was installed, and unclick the "install Torbutton" option if not, but it didn't detect right. Now if Firefox is missing we put up a warning explanation about how you really ought to be using Tor with Firefox.

We also finally started working on a fix for the Vidalia bug where if Vidalia launches Tor and then crashes later, when you start Vidalia again it'll cryptically ask for your control password.
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TorPasswordPro...
The first fix is to add a "reset" button to the cryptic message, that kills Tor for you and restarts it, and a "help" button that explains what's going on. These will be out in the next development Vidalia release, hopefully in October.

Camilo Viecco submitted a patch for our RPM spec (build) file to let us build Red Hat / SuSE packages for 64-bit architectures. Andrew included these patches in 0.2.1.6-alpha.

Advocacy
Steven Murdoch taught a lecture at the FIDIS/IFIP Brno Summer School in the Czech Republic.
http://www.buslab.org/SummerSchool2008/
The presentation was on anti-censorship in general especially on Tor. The students seemed to be interested so he encouraged them to look at Tor and see if there is anything they'd like to work on. We will see if anything comes from that.

We've also been discussing creating a Facebook application, for allowing relay operators to show off that they are running a Tor relay and hopefully encourage more to do so. We think this is a good enough idea to try building it, so Steven has started to do so. As well as adding bling to a user's profile, it would also allow us to map the network of node operators. This is one of the more promising research fields to resist Sybil attacks, see e.g.
"A Sybil-proof one-hop DHT, Chris Lesniewski-Laas"
http://pdos.csail.mit.edu/papers/sybil-dht-socialnets08.pdf

Steven had a related story regarding host-based security from his trainings in Kyrgyzstan and Poland. See also
http://www.f-secure.com/weblog/archives/00001494.html

Jacob was in a story by Declan about Internet Traceback plans:
"The Chinese Government, the NSA, Verisign and the ITU are getting together to trace users"
http://news.cnet.com/8301-13578_3-10040152-38.html

The current issue of Make Magazine has an article on how to use Tor:
http://www.make-digital.com/make/vol15/?pg=102

Helped Kasimir add new Tor controller features so Torstatus can switch to using the v3 directory system:
http://trunk.torstatus.kgprog.com/

Ease of Use
Steven is 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

Jacob Appelbaum worked on a set of instructions for rebranding Firefox, if we decide that we need to call the browser that ships in the Tor Browser Bundle something other than "Firefox". The instructions aren't complete, for example because we need more replacement logos.
https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/branding/
It looks like the process of rebranding Firefox 3 is much more straightforward. We have "move to FF3" on our TBB roadmap.

Work by Martin and Kyle on the Tor VM project continues. We have a very early prototype available now:
http://peertech.org/files/demo/testinfo.html
and we hope to give it some more testing and better documentation in the coming months.

Scalability
Joel Reardon, Ian Goldberg's student at Waterloo, has finished the final version of his thesis "Improving Tor using a TCP-over-DTLS tunnel":
http://uwspace.uwaterloo.ca/handle/10012/4011
We funded this research (along with 4x matching funding from MITACS in Canada) in the hopes that it would move us close enough to being able to switch to a UDP design that we can put it on the Tor development roadmap at some point. Many large challenges remain, but this is also promising work in that it shows that we can expect very serious performance improvements if we go this route.

We've started hunting more thoroughly for solutions to Bug 676:
https://bugs.torproject.org/flyspray/index.php?do=details&id=696
The issue is that some of the v3 directory authorities are keeping bad statistics on uptimes and stability of relays, which means they are not assigning the Stable or Guard flag correctly to them. The result is that the networkstatus consensus mislabels them, and clients end up not choosing relays or circuits in an efficient manners. This bug not only results in bad performance for clients, but also results in overloading some relays, leading to worse performance.

From the Tor 0.2.1.6-alpha ChangeLog:
"Implement most of Proposal 152: allow specialized servers to permit single-hop circuits, and clients to use those servers to build single-hop circuits when using a specialized controller. Patch from Josh Albrecht. Resolves feature request 768."
"Fixed some memory leaks -- some quite frequent, some almost impossible to trigger -- based on results from Coverity."

Several security- and integrity-related bugfixes from Tor 0.2.0.31:
"Make sure that two circuits can never exist on the same connection with the same circuit ID, even if one is marked for close. This is conceivably a bugfix for bug 779. Bugfix on 0.1.0.4-rc."
"Relays now reject risky extend cells: if the extend cell includes a digest of all zeroes, or asks to extend back to the relay that sent the extend cell, tear down the circuit. Ideas suggested by rovv."
"If not enough of our entry guards are available so we add a new one, we might use the new one even if it overlapped with the current circuit's exit relay (or its family). Anonymity bugfix pointed out by rovv."

July 2008 Progress Report

phobos — Sun, 17 Aug 2008 20:11:31 -0700

Releases:

Torbutton 1.2.0rc5 (released July 6) provides 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. This version also features Firefox 3 cookie jar support, and support for storing cookie jars in memory.
http://archives.seul.org/or/talk/Jul-2008/msg00026.html

Vidalia 0.1.6 (released July 8) fixes a bug introduced in 0.1.3 that could cause excessive CPU usage or crashing on some platforms; continues to prepare Vidalia's strings for easier translation; adds a Romanian GUI and installer translation; and updated the Farsi, Finnish, French, German, and Swedish translations.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.6/CHANG...

Tor 0.2.0.29-rc (released July 8) fixes two big bugs with using bridges, fixes more hidden-service performance bugs, and fixes a bunch of smaller bugs.
http://archives.seul.org/or/talk/Jul-2008/msg00038.html

Torbutton 1.2.0rc6 (released July 12) features fixes for a nasty history loss bug, an exception during Tor toggle, javascript being disabled in some tabs, better pref handling, and more.
http://archives.seul.org/or/talk/Jul-2008/msg00049.html

Tor 0.2.0.30 (released July 15) is the first stable release of the 0.2.0.x branch. The previous stable branch (0.1.2.x) went stable in April of 2007. We are still waiting for Torbutton and Vidalia to stabilize before announcing the Windows and OS X packages on the or-announce announcements
list. We expect to do that in August.

Tor Browser Bundle 1.1.1 (released July 20) updates Vidalia to release 0.1.6, updates Pidgin Portable to 2.4.3, updates Pidgin OTR plugin to 3.2, updates Tor to 0.2.1.2-alpha, updates Torbutton to 1.2.0rc6, and sets TZ=UTC environment variable in RelativeLink (needed by Torbutton).
https://svn.torproject.org/svn/torbrowser/trunk/README

Torbutton 1.2.0 (released July 30) is finally a stable release for the new Torbutton tree that includes application-level privacy protections.
https://svn.torproject.org/svn/torbutton/trunk/src/CHANGELOG

From the Tor 0.2.0.29-rc ChangeLog:
"When a hidden service was trying to establish an introduction point, and Tor had built circuits preemptively for such purposes, we were ignoring all the preemptive circuits and launching a new one instead. Bugfix on 0.2.0.14-alpha."
"When a hidden service was trying to establish an introduction point, and Tor *did* manage to reuse one of the preemptively built circuits, it didn't correctly remember which one it used, so it asked for another one soon after, until there were no more preemptive circuits, at which point it launched one from scratch. Bugfix on 0.0.9.x."

The upcoming 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

Proposals:

Proposal 145 (Separate "suitable as a guard" from "suitable as a new guard") suggests one approach for separating the role of "is still useful as an entry guard" from "should be an option when choosing a new entry guard". This step will help us load balance over the network better.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/145-newguard...

Proposal 146 (Add new flag to reflect long-term stability) discusses how to ship the Tor client with a set of alternate sources for initial bootstrap directory information. We already have this feature in Tor 0.2.0.x, called the "fallback consensus", but we never enabled it because the Tor client would spend too long trying directory mirrors that were long since gone from the network. This proposal moves us closer to being able to distinguish the more long-term reliable mirrors.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/146-long-ter...

Proposal 147 (Eliminate the need for v2 directories in generating v3 directories) helps wean us off of needing the old deprecated v2 directory design. Currently we only use it to give advance warning to the v3 authorities about relays that haven't heard about yet, so they can fetch information about those relays before the time arrives to make an official vote about their state.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/147-prevotin...

Proposal 148 (Stream end reasons from the client side should be uniform) describes a simple fix for a potential anonymity flaw in Tor's core protocol for passing explanations from one end of a Tor circuit to the other when an application stream ends.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/148-uniform-...

Proposal 149 (Using data from NETINFO cells) starts talking about how to make use of the timestamp and IP address listed in Tor's new NETINFO cells. In theory we can use them to decide if our clock is skewed, and to decide if a traffic analysis man-in-the-middle attack is happening against us. In practice it appears more complex than we expected.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/149-using-ne...

Proposal 150 (Exclude Exit Nodes from a circuit) allows users to specify which relays should never be used as the last (exit) hop in a circuit. We took the proposal one step further and allowed users to also specify IP addresses and netmasks for which relays to avoid in the exit position.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/150-exclude-...

Proposal 151 (Improving Tor Path Selection) is a draft proposal to implement the results of Fallon Chen's Google Summer of Code project. Her plan is to measure the expected time it takes to establish a circuit, and then abandon circuits that take significantly longer than that to form. The assumption is that circuits that take a long time to set up will generally have unacceptably high latency as well.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/151-path-sel...

Proposal 154 (Automatic Software Update Protocol) starts the discussion of how to let Vidalia automatically manage updates for Tor, Polipo, Vidalia, etc. This is very important for keeping users up to date with respect to security and stability fixes. We will especially aim to do the updates over Tor, a) for privacy, and b) so users who are blocked from the Tor website will still be able to upgrade seamlessly.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/154-automati...

Research:

Karsten Loesing's report on 7 ways to improve the performance and robustness of Tor hidden services:
http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf

Four new research papers on Tor came out in July:
http://freehaven.net/anonbib/#loesing2008performance
http://freehaven.net/anonbib/#improved-clockskew
http://freehaven.net/anonbib/#mccoy-pet2008
http://freehaven.net/anonbib/#danezis-pet2008

We continued evaluating the TBB footprints here:
https://svn.torproject.org/svn/torbrowser/trunk/docs/traces.txt

In particular, we added a new "Registry modifications" section to that file, describing some new traces that appear to be left behind after operating Tor Browser Bundle, even from the USB key. One of the most worrying is the "user assist" registry key that gets set, and (incredible as it sounds) is obfuscated by rot-13 before being set.

Ease of Use:

The first Incognito (Gentoo-based Tor LiveCD) release of 2008 is also nearing completion, and we expect to see it released in August.

Finally, we contracted to start work on the Tor VM project. The idea is to run a Linux kernel and a Tor client inside a thin VM (like QEMU) on Windows, and then transparently intercept outgoing connections and redirect them into Tor. This approach will a) make proxy-avoiding side-channel and sidejacking attacks less devastating, and b) isolate the Tor client from the rest of the OS to provide a more robust security approach. Current design document is under development at
https://svn.torproject.org/svn/torvm/trunk/doc/design.html

Getting Tor:

We have established our "gettor" email auto-responder script that lets people mail gettor@torproject.org and retrieve a copy of Tor from their mailbox. We still need to ponder more usability issues, such as translation.
https://www.torproject.org/finding-tor

We have also automated the process of checking Tor website mirrors: there's a new update-mirrors.pl script in the website directory that generates a list of mirrors ordered by when they last synced with the main website.
https://www.torproject.org/mirrors

Translations:

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

We revised our translation tutorial here:
https://www.torproject.org/translation-portal

Users continued to submit updated translations for many different languages.

We continued enhancements to the Chinese and Russian Tor website
translations. We added Vidalia, Torbutton, and website translations
into Farsi.

We also added the strings for Vidalia's installer; this required writing several scripts to convert from the "nsh" (nullscript installer language) format to the "po" (preferred by Pootle) format and back.

Vidalia Logo Design Contest

edmanm — Fri, 15 Aug 2008 17:39:06 -0700

We are currently sponsoring a design contest to create a new logo for Vidalia. The winner of the contest will receive a $250 USD cash prize. The firm deadline for contest submissions is August 22, 2008.

The logo will be used in the Vidalia software and related installers, on the website, and on t-shirts. Designers are free to choose any fonts, color combinations, and symbol options you like (no onions, though, please). The logo must include a symbolic component that is recognizable by itself without the name "Vidalia" next to it. See the contest page for more details. If you have further questions, please email contest@vidalia-project.net or stop by #vidalia on irc.oftc.net.

Here's the overall timeline for the contest:

August 15 – August 22: Entries may be submitted at the Worth1000 contest page.
August 23 – August 24: Everyone is welcome to review the submissions received and vote on their favorite design. Even if you didn't submit anything, you can still vote!
August 25 – August 31: The final winner will be announced by August 31 at the latest.

Late entries will not be eligible for the cash prize, so be sure to get your
submission in by August 22!

False Positives in 0.2.0.30: RISING found Trojan.PSW.Win32.Undef.adp

phobos — Tue, 05 Aug 2008 20:09:46 -0700

I've noticed a few comments about a Chinese anti-virus program, RISING, reporting that Vidalia.exe and Privoxy.exe are infected with Trojan.PSW.Win32.Undef.adp. In both cases, I suspect that RISING is reporting false positives. These executables as packaged and available on the Tor download page are not infected.

I've looked at the MD5 and SHA-1 sums of these programs as included in the Vidalia bundle and they match what the source packages produce as executables. The privoxy.exe included in the bundles is the exact same one as found at the Sourceforge Privoxy Download Page.

The Vidalia.exe is the same as the one included in the Vidalia Download Page.

Feel free to confirm this is true for you. Better yet, let us know if these individual packages (Vidalia.exe from Vidalia and Privoxy.exe from Sourceforge) also show up as infected.

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.

May 2008 Progress Report

phobos — Tue, 24 Jun 2008 20:39:17 -0700

Tor 0.2.0.26-rc (released May 13) fixes a major security vulnerability caused by a bug in Debian's OpenSSL packages. All users running any 0.2.0.x version should upgrade, whether they're running Debian or not.
http://archives.seul.org/or/talk/May-2008/msg00048.html

Vidalia 0.1.3 (released May 25) adds a hidden service configuration UI designed and implemented by Domenik Bork, as well as a few other bugfixes.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.3/CHANG...

The Tor Browser Bundle 1.0.2 (released May 3) and 1.0.3 (released May 16) include upgraded versions of Tor, Vidalia, Torbutton, and Firefox.

We added three new part-time developers in May. We hired Matt Edman as a part-time employee at the beginning of May, to work on Vidalia maintenance, bugfixes, and new features. We also are funding Karsten Loesing to work on making hidden service rendezvous and interaction faster, and Peter Palfrader to work on lowering the overhead of directory requests, especially during bootstrap, which should directly improve the experience for Tor users on modems or cell phones.

Google has agreed to give us some funding to work on auto-update for Windows. Our plan is for Vidalia to look at the majority-signed network status consensus to decide when to update and to what version (Tor already lists what versions are considered safe, in each network status document). We should actually do the update via Tor if possible, for additional privacy, and we need to make sure to check package signatures to ensure package validity. Last, we need to give the user an interface for these updates, including letting her opt to migrate from one major Tor version to the next.

We continued enhancements to the Chinese and Russian Tor website translations. Vidalia also added a Turkish translation.

From the Vidalia 0.1.3 ChangeLog:
"If we're running Tor >= 0.2.0.13-alpha, then check the descriptor annotations for each descriptor before deciding to do a geoip lookup on its IP address. If the annotations indicate it is a special purpose descriptor (e.g., bridges), then don't do the lookup at all."

"Remove the 'Run Tor as a Service' checkbox. Lots of people seem to be clicking it even though they don't really need to, and we end up leaving them in a broken state after a reboot."

"Only display the running relays in the big list of relays to the left of the network map. Listing a big pile of unavailable relays is not particularly useful, and just clutters up the list."

We worked toward a Torbutton 1.2.0rc1 release candidate, which will include support for Firefox 3 along with a huge pile of privacy-related bugfixes.

We spent much of the first half of May dealing with a surprise massive security vulnerability in a crypto library that comes with Debian:
http://archives.seul.org/or/announce/May-2008/msg00000.html

You can read a more detailed explanation of the effects of the flaw here:
https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mea...

Part of dealing with the flaw meant doing some quick design work so we could let new Tor users be safe without making it so old Tor users were cut off from the network:
https://www.torproject.org/svn/trunk/doc/spec/proposals/136-legacy-keys....

Sometime in late June or early July we will disable this workaround, meaning all the 0.2.0.x users who haven't upgraded yet will be cut off.

We are preparing for the Tor gathering at the Privacy Enhancing Technologies Symposium in Leuven in July. This is looking like it will be the largest physical gathering of Tor developers ever -- main developers attending include Roger Dingledine, Nick Mathewson, Jacob Appelbaum, Mike Perry, Matt Edman, Steven Murdoch, and Karsten Loesing; Tor researchers include Paul Syverson and Ian Goldberg; and we'll have 5 of our 7 Google Summer of Code students there as well.
https://blog.torproject.org/events/roger%2C-nick%2C-steven%2C-matt%2C-ka...
http://petsymposium.org/2008/program.php

The upcoming TBB release in June will include optional instant messaging support via Pidgin + Off-The-Record Messaging; replace the startup batch script with an actual application (named RelativeLink), so TBB now has a helpful Tor icon rather than an ugly batch file icon; and optionally support using WinRAR to produce a self-extracting split bundle.

We now have a more thorough set of TBB build instructions:
https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL

We also documented the build and deploy process for a new TBB version:
https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/DEPLOYMENT

We finished integrating a UPnP library into Vidalia. This feature allows users who want to set up a Tor relay but don't want to muck with manual port forwarding on their router/firewall to just click a button and have Vidalia interact with their router/firewall automatically. This approach won't work in all cases, but it should work in at least some. The upcoming Vidalia 0.1.4 (scheduled for June) 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 spent May hunting for a better online translation option, since Launchpad (intended to be used for Vidalia translation) has an ugly interface and can't handle our file formats well, and Babelzilla (intended to be used for Torbutton translation) artificially limited the number of concurrent translators we could have.

In early June we hit upon Pootle, which is a translation server that we host, as opposed to a shared web service that other organizations host. We've set up a test server at http://translation.torproject.org/ and imported strings for Vidalia, Torbutton, and Torcheck. We hope to have a lot more to show here in June.