Tor Browser 7.5 is released

The Tor Browser Team is proud to announce the first stable release in the 7.5 series. This release is available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

Apart from the usual Firefox security updates it contains some notable improvements compared to the 7.0 series. Here are the highlights:

  1. We redesigned parts of the Tor Browser user interface. One of the major improvements for our users is our new Tor Launcher experience. This work is based on the findings published at 'A Usability Evaluation of Tor Launcher', a paper done by Linda Lee et al. At our work we iterated on the redesign proposed by the research, improving it even further. Here are the main changes we would like to highlight:

    Welcome Screen

    Our old screen had way too much information for the users, leading many of them to spend great time confused about what to do. Some users at the paper experiment spent up to 40min confused about what they needed to be doing here. Besides simplifying the screen and the message, to make it easier for the user to know if they need to configure anything or not, we also did a 'brand refresh' bringing our logo to the launcher.

    Censorship circumvention configuration

    This is one of the most important steps for a user who is trying to connect to Tor while their network is censoring Tor. We also worked really hard to make sure the UI text would make it easy for the user to understand what a bridge is for and how to configure to use one. Another update was a little tip we added at the drop-down menu (as you can see below) for which bridge to use in countries that have very sophisticated censorship methods.

    Proxy help information

    The proxy settings at our Tor Launcher configuration wizard is an important feature for users who are under a network that demands such configuration. But it can also lead to a lot of confusion if the user has no idea what a proxy is. Since it is a very important feature for users, we decided to keep it in the main configuration screen and introduced a help prompt with an explanation of when someone would need such configuration.

    As part of our work with the UX team, we will also be coordinating user testing of this new UI to continue iterating and make sure we are always improving our users' experience. We are also planning a series of improvements not only for the Tor Launcher flow but for the whole browser experience (once you are connected to Tor) including a new user onboarding flow. And last but not least we are streamlining both our mobile and desktop experience: Tor Browser 7.5 adapted the security slider design we did for mobile bringing the improved user experience to the desktop as well.

  2. We ship the first release in Tor's 0.3.2 series, 0.3.2.9. This release includes support for the Next Generation of Onion Services.
  3. On the security side we enabled content sandboxing on Windows and fixed remaining issues on Linux that prevented printing to file from working properly. Additionally, we improved the compiler hardening on macOS and fixed holes in the W^X mitigation on Windows.
  4. We finally moved away from Gitian/tor-browser-bundle as the base of our reproducible builds environment. Over the past weeks and months rbm/tor-browser-build got developed making it much easier to reproduce Tor Browser builds and to add reproducible builds for new platforms and architectures. This will allow us to ship 64bit bundles for Windows (currently in the alpha series available) and bundles for Android at the same day as the release for the current platforms/architectures is getting out.

The full changelog since Tor Browser 7.0.11 is:

  • All Platforms
    • Update Firefox to 52.6.0esr
    • Update Tor to 0.3.2.9
    • Update OpenSSL to 1.0.2n
    • Update Torbutton to 1.9.8.5
      • Bug 21847: Update copy for security slider
      • Bug 21245: Add da translation to Torbutton and keep track of it
      • Bug 24702: Remove Mozilla text from banner
      • Bug 10573: Replace deprecated nsILocalFile with nsIFile (code clean-up)
      • Translations update
    • Update Tor Launcher to 0.2.14.3
      • Bug 23262: Implement integrated progress bar
      • Bug 23261: implement configuration portion of new Tor Launcher UI
      • Bug 24623: Revise "country that censors Tor" text
      • Bug 24624: tbb-logo.svg may cause network access
      • Bug 23240: Retrieve current bootstrap progress before showing progress bar
      • Bug 24428: Bootstrap error message sometimes lost
      • Bug 22232: Add README on use of bootstrap status messages
      • Bug 10573: Replace deprecated nsILocalFile with nsIFile (code clean-up)
      • Translations update
    • Update HTTPS Everywhere to 2018.1.11
    • Update NoScript to 5.1.8.3
    • Bug 23104: CSS line-height reveals the platform Tor Browser is running on
    • Bug 24398: Plugin-container process exhausts memory
    • Bug 22501: Requests via javascript: violate FPI
    • Bug 24756: Add noisebridge01 obfs4 bridge configuration
  • Windows
  • OS X
    • Bug 24566: Avoid white flashes when opening dialogs in Tor Browser
    • Bug 23025: Add some hardening flags to macOS build
  • Linux
    • Bug 23970: Make "Print to File" work with sandboxing enabled
    • Bug 23016: "Print to File" is broken on some non-english Linux systems
    • Bug 10089: Set middlemouse.contentLoadURL to false by default
    • Bug 18101: Suppress upload file dialog proxy bypass (linux part)
  • Android
  • Build System
    • All Platforms
      • Switch from gitian/tor-browser-bundle to rbm/tor-browser-build
    • Windows
    • Linux
      • Bug 20929: Bump GCC version to 5.4.0
      • Bug 23892: Include Firefox and Tor debug files in final build directory
      • Bug 24842: include libasan.so.2 and libubsan.so.0 in debug builds

As long as it fits in low resolution displays such as 640x480 and RasPi displays, I'm fine with it. It disappears quickly anyhow. Maybe the slow end-users in the study were confused by the separate popup progress bar. Wasn't the progress bar or update bar on a large empty UI in the past?

A

January 24, 2018

Permalink

I still can't use twitter at all. I've got "allow scripts globally" enabled and all objects unblocked, but none of the buttons work: Tweet, Retweet, Like, Edit Profile, arrows for drop-down menus etc etc. I click and they get highlighted but nothing happens.

Same with facebook. Only connected once with Torbrowser by mistake. They blocked my account and asked for my ID Card scan (phone number insufficient for Facebook).
They never got it.

A

January 24, 2018

Permalink

It seems that ReCAPTCHA (which comes up all the time if you search Google, visit CloudFlare protected websites etc.) is currently not serving CAPTCHA challenges to Firefox-on-Android (including Orfox/TorBrowser-on-Android) users, with a "browser not supported" message that points to https://support.google.com/recaptcha/answer/6223828?hl=en

Can anyone reproduce this issue? If so, is a mitigation planned, perhaps adding compatibility for whatever APIs ReCAPTCHA is relying on and supplying a different browser identity that they do support?

A

January 24, 2018

Permalink

When I post a comment on High or Medium security, sometimes the preview doesn't show up, and when it redirects me back to the blog post after clicking Save, the green "in moderator queue" box doesn't show up, and the blog post page refreshes infinitely.

A

January 24, 2018

Permalink

Just updated to TBB v7.5... dies under firejail. Dies independently of firejail. Executes mutual suicide pact with torbrowser-launcher package (which worked until seconds ago, with and without firejail). Re-installed torbrowser-launcher; no joy.

Death notice follows...

================

firejail /usr/bin/torbrowser-launcher 4:32
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-passwdmgr.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 10161, child pid 10162

Child process initialized
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.2.8
https://github.com/micahflee/torbrowser-launcher
Refreshing local keyring...
gpgkeys: HTTP fetch error 1: unsupported protocol
Traceback (most recent call last):
File "/usr/bin/torbrowser-launcher", line 30, in
torbrowser_launcher.main()
File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.py", line 62, in main
app = Launcher(common, url_list)
File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 91, in __init__
if not self.common.settings['installed'] or not self.check_min_version():
File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 603, in check_min_version
for line in open(self.common.paths['tbb']['versions']).readlines():
IOError: [Errno 2] No such file or directory: '/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources/versions'

Parent is shutting down, bye...

================

*This is marriage...?!?*

Yup, explanation and workaround (®works-for-me©)

Looks like TBB has moved faster than torbrowser-launcher package. This is not the first time it happened, unfortunately.

As a result, TBB is still just fine, but torbrowser-launcher is broken: it no longer finds what it is searching for, to determine if it needs to take care of upgrading TBB itself (e.g. first time or very obsolete, I see this feature as very usefull), or just launch it. When it fails to find these bits, then instead of deciding to try launching TBB gracefully anyway, it collapses.

Solution will come with a future version of torbrowser-launcher, I guess. I didn't look at the version available in sid as yet (version number is just higher), but its changelog doesn't mention anything about this, as I understand it.

Until then, we may open a terminal and just run TBB directly:

~/.local/share/torbrowser/YOURARCH/YOURTBBFOLDER/Browser/start-tor-browser

(YOURARCH: e.g. "i686", YOURTBBFOLDER: e.g.: torbrowser-browser_FR)

One step further, we may register TBB as a local app for the current user, then use the new launcher instead of torbrowser-launcher one, bypassing entirely the latter. Same as above, adding one argument:

~/.local/share/torbrowser/YOURARCH/YOURTBBFOLDER/Browser/start-tor-browser --register-app

(this results in a duplicate "icon" etc. also named "Tor Browser" in the available applications list for the current system user, but with a distinct description and which can be placed e.g. in desktop panels alongside or instead of the one from torbrowser-launcher)

I guess torbrowser-launcher package needs some love.

Maybe also, TBB release team could care a little bit more about its user base.

A

January 24, 2018

Permalink

(Probably not the correct forum for this but...) I would estimate that a full 60% of pages I visit are now blocked by cloudflare. In addition - on the exceedingly rare occation that I do actually enable js etc and lower my security settings to the point that the recaptcha will in fact work - google is now in many cases throwing up the very tiring "automated queries" error.

How is it possible that cloudflare controls/censors such a large part of the internet and, far more importantly, why is nothing being done about it?!

A

January 24, 2018

Permalink

Reposting -- it appears that unless NoScript is disabled, (attempted) posts here disappear into the void.
Anyway: automatically upgraded to "Tor Browser 7.5 (based on Mozilla Firefox 52.6.0) (64-bit)" under macOS 10.12.6; Tor crashes whenever I open a (specific) folder of bookmarks. This folder has 14 bookmarks -- so "a lot", but not A LOT. This seems to be replicable -- three or four crashes so far -- but if I close some of the tabs quickly, sometimes it doesn't crash. Didn't have this behavior in previous versions, needless to say.

Also, since I'm here: any reason not to have a global setting for declining canvas requests? If Tor is recommending not allowing as a matter of course, better to have it remembered somewhere to apply always. [I'd be ok with it remembering yea or nay for specific sites, and asking for new ones, but that's a way to fingerprint, sort of, if the attackers get ahold of the physical machine, right?]

Interesting, what crash log do you get? Could you open a ticket at our bug tracker https://bugs.torproject.org describing your issue and attaching the crash output? Thanks!

Re: the canvas prompt: there is no particular reason for not having that option right now. There is a bug report in our bug tracker: https://trac.torproject.org/projects/tor/ticket/23227 which urges us to implement that feature. One thing to think about, though, is what to do with all the broken sites that only work with canvas enabled if the user flipped the preference (and is now stuck). Maybe that's bad luck then or maybe there is something smarter we could do. I don't know yet.

A

January 24, 2018

Permalink

torbrowser-launcher &
[1] 4884
shit@linux-lvps:~> Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.2.8
https://github.com/micahflee/torbrowser-launcher
Refreshing local keyring...

shit@linux-lvps:~> Keyring refreshed successfully...
No key updates for key: EF6E286DDA85EA2A4BA7DE684E2C6E8793298290
Traceback (most recent call last):
File "/usr/bin/torbrowser-launcher", line 30, in
torbrowser_launcher.main()
File "/usr/lib/python2.7/site-packages/torbrowser_launcher/__init__.py", line 62, in main
app = Launcher(common, url_list)
File "/usr/lib/python2.7/site-packages/torbrowser_launcher/launcher.py", line 91, in __init__
if not self.common.settings['installed'] or not self.check_min_version():
File "/usr/lib/python2.7/site-packages/torbrowser_launcher/launcher.py", line 603, in check_min_version
for line in open(self.common.paths['tbb']['versions']).readlines():
IOError: [Errno 2] No such file or directory: '/home/shit/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources/versions'

[1]+ Exit 1 torbrowser-launcher

Yep this isn't good. Tumbleweed install.

  1. <br />
  2. mkdir ~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources<br />
  3. echo 'TORBROWSER_VERSION=7.5' >~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources/versions<br />

Yup, I guess Tor will loose many newbies for this and/or they'll loose some personal data e.g. bookmarks over a blinded reinstall.

Good news is, torbrowser-launcher's reinstall feature seems to still work just fine so maybe, some will try that route. So far it results in the same error (both localized and English versions), but there's a chance they don't entirely give up before a fixed tarball is published.

Here, all upgraded instances (from 7.0.11 to 7.5) now die with the same error. Looking quickly at one of them, this path is invalid, there is no "sources" subfolder. Won't be able to dig tickets or investigate any further until much later today, so I came here to see if, at least, the blog post had been updated with some warning, or anyone else had commented.

Should we not recommend to DISABLE auto upgrade until this is resolved, whenever this is not too late?

A

January 24, 2018

Permalink

Why wont my tor browser load? Ive been using this thing for over a year and it just started taking the piss for no reason. keeps saying trying to establish circuit

A

January 24, 2018

Permalink

installed on windows 7

EMET detect a SimExecFlow coming from TorBrowser and close the app (crash).
Note : There was already some problems to make TBB work with EAF and EAF+ in EMET, but it wasn't the only App requiring to disable these two mitigation. As far as I know only TBB 7.5 requires to disable SimExecFlow.

Incidentally, this page has a very strange behaviour. Sometimes everything works okay and the minute after it keeps reloading until I hit the "escape" key. And all the "reply" button and the "join discussion" form disappear. Weird.

Yes, this is a known issue, see https://trac.torproject.org/projects/tor/ticket/13893 for a long history of comments. Interestingly enough some users where under the impression that this got fixed for 32bit bundles with the switch to ESR 52. However, that does not seem to be the case for you at least. The proper fix is to get away from GCC 5 as the compiler used for the Windows bundles to GCC 6 where this problem seems to have been fixed. We are working on that: https://trac.torproject.org/projects/tor/ticket/20301.

This is weird, after copying the pref.js and user.js from my TBB7 folder to the TBB7.5 folder, it works. I didn't change anything on EMET, but now I can launch TBB 7.5.

I don't know which settings is responsible for this. Maybe "browser.tabs.remote.autostart.2" that I changed from "true" to "false" in TBB 7.
On the subject, when Emet crashed TBB 7.5, I've noticed that one instance of firefox.exe remain in the task manager. According to "process explorer.exe", the instance is on "suspended" state, when I click on resume, then firefox.exe shut down correctly.

I hope these infos can help.

Interesting, thanks for letting us know.

[EDIT]

FWIW: It seems that EMET is not compatible with sandboxing enabled. What you do with flipping that preference is outright disabling the sandbox Firefox ships. I think I'd rather rely on that one than on EMET, though. We have a long history of trying to make Tor Browser compatible with EMET (see: https://trac.torproject.org/projects/tor/ticket/13893) and it seems we still have some way to go.

It might be worth knowing whether that is actually just a Tor Browser issue or whether Firefox is affected as well. Does EMET work for you with a vanilla Firefox 52 ESR (see: https://www.mozilla.org/en-US/firefox/organizations/all/ for test versions).

Right now I've tested with Firefox Quantum. No problem with remote.autostart2 enabled. I expected a crash but no.

I used to disable remote.autostart stuff on Firefox 52 because I don't like to have too many process in the task manager. That's just me.
As I said, FF didn't work with EAF and EAF+ in EMET but so did many others apps.

I'll reinstall FF 52 ESR and run some tests in the future.

See you.

So I've installed and runned FF 52 ESR 32bits and 64bits out-of-the box, no crashes. Emet didn't complain for neither of them.
And I confirm that remote.autostart2. was enabled.

Weird...

I don't know, maybe it's remote.autostart2 + something else in Tor Browser like one of the extensions or something.

Good luck.

A

January 24, 2018

Permalink

torbrowser 7.5 no starting due to missing versions file.

After upgrade to 7.5 and closing and re-launching torbrowser, it will no longer launch.

Python error of missing file ~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources/versions

sources directory does not exist.

  1. <br />
  2. mkdir ~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources<br />
  3. echo 'TORBROWSER_VERSION=7.5' >~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources/versions<br />

torbrowser now starts with no problems

I think this is a bad idea. as you don't know if it will keep working with future versions of TBB and/or torbrowser-launcher, because neither will expect that this folder and file had been re-created manually by the user after TBB upgrade to 7.5. It could even "break things", depending on how torbrowser-launcher's maintainer decides to fix the issue.

Fact is, torbrowser-launcher still succeeds at launching TBB after the upgrade from 7.11 to 7.5, but only the first time. I did not read TBB source code, but I the only explanation I can think of is that TBB 7.5, during its first session, decides to do some clean up and deletes this part of its file tree, which it considers obsolete, and will likely do this again at least during each future upgrade.

Using "start-tor-browser --register-app" as a temporarly measure, as I described in my previous comment, should be more robust.

torbrowser 7.5 no starting due to missing versions file.

After upgrade to 7.5 and closing and re-launching torbrowser, it will no longer launch.

I have torbrowser to symbolic link to start-tor-browser -- that works.

  1. <br />
  2. hurtta:~$ torbrowser-launcher<br />
  3. Tor Browser Launcher<br />
  4. By Micah Lee, licensed under MIT<br />
  5. version 0.2.8<br /><a href="https://github.com/micahflee/torbrowser-launcher
  6. Refreshing" rel="nofollow">https://github.com/micahflee/torbrowser-launcher<br />
  7. Refreshing</a> local keyring...<br />
  8. gpgkeys: HTTP fetch error 1: unsupported protocol<br />
  9. Traceback (most recent call last):<br />
  10. File "/usr/bin/torbrowser-launcher", line 30, in <module><br />
  11. torbrowser_launcher.main()<br />
  12. File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.py", line 62, in main<br />
  13. app = Launcher(common, url_list)<br />
  14. File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 91, in __init__<br />
  15. if not self.common.settings['installed'] or not self.check_min_version():<br />
  16. File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 603, in check_min_version<br />
  17. for line in open(self.common.paths['tbb']['versions']).readlines():<br />
  18. IOError: [Errno 2] Tiedostoa tai hakemistoa ei ole: '/home/hurtta/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Docs/sources/versions'<br />
  19. hurtta:~$<br />
  20. hurtta:~$ ls -la bin/torbrowser<br />
  21. lrwxrwxrwx 1 hurtta hurtta 91 kesä 23 2017 bin/torbrowser -> /home/hurtta/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/start-tor-browser<br /><a href="mailto:hurtta@kasvihuone" rel="nofollow">hurtta@kasvihuone</a>:~$ torbrowser --verbose<br />
  22. Unable to update the static FcBlanks: 0x0600<br />
  23. Unable to update the static FcBlanks: 0x0601<br />
  24. Unable to update the static FcBlanks: 0x0602<br />
  25. Unable to update the static FcBlanks: 0x0603<br />
  26. Unable to update the static FcBlanks: 0x06dd<br />
  27. Unable to update the static FcBlanks: 0x070f<br />
  28. Unable to update the static FcBlanks: 0x2028<br />
  29. Unable to update the static FcBlanks: 0x2029<br />
  30. Unable to update the static FcBlanks: 0xfff9<br />
  31. Unable to update the static FcBlanks: 0xfffa<br />
  32. Unable to update the static FcBlanks: 0xfffb<br />
  33. Jan 27 09:09:21.686 [notice] Tor 0.3.2.9 running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2n, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.<br />
  34. Jan 27 09:09:21.686 [notice] Tor can't help you if you use it wrong! Learn how to be safe at <a href="https://www.torproject.org/download/download#warning
  35. Jan" rel="nofollow">https://www.torproject.org/download/download#warning<br />
  36. Jan</a> 27 09:09:21.686 [notice] Read configuration file "/home/hurtta/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc-defaults".<br />
  37. Jan 27 09:09:21.686 [notice] Read configuration file "/home/hurtta/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc".<br />
  38. Jan 27 09:09:21.688 [notice] Scheduler type KIST has been enabled.<br />
  39. Jan 27 09:09:21.688 [notice] Opening Socks listener on 127.0.0.1:9150<br />
  40. Jan 27 09:09:21.688 [notice] Opening Control listener on 127.0.0.1:9151<br />
  41. Jan 27 09:09:21.000 [notice] Parsing GEOIP IPv4 file /home/hurtta/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip.<br />
  42. Jan 27 09:09:21.000 [notice] Parsing GEOIP IPv6 file /home/hurtta/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip6.<br />
  43. Jan 27 09:09:21.000 [notice] Bootstrapped 0%: Starting<br />
  44. Jan 27 09:09:22.000 [notice] Starting with guard context "default"<br />

(Preview seems not work)

A

January 25, 2018

Permalink

Fedora 25 Cinnamon:Restart Tor button does not work.
I had to download Tor 7.5 and to configure everything
because the update of 7.11 is not working...

A

January 25, 2018

Permalink

I didn't find the new tor launcher easier to use. It's following most recent software by making features harder to find (or removing control from the user altogether) and dumbing down the interface with lots of white space. Please bring back Vidalia!

Vidalia was nice but it didn't scale well and it was apparently abandoned by its creator some years ago. So a better way would be to continue to try to improve the current way Tor Browser tries to accomplish some of the desirable functions of Vidalia.

A

January 25, 2018

Permalink

The special interest agenda, and other, censorship better stop. You are public, not private. On top of that, censorship is 100% out of step with the legal intent behind Tor's existence and funding. Those stupid little donation stunts don't change anything.

WE get to promote OUR views. YOU don't get to do shit.

WE don't have to talk to you certain ways. YOU have to talk to us certain ways.

WE pay you. YOU serve US.

Wooh! Someone finally said it! But the problem isn't that they won't post comments like that one. They will because doing so scores them some cheap symbolic value. Anyone can say "we're against censorship" but that's as far as it goes at Tor.

Try posting something grittier about their practices and policies. You'll be lucky if you even get the confirmation message. I can understand problems of topicality, spam and maybe a few other things, but this problem spans every whim and quirk of the highly paid employees at Tor and it is most definitely about their politics and stands on social issues.

Join the discussion...

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

7 + 8 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.