Tor is a toolset for a wide range of organizations and people who want to improve their safety and security on the Internet. Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and more. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy.
Tor aims to defend against traffic analysis, a form of network surveillance that threatens personal anonymity and privacy, confidential business activities and relationships, and state security. Communications are bounced around a distributed network of servers called onion routers, protecting you from websites that build profiles of your interests, local eavesdroppers that read your data or learn what sites you visit, and even the onion routers themselves.
Tor’s security is improved as its user base grows and as more people volunteer to run servers. Please consider volunteering your time or volunteering your bandwidth. And remember that this is development code – it’s not a good idea to rely on the current Tor network if you really need strong anonymity.
By default, Tor is configured to run at startup. If you do not want Tor to run on startup, you can disable this by selecting “Customize” in the Installer, and then un-checking the “Tor Startup Script” box. Be sure to leave the other boxes checked. Once the installer is finished and your computer restarts, Tor will start automatically. Tor comes configured as a client by default. It uses a built-in default configuration file in /Library/Tor/torrc, but most people won’t need to change any of the settings.
Privoxy is installed as part of the Tor bundle package installer. Privoxy is a filtering web proxy that integrates well with Tor. Once it’s installed, it will start automatically when your computer is restarted. You do not need to configure Privoxy to use Tor. A custom Privoxy configuration for Tor has been installed as part of the installer package.
- Major features:
- Clients now use the bandwidth values in the consensus, rather than the bandwidth values in each relay descriptor. This approach opens the door to more accurate bandwidth estimates once the directory authorities start doing active measurements. Implements more of proposal 141.
- Major bugfixes:
- When Tor clients restart after 1-5 days, they discard all their cached descriptors as too old, but they still use the cached consensus document. This approach is good for robustness, but bad for performance: since they don’t know any bandwidths, they end up choosing at random rather than weighting their choice by speed. Fixed by the above feature of putting bandwidths in the consensus. Bugfix on 0.2.0.x.
- Directory authorities were neglecting to mark relays down in their internal histories if the relays fall off the routerlist without ever being found unreachable. So there were relays in the histories that haven’t been seen for eight months, and are listed as being up for eight months. This wreaked havoc on the “median wfu” and “median mtbf” calculations, in turn making Guard and Stable flags very wrong, hurting network performance. Fixes bugs 696 and 969. Bugfix on 0.2.0.6-alpha.
- Minor bugfixes:
- Serve the DirPortFrontPage page even when we have been approaching our quotas recently. Fixes bug 1013; bugfix on 0.2.1.8-alpha.
- The control port would close the connection before flushing long replies, such as the network consensus, if a QUIT command was issued before the reply had completed. Now, the control port flushes all pending replies before closing the connection. Also fixed a spurious warning when a QUIT command is issued after a malformed or rejected AUTHENTICATE command, but before the connection was closed. Patch by Marcus Griep. Bugfix on 0.2.0.x; fixes bugs 1015 and 1016.
- When we can’t find an intro key for a v2 hidden service descriptor, fall back to the v0 hidden service descriptor and log a bug message. Workaround for bug 1024.
- Fix a log message that did not respect the SafeLogging option. Resolves bug 1027.
- Minor features:
- If we’re a relay and we change our IP address, be more verbose about the reason that made us change. Should help track down further bugs for relays on dynamic IP addresses.
