New Release: Tor Browser 8.0.4

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

This release features important security updates to Firefox.

Tor Browser 8.0.4 contains updates to Tor (, OpenSSL (1.0.2q) and other bundle components. Additionally, we backported a number of patches from our alpha series where they got some baking time. The most important ones are

  • a defense against protocol handler enumeration which should enhance our fingerprinting resistance,
  • enabling Stylo for macOS users by bypassing a reproducibility issue caused by Rust compilation and
  • setting back the sandboxing level to 5 on Windows (the Firefox default), after working around some Tor Launcher interference causing a broken Tor Browser experience.

Moreover, we ship an updated donation banner for our year-end donation campaign.

The full changelog since Tor Browser 8.0.3 is:

  • All platforms
    • Update Firefox to 60.4.0esr
    • Update Tor to
    • Update OpenSSL to 1.0.2q
    • Update Torbutton to 2.0.9
      • Bug 28540: Use new text for 2018 donation banner
      • Bug 28515: Use en-US for english Torbutton strings
      • Translations update
    • Update HTTPS Everywhere to 2018.10.31
    • Update NoScript to 10.2.0
    • Bug 1623: Block protocol handler enumeration (backport of fix for #680300)
    • Bug 25794: Disable pointer events
    • Bug 28608: Disable background HTTP response throttling
    • Bug 28185: Add smallerRichard to Tor Browser
  • Windows
    • Bug 26381: about:tor page does not load on first start on Windows
    • Bug 28657: Remove broken FTE bridge from Tor Browser
  • OS X
    • Bug 26475: Fix Stylo related reproducibility issue
    • Bug 26263: App icon positioned incorrectly in macOS DMG installer window
  • Linux
    • Bug 26475: Fix Stylo related reproducibility issue
    • Bug 28657: Remove broken FTE bridge from Tor Browser
  • Build System
    • All Platforms
      • Bug 27218: Generate multiple Tor Browser bundles in parallel

December 11, 2018


Alas, after the update from 8.0.3 to 8.0.4 no text will work. This persists on any website.

I looked into it more. One or several fonts don't work correctly in 8.0.4. It isn't a particular website and not on every website. 8.0.3 works flawlessly. Here are the screenshots to explain better. I don't think it's the tor protocol.

What is the cause for this?

Hard to say. My guess is some software on your system interfering with Tor Browser. Looking at the Changelog for 8.0.4 I somehow doubt this is caused by any of our changes. But maybe that's some weird sandboxing related thing. Does opening about:config and setting security.sandbox.content.level to 2 (and restarting) solve this problem?

security.sandbox.content.level is and was set to 2 already for many reboots and TorBrowser restarts as well. I didn't ever change it. My guess is this setting was and is set to 2 all along. After reading the Changelogs i also doubt if those changes could be the cause. Windows can't be the problem. All TorBrowsers since 4.0.0 and all versions before that run very good. It isn't very likely that some software could pose a problem. 8.0.3 runs. It is only 8.0.4 that suddenly has a bit of a difficulty.
Some software interfering with Tor Browser i would have noticed and would have cleared the problem. I would have happened in previous versions, but it did't.

Did the compiler say anything? Perhaps messages different between 8.0.3 and 8.0.4?

But the sandbox level should be on "5" now after the update. So, I wonder what went wrong in your case, or did you set that preference to "2" yourself?

Additionally, it would not be the first time that minor version updates, especially if they contain updates to Tor as well (which this version does), causes issues with installed Antivirus/Firewall software. So, I would not dismiss that option right from the beginning.

Tried both sandboxing levels 5 and 2. 8.0.4 won't run correctly inside of a VirtualBox VM. Seems sandboxing isn't the problem. No Antivirus. Guest Additions installed. Flashplayer installed, not as plugin or addon.
But aside from that, 8.0.3 and previous versions prevail.
Tried the partial update from 8.0.3 to 8.0.4 and the complete new download of 8.0.4. Doesn't work both ways.
But overwriting the old \Tor directory with the new one, it works with all versions up to 8.0.3.

i love this blog

My issue with fonts is kind of similar but I get a mirror image of the text a lot, even on, this has been happening for a little while not just 8.0.4 maybe since 8.0

imagine the text but when looking in the mirror, it will be upside down and backwards. a lot of time it will refresh by itself and looks fine.

crappy av?

Fix OS leak with javascript

You can't fix js with js

He means: don't expose Linux with js.

I am using Windows 32Bit.

How to use windows 32bit.

I noticed that the Tor manual "' has a pluggable transport called snowflake. When I go to bridges "" I do not see this pluggable transport available.

This pluggable transport works differently than the ones based on bridges. You don't get snowflake bridges out of BridgeDB. You need to have this transport available in your Tor Browser to use it. See: for how it works.

OK. so snowflake is not available for Mac OS as the only built in transports are obfs4, obfs3 and meek azure.

We are still testing it in the alpha series. So, yes, for now it's not available on any of our platforms if you are running Tor Browser stable.

This realease is for Android too?

No, there is no Android version is the current stable series. However there is in the alpha:

Tor often wont work and is incredibly slow. Has this upgrade addressed these issues - or is it a censorship issue in New Zealand.

Also I understand 'Brave' works with Tor - how can I configure this as preferences greyed out.

Thanks a bunch -This crone is not well versed in tech world - but endeavoring to stay ahead of the game.

> or is it a censorship issue in New Zealand

I haven't had any problem connecting to Tor so I'd say definitely not.

"... incredibly slow. Has this upgrade addressed these issues - or is it a censorship issue in New Zealand"
Maybe your ISP has implemented a biased policy against Tor users? (an imaginative guess)

"I understand 'Brave' works with Tor - how can I configure this as preferences greyed out"
I've never tried Brave browser. Are you saying that Brave's preferences won't allow you to set proxy connections (to connect through Tor)?

"stay ahead of the game"
reminding me of the joke about needing only to be faster than someone else, when running from a bear.

Every new open tab freezes the tor browser until it charges. Also, until now, tor browser no integrates with the desktop theme.


8.0.4 seems to be working fine for me! As always, thanks to TB team for all your hard work!

Tip for everyone:
If you use a bridge, occasionally check which version of tor that the bridge is running, and check whether or not the bridge's version is "Recommended" anymore. Go to the Relay Search on and paste the bridge's fingerprint into the search box.

For developers:
It would help if bridges in torrc were automatically checked for "Recommended" tor versions and notice was supplied instead of neglectfully assuming they are all updated.

The bridge check should be in Tor Browser? Or is that supposed to be a check in Tor itself? That said: how should the check happen if one is currently using that bridge? And what is supposed to happen in case the bridge is not "Recommended" anymore?

I'd like to see in Browser Console that guard/bridge is not recommended!

The tor binary could check them itself, and then Tor Browser reads a warning from an output of the tor binary so a warning would be sent to the user regardless of their setup. Users explicitly choose bridges and manually edit connection settings for them, so warnings about bridge status or a reminder to check their flags should at least be displayed to the user.

The network can start its part by removing "Not Recommended" bridges from the BridgeDB request services after a reasonable window of time for operators to update their bridges so the DB is sure to give out "Recommended" and recently expired versions from the start. Next, stronger emphasis could be given to bridge operators in the tor console and to their contact addresses to update in a reasonable window after their version becomes "Not Recommended" or possibly face rejection somehow from the network. Lastly, if taking the extreme step of rejecting very old versions is wise (it might not be for some edge cases), the network could somehow disallow "Not Recommended" bridges from connecting to the network after a reasonable window of time for the operators to update or for the users to find another bridge.

If the user is currently using that bridge, the check could be performed through that possibly old version bridge or optionally accepted by the user through a standard Guard node. Or instead of an automatic check, a periodic reminder (the delay of which could be, say, the length of time that standard Guard nodes are changed) could be displayed to the user to manually visit the Relay Search page and explicitly accept whatever the "Recommended" status of their bridges is. The reminder to check or the response from the program to an explicit "No" answer could include a link to the BridgeDB or related help for the user to find a new bridge if they want.

Is the version value trivial to edit? Can someone take old, "Not Recommended" code, modify the version data to an arbitrary Recommended value, rebuilt it, and pass as Recommended? For that matter, is it trivial to pass as any other flags?

On Tor Browser 8.0.4 (Apple MacOS), screen resolution should be 1000 x 1000, but it is 1000 x 0990.

(On Tor Browser 8.0, 8.1, 8.2, and 8.3 (Apple MacOS), screen resolution should have been 1000 x 1000, but it was 1000 x 0998. On Tor Browser 7.5.6 (Apple MacOS), screen resolution was 1000 x 1000.)

Ticket #27845

Really (?),
it seems there never has been a fixed window size in Mac OS X (for except one time the window was always really fixed to the same size and many people objected to that).
The standard size of an opening window seems to depend on your computer size, screen size and resolution setting, but above all it depends on the setting and place of your applications doc, visible or not?

- Doc visible gives a smaller window
- Doc invisible gives a bigger window
- Using Tails on the same monitor gives (almost?) the same size as in mac os x when having the doc collapsed.
- There are also different sizes between historical versions in combination with the doc settings.

A fast look at some previous browser versions gives at least 4 variation sizes, 1080x1080, 1080x1059, 1080x1044, 1080x989, do not know the exact tails version size right now, but seems to be something around 1080x1080 size.

Btw 1) I did not find the right setting to adjust the standard window size to another value in the about config, or xul file. (What is it?).

Btw2) Does anybody know how to make a screenshot in Tails?

I am having trouble finding the TBB button that normally appears near the URL. Isn't that needed to change the security settings (slider)? I am running in Whonix, if that matters.

Please ask the Whonix project about that. They might have made some customizations that could be the reason for your trouble.

Thank you for such a great browser, job well done.

Bug 25794: Disable pointer events

Bye, bye, smooth scrolling/moving :( But it is finger-printable as hell! Why did you forget to disable it?
Mozilla's spoofing doesn't look great: it's easy to detect whether mouse or touch is used. So, spoofing to mouse is not an option, and
But having Touch and Pointer Events APIs is a must for Android/pads. But now you enabled autodetection (?) for Android only. So, there is a strong need in development of sane fingerprinting protection for those APIs in the next ESR.

it's awesome

Onboarding breaks about:tor after the tour completed and restart:
12:42:09.290 NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref] 1 OnboardingTourType.jsm:30

What is happening in that case (apart from the error getting emitted) and on which platform are you seeing the issue?

Links are no longer clickable on about:tor. Win7.

I tried that with a clean, new Tor Browser 8.0.4 (32bit) on a Windows 7 machine and did the full onboarding (until the globe got greyed out), then restarted. I could neither see the error in the browser console, nor links not functioning. So, I am wondering what I am missing in my steps to reproduce your issue. Hrm.

Indeed, hrm. Donation banner might interfere. Did you test with alpha?