torbutton

New Tor Browser Bundles with Firefox 17.0.3esr

We've updated all of the bundles with Firefox 17.0.3esr. This includes significant changes to Torbutton and its interaction with Firefox, in addition to many new patches being added to Firefox, which are outlined below.

Very important: if you've been using the Tor Browser Bundles with Firefox 10.0.x, you must not attempt to overwrite it with the new bundle. Open these into their own directory and do not copy any profile material from older TBB versions.

https://www.torproject.org/download

Tor Browser Bundle (2.3.25-4)

  • Update Firefox to 17.0.3esr
  • Downgrade OpenSSL to 1.0.0k
  • Update libpng to 1.5.14
  • Update NoScript to 2.6.5.7
  • Firefox patch changes:
    • Exempt remote @font-face fonts from font limits (and prefer them).
      (closes: #8270)
      • Remote fonts (aka "User Fonts") are not a fingerprinting threat, so
        they should not count towards our CSS font count limits. Moreover,
        if a CSS font-family rule lists any remote fonts, those fonts are
        preferred over the local fonts, so we do not reduce the font count
        for that rule.
      • This vastly improves rendering and typography for many websites.
    • Disable WebRTC in Firefox build options. (closes: #8178)
      • WebRTC isn't slated to be enabled until Firefox 18, but the code
        was getting compiled in already and is capable of creating UDP Sockets
        and bypassing Tor. We disable it from build as a safety measure.
    • Move prefs.js into omni.ja and extension-overrides. (closes: #3944)
      • This causes our browser pref changes to appear as defaults. It also
        means that future updates of TBB should preserve user pref settings.
    • Fix a use-after-free that caused crashing on MacOS (closes: #8234)
    • Eliminate several redundant, useless, and deprecated Firefox pref settings
    • Report Firefox 17.0 as the Tor Browser user agent
    • Use Firefox's click-to-play barrier for plugins instead of NoScript
    • Set the Tor SOCKS+Control ports to 9150, 9151 respectively on all platforms
      • This fixes a SOCKS race condition with our SOCKS autoport configuration
        and HTTPS-Everywhere's Tor test. Firefox 17 appears to cache proxy
        settings per URL now, which resulted in a proxy error for
        check.torproject.org if we lost the race.
  • Torbutton was updated to 1.5.0. The following issues were fixed:
    • Remove old toggle observers and related code (closes: #5279)
    • Simplify Security Preference UI and associated pref updates (closes: #3100)
    • Eliminate redundancy in our Flash/plugin disabling code (closes: #1305)
    • Leave most preferences under Tor Browser's control (closes: #3944)
    • Disable toggle-on-startup and crash detection logic (closes: #7974)
    • Disable/remove toggle-mode code and related observers (closes: #5279)
    • Add menu hint to Torbutton icon (closes: #6431)
    • Make Torbutton icon flash a warning symbol if TBB is out of date (closes: #7495)
    • Perform version check every time there's a new tab. (closes: #6096)
    • Rate limit version check queries to once every 1.5hrs max. (closes: #6156)
    • misc: Allow WebGL and DOM storage.
    • misc: Disable independent Torbutton updates
    • misc: Change the recommended SOCKSPort to 9150 (to match TBB)

The following Firefox patch changes are also included in this release:

  • Isolate image cache to url bar domain (closes: #5742 and #6539)
  • Enable DOM storage and isolate it to url bar domain (closes: #6564)
  • Include nsIHttpChannel.redirectTo API for HTTPS-Everywhere (closes: #5477)
  • Misc preference changes:
    • Disable DOM performance timers (dom.enable_performance) (closes: #6204)
    • Disable HTTP connection retry timeout (network.http.connection-retry-timeout) (closes: #7656)
    • Disable full path information for plugins (plugin.expose_full_path) (closes: #6210)
    • Disable NoScript's block of remote WebFonts (noscript.forbidFonts) (closes: #7937)

Tor Browser Bundle (2.4.10-alpha-2)

  • Update Firefox to 17.0.3esr
  • Downgrade OpenSSL to 1.0.0k
  • Update libpng to 1.5.14
  • Update NoScript to 2.6.5.7
  • Firefox patch changes:
    • Exempt remote @font-face fonts from font limits (and prefer them).
      (closes: #8270)
      • Remote fonts (aka "User Fonts") are not a fingerprinting threat, so
        they should not count towards our CSS font count limits. Moreover,
        if a CSS font-family rule lists any remote fonts, those fonts are
        preferred over the local fonts, so we do not reduce the font count
        for that rule.
      • This vastly improves rendering and typography for many websites.
    • Disable WebRTC in Firefox build options. (closes: #8178)
      • WebRTC isn't slated to be enabled until Firefox 18, but the code
        was getting compiled in already and is capable of creating UDP Sockets
        and bypassing Tor. We disable it from build as a safety measure.
    • Move prefs.js into omni.ja and extension-overrides. (closes: #3944)
      • This causes our browser pref changes to appear as defaults. It also
        means that future updates of TBB should preserve user pref settings.
    • Fix a use-after-free that caused crashing on MacOS (closes: #8234)
    • Eliminate several redundant, useless, and deprecated Firefox pref settings
    • Report Firefox 17.0 as the Tor Browser user agent
    • Use Firefox's click-to-play barrier for plugins instead of NoScript
    • Set the Tor SOCKS+Control ports to 9150, 9151 respectively on all platforms
      • This fixes a SOCKS race condition with our SOCKS autoport configuration
        and HTTPS-Everywhere's Tor test. Firefox 17 appears to cache proxy
        settings per URL now, which resulted in a proxy error for
        check.torproject.org if we lost the race.
  • Torbutton was updated to 1.5.0. The following issues were fixed:
    • Remove old toggle observers and related code (closes: #5279)
    • Simplify Security Preference UI and associated pref updates (closes: #3100)
    • Eliminate redundancy in our Flash/plugin disabling code (closes: #1305)
    • Leave most preferences under Tor Browser's control (closes: #3944)
    • Disable toggle-on-startup and crash detection logic (closes: #7974)
    • Disable/remove toggle-mode code and related observers (closes: #5279)
    • Add menu hint to Torbutton icon (closes: #6431)
    • Make Torbutton icon flash a warning symbol if TBB is out of date (closes: #7495)
    • Perform version check every time there's a new tab. (closes: #6096)
    • Rate limit version check queries to once every 1.5hrs max. (closes: #6156)
    • misc: Allow WebGL and DOM storage.
    • misc: Disable independent Torbutton updates
    • misc: Change the recommended SOCKSPort to 9150 (to match TBB)

New Tor Browser Bundles

The Tor Browser Bundles have been updated with a bunch of new software: Tor 0.2.2.37, Vidalia 0.2.19, and we have switched to using Firefox's long-term stable release (10.0.5esr).

https://www.torproject.org/download

Tor Browser Bundle (2.2.37-1)

  • Update Tor to 0.2.2.37
  • Switch Firefox to 10.0.5esr, since we will be tracking the extended stable releases for TBB stable versions
  • Update Vidalia to 0.2.19
  • Update Torbutton to 1.4.6
  • Update NoScript to 2.4.4

New Tor Browser Bundles

The Tor Browser Bundles have been updated to Vidalia 0.2.15. The OS X and Linux bundles have Torbutton 1.4.4, but a hotfix for Windows was released with 1.4.4.1 because 1.4.4 had a minor issue that prevented the Windows bundle from going to https://check.torproject.org.

https://www.torproject.org/download

Tor Browser Bundle (2.2.33-3)

  • Update Vidalia to 0.2.15
  • Update Torbutton to 1.4.4.1
  • Update NoScript to 2.1.4
  • Remove trailing dash from Windows version number (closes: #4160)
  • Make Tor Browser (Aurora) fail closed when not launched with a TBB profile
    (closes: #4192)

Torbutton 1.4.1 Released

Torbutton 1.4.1 has been released at: https://www.torproject.org/torbutton/

This release features a "New Identity" menu option that clears browser state, closes tabs, and obtains a fresh Tor circuit for future requests. It also features a fix for breakage with Hotmail, and further isolates browser state and identifiers to the url bar domain (see https://blog.torproject.org/blog/improving-private-browsing-modes-do-not...).

However, the New Identity button and the Hotmail fix are only available to Tor Browser Bundle users. If you are still using Torbutton with a vanilla Mozilla Firefox, we strongly recommend you download the Tor Browser Bundle 2.2.x alphas from https://www.torproject.org/dist/torbrowser/ and report problems you experience, as we will be declaring them stable within the next release or two.

Stay tuned for a new Tor Browser release that contains Torbutton 1.4.1 tomorrow.

Here is the complete changelog:
* bug 523: Implement New Identity (for TBB only)
* bug 3580: Fix hotmail/live breakage (for TBB only)
* bug 3748: Disable 3rd party HTTP auth
* bug 3665: Fix several corner cases SafeCache isolation
* bug 3739: Fix https->http CORS failure for SafeCache
* bug 3414: Isolate window.name based on referrer policy
* bug 3809: Disable referer spoofing (fixes navigation issues)
* bug 3819: Fix API issue with cookie protections
* bug 3820: Fix warning w/ session store filter

Torbutton 1.4.0 Released

Torbutton 1.4.0 has been released at:
https://www.torproject.org/torbutton/

The addon has been disabled on addons.mozilla.org. Our URL is now
canonical.

This release features support for Firefox 5.0, and has been tested
against the vanilla release for basic functionality. However, it has
not been audited for Network Isolation, State Separation, Tor
Undiscoverability or Interoperability issues[1] due to toggling under
Firefox 5.

If you desire Torbutton functionality with Firefox 4/5, we recommend
you download the Tor Browser Bundle 2.2.x alphas from
https://www.torproject.org/dist/torbrowser/ or run Torbutton in its
own separate Firefox profile.

The reasons for this shift are explained here:
https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton

If you find bugs specific to Firefox 5, toggling, and/or extension
conflicts, file them under the component "Torbutton":
https://trac.torproject.org/projects/tor/report/14

Bugs that still apply to Tor Browser should be filed under component
"TorBrowserButton":
https://trac.torproject.org/projects/tor/report/39

Bugs in the "Torbutton" component currently have no maintainer
available to fix them. Feel free to step up.

(No, simply mis-filing your Torbutton toggle bugs under
TorBrowserButton won't cause them to get fixed accidentally. It will
just annoy me slightly as I relocate them to the correct component).

Here is the complete changelog:
* bug 3101: Disable WebGL. Too many unknowns for now.
* bug 3345: Make Google Captcha redirect work again.
* bug 3399: Fix a reversed exception check found by arno.
* bug 3177: Update torbutton to use new TorBrowser prefs.
* bug 2843: Update proxy preferences window to support env var.
* bug 2338: Force toggle at startup if tor is enabled
* bug 3554: Make Cookie protections obey disk settings
* bug 3441: Enable cookie protection UI by default.
* bug 3446: We're Firefox 5.0, we swear.
* bug 3506: Remove window resize event listener.
* bug 1282: Set fixed window size for each new window.
* bug 3508: Apply Stanford SafeCache patch (thanks Edward, Collin et al).
* bug 2361: Make about window work again on FF4+.
* bug 3436: T(A)ILS was renamed to Tails.
* bugfix: Fix a transparent context menu issue on Linux FF4+.
* misc: Squelch exception from app launcher in error console.
* misc: Make DuckDuckGo the default Google Captcha redirect destination.
* misc: Make it harder to accidentally toggle torbutton.

1. https://www.torproject.org/torbutton/en/design/#requirements

Improving Private Browsing Modes: "Do-Not-Track" vs Real Privacy by Design

Updated 06/16/2011: Break off window.name into its own linkability issue. While ultimately it should be handled identically to the referer, that was not clear in the original text.
Updated 07/01/2011: Add link to article about 81% consumer polling rate in favor of some form of Do Not Track...

As I said in my previous post, the Tor Project hopes to work on a set of patches that effectively improves the Private Browsing Mode of Firefox. Long term, we'd love to merge these patches upstream, and/or see them obsoleted by better implementations.

To help keep everyone on the same page with respect to this effort, I've decided to take some time to describe what we envision as our ideal private browsing mode.

Hopefully, such a mode would be useful for more than just Tor users. Indeed, there are many ways to obtain varying levels of IP address privacy once you have solid browser support for privacy by design. The average user is quite capable of going to a cafe and enabling private mode, and this ability can be explained to them in a single sentence by the UI. Arguably they can also obtain low-grade IP privacy simply by tethering to their cell phone, whose IP typically changes regularly. I am told that frequent IP rotation is also the norm for residential connections in Germany and much of the EU to deter services and malware. This is not to mention all of the commercial single-hop VPN and proxy privacy services out there that fail to provide actual browser privacy in their tools.

We believe that the attention surrounding the "Do-Not-Track" header also indicates that network privacy is an important feature. However, we believe that it must be provided by design, as opposed to via a humble request to the adversary that is impossible to audit or enforce, especially outside of the United States. In his presentation at W2SP, Balachander Krishnamurthy compared the "Do-Not-Track" request header to the real-world equivalent of leaving your door unlocked with a posted notice that reads "Do-Not-Rob". While many people actually do post "No Trespassing" and similar signs, no one expects these signs to replace actual security measures.

Unfortunately, right now the only usable and effective web privacy option for the average user is to install an ad-blocker or similar software. Personally, I see the need for an ad-blocker to achieve privacy as a huge failure of the web itself. If web tracking, profiling, and behavioral targeting is so extreme that it cannot be avoided except by blocking all ads, then the prevailing revenue model of the web is unsustainable. We must figure out a way to do non-intrusive, content-relevant advertising while still providing privacy, without relying on regulatory action that is unlikely to be enforceable.

Ok, so enough preaching. What does privacy by design look like? I'm going to describe a list of 7 key properties, some of which the major browser vendors already have or are working towards, but so far are not uniformly deployed in any browser, including even our own Tor Browser.

  1. Make local privacy optional
  2. Avoid Linkability: Minimize privacy options, plugins and addons
  3. Avoid Linkability: Isolate all non-private mode identifiers and state
  4. Avoid Linkability: Isolate state per top-level domain
  5. Avoid Linkability: Reduce fingerprintable attributes
  6. Avoid Linkability: Reduce default referer information
  7. Avoid Linkability: Restrict window.name to referer policy


Make local privacy optional

The browser vendors got it half right the first time around. There are many users who consider local storage privacy to be the primary feature they want from private browsing mode. However, we believe that local privacy is actually an orthogonal feature to network privacy: some users want both, but some only want one or the other.

Therefore, we believe that users should be given the option in private browsing mode to choose if they want to record browsing history or not. Many users will want to use private mode regularly, and will only be concerned about ad network tracking as opposed to local storage (ie similar to the "Do-Not-Track" header's use case). These users will still want history and "awesome bar" functionality to work for them. Almost all users will want to maintain access to their bookmarks and previously stored history from within the mode.

Avoid Linkability: Minimize privacy options, plugins, and addons

Beyond the choice to store history and activity on disk, there should not be numerous global options provided to private browsing modes.

Each option that detectably alters browser behavior can be used as a fingerprinting tool on the part of ad networks. Similarly, all extensions should be disabled in the mode except as an opt-in basis.

Instead of global browser privacy options, privacy decisions should be made per top-level url-bar domain to eliminate the possibility of linkability between domains. For example, when a plugin object (or a JavaScript access of window.plugins) is present in a page, the user should be given the choice of allowing that plugin object for that top-level url-bar domain only. The same goes for exemptions to third party cookie policy, geo-location, and any other privacy permissions.

If the user has indicated they do not care about local history storage, these permissions can be written to disk. Otherwise, they should remain memory-only.

Avoid Linkability: Isolate all non-private identifiers and state

All major browsers already make some effort to isolate explicit identifier state between non-private and private browsing (despite protest that their threat model does not actually require it). Obviously, privacy by design requires that this effort be continued.

The ability to link users between private and non-private browsing modes via explicit identifiers, browser state, or TLS state should be considered a flaw in the mode. After all, the user may have gone to a wifi cafe to obtain IP address privacy, expecting identifier privacy from their browser. It is not fair to the user to abjectly fail to protect them in this case.

Avoid Linkability: Isolate state to top-level domain

However, users who want continuous "Do-Not-Track"-style privacy will likely use the mode regularly, possibly even exclusively, to avoid behavior advertising and associated tracking. These users will also want to reduce the linkability between arbitrary sites they visit.

This is a particular concern for Tor as many activists use web-based email, social networking sites, and other web services for organizing. Their activity in Tor Browser on one site should not trivially de-anonymize their activity on another site to ad networks and exits.

To provide this property, all identifiers and state must be isolated to the top-level url bar domain, starting with cookies, but extending to the cache, DOM Storage, client certificates, and HTTP auth.

The benefit of this approach comes not only in the form of reduced linkability, but also in terms of simplified privacy UI. If all stored browser state and permissions become associated with the top-level url-bar domain, the six or seven different pieces of privacy UI governing these identifiers and permissions can become just one piece of UI, possibly with a context-menu option to drill down into specific types of state.

We also believe that such an identifier model makes privacy relationships much more clear to the average user. Instead of having various disjoint relationships with and permissions for hundreds of omnipresent third-party domains, users will have one relationship with each of the top-level url-bar domains that they choose to interact with and authenticate to.

Obviously, the downside of this enhanced protection against identifier linkability is that third party services that rely on third party cookie transmission may be impeded by this model. Long term, the hope is for standardized, in-browser support for services federated login and "Like" buttons. Google Chrome has actually implemented a feature called Web-Send that provides this functionality in a privacy preserving way. They have even written a legacy HTML5 version that provides the same privacy properties, save for the need to trust http://webintroducer.net for DOM Storage.

We are also trying to introduce the notion of "protected cookies" in the alpha Tor Browser series, to allow users to specify they want to maintain a relationship with certain sites but not with others. To simplify this experience, we've currently entirely disabled Third Party Cookies in Tor Browser, but we believe that this may end up breaking mashup and federated login sites that might still be able to function under the more lenient double-keyed cookie model.

Several other interim steps are possible in the meantime. One could imagine iframe attributes that cause the browser chrome to request that a site be granted permission to set top-level cookies, or even a fully automated client-side mechanism that performs this promotion automatically for selected sites on mouse-click (such a mechanism is actually being prototyped by researchers right now).

Avoid Linkability: Reduce fingerprintable attributes

Once the linkability via explicit identifiers is eliminated, it becomes important to address the linkability that is possible through browser fingerprinting.

Fingerprinting is a difficult issue to address, but that difficulty does not preclude a best-effort from being made at eliminating or mitigating the major culprits.

Luckily, the major culprit is plugin-provided information. Once plugins are restricted to only permitted top-level domains, fingerprinting linkability gets effectively reduced to the information available via CSS, Javascript, and HTTP headers.

The largest culprits in CSS and Javascript are resolution and media information (especially those properties that also provide information about the device and display as opposed to limiting information to the properties of the rendering window itself), the number of fonts that can be loaded per origin, time-based fingerprints, and WebGL device information.

It is likely that we need another Panopticlick-style study that focuses exclusively on CSS and Javascript to determine the relative importance of these components, but most of them can be addressed without serious breakage of functionality.

Avoid Linkability: Reduce default referer information

So far, the Tor Project has refrained from restricting referer primarily because we believe that restricting referer actually becomes less necessary if identifiers are isolated and linkability has been reduced.

However, non-Tor users do have one important element of linkability: IP address. Even those that have an alternate Internet connection may still be bound to a single alternate IP. These users probably actually benefit in a real way from a restricted referer. It turns out a lot of information is already smuggled or leaked via referrer and URL parameters to third party sites, either deliberately or accidentally.

Referer restriction could take multiple forms, but we believe more site flexibility is key. Sites actually have no way to restrict referer for most element types currently, and conversely, sites will always be able to subvert referer restrictions by smuggling the same data in POST or URL parameters.

Therefore, we believe that referers should be restricted by default in private browsing mode using a same-origin policy where sites from different origins get either no referer, or a referer that is truncated to the top-level domain. However, sites should also be allowed to request an exemption to this rule on a per-site basis using an html attribute, which could trigger a chrome permissions request, or simply be granted automatically (on the assumption that they could just URL smuggle the data).

While this may not seem like much of a protection, at least it allows us to differentiate negligence from deliberate information sharing, and to restrict information leakage in the default scenario. Again, because this data can always be transmitted between elements either directly or via a back-channel, it is better it be visible and apparent than covert.

Avoid Linkability: Restrict window.name to referer policy

Window.name poses many of the same conflicts as referer information. It gives sites a way to pass data between pages in the navigation lifespan of a tab. Sites can use window.name to store data, but are given no way to clear it easily. Hence it becomes very hard to differentiate deliberate data exchange from accidental leakage.

Just like referer, it is obvious that window.name should be empty whenever the URL bar is rewritten by the user. There should be no legitimate, functional need for data exchange between two arbitrary random user-typed URL bar domains in any situation. Window.name on user-entered URLs should be cleared regardless of any changes to existing referer policy.

Similarly, sites could be given the option to allow transmission of window.name to third party iframe elements, but the default should be to isolate window.name to the same origin policy. We do not believe this second step is required for Tor usage, but it may be helpful to non-Tor users, for similar reasons as the referer leakage.

As such, our current plan is to bind window.name's lifespan to the Referer header contents in our addon implementations.

Conclusion

We believe that privacy can be a differentiating feature for browsers. Even early studies revealed that many users immediately began using private browsing modes regularly, either by mistake or deliberately.

We believe that many of these users deliberately use private browsing in cafes and on other alternate Internet connections assuming that they are being protected from ad tracking and behavioral analysis. We welcome user studies to determine what users actually expect and want from private browsing modes for the definitive answer, but obviously we're pretty convinced what the outcome will be.

Privacy by design represents the technical realization of "Do-Not-Track": the ability to actually opt-out (prevent) a complete behavior profile from being built to record and model your specific web viewing habits.

In order for a private browsing mode to succeed in actually providing privacy by design, it must reduce activity linkability in all forms. Six out of the seven items mentioned above are really linkability issues at their core. Reducing the ability of the adversary to link private activity to non-private activity and also to other private activity is what privacy by design is all about. This reduction in linkability is what prevents a behavioral profile from being constructed.

The Tor Project looks forward to a day where privacy by design becomes a key feature of major browsers. We would love to be able to ship a vastly simplified browser extension that contains only a compiled Tor binary and some minimal addon code that simply "upgrades" the user's private browsing mode into a fully functional anonymous mode. The ability to do this would vastly simplify our package offerings, and make it significantly easier to get our software into censored and oppressed regions.

However, until then, we must do our best to attempt to provide software that we believe will provide the privacy and security that users have come to expect from us. For now, this means shipping our own browser.

New Tor Browser Bundles (and other packaging updates)

Tor 0.2.2.25-alpha is out and there are the usual packaging updates. You can go right to the download page to update.

The alpha Vidalia bundles have also been updated with the latest Torbutton 1.3.3-alpha which has itself been updated to work with the latest Firefox 4.0.1 release and has this notable feature:

When used with Firefox 4 or the alpha Tor Browser Bundles, it also
features support for youtube videos in HTML5, but you must currently
opt-in for youtube to provide you with HTML5 video as opposed to
flash: http://www.youtube.com/html5

Tor Browser Bundle changelogs follow.

Firefox 3.6 Tor Browser Bundles

Tor Browser Bundle for Windows

1.3.24: Released 2011-04-30

  • Update Firefox to 3.6.17
  • Update Libevent to 2.0.10-stable
  • Update zlib to 1.2.5
  • Update OpenSSL to 1.0.0d

Tor Browser Bundle for Linux
1.1.8: Released 2011-04-30

  • Update Tor to 0.2.2.25-alpha
  • Update Firefox to 3.6.17

Tor Browser Bundle for OS X
1.0.16: Released 2011-04-30

  • Update Tor to 0.2.2.25-alpha
  • Update Firefox to 3.6.17

Firefox 4 Tor Browser Bundles

Tor Browser Bundle (2.2.25-1) alpha; suite=all

  • Update Tor to 0.2.2.25-alpha
  • Update Firefox to 4.0.1
  • Update Torbutton to 1.3.3-alpha
  • Update BetterPrivacy to 1.50
  • Update NoScript to 2.1.0.3

Temporary direct download links for Firefox 4 bundles:

To Toggle, or not to Toggle: The End of Torbutton

In a random bar about two years ago, a Google Chrome developer asked me why Torbutton didn't just launch a new, clean Firefox profile/instance to deal with the tremendous number of state separation issues. Simply by virtue of him asking me this question, I realized how much better off Chrome was by implementing Incognito Mode this way and how much simpler it must have been for them overall (though they did not/do not deal with anywhere near as many issues as Torbutton does)...

So I took a deep breath, and explained how the original use model of Torbutton and my initial ignorance at the size of the problem had led me through a series of incremental improvements to address the state isolation issue one item at a time. Since the toggle model was present at the beginning of this vision quest, it was present at the end.

I realized at that same instant that in hindsight, this decision was monumentally stupid, and that I had been working harder, not smarter. However, I thought then that since we had the toggle model built, we might as well keep it: it allowed people to use their standard issue Firefoxes easily and painlessly with Tor.

I now no longer believe even this much. I think we should completely do away with the toggle model, as well as the entire idea of Torbutton as a separate piece of user-facing software, and rely solely on the Tor Browser Bundles, except perhaps with the addition of standalone Tor+Vidalia binaries for use by experts and relay operators.

The Tor Browser Bundles will include Torbutton, but we will no longer recommend that people use Torbutton without Tor Browser. Torbutton will be removed from addons.mozilla.org, and the Torbutton download page will clearly state that it is for experts only. If serious unfixed security issues begin to accumulate against the toggle model, we will stop providing Torbutton xpis at all.

I believe this shift must be done for a few reasons: some usability, some technical. Since I feel the usability issues trump the technical ones, I'll discuss them first.

Unfortunately, the Tor Project doesn't really have funding to conduct official usability studies to help us make the best choice, but I think that even without them, it is pretty clear that this migration is what we must do to improve the status quo.

I think the average user is horribly confused by both the toggle model and the need to install additional software into Firefox (or conversely, the need to *also* install Tor software onto their computers after they install Torbutton). I also think that the average user is not likely to use this software safely. They are likely to log in to sites over Tor that they shouldn't, forget which tor mode they are in, and forget which mode certain tabs were opened under. These are all nightmare situations for anonymity and privacy.

On the technical side, several factors are forcing us in the direction of a short-term fork of Firefox. The over-arching issue is that the set of bugfixes required to maintain the toggle model is a superset of those required to maintain the browser model. Trac report #39 lists the bugs we must fix for the browser model, where as to maintain the toggle model, we must fix bugs from trac report #14 in addition to the bugs in report #39.

A similar issue exists with bugs that must be fixed in Firefox. The Firefox API bugs that need to be addressed to properly support the toggle model include rather esoteric and complicated issues that few groups other than Tor will find useful.

This means more resistance from Mozilla to get the toggle mode bugs fixed or even merged, less likelihood the fixes will be used elsewhere, and more danger they will succumb to bitrot. As a result, the lag time between fix and deployment for low-priority Firefox bugs can be as long as 3 years. See Bug 280661 for an example.

The Tor Browser bugs on the other hand are more directly usable by Firefox in its own Private Browsing Mode, which makes them more likely to merge quicker, and be maintained long-term. Also, because we are releasing our own Firefox-based browser, we will also have more control over experimenting with them and deploying these fixes to our users rapidly, as opposed to waiting for the next major Firefox release.

So, we can either invest effort in improving the UI of Torbutton to better educate users to understand our particular rabbit-hole tunnel-vision of design choices, and also solving crazier Firefox bugs; or we can reconsider our user model and try to simplify our software.

We don't have the manpower (ie: enough me) to do both. This means we should go with the simpler, easier option.

We do face a small number of barriers and downsides associated with this plan. We are collecting the issues we need to address ASAP as child tickets of this bug:
https://trac.torproject.org/projects/tor/ticket/2880

Overall, the downsides seem to mostly apply to expert users and how they will adapt the custom Tor setups they have built. We don't anticipate a lot of long term issues with this group, as most of the configuration options of Torbutton will remain available, and users should still be able to install custom addons and configure their Tor Browser profile however they need (even to the point of running it side-by-side to a system tor instance that is used for non-web applications).

Additional discussion about this issue has occurred on the tor-talk mailinglist.

Hopefully this announcement doesn't ruin your day!

Web Developers and Firefox Hackers: Help us with Firefox 4

We need some web-savvy people to help us audit the Torbutton alpha series for Firefox 4. I've performed a preliminary audit, and Torbutton 1.3.2-alpha should be safe from major issues, but a lot more testing is needed. In particular, we need people to test the new Firefox 4 features.

The notes from my preliminary audit are available in the Torbutton git repository, but note that I have not tested everything that struck me as potentially troublesome, and there may be other things I missed too.

As a reminder, the types of things we are looking for are things that violate the Torbutton Security Requirements, which may include new ways to bypass proxy settings, to fingerprint users, or to use novel identifiers to correlate Tor and Non-Tor activity.

In addition, we may have some funding to address outstanding Torbutton-related bugs in Firefox. If you know C++ and/or Firefox internals, we should be able to pay you for your time to address these issues and shepherd the relevant patches through Mozilla's review process.

If you find issues, or if you are interested in working on fixing these bugs, please contact us at tor-assistants at torproject dot org. Torbutton bugs that you find can be added to the growing pile at the Torbutton Bug Tracker.

The sooner we get these issues taken care of, the sooner we can confidently release a stable Torbutton for Firefox 4.

Torbutton-alpha 1.3.1 released for testing

Torbutton 1.3.1-alpha has been released at:
https://www.torproject.org/dist/torbutton/torbutton-1.3.1-alpha.xpi and .asc

This release features a fix for the nasty pref dialog issue in 1.3.0 (bug #2011), as well as Firefox 4.0 support. Thanks to new APIs in Firefox 3.5 and better privacy options in Firefox 4, Torbutton has now been simplified as well. While we still provide a number of XPCOM components, the number of native Firefox components we replace has shrunk from 5 to just one.

However, the amount of changes involved in supporting Firefox 4 were substantial, and it is likely that these changes as well as the removal of old code has introduced new bugs. We've done our best to test out operation on Firefox 3.6 and 4.0, but we have not tested Firefox 3.0, and may have missed other issues as well. Please report any issues you notice on our bugtracker: https://trac.torproject.org/projects/tor/report/14

Here is the complete changelog: read more »

Syndicate content Syndicate content