New Release: Tor Browser 10.5a7
Tor Browser 10.5a7 is now available from the Tor Browser Alpha download page and also from our distribution directory.
Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.
This release updates Firefox to 78.6.1esr for desktop and Firefox for Android to 85.0.0-beta.7. Additionally, we update Tor to 0.4.5.3-rc. This versions also fixes a crash seen by macOS users on the new M1 processor.
Note: We are investigating a build reproducibility issue for the Android packages. We identified where the packages from different builders differ and we are working on a fix for the next version.
Note: We are aware that default bridges are not currently working in recent Tor Browser Alpha versions and Tor Browser does not start, as a result. The issue is being actively investigated.
Update: The issue impacting default bridges should now be resolved in recent Tor Browser Nightly versions.
Note: Tor Browser 10.5 does not support CentOS 6.
The full changelog since Tor Browser 10.5a6 is:
- All Platforms
- Update NoScript to 11.1.8
- Bug 40204: Update Tor to 0.4.5.3-rc
- Translations update
- Windows + OS X + Linux
- OS X
- Bug 40262: Browser tabs crashing on the new Macbooks with the M1 chip
- Build System
- All Platforms
- Bug 40194: Remove osname part in cbindgen filename
- All Platforms
Please note that the comment area below has been archived.
"Bug 40287 fix" (Switch DDG…
"Bug 40287 fix" (Switch DDG search from POST to GET) is a hit on our privacy and an errosion of anonymity of all TorBrowser users, since DDG is the default search engine.
The GET method discloses the search keywords clearly in the URL request, as the URL is not encrypted by means of HTTPS. The Tor encryption is great, but a malicious Tor node can "see" the search queries in clear, and collect information on Tor users, in time leading to corellation and deanonymization. I protest.
Even the justifying reason for this "improvement fix" is quite weak (see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/402… ):
To help that coder, simply tell him/her to open the needed links as the browser's New Tabs while keeping the original search results Tab until finished!
Is not this a natural solution we've already came to use while browsing?
That is not correct. The…
That is not correct. The path and query strings are encrypted by HTTPS. When using HTTPS (which is enforced for duckduckgo.com) the url is not visible to the exit node. We are assuming that DuckDuckGo logs all post requests, so the POST method does not provide any additional security or privacy over GET, and it only hurts the usability of Tor Browser.
In my TB (10.0.8), when I…
In my TB (10.0.8), when I click back in the DDG search scenario described above, a box pops up asking if I want to "Resend" (do the POST again) because the results are no longer cached.
I think it is probably not that big of a deal from a privacy perspective. There is a difference that POSTed search terms don't get logged in detail in webserver logs because the search terms are not part of the URL, so they are less visible to an attacker who manages to get the URL logs. However, that is not the threat model being described, and it is muted by other privacy protections built into Tor Browser while using Tor.
Also, thanks to the Tor Browser and Tor teams for all of your hard work! :-)
> DuckDuckGo SSL Lite and…
> DuckDuckGo SSL Lite and DuckDuckGo Onion SSL Lite
From the Answer #12 here:…
From the Answer #12 here: https://security.stackexchange.com/questions/7705/does-ssl-tls-https-hide-the-urls-being-accessed
That answer is a little…
That answer is a little deceiving. That information is similarly included when you send a query via POST. The only real difference between GET and POST from the perspective of a network adversary is the location of the query within the message.
URL is not encrypted by…
yes it is?
If you do any DDG search directly on the website, that already uses a GET request. GET and POST don't differ when it comes to encryption. In this context the only difference between them is your search terms appearing in the url.
> The GET method discloses…
> The GET method discloses the search keywords clearly in the URL request
That bit is true. Parameters such as query keywords are disclosed to the client's device and to the web server, but thanks to HTTPS which envelopes both GET and POST, parameters are not disclosed to eavesdroppers. As alluded by "Anonymous IT Security Guy" and the coder on gitlab, POST interferes with the Back button and with saving parameters in URLs of the client's bookmarks and history, but POST makes parameters a bit harder to log by the web server.
Hits on privacy of GET and POST in HTTPS are based on who controls the logging capability. Software is able to log URLs which include parameters sent via GET, but it's trivial to log parameters sent via POST. Tor Browser defaults to not saving history to disk, but it allows users to save bookmarks to disk at their own risk. So in Tor Browser, POST improves privacy of the bookmarks of that search engine on the client's device at the cost of degrading usability, but it does not assuredly improve privacy of logs on the server.
Downloaded 10.5a7 - win10…
Downloaded 10.5a7 - win10 pro 64b
- Installed portable/new: after configurating bridge (obfs4) - TOR doesn't start.
- Updating portable 10.5a4 - TOR doesn't start
1/20/21, 07:03:13.305 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/20/21, 07:03:13.305 [WARN] Bridge line with transport obfs4 is missing a ClientTransportPlugin line
1/20/21, 07:03:13.305 [ERR] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.5.3-rc e5c47d295bd3dc35)
As written yesterday - please don't make this version broadly available - stop and retract/withdraw from distribution channels - fix this nogo-bug first!
What's up with (automated) testing?
I'll update the blog post…
I'll update the blog post and mention this. That problem is already being investigated: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/402…
Thank you, seems more…
seems more complicated than expected. It also evaded testsuites...
Re: "Let's try remembering this for 10.5a8."
Would you mind writing/telling as soon as there are nightlies which you are assuming to fix this?
Yes, we'll update this blog…
Yes, we'll update this blog post when the fix is available.
Thanx Yes, it's alpha, but…
Yes, it's alpha, but since the update ruins existing configurations (rendering TBa unusable) - shouldn't you stop the update process until there's is a viable solution for updating?
And/or add a red CAVEAT at the announcing blog-statement above?
The "investigated"-link in…
The "investigated"-link in the blog post does not work because of extra "https//".
The .dmg download links for…
The .dmg download links for most of the MacOS releases do not exist, there is only the one for TorBrowser-10.5a7-osx64_ar.dmg.
That is a new apk created…
That is a new apk created during the build process that we use for testing. It isn't an apk you should install.
Hello! downloaded a file…
downloaded a file named "tor-browser-10.5a7-android-aarch64-androidTest.apk" from your storage.
Link to the file:
What's this? The Virus?