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 (0.3.4.9), 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 0.3.4.9
    • 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

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.

https://postimg.cc/fVYv19s4
https://postimg.cc/jwDn0pfW
https://postimg.cc/1Vc9LBvn
https://postimg.cc/hXhXdFC2
https://postimg.cc/Yvmp7tDB
https://postimg.cc/N5331mDZ

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.

Anonymous

December 11, 2018

Permalink

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.

"... 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.

Anonymous

December 11, 2018

Permalink

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

Linux

Anonymous

December 11, 2018

Permalink

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 https://metrics.torproject.org/rs.html 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?

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?

Anonymous

December 11, 2018

Permalink

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?

So:
- 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?

Anonymous

December 11, 2018

Permalink

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.

Anonymous

December 11, 2018

Permalink

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 https://trac.torproject.org/projects/tor/ticket/10286#comment:19
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.

Anonymous

December 11, 2018

Permalink

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

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.

So, some progress here. I can reproduce a bug which might be this one with the alpha. But I don't have to complete the onboarding. The links on about:tor don't work right from the beginning. Is that what you are seeing, too? Where do you see the onboarding related exception? I don't see anything like that in the browser console.

Join the discussion...

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

3 + 1 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.