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.
Joking? Firefox uses
Joking?
Firefox uses --enable-jemalloc to enable that on Windows.
See https://trac.torproject.org/projects/tor/ticket/21448#comment:2
Oh, thanks. It seems we
Oh, thanks. It seems we don't use jemalloc on Windows as we are building with mingw-w64. Might be worth thinking about whether we should.
"With regard to jemalloc in
"With regard to jemalloc in Firefox 3, the primary reason it was worthwhile was the horrible fragmentation behavior of the malloc implementations on Windows."
https://lwn.net/Articles/273001/
"Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on."
https://stackoverflow.com/questions/1624726/how-does-jemalloc-work-what…
"in 2010 Mozilla sponsored
"in 2010 Mozilla sponsored integration of Apple Mac OS X support into the stand-alone jemalloc, and in 2012 contributed MinGW Windows support."
https://github.com/jemalloc/jemalloc/wiki/Background
Yes, but what breaks is
Yes, but what breaks is enabling jemalloc when using mingw-w64 to cross-compile Tor Browser. I guess using it to build on Windows is working. But I have not tested that.
What does Tom Ritter think?
What does Tom Ritter think?
Seems he is cross-compiling
Seems he is cross-compiling well.
"Memory used by the system
"Memory used by the system allocator that is currently allocated to the "
"application. This is distinct from the jemalloc heap that Firefox uses for "
"most or all of its heap allocations. Ideally this number is zero, but "
"on some platforms we cannot force every heap allocation through jemalloc.");
I hope you do not. Jemalloc
I hope you do not. Jemalloc is quite insecure (though at least it doesn't use deprecated APIs like sbrk like ptmalloc does...), whereas the native windows memory allocator is exceptionally well hardened, beyond the native malloc in glibc (ptmalloc and dlmalloc), or even the openbsd libc. Really the only downside it has is the Fault Tolerant Heap, and even that is not a big issue for a browser. The fact that jemalloc is not used on Windows makes Firefox significantly more hardened on that platform.
I didn't know that vanilla Firefox used --enable-jemalloc on Windows, though. I was under the impression that, like Tor Browser, it used the system malloc on Windows systems. I'll add that to my notes of security advantages Tor Browser has over regular Firefox for those who are under the impression that it is just Firefox + Tor!
Also what about using
Also what about using jemalloc in Tor?
Using jemalloc for Tor would
Using jemalloc for Tor would be silly. Not only is jemalloc one of the least secure allocators due to large, aligned 2 MiB heaps, but it really is only useful for improving performance on highly multithreaded programs, like database servers and multithreaded browsers. Tor, which is rather infamously limited by its single work thread, would not benefit in the least from jemalloc.
Go and use copperhead bionic malloc or openbsd malloc and then we're talking. :P
Where are build instructions
Where are build instructions so we can compile it ourselves?
You mean the sandboxed Tor
You mean the sandboxed Tor Browser or Tor Browser? For the former see: https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tre…
and there is a Makefile. For the latter see: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/giti… and our hacking guide: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking.
I'm concerned that only one
I'm concerned that only one person is working on sandboxed-tor-browser. How can I help without being a coder? Can I make donations directly to the sandboxed-tor-browser to the developer to help?
From what I've heard, this
From what I've heard, this single person's funding for this project has also run out, so they are also no longer going to work on it full time. I'm not sure if this means it will go into maintenance hell, or if it'll be picked up by other people. I think you should go ask on #tor-project on OFTC about directly donating to that project.
It gets bug fixes. I'm not
It gets bug fixes. I'm not really doing new feature development or gigantic improvements, and the code is basically at the point where security improvements will require patching firefox, and usability improvements require fighting with D-Bus and doing UI code.
I'm also not in a position to be able to accept individual donations.