New Release: Tor Browser 9.0a8

by boklm | October 15, 2019

Tor Browser 9.0a8 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 last alpha release before the first stable release in the 9.0 series, which is planned for next week. It contains various fixes and improvements. Among them, we added a New Identity button to the toolbar, we included Tor network settings into about:preferences, we fixed the App menu items on macOS, and we solved the issue which made the Android build non-reproducible.

Known issue:

  • While building this release and checking that the build is reproducible, we found that our linux32 and macOS bundles did not match. However this seems to be an intermittent issue, as triggering a rebuild caused our builds to match. We are currently investigating the issue.

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 next week, October 22.

The full changelog since Tor Browser 9.0a7 is:

  • All Platforms
    • Bug 13543: Spoof smooth and powerEfficient for Media Capabilities
    • Bug 28196: about:preferences is not properly translated anymore
    • Bug 19417: Disable asmjs on safer and safest security levels
    • Bug 30463: Explicitly disable MOZ_TELEMETRY_REPORTING
    • Bug 31935: Disable profile downgrade protection
    • Bug 31811: Backport fix for bug 1554805
    • Bug 16285: Disable DRM/EME on Android and drop Adobe CDM
    • Bug 31602: Remove Pocket indicators in UI and disable it
    • Bug 31914: Fix eslint linter error
    • Translations update
  • Windows + OS X + Linux
    • Update Tor to 0.4.2.2-alpha
    • Update Tor Launcher to 0.2.19.5
      • Bug 31286: New strings for about:preferences#tor
      • Translations update
    • Bug 31286: Provide network settings on about:preferences#tor
    • Bug 31886: Fix ko bundle bustage
    • Bug 31768: Update onboarding for Tor Browser 9
    • Bug 27511: Add new identity button to toolbar
    • Bug 31778: Support dark-theme for the Circuit Display UI
    • Bug 31910: Replace meek_lite with meek in circuit display
    • Bug 30504: Deal with New Identity related browser console errors
    • Bug 31929: Don't escape DTD entity in ar
    • Bug 31747: Some onboarding UI is always shown in English
    • Bug 32041: Replace = with real hamburguer icon ≡
  • Windows
    • Bug 31942: Re-enable signature check for language packs
    • Bug 29013: Enable stack protection for Firefox on Windows
  • OS X
    • Bug 31607: App menu items stop working on macOS
    • Bug 31955: On macOS avoid throwing inside nonBrowserWindowStartup()
  • Linux
    • Bug 31942: Re-enable signature check for language packs
    • Bug 31968: Don't fail if /proc/cpuinfo is not readable
    • Bug 24755: Stop using a heredoc in start-tor-browser
    • Bug 31550: Put curly quotes inside single quotes
  • Android
    • Bug 31822: Security slider is not really visible on Android anymore
  • Build System
    • All Platforms
      • Bug 31293: Make sure the lo interface inside the containers is up
    • Windows
      • Bug 29013: Enable stack protection support for Firefox on Windows
    • Android
      • Bug 31564: Make Android bundles based on ESR 68 reproducible
      • Bug 31981: Remove require-api.patch
      • Bug 31979: TOPL: Sort dependency list
      • Bug 30665: Remove unnecessary build patches for Firefox

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

October 15, 2019

Permalink

One Tor Browser quirk that's been quite annoying for the past few major releases is the way it interacts with dconf database on GNU/Linux. It seem this is because Tor Browser runs with only "partially" modified HOME environment variable which results in strange behavior.

It does not to read the values from the user's dconf database, which is of course how it should be. Because it can't find such database under modified HOME, the values used are the defaults. This is expected behavior. Yet at the same time it somehow manages to write these default values to user's dconf database under original HOME nonetheless. In effect, this results in user's dconf values (which are used outside of Tor Browser by other programs) being continuously reset by Tor Browser to defaults.

One noticeably example is the file dialog in Tor Browser (GTK3 FileChooser) which resets org.gtk.Settings.FileChooser values. In practice this means GTK3 file dialog is reset to its default behavior in all other programs that use it. For example, the window size of the dialog maxes out.

Another way to confirm this is by copying ~/.config/dconf/user to Browser/.config/dconf/user. What happens is that Tor Browser now reads values from this copied file and thus does not use default values, but it still writes values to the first original file in original HOME instead of the second one in modified HOME. So to reiterate, it reads (or tries to read) dconf values from the modified HOME, but then writes them to the original HOME. And for some things like the file dialog above this write operation is performed just by opening the dialog without actually doing anything with it.

Now in this narrow case of dconf this can all legitimately be dismissed as upstream's inconsistent use of the HOME variable. However in the long run I think a better approach should be developed that more thoroughly modifies and isolates the environment that Tor Browser runs in. I know there were some abandoned sandboxing attempts in the past, however even a dumb approach like using a "chroot jail" would be better in the meantime than the current situation.

What would you suggest as an isolation of Tor Browser that we can setup ourselves?

I've been experimenting with apparmor profiles from torbrowser-launcher, adding rules to explicitly deny read/write access to ~/.config/dconf. But Tor Browser still writes to those files. It seems GTK3 stuff is being done in some other process.

So I've decided to go with the completely opposite approach by just creating a Browser/.config/dconf -> ~/.config/dconf symlink. This removes the problem with Tor Browser resetting user's GTK3 values, I just don't know if this is potentially de-anonymizing. If not you might add this symlink to your linux releases.

Anonymous (not verified) said:

October 17, 2019

Permalink

The symlink only fixes the issue in the 8.5 release, I'm sorry. In this alpha the symlink has no effect, the problem remains. Or maybe it has nothing to do with versions themselves but with some other conditions, it's hard to tell what gtk settings daemon is actually doing.

Anyway, the root of the issue seems to be an inconsistent environment: HOME variable is changed, but that's not enough. I'm not sure there's any portable way to enforce Browser/ as a home directory. Hypothetically one could use some chroot hacks, but that's probably too specific to each user's system.

What happens is that Tor Browser now reads values from this copied file and thus does not use default values, but it still writes values to the first original file in original HOME instead of the second one in modified HOME.

dconf has a partial client/server architecture. It uses D-Bus. The server is only involved in writes (and is not activated in the user session until the user modifies a preference).

A "user-db" line specifies a user database. These databases are found in $XDG_CONFIG_HOME/dconf/. The name of the file to open in that directory is exactly as it is written in the profile. This file is expected to be in the binary dconf database format. Note that XDG_CONFIG_HOME cannot be set/modified per terminal or session, because then the writer and reader would be working on different DBs (the writer is started by DBus and cannot see that variable).

What would you suggest as an isolation of Tor Browser that we can setup ourselves?

We can isolate Tor Browser from dconf-service:
add to tor-browser_en-US/Browser/start-tor-browser
export GSETTINGS_BACKEND=memory

Anonymous (not verified) said:

October 16, 2019

Permalink

at startup:
XML Parsing Error: undefined entity
Location: moz-nullprincipal:{508267cc-699c-4b82-aa3f-645e54660f44}
Line Number 1, Column 143: {508267cc-699c-4b82-aa3f-645e54660f44}:1:143

Anonymous (not verified) said:

October 16, 2019

Permalink

Win10x64

Anonymous (not verified) said:

October 16, 2019

Permalink

Yes.

Anonymous (not verified) said:

October 16, 2019

Permalink

about:plugins:
NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow] WebNavigationContent.js:267

Anonymous (not verified) said:

October 16, 2019

Permalink

when moving a tab:
TypeError: event.originalTarget.getAttribute is not a function tabbrowser.xml:2310:34
onxblmouseover chrome://browser/content/tabbrowser.xml:2310

Anonymous (not verified) said:

October 16, 2019

Permalink

Bug 28196: about:preferences is not properly translated anymore:
" This brand name can be used in messages where the product name needs to
remain unchanged across different versions (Nightly, Beta, etc.). -->"
Why did you make all product names unchanged (not only mentioned above)?

I wonder whether the above could be related to this:

On Thinkpad laptop with recent editions of Tor Browser under Tails and Debian 10, I sometimes experience a "freeze". I guess this might be an unwanted side effect of mitigations of Meltdown/Spectre type vulnerabilities.

On Dell laptop under Tails and Debian 10 I sometimes experience temporary "freezes" which can usually be overcome by pressing the "Microsoft" button.

Anonymous (not verified) said:

October 16, 2019

Permalink

Bug 30463: Explicitly disable MOZ_TELEMETRY_REPORTING:
If you disable MOZ_SERVICES_HEALTHREPORT, then Mozilla claims it also "Removes the Data Collection Preferences UI".

Anonymous (not verified) said:

October 16, 2019

Permalink

Bug 31935: Disable profile downgrade protection:
Why do you disable this useful feature that prevents damage to Tor Browser? Didn't it detect a mess with esr60 & esr68 profiles on MacOS?

Anonymous (not verified) said:

October 17, 2019

Permalink

What details? You mean downgrading a profile instead of creating a new one is your choice, right?

Anonymous (not verified) said:

October 16, 2019

Permalink

> Bug 31286: Provide network settings on about:preferences#tor
"Select a built-in bridge", etc allows to be saved as empty setting.

Anonymous (not verified) said:

October 16, 2019

Permalink

> Bug 29013: Enable stack protection for Firefox on Windows
-fstack-protector-strong appears 2 times in about:buildconfig

As for security, -fstack-protector* is another thing not properly implemented in clang, it leaves the stack guards in registers so makes it easier for exploits to store the value back.

Anonymous (not verified) said:

October 16, 2019

Permalink

Bug 30504: Deal with New Identity related browser console errors

TypeError: win.gBrowser is undefined ProcessHangMonitor.jsm:418:18

Anonymous (not verified) said:

October 16, 2019

Permalink

The new icon for new identity projects an image of something being merely cleaned or cleared. What's missing is the idea of restarting the session, that is to say, as if Tor Browser itself restarted. The fact that all existing windows actually close and a new fresh window opens is a great way of signalling that, it gives the user the feeling that they started completely afresh in a new session. (Which is why the fact that windows close and open on newnym should not be "fixed" because it's too "brusque", it's a good UX feature.)

The old icon, despite its shortcomings (e.g. can be mistaken for the "reload page" icon), nevertheless had this advantage because the spin/circle arrow symbolized restarting of the session. It also fit somewhat nicely with the "New Tor Circuit" icon (Tor onion with the spin arrow) whereas the broom icon doesn't fit in very well with the rest of icons, it doesn't seem to be TBB-related.

Maybe you could base the new icon on a flat version of the TBB icon itself (half-open onion). I think just adding a plus emblem or a reload spin arrow to the half-open onion could work very well given the fact that TBB windows will actually close and a new window will appear, as if TBB itself has restarted afresh. The icon would more clearly signify what happens before being used the first time, and the user would more easily make the intuitive association on subsequent uses.

I'm more inclined towards the spin arrow though, because the plus emblem symbolizes an addition to the current state, whereas the spin arrow is more directly associated with restarting or reloading something i.e. the previous thing gets discarded and replaced by a new one in its stead.

Anonymous (not verified) said:

October 16, 2019

Permalink

4pr? WTF?
10/16/19, 14:06:58.505 [NOTICE] Switching to guard context "bridges" (was using "default")
10/16/19, 14:06:58.506 [WARN] CreateProcessA() failed: The system cannot find the file specified.
10/16/19, 14:06:58.506 [WARN] Failed to start process: TorBrowser\Tor\PluggableTransports\obfs4pr
10/16/19, 14:06:58.506 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\obfs4pr' failed at launch.

Anonymous (not verified) said:

October 16, 2019

Permalink

Oh, fuck, it's #31286 damaged the default:

# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it

ClientTransportPlugin meek_lite,obfs2,obfs3,obfs4,scramblesuit exec TorBrowser\Tor\PluggableTransports\obfs4pr
ClientTransportPlugin snowflake exec TorBrowser\Tor\PluggableTransports\snowflake-client.exe -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302
DataDirectory C:\Tor Browser\Browser\TorBrowser\Data\Tor
GeoIPFile C:\Tor Browser\Browser\TorBrowser\Data\Tor\geoip
GeoIPv6File C:\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6
ReachableAddresses *:80,*:443

Anonymous (not verified) said:

October 17, 2019

Permalink

Isolating obfs4proxy.exe by many different ways led to a situation where it died hard many times. And switching tor properties back and forth many times finally led to this bug occurred which prevented further experiments. But it is some piece of code that wrote a torrc truncated line, right?

Anonymous (not verified) said:

October 17, 2019

Permalink

Do you really have a lot of places in code that write ClientTransportPlugin string? It seems there should be no cases to overwrite it, at first glance.

Anonymous (not verified) said:

October 19, 2019

Permalink

OK, it appears to be quite easily destroy-able: just cycle through the built-in bridges, and it starts doing bad things on a second loop.

What kind of bad things? What error messages do you get? And what second loop do you mean? How are you cycling through the built-in bridges?

I tried that with the release candidate for 9.5a1 but I did not get any broken bridge functionality.

Anonymous (not verified) said:

October 21, 2019

Permalink

obfs4 -> meek-azure -> snowflake -> obfs4 -> meek-azure = ClientTransportPlugin destroyed

So the odd thing about this is that none of the new code, nor any of the legacy code in tor-launcher or tor-button SETCONF ClientTransportPlugin, so I'm not sure how this could be happening.

Can you provide repro steps from a fresh TorBrowser install, along with logs?

Hi, Richard! Nice to see you here!
What I've found so far:
now, when "4pr" was replaced with a good one to make TBB work again, I tried to switch to a snowflake bridge, and it failed with:
"Bridge snowflake 0.0.3.0:1" line instead of two ClientTransportPlugin lines before the switch!
So, it seems it makes clearer who modifies torrc. Although, it would be much harder to reproduce that with a clean installation.

Not-OT-After-All? (not verified) said:

October 16, 2019

Permalink

For more than a year I have tried and tried without success to report a GTK3 issue related to Tor in Debian 10 "Buster" (and even Debian 9) and wonder whether this could be the cause:

> In practice this means GTK3 file dialog is reset to its default behavior in all other programs that use it.

I mostly use Debian offline but I sometimes use Tor Browser in Debian 10, and I often use debian-tor to update the system. For the latter I use synaptic. And I keep getting weird error messages about GTK3 dialog, which possibly is the reason that the synaptic front end doesn't work quite right. Since updating the system and keeping the onion repos healthly are critical functions for users and for Debian Project respectively, this is an important issue and I feel it is not good that Tor Project has for some reason been supressing the problem.

toots (not verified) said:

October 17, 2019

Permalink

On Android why is browser.safebrowsing.downloads.enabled
= false, Is it a security risk to enable? I want to save image and video files.

toots (not verified) said:

October 18, 2019

Permalink

I have the same results as descibed in the ticket you posted, also with video formats.
If I change about:config = true then it works. Being able to save entire web pages-not pdf only - would also be great.
thanks

Anonymous (not verified) said:

October 18, 2019

Permalink

I reported firefox.exe making outbound connections on 9.0a7. And it still does.
Since the release of 9.0a8, Firefox.exe has attempted to connect to:
92.123.195.41:80
92.123.195.57:80
205.185.216.42:80
205.185.216.10:80
5.102.166.10:80
5.102.166.9:80
It always happens shortly after starting TorBrowser. At which point I always create a temporary "block all" rule for the .exe. So I don't know what happens later.

Am I wrong, or is this a major bug?

Do you have by chance some Firefox process run in parallel that might not be closed yet? That would explain all the requests and in particular the one to the Windows update server (as Tor Browser is not using Windows related update mechanisms at all).

Anonymous (not verified) said:

October 18, 2019

Permalink

Is ipv6 currently any threat to anonymity on Tor? Some have said it makes Tor useless because it sends your mac address out to the internet. We only ever hear about ipv4 addresses.

Anonymous (not verified) said:

October 19, 2019

Permalink

Off topic question: are there any corresponding changelogs or news files for packages in Tor Project's Debian repository? If so, what's the URL pattern?

Anonymous (not verified) said:

October 19, 2019

Permalink

at first start:
addons.xpi WARN Failed to parse recommendation: TypeError: NetworkError when attempting to fetch resource.(resource://gre/modules/addons/XPIProvider.jsm:228:15) JS Stack trace: awaitPromise@XPIProvider.jsm:228:15
syncLoadManifest@XPIInstall.jsm:746:22
addMetadata@XPIDatabase.jsm:2720:32
processFileChanges@XPIDatabase.jsm:3160:26
checkForChanges@XPIProvider.jsm:2965:55
startup@XPIProvider.jsm:2425:12
callProvider@AddonManager.jsm:215:31
_startProvider@AddonManager.jsm:651:5
startup@AddonManager.jsm:897:14
startup@AddonManager.jsm:3493:26
observe@addonManager.js:70:29

Shubham (not verified) said:

October 19, 2019

Permalink

I'm trying to open https://read.amazon.com on the latest version of Tor but I get a black screen. It works fine on Tor versions below 7. I'm wondering if I can tweak the browser to get the web page to open.

Any insight is appreciated.

I suspect that's kind of expected as Tor Browser is by default in private browsing mode not allowing things write to disk. Do you see the same thing in a Firefox when enabling private browsing mode?