New Release: Tor Browser 9.0a7

Tor Browser 9.0a7 is now available from the Tor Browser Alpha download 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 recommend downloading the latest stable release instead.

This is the second alpha release based on Firefox ESR68. This new release contains various improvements and bug fixes. Among them, the Snowflake pluggable transport is now available on Windows too, the issue with non-reproducible builds for the 32bit Linux and Windows bundles have been fixed (we are still working on fixing the issue with the Android ones), and we added support for the x86_64 target on Android (fulfiling Google Play's new requirement for 64bit versions, allowing us to provide an x86 version again). This release also updates Tor to 0.4.2.1-alpha on desktop and 0.4.1.5 on Android. Finally, this alpha release is the first one that is compatible with the upcoming new macOS version (10.15).

Known issues:

  • The build of Tor Browser 9.0a7 for Android is not reproducible right now. We plan to fix this in the next alpha release, to give the usual guarantees reproducible builds aim to provide.
  • New Identity and the bridge configuration in the browser are not easily accessible anymore as we removed the onion button. We are currently working on a replacement for both: New Identity will be exposed directly in the toolbar and the bridge configuration gets integrated in the Firefox settings. For New Identity please use the shortcut (Ctrl+Shift+U) for now or the item in the hamburger menu.
  • Tor Browser on macOS can't get closed from the app menu anymore and other app menu items are not working either.
  • We already have a number of known tickets we need to work on in the coming weeks. The most important ones are tagged with the tbb-9.0-must-alpha keyword. Moreover, we have accumulated Firefox 68 ESR related issues over the time that can easily be queried with our ff68-esr keyword.

If you find any issue with this release, please help us by reporting them so we can fix as much as we can before the first stable release based on ESR68, which is planned for October 22.

The full changelog since Tor Browser 9.0a6 is:

  • All platforms
    • Bug 30304: Browser locale can be obtained via DTD strings
    • Bug 31065: Set network.proxy.allow_hijacking_localhost to true
    • Bug 24653: Merge securityLevel.properties into torbutton.dtd
    • Bug 31725: Pick up mk in Torbutton properly
    • Bug 31164: Set up default bridge at Karlstad University
    • Bug 15563: Disable ServiceWorkers on all platforms
    • Translations update
  • Windows + OS X + Linux
    • Update Tor to 0.4.2.1-alpha
    • Update OpenSSL to 1.1.1d
      • Bug 31844: OpenSSL 1.1.1d fails to compile for some platforms/architectures
    • Update Tor Launcher to 0.2.19.4
      • Bug 31303: Do not launch tor in browser toolbox
      • Bug 31491: Clean up the old meek http helper browser profiles
      • Translations update
    • Bug 31598: Disable warning on window resize if letterboxing is enabled
    • Bug 31562: Fix circuit display for error pages
    • Bug 31575: Firefox is phoning home during start-up
    • Bug 31491: Clean up the old meek http helper browser profiles
    • Bug 26345: Hide tracking protection UI
    • Bug 31601: Disable recommended extensions again
    • Bug 30662: Don't show Firefox Home when opening new tabs
    • Bug 31457: disable per-installation profiles
    • Bug 28822: Re-implement desktop onboarding for ESR 68
    • Bug 25483: Provide Snowflake based on Pion for Windows, macOS, and Linux
  • Windows
    • Bug 30800: ftp:// on Windows can be used to leak the system time zone
  • OS X
    • Bug 30126: Make Tor Browser on macOS compatible with Apple's notarization
    • Bug 31702: Backport Mozilla's bug 1578075
  • Linux
    • Bug 31646: Update abicheck to require newer libstdc++.so.6
    • Bug 31380: Snowflake does not start on older Linux systems
  • Android
    • Update Tor to 0.4.1.5
    • Bug 31192: Support x86_64 target on Android
    • Bug 30380: Cancel dormant by startup
    • Bug 30943: Show version number on mobile
    • Bug 31720: Enable website suggestions in address bar
  • Build System
    • All platforms
      • Bug 31621: Fix node bug that makes large writes to stdout fail
      • Bug 27493: Clean up mozconfig options
      • Bug 31308: Sync mozconfig files used in tor-browser over to tor-browser-build for esr68
    • Windows
      • Bug 30384: Use 64bit containers to build 32bit Windows Tor Browser
      • Bug 31538: Windows bundles based on ESR 68 are not built reproducibly
      • Bug 31584: Clean up mingw-w64 project
      • Bug 31596: Bump mingw-w64 version to pick up fix for #31567
      • Bug 29187: Bump NSIS version to 3.04
      • Bug 31732: Windows nightly builds are busted due to mingw-w64 commit bump
    • Linux
      • Bug 31448: gold and lld break linking 32bit Linux bundles
      • Bug 31618: linux32 builds of Tor Browser 9.0a6 are not matching
      • Bug 31450: Still use GCC for our ASan builds
Anonymous

October 05, 2019

Permalink

Regarding the bug smash project:

Some years ago comments in this blog warned that attackers are likely to exploit bugs to mess with the PRNG because non-randomness is less likely to be noticed. Just such an attack on Firefox has been described:

Kaspersky warns of encryption-busting Reductor malware
Infection manipulates browsers to snoop on TLS comms
Shaun Nichols in San Francisco
3 Oct 2019

> ...
> "The solution that Reductor’s developers found to mark TLS traffic is the most ingenious part," Kaspersky explained. "They don’t touch the network packets at all; instead developers analyzed the Firefox source code and Chrome binary code to patch the corresponding pseudo random number generation (PRNG) functions in the process’s memory." By compromising the random number generator, the malware's operators would know ahead of time how the traffic will be encrypted when the victim establishes a TLS connection, and have the ability to mark that traffic for later use. From there, the malware can easily decode the traffic and see what the transmitted data is, then send anything of interest back to the command server. Because this data can be decoded, the attacker has no need to actually tamper with the traffic while it is in transit, and thus is able to function without alerting security tools or administrators that something is amiss.

Anonymous

October 05, 2019

Permalink

TypeError: videoElement is undefined TopLevelVideoDocument.js:21:5
setFocusToVideoElement chrome://global/content/TopLevelVideoDocument.js:21

Do you have steps to reproduce this problem? If so, which are they?

Open any video file / direct link in a new tab.

I did that with https://live.serve-u.de/transfer/cccamp2019/CCCamp2019_night_4k_Stream… on my Linux box but did not see any error message in the browser console. Which operating system are you on?

Win 10 1903

What does "dies" mean here? I can play this video on a Windows 7 box fine.

The latest version of Windows is 10.0.18362.356. And there:
Media resource blob:https://demo.bitmovin.com/5e6cbd25-351b-43aa-93b6-72e6b87fdae8 could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005)
Details: error creating Video decoder av1

https://bugzilla.mozilla.org/show_bug.cgi?id=1376814 or move out the default extensions (they should be moved from profile to application directory anyway).

I tested both TB855 and this alpha, and noticed a strange difference. The stable release only uses tor.exe to connect to the web, but the alpha also attempts to connect via firefox.exe.
Not sure what this means. But I recently spend 2 days trying to stop a fresh Firefox install from making unsolicited connections to the web (without success). So I wonder if this is related.

Where are those connections going to? And how do you see that firefox.exe is making connections in the first place?

I have ComodoFirewall installed.
Here are some IPs Firefox.exe is trying to connect to:
93.184.221.240:80
8.247.186.126:80
5.102.166.9:80
5.102.166.10:80
13.107.4.50:80

Does TOR Browser for Android support custom obfs4 bridges? It seems to me it doesn't.

This code of conduct is shared under a Creative Commons CC-BY-SA 4.0
International license.

This code of conduct uses some language and framing from the Citizen Code of
Conduct, which is shared under a CC-BY-SA license: citizencodeofconduct.org

[1] https://trac.torproject.org/projects/tor/wiki/org/CommunityCouncil
[2] https://gitweb.torproject.org/community/policies.git/tree/community_cou…

So, you claim the licenses are incompatible? Or that we did not mention the other website as inspiration? Or...?

I'm guessing you're aware of this, but in any case - I get this in my output on GNU/Linux:

Fontconfig warning: "/path/Browser/TorBrowser/Data/fontconfig/fonts.conf", line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf

Fontconfig on my system is at version 2.12.6.

Yes, see: https://trac.torproject.org/projects/tor/ticket/22787. It just did not bubble up into our ToDo list. :( (Please help if you can)

Rebasing TBB on FF68 seems like it's taking a lot of effort. Thank you, for all your hard work!

It does indeed take a lot of effort, thanks!

https://www.ghacks.net/2019/10/09/hide-private-mode-for-firefox-prevent…
"prevents private browsing mode detection" is a must-have.

Why don't you return meek-cloudflare as one of the default bridges now that CloudFlare supports ESNI? Isn't that even better than to use domain fronting on Azure?

There has been some initial work and evaluation on using ESNI in meek (see https://trac.torproject.org/projects/tor/ticket/28168).

However, we're not moving forward with it immediately for two main reasons:

1) ESNI hasn't seen widespread deployment or adoption yet. We're concerned that relying on it would just get ESNI blocked by censors before it has a chance to proliferate. See the following discussion in the traffic obfuscation mailing list for more details: https://groups.google.com/forum/#!msg/traffic-obf/e7y4xQRUrXA/sE0aSpnpB…

2) It would be technically difficult to integrate ESNI after moving to meek-lite with uTLS, since golang doesn't yet have ESNI support. Waiting for this support might be one way to ensure that ESNI has been adopted widely enough to move forward :)

Error: Cannot start installing from this state XPIInstall.jsm:1346:15

How can I reproduce this error message?

Request to access cookie or storage on “https://www.https-rulesets.org/v1//rulesets-signature.1570565711.sha256” was blocked because we are blocking all third-party storage access requests and content blocking is enabled. _generated_background_page.html

really noisy spam or real access?

Not sure. How can one reproduce that message?

every other rulesets update, automatic

Okay, I've filed https://trac.torproject.org/projects/tor/ticket/32107. If there is more to add, please do in the bug ticket.

this.inputField is undefined UrlbarInput.jsm:818
_setValue resource:///modules/UrlbarInput.jsm:818
set value resource:///modules/UrlbarInput.jsm:792
URLBarSetURI chrome://browser/content/browser.js:3351
onLocationChange chrome://browser/content/browser.js:5885
callListeners chrome://browser/content/tabbrowser.js:841
_callProgressListeners chrome://browser/content/tabbrowser.js:855
_callProgressListeners chrome://browser/content/tabbrowser.js:5499
onLocationChange chrome://browser/content/tabbrowser.js:5919
_callProgressListeners resource://gre/modules/RemoteWebProgress.jsm:119
onLocationChange resource://gre/modules/RemoteWebProgress.jsm:161
receiveMessage resource://gre/modules/RemoteWebProgress.jsm:286

How can I reproduce this error?

every NS CTP

Could you spell "NS CTP" out? I have no idea what that means.

noscript click-to-play

File not found

An error occurred during a connection to onlinefreechat.com.

Check the file name for capitalization or other typing errors.
Check to see if the file was moved, renamed or deleted.

WTF?

Have a look what the page source says: "TOR is blocked due to spam and scams".

Yep, but why does TBB show "File not found"?

InvisibleToDebugger: DOMException { }
history-persistence.js:31:15
historyPersistenceMiddleware resource://devtools/client/webconsole/middleware/history-persistence.js:31

How can we reproduce this exception?

IDK

Seems to perform much more smoothly than previous stable versions (<= 8.5.x). In particular, it now loads and opens immediately, even when set to higher security levels. In previous versions it would take quite some time while spinning up CPU. I've also tested with uBlock Origin and there is no impact on performance at all, across all security levels. I think Bug 23719 might be considered fixed.

In any case, great work!

Thanks! Interesting that #23719 is not an issue anymore. Either way, we'll have a patch there shortly to be extra sure we are not affected by that bug anymore. So, we'll close the ticket once this lands.

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

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

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