New Release: Tor Browser 9.0a8

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
- OS X
- Linux
- Android
- Bug 31822: Security slider is not really visible on Android anymore
- Build System
One Tor Browser quirk that's…
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
toBrowser/.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?