# New Alpha Release: Tor Browser 15.0a4
**URL:** https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697
**Category:** Tor Browser Alpha Feedback
**Tags:** tor-browser
**Created:** [October 16, 2025, 10:53am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697 "2025-10-16T10:53:49Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@system](https://forum.torproject.org/u/system)
#### Post date: [October 16, 2025, 10:53am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/1 "2025-10-16T10:53:49Z")
by [morgan](https://blog.torproject.org/author/morgan) | October 16, 2025
Tor Browser 15.0a4 is now available from the [Tor Browser download page](https://www.torproject.org/download/alpha/) and also from our [distribution directory](https://www.torproject.org/dist/torbrowser/15.0a4/).
This version includes important [security updates](https://www.mozilla.org/en-US/security/advisories/) 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](https://support.mozilla.org/en-US/kb/ai-chatbot)). 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](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44069) 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](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44108) from previous Tor Browser versions.
### 🐧 Updated Emoji Font for Linux
We have included the [Noto Color Emoji font](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41561) with our Linux builds. Linux users should now have all the latest and greatest emoji provided by [Noto Emoji](https://github.com/googlefonts/noto-emoji/).
### 🈴️ Improved CJK Glyph Rendering
At the [suggestion of a cypherpunk](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44227), we have swapped out the Noto font family for [Jigmo](https://kamichikoichi.github.io/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](https://developer.mozilla.org/en-US/docs/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](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44234). We therefore now rely on the [NoScript extension](https://noscript.net/) 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](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44123) 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](https://support.torproject.org/misc/bug-or-feedback/).
⚠️ **Reminder** : Tor Browser Alpha release channel is for [testing only](https://community.torproject.org/user-research/become-tester/). If you are at risk or need strong anonymity, stick with the [stable release channel](https://www.torproject.org/download/).
## Full changelog
The [full changelog](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/main/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt) 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](https://blog.torproject.org/new-alpha-release-tor-browser-150a4)
---
### Author:  [@Noino](https://forum.torproject.org/u/Noino)
#### Post date: [October 17, 2025, 10:49am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/2 "2025-10-17T10:49:14Z")
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](https://browserleaks.com/fonts). 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](https://www.utf8-chartable.de/unicode-utf8-table.pl?start=1280&number=1024)):-
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](https://gitlab.com/matzfan/selenium-tor/-/jobs/11748486860) and the test code is [here](https://gitlab.com/matzfan/selenium-tor/-/blob/master/test/features/fingerprinting/test_browserleaks_fonts.rb?ref_type=heads).
---
### Author:  [@tejasvi](https://forum.torproject.org/u/tejasvi)
#### Post date: [October 17, 2025, 10:54am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/3 "2025-10-17T10:54:18Z")
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.
---
### Author:  [@PieroV](https://forum.torproject.org/u/PieroV)
#### Post date: [October 21, 2025, 9:10am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/4 "2025-10-21T09:10:05Z")
@Noino Hi! What you’re doing is great! We would like to do something similar with [TZP](https://arkenfox.github.io/TZP/tzp.html) (it even has some global JS variables to use for that, we never took the time to create something that uses them).
> [@Noino](#):
>
> \*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.
That is sorta known. The font fallback is async, and the second refresh will have everything in cache.
> [@Noino](#):
>
> 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
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?
---
### Author:  [@Noino](https://forum.torproject.org/u/Noino)
#### Post date: [October 21, 2025, 10:34am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/5 "2025-10-21T10:34:45Z")
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](https://github.com/firecow/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](https://hub.docker.com/r/domistyle/tor-browser) 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](https://github.com/DomiStyle/docker-tor-browser). The container they use is [based on](https://github.com/DomiStyle/docker-tor-browser/blob/b935ba703dfbbfb9c0c735ac8d42fdb8eb981cab/Dockerfile#L2) 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!
---
### Author:  [@Noino](https://forum.torproject.org/u/Noino)
#### Post date: [October 21, 2025, 11:09am UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/6 "2025-10-21T11:09:07Z")
@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.
---
### Author:  [@PieroV](https://forum.torproject.org/u/PieroV)
#### Post date: [October 21, 2025, 12:41pm UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/7 "2025-10-21T12:41:11Z")
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.
---
### Author:  [@PieroV](https://forum.torproject.org/u/PieroV)
#### Post date: [October 21, 2025, 12:49pm UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/8 "2025-10-21T12:49:01Z")
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.
---
### Author:  [@Noino](https://forum.torproject.org/u/Noino)
#### Post date: [October 21, 2025, 2:26pm UTC](https://forum.torproject.org/t/new-alpha-release-tor-browser-15-0a4/20697/9 "2025-10-21T14:26:31Z")
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.