This release brings us up to date with Firefox 52 ESR which contains progress in a number of areas:

Most notably we hope having Mozilla's multiprocess mode (e10s) and content sandbox enabled will be one of the major new features in the Tor Browser 7.0 series, both security- and performance-wise (Update (July 7, 12:40 UTC): While sandboxing is enabled in Tor Browser 7 it turns out that the long awaited content sandboxing did not make it into the Firefox ESR series as there were still stability issues with it. We try to backport the necessary patches to make it work for Tor Browser, though.). While we are still working on the sandboxing part for Windows (the e10s part is ready), both Linux and macOS have e10s and content sandboxing enabled by default in Tor Browser 7.0. In addition to that, Linux and macOS users have the option to further harden their Tor Browser setup by using only Unix Domain sockets for communication with tor. Update (June 8, 8:00 UTC): As the last point caused some confusion: enabling Unix Domain sockets alone does not harden Tor Browser. One needs that *and* additional sandboxing mechanisms that prevent communication over TCP/IP.

The highlights in our tracking and fingerprinting resistance improvements are: cookies, view-source requests and the Permissions API are isolated to the first party URL bar domain now to enhance our tracking related defenses. On the fingerprinting side we disabled and/or patched several new features, among them WebGL2, the WebAudio, Social, SpeechSynthesis, and Touch APIs, and the MediaError.message property.

WIth the switch to ESR 52 come new system requirements for Windows and macOS users: On Windows Tor Browser 7.0 won't run on non-SSE2 capable machines anymore. On Apple computers OS X 10.9 is now the minimum system requirement.

Besides new system requirements for Windows and macOS users, there are some known issues with Tor Browser 7.0 as well:

Mozilla stopped ALSA support in Firefox 52 for Linux users. This means without having PulseAudio available, sound will be broken in Tor Browser 7.0 on Linux.

Tor Browser has recently been freezing on some websites. This is related to a NoScript bug which will hopefully get addressed in a new NoScript version rather soon. If not then we'll ship a workaround for it in the planned Tor Browser 7.0.1 which will update Firefox to 52.2.0esr next week.

Apart from switching to the new Firefox ESR and dealing with related issues we included a new Tor stable version (0.3.0.7) and updated our NoScript (5.0.5) and HTTPS-Everywhere versions (5.2.17).

We updated our toolchains during the ESR transition as well. In particular we retired the old GCC-based one for our macOS cross-compilation and rely solely on clang/cctools now.

Any for Tor Browser to change back "Highlight All" keyboard shortcut to "Alt+A", instead of Mozilla's change to "Alt+L".

The change now affect TBB, after the move to Firefox 52 ESR.
Mozilla apparently made the change to accommodate Mac users, but made change to all distributions.
"Alt+L" is very annoying, for it is no longer a simple one-handed operation as "Alt+A".

" Since the update, Tor does not save my adjustment to the network setting and about:config, meaning I have to re-do at each browser launch. Anyone have any idea what happened?

Submitted by toruser39284 (not verified) on June 08, 2017

" Could you give us steps how to reproduce your problem? What exactly did you do which worked in the past but does not do so now anymore? "
Submitted by gk on June 09, 2017

In reply to Since the update, Tor does… by toruser39284

" I’m just using the Tor browser without the Tor network by going into network settings and selecting “No Proxy”. Then in “about:config” going to “network.proxy.socks_remote_dns” and Toggling. These settings do not save after I quit the browser and must re-do each time I launch the browser. Previous versions saved these configuration changes and would not require me to do this every time on browser launch.

I have been awaiting an answer on this. Latest update did not address this problem. Please let me know.

Sorry to bother you guys, but Tor browser 7.x doesn't work for me, no matter what OS I use.

To cut it short, I have Tor browser 6.5.2 running fine on my windows 7 desktop computer, a few day ago it automatically downloaded 7.0 update, the next time I try to run it, the progress bar stuck at 'retrieving network status' stage, waiting overnight and nothing happens.

Suspecting a corrupted update, I deleted that installation, rolled back to a clean 6.5.2 browser, and downloaded a fresh 7.0 installation file, loaded the same set of obfs4 bridges to the newly installed Tor browser7.0, and it didn't help, when I run it, the progress bar still stuck at 'retrieving network status'.

Alarmed, I checked the log file, and witnessing a crapload of ''Ignoring directory request, since no bridge nodes are available yet." warning, also the exact place where the bootstrap process is '25% asking for network consensus'.

Since I also have a flashdisk loaded with tails 2.12, I decided to do a signature verification, both 6.5.2 binary file and 7.0 turned out ok.

To rule out any antivirus false-positive or network hardware/driver based failures, I booted from tails 2.12, and downloaded a fresh image of tails 3.0 through Tor browser, and burned it to a DVD disk, when I booted from the tails 3.0 DVD, and try to connect to tor network, again using the same set of obfs4 bridges, the same symptom happens, the progress bar won't go past 'retrieving network status' stage. A quick look through the log created again revealing a series of 'Ignoring directory request, since no bridge nodes are available yet.' warning, occasionally, 'I learned some more directory information, but not enough to build a circuit: We have no usable consensus. ' appears. Waiting for hours doesn't make any differences.

From those symptoms, I can only draw the conclusion that either this particular version of Tor browser has some pluggable transport related coding issue, or the country I live in has come up with some particular effective measure to attack the bootstrapping process of tor browser 7.0.

I'm at a total loss here, can anyone share their experience with TBB7.0 or tails 3.0?

I have had Tor on two of my Macs (OS X10.6.8 & 10.8.5) for only a few months, and have generally enjoyed using it without really understanding it. I do, however understand and completely agree with the need for anonymous browsing for ordinary citizens.
This morning the browser on the 10.8.5 mac wouldn't boot-- giving me the following error msg in a Finder Window: "...you have OSX 10.8.5. the Application requires OSX 10.9 or later."
I do not recall installing or approving an install of an updated version or Tor in the last several days.
I tried rebooting & re-loading the Tor Browser but got the same results. I cannot use Tor on my 10.8.5 machine, nor can I find any workarounds on your site. (I am writing this from my 10.6.8 machine, by the way.)

Now I have two Qs:
1- How can I retrieve the earlier version of Tor Browser to restore the Tor connection to my 10.8.5 machine?
2- How can I prevent this from happening to my to.6.8 machine?

Note:
I must honestly admit that I am computer-challenged, and don't understand much of computer-speak. I am not qualified to mess with my Terminal nor have I even seen this thing called the Registry on any of my computers.
Layman-speak, insofar as it is possible, will be appreciated.
Thanks. Andy 6/17/17

Generally speaking: Tor Browser now requires OS X 10.9 as the minimum on Apple computers. That is a new requirement that came with the switch to Firefox 52. That you got it on your 10.8.5 system is probably due to a bug we recently fixed (https://trac.torproject.org/projects/tor/ticket/22558), it should not happen again. Now, if you just use your 10.6.8 machine you won't get Tor Browser 7 with all the important security updates. You will stay on the unsecure 6.5.2. The same will happen on your 10.8.5 machine once you have an older Tor Browser version there as well. All the released versions can be found on https://archive.torproject.org/tor-package-archive./torbrowser/.

This new version of TBB is going to take some getting used to. I'm no computer guru by any stretch of the imagination and have no technical skill in computer sciences/IT etc but I do love exploring around in the deep. It's really quite fascinating what kind of stuff is in those depths - many times very interesting and of course at other times rather morbid to say the least. I love the feeling I get when I'm just about to open an onion link (however risky it may be and I am aware of that - I do so at my own risk ) that I've not seen, don't recognize and have no indication of what it might be and no idea of what I'm about to enter into. That little rush that comes over me like sitting in a horror movie waiting for the main character to do this or that and it's all suspenseful and I'm all on the edge of my seat. I love it, can't beat it.

I'm curious to know where the visual feedback offered up by the last version of TBB disappeared to??? For example, in the most recent version of TBB, at the top left of the browser's URL I could change my session, I could change my identity or (sad but true, most intriguing part to me) I could pull down a drop list where I could see the various hops that my data would travel across.

Would someone, anyone be so kind as to direct me to where I can either see this information or explain which add-ons or modifications I might need to make so that I can enable this information once more - or perhaps it's just under my nose and I'm overlooking it entirely. Yes, I know never to modify the browser for security reasons (and I never have). I just can't imagine this would be OK to do now but I'll sure look forward to having that information again.

An important change that you should have pointed out in the release announcement for 7.0.

If TBB refuses to start, and exits with errors like Could not bind to 127.0.0.1:9150: Address already in use, you should check your torrc configuration file and remove any lines starting with SocksPort or ControlPort left over from older TBB releases.

At least, this fixed the problem for me. Corrections and more details are appreciated.

That depends. Are you running Windows on it? Then it should not. However it is not clear what happens in this case. Could you give it a try and report back what is happening in that case?

Assuming it is not working for you, could you do us an additional favor and test a build that is supposed to warn users when installing Tor Browser on Windows on a non-SSE2 machine? We did not find such a machine yet and could therefore not verify whether our patch behaves correctly. The bundle can be found on:

Hi! There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.2-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series.

Changes in version 0.3.3.2-alpha - 2018-02-10

Major features (denial-of-service mitigation):

Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902.

Major bugfixes (netflow padding):

Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha.