New Release: Tor Browser 8.5

[Update 5/22/2019 8:18 UTC: Added issue with saved passwords and logins that vanished to Known Issues section.]

Tor Browser 8.5 is now available from the Tor Browser download page and also from our distribution directory. The Android version is also available from Google Play and should be available from F-Droid within the next day.

This release features important security updates to Firefox.

After months of work and including feedback from our users, Tor Browser 8.5 includes our first stable release for Android plus many new features across platforms.

It's Official: Tor Browser is Stable on Android

Tor Browser 8.5 is the first stable release for Android. Since we released the first alpha version in September, we've been hard at work making sure we can provide the protections users are already enjoying on desktop to the Android platform. Mobile browsing is increasing around the world, and in some parts, it is commonly the only way people access the internet. In these same areas, there is often heavy surveillance and censorship online, so we made it a priority to reach these users.

Tor Browser for Android

We made sure there are no proxy bypasses, that first-party isolation is enabled to protect you from cross-site tracking, and that most of the fingerprinting defenses are working. While there are still feature gaps between the desktop and Android Tor Browser, we are confident that Tor Browser for Android provides essentially the same protections that can be found on desktop platforms.

Thanks to everyone working on getting our mobile experience into shape, in particular to Antonela, Matt, Igor, and Shane.

Note: Though we cannot bring an official Tor Browser to iOS due to restrictions by Apple, the only app we recommend is Onion Browser, developed by Mike Tigas with help from the Guardian Project.

Improved Security Slider Accessibility

Our security slider is an important tool for Tor Browser users, especially for those with sensitive security needs. However, its location behind the Torbutton menu made it hard to access.

Tor Browser Security

During the Tor Browser 8.5 development period, we revamped the experience so now the chosen security level appears on the toolbar. You can interact with the slider more easily now. For the fully planned changes check out proposal 101.

A Fresh Look

We made Tor Browser 8.5 compatible with Firefox's Photon UI and redesigned our logos and about:tor page across all the platforms we support to provide the same look and feel and improve accessibility.

Tor Browser icons

The new Tor Browser icon was chosen through a round of voting in our community.

We'd like to give a big thanks to everyone who helped make this release possible, including our users, who gave valuable feedback to our alpha versions.

Known Issues

Tor Browser 8.5 comes with a number of known issues. The most important ones are:

  1. While we improved accessibility support for Windows users during our 8.5 stabilization, it's still not perfect. We are in the process of finishing patches for inclusion in an 8.5 point release. We are close here.
  2. There are bug reports about WebGL related fingerprinting which we are investigating. We are currently testing a fix for the most problematic issue and will ship that in the next point release.
  3. The upgrade to Tor Browser 8.5 broke saved logins and passwords. We are investigating this bug and hope to provide a fix in an upcoming point release.

We already collected a number of unresolved bugs since releasing Tor Browser 8 and tagged them with our tbb-8.0-issues keyword to keep them on our radar. Check them out before reporting if you find a bug.

Give Feedback

In addition to the known issues, we are always looking for feedback about ways we can make our software better for you. If you find a bug or have a suggestion for how we could improve this release, please let us know.

Full Changelog

The full changelog since Tor Browser 8.0.9 is:

  • All platforms
    • Update Firefox to 60.7.0esr
    • Update Torbutton to 2.1.8
      • Bug 25013: Integrate Torbutton into tor-browser for Android
      • Bug 27111: Update about:tor desktop version to work on mobile
      • Bug 22538+22513: Fix new circuit button for error pages
      • Bug 25145: Update circuit display when back button is pressed
      • Bug 27749: Opening about:config shows circuit from previous website
      • Bug 30115: Map browser+domain to credentials to fix circuit display
      • Bug 25702: Update Tor Browser icon to follow design guidelines
      • Bug 21805: Add click-to-play button for WebGL
      • Bug 28836: Links on about:tor are not clickable
      • Bug 30171: Don't sync cookie.cookieBehavior and firstparty.isolate
      • Bug 29825: Intelligently add new Security Level button to taskbar
      • Bug 29903: No WebGL click-to-play on the standard security level
      • Bug 27290: Remove WebGL pref for min capability mode
      • 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 29239: Don't ship the Torbutton .xpi on mobile
      • Bug 27484: Improve navigation within onboarding (strings)
      • Bug 29768: Introduce new features to users (strings)
      • Bug 28093: Update donation banner style to make it fit in small screens
      • Bug 28543: about:tor has scroll bar between widths 900px and 1000px
      • Bug 28039: Enable dump() if log method is 0
      • Bug 27701: Don't show App Blocker dialog on Android
      • Bug 28187: Change tor circuit icon to torbutton.svg
      • Bug 29943: Use locales in AB-CD scheme to match Mozilla
      • Bug 26498: Add locale: es-AR
      • Bug 28082: Add locales cs, el, hu, ka
      • Bug 29973: Remove remaining stopOpenSecuritySettingsObserver() pieces
      • Bug 28075: Tone down missing SOCKS credential warning
      • Bug 30425: Revert armagadd-on-2.0 changes
      • Bug 30497: Add Donate link to about:tor
      • Bug 30069: Use slider and about:tor localizations on mobile
      • Bug 21263: Remove outdated information from the README
      • Bug 28747: Remove NoScript (XPCOM) related unused code
      • Translations update
      • Code clean-up
    • Update HTTPS Everywhere to 2019.5.6.1
    • Bug 27290: Remove WebGL pref for min capability mode
    • Bug 29120: Enable media cache in memory
    • Bug 24622: Proper first-party isolation of s3.amazonaws.com
    • Bug 29082: Backport patches for bug 1469916
    • Bug 28711: Backport patches for bug 1474659
    • Bug 27828: "Check for Tor Browser update" doesn't seem to do anything
    • Bug 29028: Auto-decline most canvas warning prompts again
    • Bug 27919: Backport SSL status API
    • Bug 27597: Fix our debug builds
    • Bug 28082: Add locales cs, el, hu, ka
    • Bug 26498: Add locale: es-AR
    • Bug 29916: Make sure enterprise policies are disabled
    • Bug 29349: Remove network.http.spdy.* overrides from meek helper user.js
    • Bug 29327: TypeError: hostName is null on about:tor page
    • Bug 30425: Revert armagadd-on-2.0 changes
  • Windows + OS X + Linux
    • Update OpenSSL to 1.0.2r
    • Update Tor Launcher to 0.2.18.3
      • Bug 27994+25151: Use the new Tor Browser logo
      • Bug 29328: Account for Tor 0.4.0.x's revised bootstrap status reporting
      • Bug 22402: Improve "For assistance" link
      • Bug 27994: Use the new Tor Browser logo
      • Bug 25405: Cannot use Moat if a meek bridge is configured
      • Bug 27392: Update Moat URLs
      • Bug 28082: Add locales cs, el, hu, ka
      • Bug 26498: Add locale es-AR
      • Bug 28039: Enable dump() if log method is 0
      • Translations update
    • Bug 25702: Activity 1.1 Update Tor Browser icon to follow design guidelines
    • Bug 28111: Use Tor Browser icon in identity box
    • Bug 22343: Make 'Save Page As' obey first-party isolation
    • Bug 29768: Introduce new features to users
    • Bug 27484: Improve navigation within onboarding
    • Bug 25658+29554: Replace security slider with security level UI
    • Bug 25405: Cannot use Moat if a meek bridge is configured
    • 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
    • Bug 27905: Fix many occurrences of "Firefox" in about:preferences
    • Bug 28369: Stop shipping pingsender executable
    • Bug 30457: Remove defunct default bridges
  • Windows
    • Bug 27503: Improve screen reader accessibility
    • Bug 27865: Tor Browser 8.5a2 is crashing on Windows
    • Bug 22654: Firefox icon is shown for Tor Browser on Windows 10 start menu
    • Bug 28874: Bump mingw-w64 commit to fix WebGL crash
    • Bug 12885: Windows Jump Lists fail for Tor Browser
    • Bug 28618: Set MOZILLA_OFFICIAL for Windows build
    • Bug 21704: Abort install if CPU is missing SSE2 support
  • OS X
    • Bug 27623: Use MOZILLA_OFFICIAL for our builds
  • Linux
    • Bug 28022: Use `/usr/bin/env bash` for bash invocation
    • Bug 27623: Use MOZILLA_OFFICIAL for our builds
  • Android
  • Build System
    • All platforms
      • Bug 25623: Disable network during build
      • Bug 25876: Generate source tarballs during build
      • Bug 28685: Set Build ID based on Tor Browser version
      • Bug 29194: Set DEBIAN_FRONTEND=noninteractive
      • Bug 29167: Upgrade go to 1.11.5
      • Bug 29158: Install updated apt packages (CVE-2019-3462)
      • Bug 29097: Don't try to install python3.6-lxml for HTTPS Everywhere
      • Bug 27061: Enable verification of langpacks checksums
    • Windows
    • OS X
    • Linux
      • Bug 26323+29812: Build 32bit Linux bundles on 64bit Debian Wheezy
      • Bug 26148: Update binutils to 2.31.1
      • Bug 29758: Build firefox debug symbols for linux-i686
      • Bug 29966: Use archive.debian.org for Wheezy images
      • Bug 29183: Use linux-x86_64 langpacks on linux-x86_64
    • Android
      • Bug 29981: Add option to build without using containers
Anon

May 26, 2019

Permalink

Since upgrading to TBB 8.5, I've experienced crashes. Specifically, in less than a week of using it:
* on 4 or 5 occasions: tab has crashed
* on 2 occasions: entire browser has suddenly terminated/closed without warning

On all of these occasions, I was browsing twitter threads at the time. Javascript was disabled. I was not using the mobile version of twitter, but instead hiding the annoying 'javascript is disabled' overlay that twitter uses.

This did not happen to me at all in previous TBB.

Javascript disabled just by setting security to 'safest'.

Haven't managed to pin down a set of steps that always reproduces it.

However, I have noticed that when I run TBB inside a VM, it happens a *lot* more often, and not only on twitter threads, but also on basic, lightweight sites. In that case it happens so often (every few minutes) that TBB becomes virtually unusable - on one occasion, after the whole browser had crashed and I launched it again, it started up with the start tab itself (about:tor) crashed!

As with the non-VM case, it's a mixture of individual tabs crashing (sometimes) and whole browser crashing (slightly more often).

I will check if various factors/variations make a difference, and see if I can come up with a way to reproduce it.

In the meantime, is anyone else experiencing more crashes? I'm surprised if not. I mean, it could be something wrong with my individual machine (bad RAM?) but the way it coincides with the upgrade to a new version, and the lack of any problems with this machine, makes that seem unlikely that's the whole story. (Am also trying not to jump to the conclusion that these are attempts to run an exploit of some sort being run on my machine!)

When using the (32-bit debian) VM, whole browser segfaulted:
1st session: after 7m20 use
2nd session: after 7m25 (just being open while I worked on a text document, no pages browsed)
3rd session: after 40m30 use
4th session: after 8m05 use
5th session: after 2m20 use
6th session: after 40s (didn't have time to browse any pages)
7th session: after 1m20 (didn't have time to browse any pages)

I then decided to restart the VM, since the crashes were getting more frequent. Then:

1st session: tab crashed immediately, but not whole browser - have since been browsing for over an hour with no crashes

I ran a basic command to log CPU usage/free memory, and there does *not* seem to be a pattern of the crashes being preceded by either low memory or high CPU usage.

Will continue to investigate.

OK, I did a RAM test on the affected machine, and found errors. I imagine that's causing the problem - sorry for not trying this sooner!

Not sure why the problems only started with this new version of TBB - either it's a coincidence or the new version happens to be more likely to use the bad areas of RAM due to some change.

I guess the reason I haven't seen issues with any other programs is that I mainly use this machine for TBB, and it simply uses much more memory than anything else I'm running, so more likely to trigger a problem.

Thanks again and sorry for wasting your time - if the problem persists even with good RAM, I'll file a bug.

Anon

May 26, 2019

Permalink

PS Your blog still has that horrible annoying bug where, after posting a comment, the page reloads endlessly. Opening the page in a new tab doesn't fix it. Only 'New Identity' seems to fix it, so maybe due to some cookie or something that is set after commenting?

Again, this is with js disabled.

It has been mentioned in previous comment threads, so if you dig those up, probably someone has already worked out the cause. Thanks :)

Anon

May 26, 2019

Permalink

Some kernel log entries that show the crashes, in case that helps:

Chrome_~dThread[12127]: segfault at 0 ip af39dbe8 sp adaf8c50 error 4 in libxul.so[aef12000+6bc2000]
Web Content[13544]: segfault at 0 ip af00b301 sp bf8b23a0 error 4 in libxul.so[aef97000+6bc2000]
Web Content[11806]: segfault at dea7fff0 ip b100165c sp bfb91790 error 5 in libxul.so[aef82000+6bc2000]
Chrome_~dThread[10430]: segfault at 0 ip af3fd387 sp aebb9080 error 6 in libxul.so[aef51000+6bc2000]
Chrome_~dThread[10407]: segfault at 0 ip af3d0387 sp aeb8c080 error 6 in libxul.so[aef24000+6bc2000]
Chrome_~dThread[10092]: segfault at 0 ip af3dd387 sp aeb9c080 error 6 in libxul.so[aef31000+6bc2000]
Chrome_~dThread[10130]: segfault at 0 ip af450387 sp aec0c080 error 6 in libxul.so[aefa4000+6bc2000]
Web Content[3587]: segfault at 0 ip 004565ee sp bfae4ed0 error 6 in firefox.real[448000+3b000]
Web Content[6860]: segfault at 0 ip 0045c5ee sp bfc0f230 error 6 in firefox.real[44e000+3b000]
Chrome_~dThread[7985]: segfault at 0 ip af48c387 sp aec48080 error 6 in libxul.so[aefe0000+6bc2000]
Chrome_~dThread[2989]: segfault at 0 ip af456387 sp aec12080 error 6 in libxul.so[aefaa000+6bc2000]
Chrome_~dThread[2942]: segfault at 0 ip af3f4387 sp aebb0080 error 6 in libxul.so[aef48000+6bc2000]
Chrome_~dThread[7963]: segfault at 0 ip af414387 sp aebd0080 error 6 in libxul.so[aef68000+6bc2000]
Chrome_~dThread[16856]: segfault at 0 ip af48f387 sp aec4b080 error 6 in libxul.so[aefe3000+6bc2000]
Chrome_~dThread[16651]: segfault at 0 ip af3c7387 sp aeb83080 error 6 in libxul.so[aef1b000+6bc2000]
Chrome_~dThread[16612]: segfault at 0 ip af4ad387 sp aec69080 error 6 in libxul.so[af001000+6bc2000]

Anon

May 27, 2019

Permalink

Sandboxing: I am a bit confused and I am sure that I am not the only one.

On the subject of this release there are some comments that sandboxing does not work. Is that true? If it is, what is the sandboxing shown under about:config with a value of 5?

Expanation please.

Thank you

There are different kinds of sandboxing. The one you see in about:configis a browser-internal one where the process(es) all the content is running in is/are sandboxed to prevent potential issues affecting the whole Firefox or your host system.

The sandboxing that is supposed to not work anymore is one that is done by an external tool which is running the whole Firefox inside a sandbox (where the content processes are additionally sandboxed as explained above).

Anon

May 27, 2019

Permalink

> Backport SSL status API

This is brilliant!

Thanks for doing this - since mozilla phased out legacy extensions without bothering to ensure WebExtensions had the same functionality, I've been waiting ages for a tor browser that would allow access to certificate info again.

I assumed I would have to wait until much later this summer when the first alpha tor browser would be based on the next firefox ESR - it never occurred to me to ask for that API to be backported - never thought that was an option.

Now it's happened without me even needing to request it - or having to use an alpha version. This is great :)

Anon

May 28, 2019

Permalink

Contrary to what's said in the blog post, I find that changing the security setting is now slightly harder, not easier. It's the same number of clicks, but the interface isn't as nice. Also, when the browser switches to the about:preferences tab, memory of which tab was newest opened is lost, adversely affecting tab navigation experience when the user opens multiple links in new tabs.

I understand there's been a design decision to put the security slider in about:preferences to prevent accidental changes to the security setting, and to make it clear that the setting takes effect on all tabs (https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-s…).

I personally would like to see the security slider immediately after clicking on the shield icon, rather than additionally needing to click on the "Advanced Security Settings..." button that brings up a new about:preferences tab that shows 3 small radio buttons.

I really like that the security setting is visible simply by looking at the shield icon though! :-)

Thanks for the feedback. I am not sure I understand the "memory of which tab was newest opened is lost". Let's say I have three tabs open and the second one has focus. Then I click on the shield and change the security level and then I close that about:preferences tab again. I get back to the second tab that had focus, which seems expected to me. Do you see something differently?

I can see why you'd like to save one click and get the directly to about:preferences when clicking on the icon. However, the shield icon serves different purposes: One is to immediately show the security level. Then it should give the option to change the level. But, thirdly, it should inform users what the level means and provide access to further information. Fourthly, it should caution the user to use the slider to just change the setting for a particular site because changing it affects the whole browser session (meaning all the other open tabs as well). All that is hard to achieve if one directly goes to about:preferences by just clicking on the icon.

Thank you for the reply.

Actually, I personally would like to see the security slider (like the compact one that existed prior to version 8.5) immediately when I click on the security shield button. The about:preferences interface is less friendly.

I'm not sure how best to make it clear to users that the security setting affects all tabs without putting those settings into about:preferences. Placing some kind of warning message near the security slider would be all I could think of.

Sorry for not being clear about the last opened tab memory matter. Also, it's not a major problem, just something I observe before/after the change to version 8.5.

When I open multiple links in new tabs, those tabs appear to the right of the current tab, in the order (left-right) that I click on the links. If I then wish to change the security setting, I need to open a tab for about:preferences. After changing the security setting and closing about:preferences, as you explained I do appear back at the tab I was focused on. However, when I open more links in new tabs, those links now appear immediately after the current tab, not after the tab of the last link I clicked before opening about:preferences, so the order (left-right) of the new tabs is no longer the order that I opened them.

Your tab issue is the normal behavior of Firefox. Tor Browser is based on Firefox ESR. In about:config, three boolean settings affect it:

  • browser.tabs.insertRelatedAfterCurrent, for links you open
  • browser.tabs.selectOwnerOnClose jumps back to the original tab
  • browser.tabs.insertAfterCurrent, for blank New Tabs. Not yet in Tor Browser standard releases.

Current Firefox versions forget the owner (parent/stem) tab when another tab is given focus, including if that other tab is a related (child/leaf) tab. Your issue is based on insertRelatedAfterCurrent. The behavior that gk described is based on selectOwnerOnClose. If you want Firefox to remember the state of all tab relation trees as you move between tabs, create a ticket on Mozilla's bug tracker.

Could you explain what you mean by "isn't as nice" and "less friendly"? I agree in some sense, but I think it was one of their intentions. Aesthetics aside, a slider communicates the levels more quickly but is physically easier for mouse and touch users to manipulate. Radio buttons slow down interpretation and interaction. Slowing, discouraging, or worst of all, confusing a user's interpretation is bad, but slowing a user's manipulation of this option is good. Radio buttons also improve accessibility compared to the way they set up the slider because the text descriptions for each level are always on screen.

Anon

May 29, 2019

Permalink

Since no-script is hidden by default(can get appeared by customize), the default security level should be safest but not standard.

I also feel that Tor Browser shouldn't be shipped with the security setting set to "Standard" mode.

I did the following:

  • Add the following line to <tor-browser-path>/Browser/TorBrowser/Data/Browser/profile.default/user.js:
    user_pref("extensions.torbutton.security_slider", 1);
    (a value of 1 is for "Safest", and I believe 2 is for "Safer" and 4 is for "Standard")
  • Put NoScript back onto the toolbar. I want to clearly see whether or not Javascript is running and from what domains.

Does doing any of the above harm the browser's anonymity??

I think that should be okay, because we assume you are not the only one using the Safest settings. I agree with you that we might want to get to a default security settings of level "Safer" for Tor Browser. But we are not there yet as the usability penalty due to site breakage is still too high right now.

Anon

May 29, 2019

Permalink

When using transport meek-azure on a Mac OS, 2 process names open called "tor browser" instead of just 1. Is this normal or a fault?

Anon

May 30, 2019

Permalink

Why is the listed IP for the ExitNode in Tor Circuit informations not the same as shown in ip-check.info test results for 'your ip' ?

There could be different reasons for this, so this is hard to say without looking at what is actually going on. What often happens for this kind of tests is that they first try to determine your IP address and then bounce you off to different domains testing various tracking mechanisms and you finally land on the results page showing the IP they saved first together with the other results. However, that bouncing off to other domains causes different circuits to be used and thus, your circuit display gets updated which causes the effects you see.

thx
whoer.net is identical to ip-check.info, another (my) IP than listed in Tor Circuit, but other myip info sites are identical with the listed ExitNode, so far so good. How could it be, to find some IPs in protocol using Tor, with 0 zero bytes send, but 3 bytes received. Is this ok and has technical reasons, because should never happended at all using firewall, e.g. found 212.51.156.89 with that and 37.191.193.148 too and this one with destination port 38443, both 0 zero bytes send from own system, 3 bytes received by own system. Why received without started connection?

Sry, there was a fault in my post, 0 zero packets send and 3 packets received wasn't from system view, the data log shows the outside IPs view, so my system had send 3 packets to Tor IP x.x.x.x, but received none, so that's how it should work and hadsdone, sry.

Next question. Actually, I always used to see all Tor connected IPs with minimum some packets send and some packets received (e.g. 3 send, 3 received). So this behaviour, see my last posts, the Tor Node gets 3 packets from own system and didn't done handshake, means Tor Node didn't answer, I didn't mentioned before. Is there an explanation for this?

In addition to this ticket (thanks GeKo), do you know how to obtain system logs from this device (using adb logcat, or similar) and, if yes, can you provide the crash log stack trace for it? Either providing it here or on the ticket are good.

Also, did you try the new alpha version? There isn't much difference between the stable and alpha version, but confirming the alpha version crashes would be good, too.

Anon

May 31, 2019

Permalink

despite being on tor browser whenever i try to use any onion links. it tells me that i need to download tor browser to access the link BUT im on tor browser when it says that??? can anyone help im so confused XD

Idea: there should be an official TP list, easy to find in TP website, describing some things to mention in any TBB bug report. For example:

o what operating system are you using?

o where did you get Tor Browser and how did you install it? did you verify the detached signature before installing? [How does one replace "detached signature" with concise ordinary language? I have no idea.]

o are you running multiple instances of Tor or Tor Browser? [How does one replace the technical term "instance" with concicse ordinary language? Nothing comes to mind.]

o what exactly did you type into the Tor Browser location pane and exactly what happened next? [How does one replace "location pane" with concise ordinary language? How to handle fact most users will be too stressed to write down exactly what happened for a bug report? I have no idea.]

I have no idea if this is helpful in answering the OP but it might start some wheels turning about improving Tor Browser support.

Anon

May 31, 2019

Permalink

I can not run my Obfs4 bridge which works normorally on PC in TBB for Android. Can you check it? Please!
In addition, there are only 2 kinds of bridge(Obfs4 and Meek azure) can be used in China. We need more new kinds of bridge!

Anon

June 02, 2019

Permalink

Now that the NoScript button has been removed, how am I supposed to whitelist JavaScript on one website? (I use Safest mode.) For example, youtube.com.