Tor Browser 12.0a4 updates Firefox on Android, Windows, macOS, and Linux to 102.4.0esr.
This version includes important security updates to Firefox and GeckoView. There were no Android-specific security updates to backport from the Firefox 106 release.
What's new?
Tor Browser 12.0a4 includes a number of changes that require testing and feedback:
Multi-locale bundles (Desktop)
This is the first multi-locale release of Tor Browser Alpha for desktop. All supported languages are now included in a single bundle, and can be changed without requiring additional downloads via the Language menu in General settings.
What to test: Tor Browser Alpha should default to your system language on first launch if it matches a language we support. Alpha testers are also encouraged to test changing language within about:preferences#general, and to report any new bugs with localization in general.
tor-launcher migration (Desktop)
Parts of the code that power tor-launcher – which starts tor within Tor Browser – have been refactored. Although this work doesn't include any changes to the user experience, those who run non-standard Tor Browser setups are encouraged to test 12.0a4 on their systems.
What to test: Alpha testers who run non-standard Tor Browser setups (including, but not limited to, those who use system tor in conjunction with Tor Browser) should test starting and connecting to Tor, and report any unexpected error messages they encounter. All of the previously supported environment variables should still behave the same way as in the stable series.
Onion Auth fixes (Desktop)
12.0a4 includes two fixes to Onion Service client authorization:
A fix to the auth window itself, which was broken in Alpha due to a regression caused by the esr102 transition: tor-browser#41344
Another fix to a longstanding issue with Onion Auth failing on subdomains, which has also been backported to 11.5.5: tor-browser#40465
What to test: Accessing client authorized Onion Services on both top-level and subdomains.
Always prioritize .onion sites (Android)
Android users can now enable automatic Onion-Location redirects by switching "Prioritize .onion sites" within Privacy and Security settings.
What to test: Enable "Prioritize .onion sites" within settings, visit a website that supports Onion-Location, and verify that you were redirected to the website's .onion address.
Unified Español locale (Desktop and Android)
Previous versions of Tor Browser Alpha were available in both "es" and "es-AR" (Español Argentina) locales. In Tor Browser 12.0a4 these have been unified into a single Spanish locale instead.
What to test: Alpha testers who use the "es-AR" locale should be automatically switched to "es-ES" after updating.
Tor Browser 12.0a4 64bit on a German Windows 10 64bit
After installing TB with the preset language (German) by the installer the browser opens in the correct language (German). Menu, settings, About dialog and manual are in German.
But, after switching to English (en-US) via about:preferences#general there are some untranslated texts, see screenshots for examples. The About dialog and manual are in English.
Hi @tobrop! It sounds like you’re experiencing this issue, which I’ve just opened a ticket for:
Could you try restarting Tor Browser Alpha with your desired language selected in about:preferences#general to see if that fixes the untranslated strings please?
In the following screenshot, the “Learn more” link opens https://support.torproject.org/en-US/onionservices/client-auth/.
What about to open about:manual#onion-services instead? There’s a chapter ONION SERVICE AUTHENTICATION
Using 102.2.21-Beta (12.0a4) on android. Tried always prioritize .onion sites. Tried blog.torproject.org and the new reddit.com. Went to both sites. Neither redirected me to onion sites. Tor browser on alpha desktop forwards as expected.
I also have an issue with the tor-launcher migration.
I tried running normal Tor browser 11.5.7 (based on Mozilla Firefox 91.13.0esr) (64-bit) and have it open like normal. Launching Tor Alpha browser 12.0a4 (based on Mozilla Firefox 102.4.0esr) (64-bit) at the same time results in this popup. I guess non-standard setup would be running both normal Tor browser and alpha at same time. I have never been able to run both browsers at the same time. No change from previous alpha versions.
Tor Launcher
Tor exited during startup. This might be due to an error in your torrc file, a bug in Tor or another program on your system, or faulty hardware. Until you fix the underlying problem and restart Tor, Tor browser will not start.
Strange, I just tested both URLs and was successfully redirected each time. Paging @PieroV to see what we can do to narrow down the bug.
Right, it’s not possible to run two Tor Browsers like that straight out of the box. By non-standard setups, we mean things like using system tor in conjunction with Tor Browser
Onion-location has a huge defect: the event wired to onion location might takes a very long time to be triggered.
It depends on the size of a page, and on the circuit you are using in turn: if you got a slow circuit and the page is quite big, it might take more than a minute before starting redirecting you.
We have an issue for that on GitLab, but we never had the time to look at it properly (I’ve tried, but I fear you need to go down the rabbit hole of Firefox HTTP code).
Basically, what Duncan said.
You could theoretically use two Tor Browsers by specifying a few environment variables.
You have two possibilities:
You use the same tor (as little-t-tor): one browser launches it, and controls it; the other one just connects to it (and it will not show you connection settings in about:preferences).
You will need to specify the same password for the control port to both browser (normally it’s randomly generated), and you will need to tell the second browser only to connect to tor.
You specify a custom couple of socks and control port addresses for one of the two browsers (e.g., SOCKS to 9502 and control to 9503).
One proposal was to randomize the port number used for the control port, but I didn’t like it very much (we’d need a way to avoid conflicts with other services on your system).
For the socks port, it’s possible to ask Tor to open one randomly and then tell you which one it’s using on the control port, but we haven’t implemented on the browser side, yet.
We plan to resume the work on this part of Tor Browser for 12.5 and we might implement this.
TOR_CONTROL_PASSWD is the variable used for the password, but you could use also a cookie file with TOR_CONTROL_COOKIE_AUTH_FILE (it will need the correct permissions, 600 on Linux IIRC, not sure for the other OS). You will need to set also TOR_SKIP_LAUNCH. TOR_CONTROL_PORT and TOR_SOCKS_PORT are the variables to use for 2. If you are on a Unix system (Linux or macOS), you could also use Unix sockets. In case the variables are TOR_CONTROL_IPC_PATH and TOR_SOCKS_IPC_PATH.
These environment variables can be replaced with preferences in about:config (I don’t remember which ones, though).
These configurations haven’t tested very much so please let me know if you happened to test and found errors.
I tried the onion-location feature a few times. I was able to get it to redirect one time but other times it doesn’t seem to be working. Another time I went on the torproject.org website and even after about 10 minutes it hasn’t redirected. I also remember when I first installed this version of alpha it did seem to work for me so it seems to be hit or miss.
As far as the two versions running side by side I don’t mind having to run them separately. I just wanted to mention it since I wasn’t sure what was meant by “non-standard setups”
In my builds I get redirected to the correct manual page.
Could you please try again?
I’ve tried both in English and in German, on Linux, and English on Windows 10.
Have you tried with a fresh installation or updated an older alpha?
In the latter case it might be a problem of cache of UI files (which is a problem anyway…).
It was a fresh installation of TB 12.0a4 64bit on a German Windows 10 64bit.
Just tried it again with a new installation of TB 12.0a4. Same behavior, the link opens https://support.torproject.org/en-US/onionservices/client-auth/ respectively https://support.torproject.org/de-DE/onionservices/client-auth/
I’ve tested onion location instead of onion authentication! I’ve noticed only now that the screenshot was for the authentication.
And yes, I can indeed confirm the problem!
In our workflow we open GitLab issues, both to track the problems and to add them to the changelogs.
Do you have an account for our GitLab? In case would you like to open the issue yourself?
Otherwise I can do, as you prefer .
so please let me know if you happened to test and found errors.
.
.