New Release: Tor Browser 8.5a9

Tor Browser 8.5a9 is now available from the Tor Browser Project page and also from our distribution directory.

Note: this is an alpha release: an experimental version for users who want to help us test new features. For everyone else, we recommended downloading the latest stable release instead.

This release features important security updates to Firefox.

This new Tor Browser version picks up Firefox security bug fixes coming with Firefox 60.6.0esr and ships the second alpha in Tor's 0.4.0 series, 0.4.0.2-alpha. Besides those and other regular component updates (e.g. OpenSSL to 1.0.2r), we are proud to give three major features wider testing in our alpha series:

  • Firstly, for our desktop users, we redesigned our security controls, exposing the security slider state directly on our reorganized toolbar. The current code implements large parts of proposal 101, and we hope we make the overall experience less confusing that way, especially for inexperienced users. Thanks to Richard for all the hard work on this!
  • Secondly, we redesigned our bootstrapping interface for Tor Browser on Android, giving what we hope is a similar experience to the one provided for desktop versions. This is the first big part in our efforts to drop our dependency on Orbot while still making bootstrapping progress and bridge/pluggable transport configuration easily accessible. Thanks to Matt for all the work on this feature!
  • Thirdly, we implemented pluggable transport support for our mobile users, allowing them to bypass censorship with the help of obfs3, obfs4, and meek. It is possible to use both built-in bridges and custom ones, which users can obtain e.g. from BridgeDB or friends.

The full changelog since Tor Browser 8.5a8 is:

  • All platforms
    • Update Firefox to 60.6.0esr
    • Update Torbutton to 2.1.5
      • Bug 25658: Replace security slider with security level UI
      • Bug 28628: Change onboarding Security panel to open new Security Level panel
      • Bug 29440: Update about:tor when Tor Browser is updated
      • Bug 27478: Improved Torbutton icons for dark theme
      • Bug 29021: Tell NoScript it is running within Tor Browser
      • Bug 29239: Don't ship the Torbutton .xpi on mobile
      • Translations update
    • Bug 29120: Enable media cache in memory
    • Bug 29445: Enable support for enterprise policies
  • Windows + OS X + Linux
    • Update Tor to 0.4.0.2-alpha
      • Bug 29660: XMPP can not connect to SOCKS5 anymore
    • Update OpenSSL to 1.0.2r
    • Update Tor Launcher to 0.2.18.1
      • Bug 29328: Account for Tor 0.4.0.x's revised bootstrap status reporting
      • Bug 22402: Improve "For assistance" link
      • Translations update
    • Bug 25658+29554: Replace security slider with security level UI
    • Bug 28885: notify users that update is downloading
    • Bug 29180: MAR download stalls when about dialog is opened
    • Bug 27485: Users are not taught how to open security-slider dialog
    • Bug 27486: Avoid about:blank tabs when opening onboarding pages
    • Bug 29440: Update about:tor when Tor Browser is updated
    • Bug 23359: WebExtensions icons are not shown on first start
    • Bug 28628: Change onboarding Security panel to open new Security Level panel
  • Android
    • Bug 28329: Design Tor Browser for Android configuration UI
    • Bug 28802: Support PTs in Tor Browser for Android
    • Bug 29794: Update TBA built-in bridges
    • Bug 27210: Add support for x86 on Android
    • Bug 29809: Only ship tor binary for .apk architecture
    • Bug 29633: Don't ship pdnsd anymore
    • Bug 28708: about:tor is not the default homepage after upgrade
    • Bug 29626: Application name is now "Always-On Notifications"
    • Bug 29467: Backport fix for arc4random_buf bustage
  • Build System
    • All platforms
      • Bug 25876: Generate source tarballs during build
      • Bug 28685: Set Build ID based on Tor Browser version
      • Bug 29194: Set DEBIAN_FRONTEND=noninteractive
    • Linux
      • Bug 26323+29812: Build 32bit Linux bundles on 64bit Debian Wheezy
      • Bug 29758: Build firefox debug symbols for linux-i686
    • Android
      • Bug 29632: Use HTTPS for downloading Gradle

a) Google captchas load via JavaScript from google.com and gstatic.com. The Safest level disables JavaScript on all sites, not just Googles. To load Google captchas on sites that use them (many more sites than just Googles), either lower to Safer or try changing the trust options for sites in NoScript. Some other types of captchas do not require JavaScript, but Google-style captchas require it. Many sites interrupt navigation with captchas, and some do it much more than others. All Tor users have been frustrated with Google-style captchas many years before 8.5a9. If you want search results from Google but without captchas, try the Startpage.com search option that is bundled in Tor Browser. DuckDuckGo uses results from Yandex, I think.

b) YouTube is very dependent on JavaScript unfortunately, so you have to lower to Safer or change NoScript options. To watch videos on Safer, you have to enable Media for youtube.com in NoScript anyway.

The behavior by those sites has been for many years, not recently. Other sites have different requirements for the browser or if the proxy/VPN is open to other users or private. Some sites are friendly to Tor on Safest and are competitors to Google services.

Anonymous

March 22, 2019

Permalink

360 total security detected a trojan upon start up for a 85a8 tor browser when it tried to auto update to version 85a9. just letting you know,

<<<<>>>>>

Anonymous

March 22, 2019

Permalink

Hi. Can you please make use of the bundled Orbot optional? Before the latest release on Android, I could ignore it and configure the Browser to connect to the system Orbot using its socks port no. Perhaps add a checkbox that say "I will use system Tor" to allow me to move past the Tor connection screen. Thanks.

We won't ship a bundled Orbot in the final Tor Browser version for Android. It's currently just there to give us the opportunity to test a desktop flow on mobile (which we want to keep), that is a secure way to start Tor Browser which is then bootsrapping Tor and once that is ready a browser window opens up.

Anonymous

March 23, 2019

Permalink

It's better to remove the torbutton icon in TBB 8.5, because now it looks like a leftover and will shock the users of the stable series.

Anonymous

March 23, 2019

Permalink

Question: I prefer using security on "Safest". Now, if NoScript icon is hidden, please explain how to access it frequently and allow the scripts for the select individual sites. Opening Menu--Add-ons EVERY session (since NoScript can't remember the per-site-permissions) is too much, and reducing the security for all sites including all the 3-rd party scripts, is just bad. Am I missing something?

On a different topic, there is another open-source add-on called uMatrix that remembers the per-site settings and seemingly offers more protection options, and you can probably disable its filtering part if it conflicts with your concept.
I'm familiar with your design goals, but, as the above poster noticed, we actually do need at least some filtering from the spies/trackers -- and that done uniformly for all -- so perhaps this could be somehow re-considered.
Or, say, audit and consider including uBlock Origin that Tails already ships?

Regarding your question there are two answers to it:

1) We reset the toolbar once to start with a clean slate (and we take care with your manually installed icons in #29825). So, if you feel you need more than the security settings and the Torbutton icon, please customize the toolbar as you see fit. In particular, there is nothing that should prevent you to add the NoScript button again and use it as you were used to.

2) We like to expose the sort of functionality you want without adding a NoScript button back. See: https://trac.torproject.org/projects/tor/ticket/25658#comment:109 for a first iteration of what we specified in the accompanying proposal (see: section 2.2 in https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-s…) I am not sure yet, whether we will have this ready for 8.5 but we'll get to it.

For uBlock we have have https://trac.torproject.org/projects/tor/ticket/17569. However, if we really would do that at some point then it will require much more work than auditing it as it currently works badly on higher security levels (https://trac.torproject.org/projects/tor/ticket/23719) and has probably other issue we are not aware of yet. Moreover, the security settings are currently heavily depending on NoScript functionality. Thus, we'd need to disentangle that as well before moving to uBlock instead.

@gk: Thanks for the details. This (hopefully temporary) loss of the functionality to allow-scripts-per_site is horrible. The current 3 levels ("Allow all scripts or none") are just useless. Of course, we want to be normally at the Safest level, but still function at the select sites.
And, since some of us use the stateless machines, now we have to manually return NoScript icon to the toolbar every session. Recommend returning NoScript icon there by default *until your 8.5 is actually out*.

BTW, Section 3.1 of your proposal says "It would be good to point this out in the transition phase to the new interface..." - Indeed. Explain in Changelogs?

"Thus, we'd need to disentangle that as well before moving to uBlock instead." While uBlock has the advantage that Tails has already adopted it, really, the devs should to look at uMatrix by the same author (or a combo of the two). uMatrix gives a lot more controls by site, clearly shows the unneeded 3-rd party junk, allows clearing the browser cache automatically if it's left open for too long, etc. Since it's not only the scripts that track you, it's important to be able to see and block CSS, pictures, frames, etc. per site - and including the 3rd party entries. If your ver. 8.5 proposal is about giving us the same fine level of control - natively, without uMatrix - that would be terrific.

Thanks for those links!

To your 1)
So... simplifying the out-of-the-box experience but allowing power users to restore the features they want. Sounds good. Better than what GNOME 3 did.

To your 2)
I'm on the fence about cascading the top document's restrictions to subdocuments under Safer and Safest. I want a generic browser fingerprint, but I don't want to enable resource-hungry content when I aim to enable a site's basic functionality. If I restore the NoScript button to the toolbar so I can fine-tune permissions myself, I would like to be able to silence the URL bar alerts for those options so they don't annoy me. The canvas or location alerts already annoy users. But then it follows to be able to revert to URL alerts if we wanted, and that might mean wiping the fine-tuned options.

I would also like NoScript (or uBlock Origin or uMatrix) to be able to block XSS automatically and not popup, but that is something to ask those developers, not Tor. I don't think I have ever seen an XSS that had to be allowed.