New Release: Tor Browser 8.0.4

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.

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.

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.

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

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?

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?).

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.

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.