vidalia bundle

Vidalia 0.2.3 released

phobos — Thu, 03 Sep 2009 06:48:53 -0700

On August 27th, we released Vidalia 0.2.3. This fixes some more bugs with "Who has used by bridge" functionality and switches to Qt signals for event handling.

The updated Vidalia packages can be found at https://www.torproject.org/vidalia

The changes are:

Create the data directory before trying to copy over the default
Vidalia configuration file from inside the application bundle on Mac
OS X. Affects only OS X drag-and-drop installer users without a
previous Vidalia installation.
Change all Tor event handling to use Qt's signals and slots mechanism
instead of custom QEvent subclasses.
Fix another bug that resulted in the "Who has used my bridge?" link
initially being visible when the user clicks "Setup Relaying" from
the control panel if they are running a non-bridge relay.
(Ticket #509, reported by "vrapp")
Always hide the "Who has used my bridge?" link when Tor isn't running,
since clicking it won't return useful information until Tor actually
is running.

Major changes to OS X Vidalia Bundle with 0.2.2.1-alpha

phobos — Wed, 02 Sep 2009 18:15:42 -0700

As highlighted in the 0.2.2.1-alpha release notes, the Vidalia Bundle for OS X includes some major changes. Many of these are for ease of use and user experience improvements. The release of OS X 10.6 (Snow Leopard) gave me a fine excuse to release the improvements.

It's best to un-install Tor/Vidalia and then install this new bundle; rather than upgrade. If you want to upgrade, you'll need to update the paths for Tor and Polipo in the Vidalia Settings window.

There has been a lot of testing since this test release of the drag and drop installer for OS X in January. The main goal was to make installation far easier, less error prone, and keep all of the bundle in a single directory for easier configuration and un-installation.

The changes are:

- Upgrade Vidalia from 0.1.15 to 0.2.3 in the Windows and OS X installer bundles. See https://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.2.3/CHAN... for details of what's new in Vidalia 0.2.3.
- OS X Vidalia Bundle: move to Polipo 1.0.4 with Tor specific configuration file, rather than the old Privoxy.
- OS X Vidalia Bundle: Vidalia, Tor, and Polipo are compiled as x86-only for better compatibility with OS X 10.6, aka Snow Leopard.
- OS X Vidalia Bundle: The multi-package installer is now replaced by a simple drag and drop to the /Applications folder. This change occurred with the upgrade to Vidalia 0.2.3.

Tor 0.2.2.1-alpha released

phobos — Wed, 02 Sep 2009 12:32:58 -0700

Tor 0.2.2.1-alpha disables ".exit" address notation by default, allows
Tor clients to bootstrap on networks where only port 80 is reachable,
makes it more straightforward to support hardware crypto accelerators,
and starts the groundwork for gathering stats safely at relays.

https://www.torproject.org/download

We've been improving our packages and bundles:
Packaging changes:

Upgrade Vidalia from 0.1.15 to 0.2.3 in the Windows and OS X
installer bundles. See
https://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.2.3/CHAN...
for details of what's new in Vidalia 0.2.3.
Windows Vidalia Bundle: update Privoxy from 3.0.6 to 3.0.14-beta.
OS X Vidalia Bundle: move to Polipo 1.0.4 with Tor specific
configuration file, rather than the old Privoxy.
OS X Vidalia Bundle: Vidalia, Tor, and Polipo are compiled as
x86-only for better compatibility with OS X 10.6, aka Snow Leopard.
OS X Tor Expert Bundle: Tor is compiled as x86-only for
better compatibility with OS X 10.6, aka Snow Leopard.
OS X Vidalia Bundle: The multi-package installer is now replaced
by a simple drag and drop to the /Applications folder. This change
occurred with the upgrade to Vidalia 0.2.3.

Changes in version 0.2.2.1-alpha - 2009-08-26
Security fixes:

Start the process of disabling ".exit" address notation, since it
can be used for a variety of esoteric application-level attacks
on users. To reenable it, set "AllowDotExit 1" in your torrc. Fix
on 0.0.9rc5.

New directory authorities:

Set up urras (run by Jacob Appelbaum) as the seventh v3 directory
authority.

Major features:

New AccelName and AccelDir options add support for dynamic OpenSSL
hardware crypto acceleration engines.
Tor now supports tunneling all of its outgoing connections over
a SOCKS proxy, using the SOCKS4Proxy and/or SOCKS5Proxy
configuration options. Code by Christopher Davis.

Major bugfixes:

Send circuit or stream sendme cells when our window has decreased
by 100 cells, not when it has decreased by 101 cells. Bug uncovered
by Karsten when testing the "reduce circuit window" performance
patch. Bugfix on the 54th commit on Tor -- from July 2002,
before the release of Tor 0.0.0. This is the new winner of the
oldest-bug prize.

New options for gathering stats safely:

Directories that set "DirReqStatistics 1" write statistics on
directory request to disk every 24 hours. As compared to the
--enable-geoip-stats flag in 0.2.1.x, there are a few improvements:
1) stats are written to disk exactly every 24 hours; 2) estimated
shares of v2 and v3 requests are determined as mean values, not at
the end of a measurement period; 3) unresolved requests are listed
with country code '??'; 4) directories also measure download times.
Exit nodes that set "ExitPortStatistics 1" write statistics on the
number of exit streams and transferred bytes per port to disk every
24 hours.
Relays that set "CellStatistics 1" write statistics on how long
cells spend in their circuit queues to disk every 24 hours.
Entry nodes that set "EntryStatistics 1" write statistics on the
rough number and origins of connecting clients to disk every 24
hours.
Relays that write any of the above statistics to disk and set
"ExtraInfoStatistics 1" include the past 24 hours of statistics in
their extra-info documents.

Minor features:

New --digests command-line switch to output the digests of the
source files Tor was built with.
The "torify" script now uses torsocks where available.
The memarea code now uses a sentinel value at the end of each area
to make sure nothing writes beyond the end of an area. This might
help debug some conceivable causes of bug 930.
Time and memory units in the configuration file can now be set to
fractional units. For example, "2.5 GB" is now a valid value for
AccountingMax.
Certain Tor clients (such as those behind check.torproject.org) may
want to fetch the consensus in an extra early manner. To enable this
a user may now set FetchDirInfoExtraEarly to 1. This also depends on
setting FetchDirInfoEarly to 1. Previous behavior will stay the same
as only certain clients who must have this information sooner should
set this option.
Instead of adding the svn revision to the Tor version string, report
the git commit (when we're building from a git checkout).

Minor bugfixes:

If any the v3 certs we download are unparseable, we should actually
notice the failure so we don't retry indefinitely. Bugfix on
0.2.0.x; reported by "rotator".
If the cached cert file is unparseable, warn but don't exit.
Fix possible segmentation fault on directory authorities. Bugfix on
0.2.1.14-rc.
When Tor fails to parse a descriptor of any kind, dump it to disk.
Might help diagnosing bug 1051.

Deprecated and removed features:

The controller no longer accepts the old obsolete "addr-mappings/"
or "unregistered-servers-" GETINFO values.
Hidden services no longer publish version 0 descriptors, and clients
do not request or use version 0 descriptors. However, the old hidden
service authorities still accept and serve version 0 descriptors
when contacted by older hidden services/clients.
The EXTENDED_EVENTS and VERBOSE_NAMES controller features are now
always on; using them is necessary for correct forward-compatible
controllers.
Remove support for .noconnect style addresses. Nobody was using
them, and they provided another avenue for detecting Tor users
via application-level web tricks.

Investigating http proxy performance with Tor

phobos — Wed, 19 Aug 2009 14:57:17 -0700

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.

So I did it myself, in a loose manner. I wanted to quantify "feels faster".

The raw data from all the testing is :

Tamper Data as xml,
proxy config files,
and results in a spreadsheet.

This is all contained in http://freehaven.net/~phobos/polipo-v-privoxy.tar.gz {.asc). There is a README as well. And yes, the ruby script is a quick and dirty hack.

I tested a few scenarios:

1) native polipo and privoxy without using Tor.
2) polipo and privoxy forwarding to Tor localhost:9050.
3) firefox socks5 direct to Tor via localhost:9050.

The summary of results:

Native polipo is 54.5% faster on average than native privoxy. This could be due to polipo's caching, http 1.1 pipelining, and it can serve bits as fast as they come in from the network. Privoxy needs to load the whole page, scan it, and then send it to the client. Even if privoxy filtering is disabled, it still works the same way.
Polipo caching shines with Tor usage. Performance is still about 40% faster with polipo than privoxy. Common images are cached, and served from the memory cache in single-digit millisecond ranges. Privoxy needs to wait for Tor to wholly deliver the bits. Caching is faster, this we know already. However, from a user perspective, it's just faster to load pages.
socks5 in Firefox 3.5.2 did better than I expected. It was about twice as slow as polipo, but still twice as fast as privoxy. I chalk this up to the tor circuit variability more than anything else.
I tried testing a click to a second page to see how much polipo caching helps people reading different pages on the same site. It helps, but not as much as I expected. Polipo ranged from slower than privoxy to 40-100% faster. Too much variability to make a real determination.

Caveats: Testing under tor is highly variable. I used the same circuits for both the polipo and privoxy tests to minimize variability. However, I can't control node load and congestion.

Out of 23 get requests for the Torproject.org/index.html.en, 17 are for the country flags. Perhaps we should load these last at the bottom of the page, or do something else to speed up the torproject page load.

As I was doing this, I kept thinking of other ways to do it better;

time requests and bits between tor, the http proxy, and the browser. How long does each request take to get from the browser, to the proxy, to tor and back across each layer? how much latency does each piece of software add to the request and delivery?
automate testing and let it run on a normal tor client over weeks. This will average out tor network variability and show "typical" user experience.
Pick a sampling of the top 100 websites by visits worldwide and measure their performance with the three methods, fully instrumented as in #1.
Do user experience measurements. Pay/ask/bribe people to sit in front of a computer, video record their browsing and feedback, and ask for a rating of each configuration (socks5, polipo, privoxy, and a placebo).
re-run #2 and run gcov to watch the code paths used in each piece of software, and figure out what can be optimized for performance.
test various "private browsing modes" through tor to see which browser is faster; firefox, safari, chromium, torfox, or torora.
how can we better tune polipo caching dynamically based on system ram config? Does having 1GB of cache provide significant benefits over the default?

I'm sure there are lots of things wrong with my measurements, minimal analysis, and results.

Constructive criticism is welcome.

Experimental OS X Drag and Drop Vidalia Bundle Installer

phobos — Tue, 13 Jan 2009 08:26:22 -0800

I asked for community feedback in this post about drag and drop installation of the Vidalia bundle for Apple's OS X. In working with the Vidalia team, we now have a drag and drop installer. This is experimental. It's designed for a clean install. It won't migrate your settings, nor will it configure anything for you. Upon installing, your milk may sour and your salt may run off with your pepper. Now that the disclaimers are over, here's what it contains and does do for you.

It includes Universal binaries for:

Vidalia version 0.2.0-svn r3425
Polipo 1.0.4 configured to use Tor as a socksproxy
Tor 0.2.1.10-alpha compiled with prefix and bindir set to /Applications/Vidalia.app

You can download them along with the pgp signature and the SHA-1 hash. **Update 2009-01-22 changed packages to r3467 of Vidalia and updated Tor to 0.2.1.11-alpha.

It's a self-contained disk image that has 3 items. The Vidalia.app package, a README.txt, and a folder full of licenses. There is a pretty background for the disk image courtesy of dr|z3d, and a link to the /Applications folder. And while everything is in a simple dmg file, this is not a Tor Browser Bundle for OS X. Running the applications out of the dmg may work, but OS X writes to plist files, caches, and other things all over the installed system. Please wait until we can properly create a TBB for OS X; for this is not it. However, if you are interested in helping out with a TBB for OS X, we're happy to have you help.

Installation is literally this: "Drag the Vidalia icon to the Applications folder". Boom. Done. Vidalia, Tor, and Polipo are installed. Go to your Applications folder and double-click the Vidalia icon. Everything should work out of the box. All bets are off if you have a pre-configured Tor, Vidalia, Polipo, or Privoxy.

Here is a running CHANGELOG of what's new in Vidalia 0.2.0-svn. One of the changes is that your Vidalia data directory is no longer ~/.vidalia/ but ~/Library/Vidalia. If you don't have a vidalia.conf in ~/Library/Vidalia, there is a sample vidalia.conf in /Applications/Vidalia.app/Contents/Resources that is copied to ~/Library/Vidalia to make this bundle work.

The changes to Polipo are documented. See the README file for some details.

The only change to Tor are the parameters passed to configure:
"CFLAGS="-O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk"
CONFDIR=/Applications/Vidalia.app
./configure --prefix=/Applications/Vidalia.app --bindir=/Applications/Vidalia.app
--sysconfdir=/Library --disable-dependency-tracking". And edit the Makefile to remove the tests for /Library/Tor.

The goal is to make it easier for users to install the Vidalia Bundle and get Tor working. Using Vidalia to configure Tor is recommended. I don't know if this is the final direction, but enough people have trouble installing and configuring our packages in OS X, this is worth a test.

I look forward to your feedback. Thanks!

OS X Vidalia Bundle Thoughts

phobos — Wed, 29 Oct 2008 19:43:41 -0700

A few weeks ago, I watched some non-technical OS X users attempt to install the Vidalia-Tor Bundle. Many of them tried to drag the installation package to Applications. A few were surprised it required an installation at all.

In Vidalia trunk I committed a different way to install Vidalia, Tor, and Polipo. In this new dmg, you just open it up and drag the Vidalia icon into Applications. You now have Tor, Vidalia, and Polipo pre-configured and running completely out of Applications. While this works well for users that never installed Tor/Vidalia before, it doesn't work so well for existing installations.

Is it smart to think users will un-install their existing Vidalia/Tor bundle before using the drag and drop installation method? My inclination is that it isn't smart. This installation method also removes the ability to automatically install Torbutton for Firefox.

In comparison, the current method is to ship a dmg which contains a metapackage. This metapackage contains a few scripts to run pre and post-installation, which do smart things to save current configurations, upgrade existing software binaries, and try to install Torbutton for Firefox. In general, this method has worked well for most users. I've heard from enough people to know they tried to drag and drop the metapackage into Applications at first, and when that didn't work, double-clicked the metapackage to start the installer.

I'm now leaning towards creating a Tor Browser Bundle for OS X; which can run out of the dmg or be installed via drag and drop. Much like the current Tor Browser Bundle (also, we should stop naming everything Tor), it would be self-contained and leave zero trace on the machine after closing.

Thoughts on ways to make the OS X install easier, ostensibly via drag and drop install? Or is the effort to create a TBB for OS X a better use of resources?

Jacob and Matt join the Tor Project

phobos — Thu, 29 May 2008 13:36:47 -0700

Jacob Appelbaum joins us to help out with:

developing a translation portal. This should help us find translators
and make their updates easier.
coordinating the Tor translation team and getting parts that need
translating, translated.
helping to better document Tor for non-technical users.
writing an auto-responder to use Google's gmail to deliver Tor to
users who request it
helping to get auto-updating for Tor and Vidalia working seamlessly
maintaining the code that runs the tor exitlist
generally advocating Tor

Matt Edman joins the Tor Project. Matt joins to help us enhance Tor's
interactions with Vidalia. Specifically, he's working on:

integrating upnp libraries into vidalia to make it easier to setup servers
displaying Tor's startup status more visually in Vidalia to help users
understand what's going on as Tor starts
assist with making translating Vidalia's interface and help files
easier for translators
helping to flesh out proposals in queue on or-dev
helping to get auto-updating or Tor and Vidalia working seamlessly
tackling the "matt" section of the TODO file.

Welcome Jacob and Matt!

Vidalia bundle, OSX and Qt bugs

phobos — Sun, 20 Jan 2008 10:50:53 -0800

It appears Qt-4.3.3 has a bug that is causing Vidalia to crash when the list of Tor nodes refreshes and is sorted. The current 0.1.2.19-stable and 0.2.0.17-alpha bundles for OSX are built against Qt-4.3.3.

I've downgraded the build hosts to Qt-4.3.2. The rebuilt OSX vidalia-bundle packages for both 0.1.2.19-stable and 0.2.0.17-alpha are available as:

These bundles contain Vidalia compiled with Qt-4.3.2. This makes Vidalia happy again.