Tor Browser 7.0.1 is released

Tor Browser 7.0.1 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

This is the first minor release in the 7.0 series, updating Firefox to 52.2.0esr, Tor to, and HTTPS-Everywhere to 5.2.18. Additionally, we worked around an annoying freezing of Tor Browser which is due to a NoScript bug and made the security slider window slightly larger.

Here is the full changelog since 7.0:

  • All Platforms
    • Update Firefox to 52.2.0esr
    • Update Tor to
    • Update Torbutton to
      • Bug 22542: Security Settings window too small on macOS 10.12
    • Update HTTPS-Everywhere to 5.2.18
    • Bug 22362: NoScript's XSS filter freezes the browser
  • OS X
    • Bug 22558: Don't update OS X 10.7.x and 10.8.x users to Tor Browser 7.0

June 19, 2017


Bad that new version Tor does not support Windows XP Pro SP3. Not all and not everywhere can itself to allow to buy the new modern computer and not there is desire beside all to move to more modern versions Windows.


June 19, 2017


Hi torteam!

Little mess here. After my update from torbrowser (browserbundle) 6.5.(?) to 7.0.0 I realized, that the entrynode never changed. Nevermind what I do, new circuit, new identity, close torbrowser and reopen, wait some minutes for the automatic circuitchange – every time the same result, every time the same IP-adress of the same entrynode appears. I purged the browserbundle, download the new version directly, every thing was fine.

Then version 7.0.1 was out, I updated, the problem with the same entrynode again appears. Purged browserbundle, download new version directly, same problem. Purged, download experimental version, same problem. Tried it any times. Than go back to versions 6.5 and 6.0.8 (had still the tar-archives), but now had the same problem with the old versions too.
Happened on an old machine with a Pentium(R) M (by default with WinXP as OS) with the latest stable Debian Jessie.

At the weekend I installed the new Debian 9 as a complete fresh OS on that machine, download torbrowserbundle 7.0.1, start torbrowser, had again the same entrynode, nevertheless I do (close, new circuit, new identity). All downloads were right from your page here, 32-bit-versions.

To clearyfy: the entrynodes between the several installations are different (5xFrance, 8xGermany, 3xNetherlands, 1xDenmark, 1xChech, 1xMoldavia, 1xLuxembourg), only in one case an IP appear twice.
But once installed, the IP of the entrynode never changed.

Made I a mistake, is the hardware too out of date, is it a bug or should I go for tinfoil?

Ah, ok, thanks!
I´ve never noticed that before, since when is it included?
And what means „often is a feature“? There are situations when its not a feature?

In the details u linked is written about a few relays used as entrynodes. Is this means if I open the torbrowser in one hour or tomorrow I should see another entrynode?

We added the entry guard feature in Tor in 2006.

You can read a whole lot more about entry guards, and why they're critical to security, in this blog post:…

(As for your other question, I think gk meant "(not rotating your entry guard often) (is a feature)", not "(not rotating your entry guard) (often is a feature)". If that clarifies. :)

Thanks, I understand. The point I never noticed before that not rotating of the entrynodes is my own inattention and bias I think.

But to be shure: there is a pool of few (3-4) entrynodes for me since I installed and started the torbrowserbundle, but only one will appear for me/my client will use until this relay precipitates or in a few weeks (6-8) the pool itself will change (a bit?)? So for several weeks the same IP have to be appear as my entrynode if the torbrowser work correctly. But if the same IP stay much longer as my entrynode, something went wrong. Right?

I running Mac OS and noticed that the "Tor circuit for this site" displays

Bridge: OBFS4 followed by the other couple of IPs.

My concern is sometimes I will see Bridge: OBFS4 (United states)

Why does it show the country and as far as I can see only U.S.?

It shows the country as for all the other relays in your circuit. Thus, there is nothing special in that regard. There are bridges in other countries as well but your Tor Browser picked a U.S.-based one and sticks to it.

it doesn't matter what settings I use to stop auto-updates, nor even if I go into the about:configs and hard-code everything against auto-updates.
The browser keeps forcing auto-updates from v6_5_2.
I am having issues with the newest v7 tree, and need to wait on the 7s
Why? why can the auto-updates NOT be stopped? what have you done?

I just tested it with a clean new Tor Browser 6.5.1 and it is not updating provided I change the update related preferences *before* I start the browser (you can specify to never check for updates or check but only apply them after a click, both works for me). The update check happens even before you switch any preferences in your about:config during start-up.

No, that's not the solution, nor does it address the bug and security hole. I have done the same thing numerous times, and the error WILL replicate. Cycle through several runs of the browser after it has already been installed and at one point in a subsequent startup it will just override all browser update options(including manual changes to the about:config and even removing update URL addresses in the about:config) and just install the new version automatically. In other words, completely re-install the browser and set all variables to NOT update at the initial launch. And then run the browser a few times, visit some sites, leave it open for a bit. Then close it, and restart. Do that a few times, and then suddenly, it will just override all your settings and just update itself automatically contrary to your settings.
Respectfully, this is a big security hole, if that is all that is. It is certainly a bug. Where in the code base are your forcing this update?? Is that also replicated in the new v7 series?
I appreciate your quick answer in reply, but that's not really an answer that has any depth.
Let me repeat the obvious, this is not merely a bug, but instead one of the standard items on the list of SECURITY HOLES. If you've hard-coded forced updates, just disclose that. But if you have not, then you have left a big hole here that can be triggered by something other than the user. If the update process is open to be triggered by an hole in your code, then a malevolent process, or site, or party (M-T-M) could trigger an update and compromise security. To be fair, let's assume that you have the code-signing process in your auto-updates all properly locked down. (that's a big assumption, but we want to trust you). If a new vector or exploitable bug is introduced in a new version-- particularly as you update the rolling changes in Firefox-- that was non-existent in a prior version, then you have just forced the user into a security compromise. There is also the other annoyance of simple system incompatibility with the new version. Either way, it is for this very reason that organizations routinely lag with updates until new versions have had a chance to fully bake-in.
Now, I realize that this is a long post, but this is a pretty big bug, and it is replicable. Either you address it, or it needs to be broadcast to the larger Tor user base and let them start asking questions. Could I delve into the code-base myself? Sure, but that is a big investment of time that might be unnecessary if you (the developers) just please be transparent about this issue and disclose what, exactly, you have coded this to do. If you don't know, then that's another problem altogether. But let's wait for your answer. Please do. And if you don't have one, at least point to the location in the code-base where the community developers should start looking to contribute a possible fix to your coding or design errors.
Please, answer with something more substantive that a flippant response. This issue is replicable, and it is serious.
thank you in advance.

Even though my answer was not as long as yours it was not flippant: I tested your issue yesterday quite for some time with different configurations and could not reproduce it.

Now, first of all, we don't ship our own updater but the one Firefox uses. You might be interested in reading how it works: + linked pages. While we are patching the updater to fit our needs we don't patch the mechanism that is responsible for automatic updates. The two patches we have are

a) for using the Firefox update process (…) and

b) for making use of MAR file signing (…).

If you don't trust the preferences I mentioned in my previous reply you can set app.update.url to "" or some internal URL as we do for Torbutton/Tor Launcher updates (we use data:text/plain,).

What would be helpful is seeing some log in case that happens again. You can enable update logging with the app.update.log preference.

Finally, no, website can't trigger an update. Not sure where malevolent processes come into play here but they can just easily overwrite your firefox binary and then it is game over. Not sure what "party (M-T-M)" is? You mean some man-in-the-middle attacker? They can't trigger an update either unless they can break TLS/bypass the key pinning.

the auto-updates are functioning independent of the toggle in the options dialogue. In addition, not even manually editing the about:config file solves the problem. I'm not sure what exactly is causing the over-rides, but after wasting entirely too much time I suspect that it may be related to one of two things: (1) permitting messaging to Windows OS from a site after granting permission in the browser window, or (2) some bug in the Tor launcher. I did notice that when I completely turn off updates, the browser just ignores the settings and updates itself, but when I choose the option to let me decide whether to install updates, the browser doesn't update itself for a while. Not sure what does cause the eventual update in this configuration, but it eventually triggers. I'm fairly fluent in browser programming, but don't have the time to deep debug this issue. Nonetheless, I must say that I consider this an extremely serious security issue. I know, I know, certificates & signing etc. etc. But SOMETHING IS MIS-CODED here that is causing the system run against the manual controls and toggles. Assuming that's true, then I suspect that the error could be hijacked by a 3rd party or M-T-M.
If you have any response-- and by you, I mean the developers, please respond here so that all can see. I've already searched the blog, and even Googled the issue, but there is nothing. Respectfully, I consider this both a BUG, and a serious security hole/threat.
Thank you in advance.

See my answer to the previous comment.

Everyone with running Linux should update!

Why are login pages for all onion sites showing me a crossed out lock icon and telling me "this connection is not secure" whenever I click in the password boxes?

How come everything is coming up http and not https?

Because a lot of .onion sites don't have certificates for a bunch of reasons. But we have a bug on our radar to address at least some of the issues you mentioned:

onion services are encrypted already.
to deactivate the warning message:
security.insecure_field_warning.contextual.enabled - toggle to false

I have noticed lately that Tor Browser often shows one exit node, the IP, and the country, while various testing sites, such as , and, will now show something entirely different, different IP and different country entirely. This is a new behavior and occurs consistently on both Tor Browser and Tails, as well as on different machines, and running from a DVD or USB key.

I find this disturbing. Any explanations?

How can we reliably know and verify the country where our exit node resides if different services are at odds with what Tor Browser is reporting, more often than not?

The circuit you used while the tests looked for your IP could have timed out before you landed on the final page or there are various redirects to different top level domains in the test included that could lead to this result. Hard to tell.

You can click on the onion menu next to the URL bar when loading sites and see live what your circuit usage looks like.

I have checked to see if the circuit has changed during the test, but it has not.
As I said, this is entirely new behavior.

When I go to, it always agrees with what Tor Button is reporting. But, when i go to the testing sites mentioned, they show a different IP and a different country. Very disturbing.

Just now I changed the circuit and Tor Button shows an exit node in Sweden. I now have ten minutes before it changes automatically. I go to, and it shows a different IP with an exit in Romania, which is often the case. Tor Button still shows an IP in Sweden.

Doesn't boost my confidence at all.

> I now have ten minutes before it changes automatically.

That hasn't been the case forever (Tor Browser sets and uses `KeepAliveIsolateSOCKSAuth`).

> I go to, and it shows a different IP with an exit in Romania, which is often the case.

You don't think that all your traffic to every single site goes down the same circuit do you? That hasn't been the case, basically ever. And if it were otherwise, it would be a bug.

> Doesn't boost my confidence at all.

Maybe if you correctly understood how it is supposed to behave, you'd have more confidence.

I may not be a rocket scientist, a cyber-security erxpert, or a network engineer, but I do understand how Tor Browser has behaved in these tests in the past, up until this release. The current behavior never occured until this release. So, where is the clear layman's explanation for the change?

If the end user cannot reliably test and have confidence in at least knowing which entry and exit nodes are being used, at any time, then there is no utility in having Torbutton show the supposed nodes.

Which one is to be believed? Tor button or the testing site? Both? Is more than one Tor circuit being used at a time, when only a single browser tab is opened? Are two instances of Tor running, when there should only be one? How and why should that occur?

When what was once testable becomes untestable, because the reliability of popular tests is now in question, which in turn throws tor button node reporting into question, where should our confidence come from? Tor button alone? Why is it no longer easily and independently verifiable, when it has been, up until now?

See my answer below. When you say "different", do you mean "different from what the last site in the other tab told me"? Or do you mean that the text on the web page disagrees with the "Tor circuit for this site" read-out you get by clicking on the green onion while you're on that tab?

Why do you want to believe something? Torbutton shows you the last circuit for some site. Testing site uses different addresses to check the linkability and shows IP of some exit. What's the problem?

Right, Tor Browser started using per-tab isolation (or more precise, per "destination listed in the url bar" isolation) went into Tor Browser 4.5-alpha-1 in November 2014:…
" * Bug 3455: Use SOCKS user+pass to isolate all requests from the same url domain"

See also Section 4.5 of

In short, the "now have 10 minutes" thing is what the program Tor does by default, but Tor Browser configures Tor to do its circuits differently.

Hope that helps!

Hmmm.... while watching Onion circuits and the circuit data in TB itself, I reloaded this page, then followed the link in your post. My circuit did not change (which suprised me since I thought following a link to a third party site would give a new circuit), but the exit server did agree with one named by ipcheck. I called "new circuit" in TB (which did indeed create a new circuit) and tried again, with same result for the new exit server.

(FWIW, I am using TB in Tails 3.0.)

Hi, since I downloaded this latest version, tor doesn't open anymore, I've tried everything, I changed the install location but nothing seems to work

I suspect you are on Windows? If so, which version? Do you have an antivirus/firewall software installed? If so which one? Could you uninstall it and test whether that solved your problem? This kind of software is pretty intrusive and is known to prevent Tor Browser from starting in some cases. Do you get error messages when trying to start Tor Browser?

I have exactly the same issue. I have windows 7 64 bit and i have tried everything it said, i have closed my firewall and antivirus i have deleted tor and reinstalled it, i have installed it in a different location. Nothing! I use to just update tor and it normal works, what must i do know to get it to work?

every time I tor update from 6.5.2 to the new version it does not open.. please help very computer illiterate... thanx

I suspect you are on Windows? If so, which version? Do you have an antivirus/firewall software installed? If so which one? Could you uninstall it and test whether that solved your problem? This kind of software is pretty intrusive and is known to prevent Tor Browser from starting in some cases. Do you get error messages when trying to start Tor Browser?

Since the new tor browser 7.0.1 and tor are out pageloads are much faster than before. I guess this is due to the multiprocess firefox. Good work so far.

Thanks, and, yes, multiprocess mode plays a big role here.

does someone know why i get circuits with excluded nodes
(StrictNodes 1) ?

StrictNodes doesn't apply to ExcludeExitNodes nor ExitNodes. Did you know that? Does that help?

If not, where did you set StrictNodes 1? What file? And are you expecting this to affect Tor Browser or your system's Tor?

neither it helps nor it is an answer to my question.
StrictNodes 1 applies to ExcludeNodes and i still have circuits with nodes i have

Ok. So ...

If not, where did you set StrictNodes 1? What file? And are you expecting this to affect Tor Browser or your system's Tor?

i just want that 'excluded' means excluded?
how to do?

US Deputy Attorney General Rod Rosenstein has been much in the US news of late, but there's another reason why Tor users worldwide should be paying attention to what he's saying to the US Congress: that Tor poses a drastic "threat" which "cannot be overstated".…
> Department of Justice must continue to take a leading role in enhancing the capabilities of the law enforcement and national security communities. This budget request will provide $21.6 million in funding to counter the “Going Dark” threat. The seriousness of this threat cannot be overstated. “Going Dark” refers to law enforcement’s increasing inability to lawfully access, collect, and intercept real-time communications and stored data, even with a warrant, due to fundamental shifts in communications services and technologies. This phenomenon is severely impairing our ability to conduct investigations and bring criminals to justice. The FBI will use this funding to develop and acquire tools for electronic device analysis, cryptanalytic capability, and forensic tools. The Department’s role has been to collect, house, analyze, and share critical data among our federal, state, local, and tribal partners.

Rosenstein is demanding an extra 21 million USD of funding to fight the "Going Dark" threat [sic]. Can Tor user donations match that figure? If every Tor user gave ten dollars this year, I suspect the answer is "yes".

My OS is debian wheezy 32bit

Since long I have 2 installations of torbrowser
The first one with fairly standard settings in
The second one (with noscript and httpseverywhere disabled for sites that need it)

Both installations were on 6.52. The second installation auto-updated to 7.01 and later to 7.02

I kept the 6.52 installation just in case.

When starting tb 7.02 the system monitor shows processes tor, firefox and for a split second a process named 'Web'.
Then only processes tor and firefox remain (of course a lot of standard processes out of focus here...)

As soon as I connect to a site, the 'Web' process returns.
'Web' is alive till I exit torbrowser or choose new_identity.

Torbrowser 6.52 doesn't start such a 'Web' process.

'Web' seems to stem from
~/tor-browser_en-US2/Browser/plugin-container -greomni

Is that something to worry about?


(-- > mysterious 'Web' process)
correction: tor browser auto-updated to 7.0 and then to 7.0.1 (I wrote about auto-update to 7.01 and then to 7.02, my fault)

Yes, I believe this situation is normal.

The new Firefox, which Tor Browser 7.0 is based on, has some sandboxing features, where each tab can run things in its own sandbox. Those extra processes you see are from the sandboxed tabs.

thanks for calming me down :)

Today I have updated the non-tor firefox to 52.2.0 and it does as well create that 'Web' process.


> My OS is debian wheezy 32bit

You may have good reasons for sticking to wheezy (no need to explain here if so), but otherwise I'd urge you to consider updating to the new stable (stretch, aka Debian 9). This is available for 32 bit machines, but as someone else noted recently in a blog comment here, 64 bit machines offer some security innovations which are worth taking advantage of if you can upgrade. Also, as you may have noticed, Tails is no longer compatible with 32 bit machines.

"" set to false (security level: high) breaks some pages

Would the pages that break happen to be those that use SVG in content?

7.01 with protonmail is slow. It can take more than a minute to turn a page.