New Release: Tor Browser 8.0.3

by boklm | October 23, 2018

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

This release features important security updates to Firefox.

Tor Browser 8.0.3 includes newer NoScript and HTTPS Everywhere versions. Moreover, it ships with a donation banner for our end of the year campaign and includes another round of smaller fixes for Tor Browser 8 issues on Linux systems. We also switched to a newer API for our NoScript <-> Torbutton communication, which we need for the Security Slider.

The full changelog since Tor Browser 8.0.2 is:

  • All platforms
    • Update Firefox to 60.3.0esr
    • Update Torbutton to 2.0.8
      • Bug 23925+27959: Donation banner for year end 2018 campaign
      • Bug 24172: Donation banner clobbers Tor Browser version string
      • Bug 27760: Use new NoScript API for IPC and fix about:blank issue
      • Translations update
    • Update HTTPS Everywhere to 2018.9.19
    • Update NoScript to 10.1.9.9
  • Linux
    • Bug 27546: Fix vertical scrollbar behavior in Tor Browser 8 with Gtk3
    • Bug 27552: Use bundled dir on CentOS/RHEL 6
Tags
tor browser
tbb
tbb-8.0
khled.8@hotmai.com

Jean (not verified) said:

October 26, 2018

Permalink

Thank you very much for everyone for the great work making Tor better all those years - lots of love

khled.8@hotmai.com

SuperOnions (not verified) said:

October 26, 2018

Permalink

Default Tor Browser 8.0.3 window resolution is _1000 wide x 998 high_, with saved bookmarks and saved bookmarks folders visible in the horizontal Bookmarks Toolbar visible beneath the Address Bar, and all other settings affecting resolution have their standard-default settings.

8.0.3 resolution should be 1000x1000, as in Tor Browser 7.5.6, with saved bookmarks and saved bookmarks folders visible in the horizontal Bookmarks Toolbar visible beneath the Address Bar, and all other settings affecting resolution have their standard-default settings.

This defect, resolution:1000x998, in 8.0.3 duplicates the identical defect, resolution:1000x998, present in 8.0, 8.0.1, and 8.0.2.

See: https://trac.torproject.org/projects/tor/ticket/27845

Platform: macOS 10.10.5, desktop

khled.8@hotmai.com

bookmarks gone (not verified) said:

October 26, 2018

Permalink

Can someone please help me. McAfee had quarenteed an object when I installed the new TBB update (Windows 10 64-bit). I now lost all my bookmarks when I thought by deleting the entire Tor browser off my desktop that I could do a new TBB install thinking bookmarks would still be there but it's not. I went to the Firefox user profile for bookmark backups but they only show the bookmarks I have for Firefox. Did me uninstalling the entire Tor browser delete any chance of me retrieving my bookmarks or is there another way to find them on my system? Thank You!

khled.8@hotmai.com

hello (not verified) said:

October 27, 2018

Permalink

also with 8.0.3 noscript settings not being saved
i would call this an "important security risk"

khled.8@hotmai.com

Anonymous (not verified) said:

October 27, 2018

Permalink

high CPU usage on pornhub.com >
./firefox.real --class Tor Browser -profile TorBrowser/Data/Browser/profile.default
browser console not working properly, platform Arch.

khled.8@hotmai.com

tortor (not verified) said:

October 28, 2018

Permalink

I have requested new bridges several times over 10 times but I keep getting the same bridges.
94.181.82.25:34457
172.104.184.204:41319
79.66.110.5:42215
can you tell me why?

Its not the specific bridges that repeat its the bridges the torbrowser application aquires when getting bridges from "tor network settings" then "provide a brisge I know". another Mac running high siera had the same issue

Starting with version 8, 90% OF THE TIME when I start Tor I get the error page that says "Something is wrong" and complaining that Tor is not connected. I quit Tor and restart it and 100% of the time Tor connects on the second try.

It looks like the initial connection on the first startup is either being refused or is timing out prematurely. Is there a workaround for this behavior?

I dont get the "Something is wrong" part however Tor often does hang on first boot, restarting always works, so far.

So it looks like the first start of Tor 8.0.3 is hanging in your case and immediately failing in my case. This might reflect a TCP timeout issue. You are hanging waiting for a connection. I am displaying the "Something is wrong" red error startup tab in Tor because my connection is immediately failing. But what is common to both our cases is that the first start of Tor 8.0.3 fails to connect properly. The second connection seems to work.

No chance that this is some kind of man-in-the-middle attack?

Just got TBB setup on W7 and working. Had tinywall allowing TBB through. No trouble getting online but I'm getting a crash on exiting TBB. A dialog box comes up about 30secs later where I can close TBB. In taskmanager theres 2x firefox exe's - One is using 127328 kbs the other is 3596kbs Is this normal?
Thx

When I first used to start TBB I always clicked on the link "check if I'm currently using Tor" Also I sometimes like to go to the Tor Project page but there's no link to that either. Can we have these back please?

Is it possible to prevent bookmark icons?
Is it also possible to remove them?

Keep up the awesome work, guys.

Since the summer time started on in Brazil, Tor has stopped to work. It does not connect to any bridge. Other common browsers work regularly. Sometimes during the fail Tor produces some message about a fail in the clock of something.

Tor needs an accurate clock to work properly. Please double-check that your clock is set correctly after the summer time started.

When I close the browser the Tor process is kept alive as a child of systemd which prevents me from restarting the browser. I need to manually terminate the Tor process before I am able to restart the browser.

Is that reproducible? How are you closing Tor Browser? What log output do you get in a terminal if you are closing it? (You can see output by starting the browser with ./start-tor-browser.desktop --debug)

It is reproducible for me. I close the browser simply by clicking the close button in the browser's window frame.

start-tor-browser.desktop does not start the browser, but start-tor-browser does.

When I close the browser the output first mentions a JavaScript error in tor-circuit-display.js (myController is null) and then there are some warnings which look a bit like this:

[Parent ..., Gecko_IOThread] WARNING: pipe error ... Connection reset by peer: file /var/.../ipc_channel_posix.cc, line 353

And finally when I manually terminate the Tor process I am notified:

Catching signal TERM, exiting cleanly.

Does this happen with a freshly downloaded Tor Browser from our website, installed to a different location?

Yes it does

Correction: Tor detaches from firefox.real when I close the browser and becomes a standalone process, not a child of systemd. I misread the process graph. My apologies. But I must still manually terminate the Tor process before I can restart the browser.

Okay, thanks. I opened https://trac.torproject.org/projects/tor/ticket/28699 for that bug for further investigation. Please help us tracking this issue down as we can't reproduce it. If you can comment on that ticket and could answer follow-up questions (and test possible debug builds/fixes) that would be really helpful, thanks!

A big problem with Tor Browser is that many image and file downloading web sites don't work!
These web sites request captcha's and/ or clicking trough multiple layers of javascript links to get into the stuff but they load the final thing (image, or file, or page) from a different sub-domain, sometimes even different domains! And then present the error that the IP is wrong... because Tor Browser is using different paths to different sub-domains and different domains.
There should be a way to allow, at least for some sessions to allow the Tor Browser to use the same path at the very least in the same tab, and maybe even give that option to the all session and all tabs existent or new or to the actual tab and any new tab or windows it opens... from the web site point of view the IP should always seem the same no matter what sub-domains/ different domains it loads to find out if the user is really coming from that IP or using Onion network.
This is extremely danger when not used carefully so some UI should warn visually the user when that is being done... and should be explicitly activated by the user for that "Identity session", and the user should be able to disable it.
Otherwise there exists web sites that can't be used at all because of this way of working of Tor Browser.

Hello, how do I disable JavaScript in this new version?

As in the old one by setting the security slider to the safest level.

Hi Mike

Maybe you will also find the following pages helpful:

https://hackademix.net/2017/12/04/noscript-quantum-vs-legacy-in-a-nutsh…

https://blog.jeaye.com/2017/11/30/noscript

It happen to me one time a web site I was in is blocked in Russia, the problem is the redirect the domain to another and I couldn't ask for a new onion path since the domain was redirected before I could do that.
Can you add a manual mode in the options to ask for a new path for a specific domain/ sub-domain without having to enter in a tab such that the Tor makes a new path to it and allow the current tabs to get the new path and keep/ start using the page.

How would that work in practice? You would get a question in every redirect case asking whether you want to have the redirect over a new circuit?

Another way might be to have a circuits/domains tab that you can open which displays all of the active circuits/domains, similar to how the downloads tab displays a list of downloaded files. You could order the circuits by most recent attempted connection and a display a "new circuit" button next to each circuit, similar to how there is a "pause/resume/retry" button next to each incomplete download on the downloads tab.

It should be enough some UI to enter the domain/ sub-domain and ask Tor manually for a new path to it.
For example, bellow "New Tor Circuit for this Site" option you could add "New Tor Circuit for user provided URL". And explain in help section that in case TOR is making you exit in a server that is redirecting the domain to some other domain/ sub-domain (ex.: country's that censor some contents like Russia and many others) some times to show a message that you were trying to access a forbidden domain, the user should request manually for a new circuit so that it doesn't keep ending in the same censored server.

I would add there is another problem/bug closely related to the problem Loook describes. If a website fails to load due to a timeout, the circuit is displayed but clicking on "new circuit" only reloads the page but does not provide a new circuit! "New circuit" only works as expected if a connection is already established. I am using the linux 8.0.3 version.

I can not see download files

What platform and Tor Browser version are you using? Where are you looking for those files?

When I try to access the site "https://www.usnews.com/news/best-countries" even using many different TOR circuits I get the message
"Access Denied
You don't have permission to access "http://www.usnews.com/" on this server.
Reference #18.edcf180.1542840518.2dd64b6 "

I find it hard to belive that a US news site would block TOR access. Could you provide some reasons why TOR would be blocked or could this be blocked from other sources?

That website is using the CDN services by Akamai and they have a Tor blocklist installed by default. Chances are high that the site owner either does not know about and is just running with the default settings. Please ask them to get rid of that Tor ban, thanks!

So Akamai is just as bad as Cloudflare then! How sad. I recall reading a blog post some time ago which discussed the problem with Cloudflare and it referenced a report by Akamai which found the proportion of legitimate web traffic to be the same for Tor and non-Tor users, so I can't see why they think a default Tor blocklist is a good idea, it just deprives users of content and site owners of traffic!

I noticed that when I go to "https://bridges.torproject.org/options" for bridges and select IPv6 I get the message

"Uh oh, spaghettios!
There currently aren't any bridges available... Perhaps you should try going back and choosing a different bridge type! "

Are IPv6 bridges available? This occurs for all bridge types

Hm, this works for me now. Could you retry and report back in case this is still broken for you?

Just wanted to say I am using 8.0.3 on Debian 9.4 and it appears to be working great. As always, a million thanks to the Tor Browser team for all your hard work! My contribution will be coming your way in a week or so, I hope.

Thanks!

After posting a comment here the page gets caught in some kind of redirect loop.

I think this happens with JavaScript being disabled, which is a bug which we still not have fixed yet, see: https://trac.torproject.org/projects/tor/ticket/22530.

When I right click a link to open in a new private window, the new window opens against the top of my screen. It will resize itself to full screen almost spontaneously, and quite unpredictably. I try to place the mouse cursor at the top of the browser window to click and drag the window down. Sometimes I make it before "Full Screening", and other times ... BOOM! There it goes. Also, when the browser resizes, there is no yellow warning banner at the top anymore advising against resizing the browser. That's different. This is a TBB 8.0.3_x64bit on a Windows 7-x64bit machine. Thank you for helping all of us users with your continuous dedication to Tor Project.

That warning is only shown three times, assuming users know what they are doing after ignoring it. For the window resizing issue I've opened https://trac.torproject.org/projects/tor/ticket/28700. Thanks for the report.

Re: https://trac.torproject.org/projects/tor/ticket/28700 ...
Thanks gk. I have gone through 2 or three new mice trying to remedy some odd mouse performance (all of them the same brand from the same retailer ... not my first choice, but they were what was for sale). My last selection has been a different and well known brand (the last one in my reserves). The erratic TBB window resizing has ceased. Other problems with highlight-copy-paste seem solved, too. The warning still does not appear if I deliberately resize though. My trouble may have been defective hardware, i.e.: the computer mice.

Aha! Thanks for the report back. I am closing the ticket then. Please reopen if this does not seem like a hardware issue on your side.

When I read this and think of the times when I have accidentally resized to full screen with a slip of the mouse, I would think it better for the browser to catch a resize event and warn the user before it goes ahead with the resize rather than after when it is too late. "Are you sure you want to do this?" seems a better question than "did you really mean to do that?" But maybe it is more challenging to implement this way, I don't know.