Discontinuing the hardened Tor Browser series

When we started with the hardened Tor Browser series 18 months ago, we had two main purposes in mind:

  • It should give users an even more secure Tor Browser, especially at higher security levels where JavaScript is partially or completely disabled.
  • It should help us to identify issues earlier, therefore allowing to develop and backport fixes to the Tor Browser alpha and stable series.

The hardened series was a non-stable series on purpose, aimed at experienced users. The reason for that was not only the heavy performance impact of the hardening and debugging features we deployed. Rather, the impact of mixing both in Tor Browser seemed to be not well understood either: for example, does compiling Tor Browser with Address Sanitizer really lead to a more secure browser, given that the sanitizer is mainly intended as a debugging tool? Moreover, just using the hardening options provided by the toolchain seemed to be an incomplete solution to the problem—a bandaid until we could provide a more complete approach to hardening.

Looking again at its purposes above, we think it is safe to say that the hardened series indeed helped us identifying issues early on: with it we found bugs both in Firefox and tor and they got resolved quickly.

The picture is not so clear with respect to the promised security benefits. Part of the problem is that "more secure" can mean a wide variety of things. Another part is that we did not measure if we were indeed adding a security benefit to Tor Browser with all the techniques we deployed. What we learned over the course of the past 18 months, however, is that enabling expensive hardening can aid in making Tor Browser crashes much more reliable.

But that's not the only thing we learned. It seems we underestimated the confusion among users caused by labeling the series as "hardened" while at the same time including features for debugging purposes as well. The resulting experimental character of this series made it hard for users to decide whether that's actually the Tor Browser they wanted to have or not.

Where does that leave us? We've decided to stop having a "hardened" browser series, and instead we'll provide separate tools for the two purposes that it aimed to solve:

Users that are currently on the hardened update channel will get an update to the most recent Tor Browser alpha with a note to use Sandboxed Tor Browser instead for enhanced security. While the Sandboxed Tor Browser is currently in an experimental state itself, we feel that it provides much better safeguards against exploitation than the features we shipped in the hardened series.

Having Sandboxed Tor Browser for hardening the browser experience allows us to do an even better job with finding problems earlier in our Tor Browser patches or code in Tor Browser generally: we can include more debugging aids into special debug builds. We plan to do so and get back to dedicated debug nightly builds when we switch to our reproducible builds manager (rbm), which is happening soon.

Finally, thanks to all users of the hardened Tor Browser series. We hope Sandboxed Tor Browser and the upcoming debug builds will provide an even better match to your needs. If not, please make sure to file a bug in our bug tracker and we'll look into it.


April 20, 2017


For me the main characteristic of the hardened series was that it included Selfrando, is there a plan to make it land in alpha?

It would have been in the 7.0a3 alpha if we had not found last minute issues with selfrando and the switch to ESR52. It is planned to have it in 7.0a4 for 64bit Linux.


April 20, 2017


When will you remove debugging information (-g) from release versions?

Hm. We are building Tor Browser the same way as Mozilla does it seems or are you saying the Mozilla bundles are not built with -g? That said we are stripping all the symbols to provide separate debug archives for investigating crashes. So, what exactly is added and problematic in our case if we follow Mozilla in that regard?


April 20, 2017


Will miss the hardened series.

Used it with firejail

And yes, Where is selfrando?

It missed the 7.0a3 deadline due to issues with the switch to ESR52 but should be back in 7.0a4.

Just a tip, maybe don't make it so hard for people to find the link to the binaries of the sandboxed browser... :) (ie maybe put a link on https://www.torproject.org/download/download-easy.html.en or at least https://www.torproject.org/download/download.html.en instead of [1])

Tor Browser Sandbox
[1] https://www.torproject.org/projects/torbrowser.html.en#downloads

Thanks. This is currently still experimental software but once we think it has stabilized enough it will for sure get a more prominent position on our download page(s).

Seconding the prior comment... Sandboxing is a good addition, but it is not a "better match to our needs". It does not replace the memory exploit defenses (Selfrando), it only hopes to contain the exploit, once it was allowed due to the weak memory defenses.
It's like treating the symptoms of a problem... Please consider dealing with the cause - include the defenses (Selfrando) in the Sandboxed version?

There's a ticket for integrating Selfrando into the alpha Linux builds (and hopefully to the stable release then)

#20683 - Integrate selfrando into the alpha Linux 64bit builds


The idea is not to sacrifice selfrando (or whatever similar means come to mind) for sandboxing. Sandboxed Tor Browser is pretty much agnostic to whatever Tor Browser version it is used with (it lets you select on which channel you want to be at start-up). All in all we still think that the current sandboxing code for Linux makes it less likely that a user gets exploited compared to using the hardened version. Sure, we can make the result even better by shipping selfrando to alpha (and later stable) users and that is planned and currently worked on.

I am currently using a Tor Browser that is sandboxed, but the sandbox is on the hardened channel. about:tor still shows that I have 7.0a2-hardened. Will I/have I obtained the update to 7.0a3 not hardened

Update on previous comment:
7.0a3 was published to the sandbox but it refused because it was considered a downgrade. Bugs anyone?

> Bugs anyone?

If the behavior on 0.0.6 is anything but "detect that a hardened bundle is present, force a reinstall", then that's a bug.

If the sandbox code is anything older than that, I assume stuff breaks, because the sandbox handles updates somewhat differently from Tor Browser, and the code doesn't ever really expect channels to go away.

Okay, just deleted my old configs and moved to TOR browser stable

Even after a clean install, the Sandboxed TB's Preferences don't look normal. All the checkboxes look empty, and stay empty after clicking on them. So, after a while it's hard to know what options are in the "checked state" and what aren't. Decided to reinstall and then left the checkboxes alone.
Funny - hope they are selected right. :-)

That's a new one for me, and I haven't seen that on any of the systems I've tested the code on. Though I'm not surprised that the UI can randomly break, especially considering I'm not really a UI programmer.

`sandboxed-tor-browser` follows the XDG Base Directory Specification, and writes a JSON format config file to a standard location (`$XDG_CONFIG_DIR/sandboxed-tor-browser/sandboxed-tor-browser.json`), so it should be easy to check what's actually set.

nb: While human readable, any/all bugs relating to "I edited it and it broke" will be ignored.

Does the alpha provide better security than regular tbb?

Vice versa

What you can be sure about: The sandbox provides better security than both regular and alpha tbb.

- No sound at all - after the switch from hardenen TB to the latest standardTB,

So maybe you should warn users about this and not do the upgrade that was pushed today , if sound is very important to them,

warn in the popup that the users will lose all kind of sound in Linux, in all kind of dists that uses ALSA / jack instead of pulse-audio. It does not seems possible to fix this in Firefox now for us users :- ( should we go back to the 51-series?

what is your plan to re-enable sound on the web for TB in the future? (pulse audio can not be used for many reasons, security might also be one of them)

This is the only clue an user gets when an audio stream or html5-media with sound tries to start, a popup that says..:

Thank you for you work with TB and firefox

> what is your plan to re-enable sound on the web for TB in the future?

I don't think it's reasonable to expect the Tor Browser developers to maintain an audio backend that has been deprecated upstream, that will slowly rot away due to lack of developer attention.


is it really a big problem to support that?
Alsa seems to be in the kernel, and also pulse audio
seems to be just an extra risk-layer on top on Alsa (?)

I can understand that it is preferred to use only one
method, if it is true that no one cares
but pulse audio seems to me like a potential big risk and not worth it.

+adding a lot of junk to many the slim distros.. to do the same job

No telemetry? No sound! (c) Mozilla

Maybe it would have been better to wait until selfrando and sandboxing are stable and available before discontinuing the hardened builds? The current alpha version is almost unusable (downloading a file crashes the browser).

The version(s) of SelfRando that shipped with the `hardened` code had some "interesting" defects. The newer code is supposed to be better.

FWIW, sandboxing is version agnostic and works with the release bundle. While each person's experience will vary, it works well for my use cases, and has been all I use since the moment it started compiling. That said, I am biased, and it does break certain things, YMMV.

Too bad I only have a x86 processor and no one that can run 64bits systems, will never have the opportunity to use the sandbox :/

I have great news. The deprecation of the `hardened` channel does not affect you at all, because you couldn't use that either.

Anonymous wants 32-bit sandbox, and you're joking at him :)

Don't worry, I know that he has valid reasons to not support it https://bugs.torproject.org/20940, wont blame him :P (but that doesn't change the fact that I will be sticking with this 86 processor for the rest of my life)

Rather random thought: f I am to use a stable intergrated sandboxed Tor browser in the future, is there a reason to use firejail on top of it?

"sandboxed" may mean different things here. Firefox 52 which Tor Browser 7.0 will be based upon ships with content sandboxing which should make it harder to exploit vulnerabilities found in the browser. Then there is Sandboxed Tor Browser for Linux 64bit users that is using bubblewrap to provide a process-wider sandbox. In it you can run any Tor Browser series, be it the stable one, the alpha one or some nightly build.

So, I assume you mean "content sandboxing" when talking about "sandboxed". In that case I'd say there are good reasons to use process-wide sandboxing in combination with it. We'd recommend Sandboxed Tor Browser for that, though.

There's design reasons why `sandboxed-tor-browser` is a separate executable. I don't see "integration" happening without a considerable amount of redesign in how Tor Browser works.

I personally think it's pointless to combine the bubblewrap based sandbox (`sandboxed-tor-browser`) with firejail, assuming that sort of configuration even works (and I suspect it won't), because of the amount of overlap between the feature sets.

As a journalist in my country, I feel the security tor provides is necessary. But I'm far from an advanced tor user or developer. Should I be using the hardened alpha over the standard browser? "Alpha" is intimidating and sounds highly unstable. What should I do?

What is your system? If you're using Linux 64 you should be using the sandbox which provides much more security.

You shouldn't be using the (now) discontinue "hardened alpha" since it is more designed for people who want to debug and find bugs.

problem with recent tor browser for windows........seems kind of defunt. doesn't really work taht stable and fails to load website....something wrong?

Was the discontinuation of the experimental hardened browser completely at your discretion, or were you approached by any government entities that may have taken issue?

It was just us.

You can read the history of the ticket at:

And some cypherpunks ;)

You count as part of us. ;)

"Alpha" is intimidating and sounds highly unstable. What should I do?"
You shouldn't use alpha.
(This easy answer was so many times misunderstood, because "hardened" looked like a better product without stable version. Thanks for removing it.)

I am pleased that some clarity will come to the different versions as many that use TOR are not familiar with some of the geeky terms such as "Sandboxing". It has always been a problem that certain aspects of using TOR at maximum safely has been obscure on this group itself and one has had to go to other sites to find out what tweaks can be done to improve security. For example, i see on the latest version we still have all these links to google in the about:config page. Would there not be a way to delete anything to do with google perhaps in the security settings?

Thanks for your work

I see that mistake quite commonly with those who use Tor for less legitimate purposes. Not a real survey though.

What about jemalloc on all platforms?

What about it? Firefox and thus Tor Browser is currently using it on Windows, macOS, Linux.