New Alpha Release: Tor Browser 15.0a4

Feedback Tor Browser Alpha Feedback
1

by morgan | October 16, 2025

lead.png1200×675 463 KB

Tor Browser 15.0a4 is now available from the Tor Browser download page and also from our distribution directory.

This version includes important security updates to Firefox.

Release Candidate

If all goes as planned, this will be our last alpha release in the 15.0 series before it is promoted to stable in the last week of October. Next week we will be focusing primarily on QA and ensuring all the various features and scenarios supported in Tor Browser still work as expected. This QA work will be tracked in the following gitlab issues:

As we reach the home stretch, now would be a great time to download and try out Tor Browser Alpha! We would appreciate it if the community would evaluate and exercise these following changes:

🤖 Removal of Various AI Features

Over the past year Mozilla has been working on integrating various AI features and integrations into Firefox (e.g. the AI chatbot sidebar). Such machine learning systems and platforms are inherently un-auditable from a security and privacy perspective. We also do not want to imply recommendation or promotion of such systems by including them in Tor Browser. Therefore, we have done what we can to remove such features from the browser.

☁️ Rename meek-azure pluggable-transport to just meek

In the past, we have used various cloud platform to host meek pluggable-transport backends including Google, Amazon, and Azure. However, as time passed these backends have moved and migrated and thus the cloud provider-specific name has become an historical artifact. Therefore, we have dropped the Azure part of the name and now just call it meek. Let this be a lesson to you about naming things!

🟪 Improved Dark Theme Support in Browser Chrome

We have improved the styling for our various Tor Browser-specific UI components for dark browser themes. All of our various purple elements should now look like they belong.

🦊 Removal/Replacement of New Firefox/Mozilla-specific Branding and Features

As part of ordinary incremental UI updates over the past year and the implementation of new features, Mozilla has added various new brand assets and service integrations. This includes things like those cute little fox graphics, Firefox Home, and the new History Sidebar. As of this release, there should not be any more Firefox or Mozilla specific branding, features, or service integrations accessible in Tor Browser. The new history sidebar in particular has been replaced with the legacy history panel from previous Tor Browser versions.

🐧 Updated Emoji Font for Linux

We have included the Noto Color Emoji font with our Linux builds. Linux users should now have all the latest and greatest emoji provided by Noto Emoji.

🈴️ Improved CJK Glyph Rendering

At the suggestion of a cypherpunk, we have swapped out the Noto font family for Jigmo. This should allow more Chinese, Japanese, and Korean graphemes to render accurately in web content.

✉️ Letterboxing Styling Improvements

We have tweaked our custom styling of the web-content letterboxing feature to confirm with and adapt to Firefox's own styling changes in Firefox 140. These tweaks should also play nicely with upstream's vertical tabs feature.

🚫 WebAssembly Restrictions Now Managed by NoScript

Historically, we have disabled WebAssembly globally when the browser is in the Safer and Safest security levels. However, with the latest Firefox version this has proven to be too aggressive, as doing so broke functionality in the built-in PDF reader. We therefore now rely on the NoScript extension built into the browser to handle disabling WebAssembly functionality in web content while the browser is in the Safer and Safest security levels, while also allowing WebAssembly to run unhindered in safe+privileged contexts like the PDF reader.

🔍 Stopped Hiding Protocol in URL on Desktop

Mozilla has reversed course on when the protocol portion (e.g. http or https) of the URL in the URL bar is hidden since Firefox 128. We used to have logic in one of our patches around Onion Services (which are always end-to-end encrypted regardless of the application-level protocol used) to follow whatever Firefox does for https. However, with the latest changes in Firefox, this patch became a bit gnarly to apply correctly so we took a step back and thought to ourselves, why are we even conditionally hiding this from the user?

So for now, we have decided not to hide the protocol from the user on Desktop platforms using a supported Firefox pref. We continue to follow upstream and always hide the protocol in the URL bar on Android (where horizontal space is at a premium). Users of Tor Browser Android can simply click the icon in the URL bar to get all the info about a websites HTTPS usage.

Send us your feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know.

⚠️ Reminder: Tor Browser Alpha release channel is for testing only. If you are at risk or need strong anonymity, stick with the stable release channel.

Full changelog

The full changelog since Tor Browser 15.0a3 is:

This is a companion discussion topic for the original entry at https://blog.torproject.org/new-alpha-release-tor-browser-150a4
2

I’m seeing a slight oddity with the Unicode glyph fingerprint with this release and thought I’d report it in case it is significant:

BrowserLeaks offer a font fingerprinting test here. This test produces a consistent* Unicode Glyphs fingerprint of 625E1D91 with release 15.0a4.

*I have found that one needs to navigate to the URL and then refresh the page at least one in order to obtain a deterministic result.

If I conduct the same test with Tor Browser inside a Docker container I consistently get a different result: 72F03AFF. The different hash seems to be the result of a difference at a single code point in the BrowserLeaks test: U+05C6 (a Hebrew character apparently):-

Outside Docker container: 520,1773 606,1840 520,1773 720,1361 606,2029 606,2029

Inside Docker container: 520,1773 606,1840 520,1773 720,1361 635,2290 606,2029

The Font Metrics fingerprint is the same for both: 579781F1133FB2AE99E2CF21B4F4BC60

I am reporting this as I use the BrowserLeaks font test in my Ruby Selenium bindings for Tor Browser. I run this and several other tests for every new stable and alpha release to ensure Tor Browser’s fingerprint when automated with Selenium is the same as the one I get from Tor Browser on my desktop. As far back as release 13 the BrowserLeaks results have always been the same inside and outside a Docker container. This is the first release where that is not the case.

I appreciate this issue is of a technical nature and am happy to raise an issue on GitLab if that is appropriate. This might of course be an oddity of the BrowserLeaks test and nothing to worry about. FYI my desktop system is Linux. The failing test job is here and the test code is here.

3

Is it possible to disable WebAssembly globally for those who are not interested in pdf reader? Unfortunately nothing is truly safe+privileged and using a separate pdf reader might be preferred in that case.

4

@Noino Hi! What you’re doing is great! We would like to do something similar with TZP (it even has some global JS variables to use for that, we never took the time to create something that uses them).

That is sorta known. The font fallback is async, and the second refresh will have everything in cache.

I would have to check the source code of the test to understand which glyphs they are testing.

But before I do, I might already know the cause: some distros have updated freetype and harfbuzz. Sadly, this is affecting how some glyphs are rendered, which might explain the change you see.

Do your docker image and configuration on desktop have the same versions of those libs?

5

Hi @PieroV.

My Mint 22.2 desktop has the following versions:

libfreetype6/noble,now 2.13.2+dfsg-1build3 amd64 [installed]

libharfbuzz0b/noble,now 8.3.0-2build2 amd64 [installed]

The docker image I used was from the gitlab-ci-local project. I run my tests with this tool locally before pushing to GitLab. This uses trixie (Debian 13.1) containers and trixie has freetype 2.13.3 and harfbuzz 10.2.0. AFAIK this environment should be the same as GitLab’s shared runners. And as expected, I get the same result when my tests run on these on GitLab.

I’ve actually just tried the browserleaks fonts test on another machine I have running LMDE 7, which is trixie-based, and I get the 625E1D91 fingerprint for 15.0a4 (i.e. the same as on my Mint 22.2 Ubuntu-based desktop).

In case you ever need to perform fingerprinting tests in docker, a docker container for Tor Browser is available at docker hub. It uses the latest stable release, but it is trivial to build an image for an alpha release from the source code. The container they use is based on Ubuntu 22.04 (freetype 2.11.1 and harfbuzz 2.7.4) and when I ran the browserleaks test in a custom 15.0a4 image I’d built using this, I got the 72F03AFF result again.

Anyway, I hope all this helps. I use TZP as part of my test suite, so any improvements there would be great!

6

@tejasvi welcome to the forum.

I believe that WebAssembly (wasm) can be disabled in about:config by setting javascript.options.wasm to false. You’d want to verify this before relying on it of course. Also note this may impact on your anonymity, as anyone checking for wasm will detect your browser as different to other Tor Browser users.

1 Like
7

Right, I’ve seen the question but forgot to answer.

Yes, the pref is still there, but we usually suggest against checking prefs in about:config.

Disabling WASM in standard is trivially detectable.

8

This is interesting indeed!

Could you please try to run the tests on 15.0a3 again?

It’d be interesting to exclude any environment change.

If 15.0a3 stays the same it could be interesting to check the nightlies between 15.0a3 and 15.0a4 as well, the know whether it was a change due to something we changed, or whether it was an upstream change.

I know it’s a lot to test. So, if we see 15.0a3 still matches could you open an issue on our GitLab? I can’t promise I will follow up soon, but at least we’ll put it on records.

9

Here are the results of the browserleaks fonts test Unicode glyphs fingerprint for 15.0a3:

Mint 22.2 (noble) desktop: cb74ddb8

LMDE 7 (trixie) desktop: cb74ddb8

Docker (trixie container): cb74ddb8

Docker (jammy container): cb74ddb8

I’ll open an issue on GitLab, thanks.