Tor Blog | The Tor Project
blog.torproject.org.web.brid.gy
Tor Blog | The Tor Project
@blog.torproject.org.web.brid.gy
New Alpha Release: Tor Browser 16.0a2
<article class="blog-post"> <source media="(min-width:415px)" type="image/webp" /> <source type="image/webp" /> <img class="lead" src="https://blog.torproject.org/new-alpha-release-tor-browser-160a2/lead.png" /> <div class="body"><p>Tor Browser 16.0a2 is now available from the <a href="https://www.torproject.org/download/alpha/">Tor Browser download page</a> and also from our <a href="https://www.torproject.org/dist/torbrowser/16.0a2/">distribution directory</a>.</p> <p>This version includes important <a href="https://www.mozilla.org/en-US/security/advisories/">security updates</a> to Firefox.</p> <p>⚠️ <strong>Reminder</strong>: The Tor Browser Alpha release-channel is for <a href="https://community.torproject.org/user-research/become-tester/">testing only</a>. As such, Tor Browser Alpha is not intended for general use because it is more likely to include bugs affecting usability, security, and privacy.</p> <p>Moreover, Tor Browser Alphas are now based on Firefox's betas. Please read more about this important change in the <a href="https://blog.torproject.org/future-of-tor-browser-alpha/">Future of Tor Browser Alpha</a> blog post.</p> <p>If you are an at-risk user, require strong anonymity, or just want a reliably-working browser, please stick with the <a href="https://www.torproject.org/download/">stable release channel</a>.</p> <p>Finally, we would like to thank the following community members for their contributions this release:</p> <ul> <li>NoisyCoil for their fixes for <a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41706">tor-browser-build#41706</a></li> </ul> <p>If you would like to contribute, our contributor guide can be found <a href="https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Development-Information/Tor-Browser/Contributing-to-Tor-Browser">here</a>.</p> <h2>Catching up With Rapid-Release</h2> <p>Over the past few months we have been sprinting to catch Tor Browser Alpha up with Firefox Rapid-Release. Tor Browser Alpha is now based on Firefox 147 and the rebase to Firefox 148 is <a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44510">now underway</a>. We also have a massive head-start on our bugzilla triage and have already flagged dozens of upstream patches which we will need to <a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues?sort=created_date&amp;state=opened&amp;label_name%5B%5D=Apps%3A%3AType%3A%3AAudit&amp;milestone_title=Browser%2016.0&amp;first_page_size=100">investigate further for ESR 153</a>.</p> <p>Unfortunately (though somewhat expectedly), all this progress has introduced some bugs and blockers.</p> <h3>🤖 Android APK Too Big</h3> <p>The upstream changes from Firefox pushed us over the approximate 100 MB size limit imposed by the Google Play Store on our Android packages. To trim off some more bytes and get us under the threshold we back-ported usage of the <a href="https://terser.org/">terser JavaScript minifier</a> (to reduce the size of the JavaScript source) and we now conditionally compile out preferences for unrelated platforms (i.e. we no longer ship preferences on Tor Browser Android which only affect Desktop).</p> <p>This issue has been resolved in <a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41688">tor-browser-build#41688</a>.</p> <h3>🛑 Websites Failed to Load</h3> <p>In Tor Browser 16.0a1 we discovered an intermittent issue where websites would fail to load after bootstrapping. This has a resulted in the browser being essentially unusable for a significant number of testers.</p> <p>The proximal cause for this that the NoScript extension would be put to sleep and unable to respond to requests made by the browser content process. Our engineers discovered this seems to have been fallout over upstream changes around how WebExtensions interact with the browser in permanent private-browsing mode. For now, we have worked-around this bug with patches to both NoScript and Tor Browser. When we know more, we will open an issue upstream with Mozilla.</p> <p>This issue has been resolved in <a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44398">tor-browser#44398</a>.</p> <h2>Send us your feedback</h2> <p>If you find a bug or have a suggestion for how we could improve this release, <a href="https://support.torproject.org/misc/bug-or-feedback/">please let us know</a>.</p> <h2>Full changelog</h2> <p>The <a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/main/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt">full changelog</a> since Tor Browser 16.0a1 is:</p> <ul> <li>All Platforms<ul> <li>Updated NoScript to 13.5.11.90301984</li> <li>Updated Tor to 0.4.9.4-rc</li> <li>Updated OpenSSL to 3.5.5</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44303">Bug tor-browser#44303</a>: Extension update job might never work on Android</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44416">Bug tor-browser#44416</a>: Rebase alpha onto 147</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44420">Bug tor-browser#44420</a>: Drop "rights" from components.conf</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44482">Bug tor-browser#44482</a>: Script execution in Safest mode via data URI navigation</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44492">Bug tor-browser#44492</a>: Fix python linting warnings in our test files</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44580">Bug tor-browser#44580</a>: Registers noscript to check for updates on first run</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41676">Bug tor-browser-build#41676</a>: Update toolchains for Firefox 147</li> </ul> </li> <li>Windows + macOS + Linux<ul> <li>Updated Firefox to 147.0a1</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44289">Bug tor-browser#44289</a>: RFPHelper console error when <code>--toolbar-field-color</code> is set to <code>inherit</code></li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44343">Bug tor-browser#44343</a>: Hide the default browser settings again after MozBug 1969949</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44460">Bug tor-browser#44460</a>: Payment methods and addresses setting headings are visible in settings</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44522">Bug tor-browser#44522</a>: Move common changes to about dialog to base-browser</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44535">Bug tor-browser#44535</a>: Letterboxing background colour is no longer used</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44554">Bug tor-browser#44554</a>: Unlabeled AI item in tab context menu in 147</li> </ul> </li> <li>Linux<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44410">Bug tor-browser#44410</a>: Use system's size for UI font on Linux</li> </ul> </li> <li>Android<ul> <li>Updated GeckoView to 147.0a1</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44398">Bug tor-browser#44398</a>: Unable to load websites after a short amount of time on Android</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44469">Bug tor-browser#44469</a>: Fix branding on Android RR</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44507">Bug tor-browser#44507</a>: Drop the dependency on Sentry</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44523">Bug tor-browser#44523</a>: New circuit seems to have disappeared from 147 on Android</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44532">Bug tor-browser#44532</a>: Backport Bug 1967968: Minify the pdf.js code in order to improve the loading performance</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44533">Bug tor-browser#44533</a>: Update NoScript to the version bundled with the browser on Android</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44591">Bug tor-browser#44591</a>: TBA Alpha fails to initialize WebExtensions</li> </ul> </li> <li>Build System<ul> <li>All Platforms<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44452">Bug tor-browser#44452</a>: Improve tb-dev range-diff and diff-diff</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44498">Bug tor-browser#44498</a>: Update translations CI to account for 1.0 version gap between alpha and stable</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41535">Bug tor-browser-build#41535</a>: Update macOS and Windows containers to Debian trixie</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41664">Bug tor-browser-build#41664</a>: Investigate and fix issue with unexpected build_id changes</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41668">Bug tor-browser-build#41668</a>: Build mozharness.zip when building dev artifacts</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41671">Bug tor-browser-build#41671</a>: Update tools/signing/linux-signer-sign-android-apks to check for v3 signatures instead of v1</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41678">Bug tor-browser-build#41678</a>: Consider set -u and maybe set -o pipefail</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41682">Bug tor-browser-build#41682</a>: relprep.py should fail when a GitHub release is not found</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41685">Bug tor-browser-build#41685</a>: Add henry to list of taggers in relevant projects.</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41687">Bug tor-browser-build#41687</a>: Add single <code>make list_toolchain_updates</code> command to list all toolchain updates</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41691">Bug tor-browser-build#41691</a>: Update Lyrebird to v0.8.1</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41705">Bug tor-browser-build#41705</a>: Remove unnecessary workaround in projects/go/build</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41707">Bug tor-browser-build#41707</a>: firefox-l10n fails to build with <code>fetch_locale: 1: set: Illegal option -o pipefail</code></li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41708">Bug tor-browser-build#41708</a>: relprep.py fails to update extensions when out/browser does not exist</li> <li><a href="https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40095">Bug rbm#40095</a>: cached checksums should not be used for input files when refresh_input is enabled</li> <li><a href="https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40096">Bug rbm#40096</a>: <code>container extract</code> is showing confusing error when target directory already exists</li> <li><a href="https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40100">Bug rbm#40100</a>: The GZIP variable makes set -u fail</li> </ul> </li> <li>Windows + macOS + Linux<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41427">Bug tor-browser-build#41427</a>: Drop the openURL property from the update</li> </ul> </li> <li>Windows + Linux + Android<ul> <li>Updated Go to 1.25.6</li> </ul> </li> <li>Linux<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41706">Bug tor-browser-build#41706</a>: Bump glibc to v2.28 in the linux cross-toolchain (aarch64)</li> </ul> </li> <li>Android<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44508">Bug tor-browser#44508</a>: Drop clearkey also on Android</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/32200">Bug tor-browser-build#32200</a>: only include required bits of OpenSSL in Android builds</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41679">Bug tor-browser-build#41679</a>: Android tor-expert-bundle archives missing version in filename</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41684">Bug tor-browser-build#41684</a>: Use only the NDK as var/compiler on Android</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41688">Bug tor-browser-build#41688</a>: 147 nightlies exceed the Play Store threshold</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41699">Bug tor-browser-build#41699</a>: Delete prefs specific to other architectures in omni.ja</li> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41702">Bug tor-browser-build#41702</a>: Replace uglifyjs with terser</li> </ul> </li> </ul> </li> </ul> </div> <div class="categories"> <ul><li> <a href="https://blog.torproject.org/category/applications"> applications </a> </li><li> <a href="https://blog.torproject.org/category/releases"> releases </a> </li></ul> </div> </article>
blog.torproject.org
February 4, 2026 at 6:50 PM
Arti 2.0.0 released: Relay, directory authority, and RPC development.
<article class="blog-post"> <source media="(min-width:415px)" type="image/webp" /> <source type="image/webp" /> <img class="lead" src="https://blog.torproject.org/arti_2_0_0_released/lead.png" /> <div class="body"><p>Arti is our ongoing project to create a next-generation Tor implementation in Rust. We're happy to announce the latest release, Arti 2.0.0.</p> <p>While "2.0" may sound like an exciting release number, it's actually fairly mundane. <a href="https://semver.org">Semver</a> requires us to bump our major version number when making breaking changes, and we had a couple breaking changes we wanted to make in order to keep our APIs tidy. These breaking changes are:</p> <ul> <li>Removing support for the long-deprecated <code>proxy.socks_port</code> and <code>proxy.dns_port</code> configuration options (<code>proxy.socks_listen</code> and <code>proxy.dns_listen</code> should be used instead).</li> <li>Removing support for the old syntax for specifying directory authorities. The new syntax can be seen in the <a href="https://gitlab.torproject.org/tpo/core/arti/-/blob/df5fba75c61001b07115776518f95bcb4d51681c/crates/arti/src/arti-example-config.toml#L449-484">example configuration</a>.</li> <li>Marking all APIs in the <code>arti</code> crate experimental. These APIs are likely to get moved into other crates or removed in the future, and anyone who uses APIs from the <code>arti</code> crate directly (as opposed to <code>arti-client</code> or other lower-level crates) should file an issue explaining their usecase, so that it can be considered as we move these APIs elsewhere.</li> </ul> <p>Other than removing deprecated features, this release adds support for using the <code>inet-auto</code> socket type to automatically pick an unused TCP port for the RPC server.</p> <p>There is also a significant amount of behind-the-scenes work on relay and directory authority functionality in this release.</p> <p>On the relay front, this includes our new generic and modular <a href="https://gitlab.torproject.org/tpo/core/arti/-/blob/a63c96bdc62fc088affa565be61c0215830b870e/doc/dev/notes/relay-conflux.md">circuit reactor architecture</a>, the ability to launch relay channels, the ability to respond to handshakes, and the groundwork for relays to act as the server side of a TLS connection.</p> <p>On the directory authority front, we've done significant work on authority certificate management, allowing Arti to download, validate, and store authority certificates.</p> <p>While running Arti as a relay or directory authority is not yet supported, we're making good progress towards those long-term goals.</p> <p>For full details on what we've done, including API changes, and for information about many more minor and less-visible changes, please see the <a href="https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md?ref_type=heads#arti-200--2-february-2026">CHANGELOG</a>.</p> <p>For more information on using Arti, see our top-level <a href="https://gitlab.torproject.org/tpo/core/arti/-/blob/main/README.md">README</a>, and the documentation for the <a href="https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crates/arti/README.md"><code>arti</code> binary</a>.</p> <p>Thanks to everybody who's contributed to this release, including Niel Duysters, carti-it, hjrgrn, and sjcobb!</p> <p>Also, our deep thanks to our <a href="https://www.torproject.org/about/sponsors/">sponsors</a> for funding the development of Arti!</p> </div> <div class="categories"> <ul><li> <a href="https://blog.torproject.org/category/announcements"> announcements </a> </li><li> <a href="https://blog.torproject.org/category/releases"> releases </a> </li></ul> </div> </article>
blog.torproject.org
February 3, 2026 at 4:50 PM
New Release: Tor Browser 15.0.5
<article class="blog-post"> <source media="(min-width:415px)" type="image/webp" /> <source type="image/webp" /> <img class="lead" src="https://blog.torproject.org/new-release-tor-browser-1505/lead.png" /> <div class="body"><p>Tor Browser 15.0.5 is now available from the <a href="https://www.torproject.org/download/">Tor Browser download page</a> and also from our <a href="https://www.torproject.org/dist/torbrowser/15.0.5/">distribution directory</a>.</p> <h2>Vietnamese Text Vandalism</h2> <p>A few days ago, one of our community members reported that some of the Vietnamese text translations in Tor Browser Android had been vandalised by a malicious contributor. Unfortunately, this mis-translated text ended up shipping in Tor Browser 15.0.4. These changes did <em>not</em> affect the browser's functionality or security properties in any way.</p> <p>In addition to shipping an unscheduled release to fix this problem, we are also reviewing the processes around accepting translation updates so that something like this does not again make it into Tor Browser Stable. Our goal is to keep community contributions open and welcome, while adding safeguards where needed.</p> <p>Finally, we want to thank our community of volunteer translators and in particular user <strong>SweetSea</strong> for reporting this issue to <a href="https://support.torproject.org/get-in-touch/chat-with-us/">our localisation developer channel (#tor-l10n)</a>. If you would like to help improve translations and join the community, please consider <a href="https://community.torproject.org/localization/becoming-tor-translator/">becoming a Tor translator</a>!</p> <h2>Send us your feedback</h2> <p>If you find a bug or have a suggestion for how we could improve this release, <a href="https://support.torproject.org/misc/bug-or-feedback/">please let us know</a>.</p> <h2>Full changelog</h2> <p>The <a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/maint-15.0/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt">full changelog</a> since Tor Browser 15.0.4 is:</p> <ul> <li>All Platforms<ul> <li>Updated Tor to 0.4.8.22</li> <li>Updated NoScript to 13.5.12.1984</li> <li>Updated OpenSSL to 3.5.5</li> </ul> </li> <li>Android<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44533">Bug tor-browser#44533</a>: Update NoScript to the version bundled with the browser on Android</li> </ul> </li> <li>Build System<ul> <li>All Platforms<ul> <li><a href="https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41691">Bug tor-browser-build#41691</a>: Update Lyrebird to v0.8.1</li> </ul> </li> <li>Windows + Linux + Android<ul> <li>Updated Go to 1.24.12</li> </ul> </li> </ul> </li> </ul> </div> <div class="categories"> <ul><li> <a href="https://blog.torproject.org/category/applications"> applications </a> </li><li> <a href="https://blog.torproject.org/category/releases"> releases </a> </li></ul> </div> </article>
blog.torproject.org
January 30, 2026 at 2:51 PM
New Release: Tails 7.4.1
<article class="blog-post"> <source media="(min-width:415px)" type="image/webp" /> <source type="image/webp" /> <img class="lead" src="https://blog.torproject.org/new-release-tails-7_4_1/lead.jpg" /> <div class="body"><p>This release is an emergency release to fix critical security vulnerabilities in OpenSSL, a network encryption library used by Tor.</p> <h2>Changes and updates</h2> <h3>Included software</h3> <ul> <li><p>Update the OpenSSL library to 3.5.4, which fixes <a href="https://lists.debian.org/debian-security-announce/2026/msg00022.html">DSA 6113-1</a>, a set of vulnerabilities that could be critical. Using this set of vulnerabilities, an malicious Tor relay might be able to deanonymize a Tails user.</p> <p>We are not aware of these vulnerabilities being exploited in practice.</p> </li> <li><p>Update the <em>Tor</em> client to 0.4.8.22.</p> </li> <li><p>Update <em>Thunderbird</em> to <a href="https://www.thunderbird.net/en-US/thunderbird/140.7.0esr/releasenotes/">140.7.0</a>.</p> </li> </ul> <h2>Fixed problems</h2> <ul> <li><p>Fix Gmail authentication in <em>Thunderbird</em>. (<a href="https://gitlab.tails.boum.org/tails/tails/-/issues/21384">#21384</a>)</p> </li> <li><p>Add a spinner when opening the Wi-Fi settings from the Tor Connection assistant. (<a href="https://gitlab.tails.boum.org/tails/tails/-/issues/18594">#18594</a>)</p> </li> </ul> <p>For more details, read our <a href="https://gitlab.tails.boum.org/tails/tails/-/blob/master/debian/changelog">changelog</a>.</p> <h2>Known issues</h2> <p>The homepage of Tor Browser incorrectly says you are still using Tails 7.4, even after you have upgraded to 7.4.1. It also links to the release notes for that older version.</p> <p>If in doubt, to verify that you are using Tails 7.4.1, choose <strong>Apps ▸ Tails ▸ About Tails</strong>.</p> <h2>Get Tails 7.4.1</h2> <h3>To upgrade your Tails USB stick and keep your Persistent Storage</h3> <ul> <li><p>Automatic upgrades are available from Tails 7.0 or later to 7.4.1.</p> </li> <li><p>If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a <a href="https://tails.net/doc/upgrade/#manual">manual upgrade</a>.</p> </li> </ul> <h3>To install Tails 7.4.1 on a new USB stick</h3> <p>Follow our installation instructions:</p> <ul> <li><p><a href="https://tails.net/install/windows/">Install from Windows</a></p> </li> <li><p><a href="https://tails.net/install/mac/">Install from macOS</a></p> </li> <li><p><a href="https://tails.net/install/linux/">Install from Linux</a></p> </li> <li><p><a href="https://tails.net/install/expert/">Install from Debian or Ubuntu using the command line and GnuPG</a></p> </li> </ul> <p>The Persistent Storage on the USB stick will be lost if you install instead of upgrading.</p> <h3>To download only</h3> <p>If you don't need installation or upgrade instructions, you can download Tails 7.4.1 directly:</p> <ul> <li><p><a href="https://tails.net/install/download/">For USB sticks (USB image)</a></p> </li> <li><p><a href="https://tails.net/install/download-iso/">For DVDs and virtual machines (ISO image)</a></p> </li> </ul> <h2>Support and feedback</h2> <p>For support and feedback, visit the <a href="https://tails.net/support/">Support section</a> on the Tails website.</p> </div> <div class="categories"> <ul><li> <a href="https://blog.torproject.org/category/tails"> tails </a> </li><li> <a href="https://blog.torproject.org/category/releases"> releases </a> </li></ul> </div> </article>
blog.torproject.org
January 30, 2026 at 2:50 PM
New Release: Tails 7.4
## New feature ### Persistent language and formats You can now save your language, keyboard layout, and formats from the _Welcome Screen_ to the USB stick. These settings will be applied automatically when restarting Tails. If you turn on this option, your language and formats settings are saved unencrypted on the USB stick to help you type the passphrase of your Persistent Storage more easily. ## Changes and updates * Update _Tor Browser_ to 15.0.4. * Update _Thunderbird_ to 140.6.0. * Update the _Linux_ kernel to 6.12.63. * Drop support for BitTorrent download. With the ongoing transition from BitTorrent v1 to v2, the BitTorrent v1 files that we provided until now can become a security concern. We don't think that updating to BitTorrent v2 is worth the extra migration and maintenance cost for our team. Direct download from one of our mirrors is usually faster. ## Fixed problems * Fix opening _.gpg_ encrypted files in _Kleopatra_ when double-clicking or selecting _Open with Kleopatra_ from the shortcut menu. (#21281) * Fix the desktop crashing when unlocking _VeraCrypt_ volumes with a wrong password. (#21286) * Use 24-hour time format consistently in the top navigation bar and the lock screen. (#21310) For more details, read our changelog. ## Get Tails 7.4 ### To upgrade your Tails USB stick and keep your Persistent Storage * Automatic upgrades are available from Tails 7.0 or later to 7.4. * If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade. ### To install Tails 7.4 on a new USB stick Follow our installation instructions: * Install from Windows * Install from macOS * Install from Linux * Install from Debian or Ubuntu using the command line and GnuPG The Persistent Storage on the USB stick will be lost if you install instead of upgrading. ### To download only If you don't need installation or upgrade instructions, you can download Tails 7.4 directly: * For USB sticks (USB image) * For DVDs and virtual machines (ISO image) ## Support and feedback For support and feedback, visit the Support section on the Tails website. * tails * releases
blog.torproject.org
January 16, 2026 at 6:52 AM
Arti 1.9.0 released: Proxy improvements, relay development, and more.
Arti is our ongoing project to create a next-generation Tor implementation in Rust. We're happy to announce the latest release, Arti 1.9.0. This release includes some behind-the-scences work on relays and directory authority development, and adds improved support for running with dynamically assigned ports. For example, Arti now accepts `proxy.socks_listen = "auto"` to configure its SOCKS proxy with an operating-system-assigned port, and writes the assigned port to a structured JSON file in Arti's data directory. Following this change to dynamic port assignments, we also depreacted `0` as a port number for making it disabling this feature all together. There has also been some interesting development going on with onion services, namely that Arti's key manager is now available as an experimental public API, intended for use by Arti's key management CLI. This is an API change only, users of the CLI are not affected by it. Our effort to support relays in Arti also made notable progress. Namely, the relay circuit reactor is now capable of handling incoming data stream requests, something crucial for the overall operational design of this component. Likewise, development in the domain of directory authorities also progressed significantly. This release contains some refactoring of various network document types and APIs and adds experimental support for directory authority key certificates. Similarly, the directory mirror got the relevant logic for downloading network documents from directory authorities. For full details on what we've done, including API changes, and for information about many more minor and less-visible changes, please see the CHANGELOG. For more information on using Arti, see our top-level README, and the documentation for the `arti` binary. Thanks to everybody who's contributed to this release, including Benjamin Erhart, Jérôme Charaoui, Neel Chauhan, Nihal, Pier Angelo Vendrame, Yaksh Bariya, hjrgrn, and tla. Also, our deep thanks to our sponsors for funding the development of Arti! * announcements * releases
blog.torproject.org
January 14, 2026 at 2:49 AM
New Release: Tor Browser 15.0.4
Tor Browser 15.0.4 is now available from the Tor Browser download page and also from our distribution directory. This version includes important security updates to Firefox. ## Send us your feedback If you find a bug or have a suggestion for how we could improve this release, please let us know. ## Full changelog The full changelog since Tor Browser 15.0.3 is: * All Platforms * Bug tor-browser#44418: Update built-in obfs4 bridges * Bug tor-browser#44433: Weird §:domain.com label in the Blocked Objects window * Bug tor-browser#44470: Rebase Tor Browser stable onto 140.7.0esr * Bug tor-browser#44474: Backport Security Fixes from Firefox 147 * Bug tor-browser#44482: (H1) Script execution in Safest mode via data URI navigation * Windows + macOS + Linux * Updated Firefox to 140.7.0esr * Android * Updated GeckoView to 140.7.0esr * Bug tor-browser-build#41681: Keep public suffixes up-to-date on 140esr-based Tor Browser for Android * Build System * All Platforms * Bug tor-browser-build#41654: Make relprep.py update Moat settings * Bug tor-browser-build#41682: relprep.py should fail when a GitHub release is not found * Bug rbm#40090: Make the cleanup faster * Bug rbm#40095: cached checksums should not be used for input files when refresh_input is enabled * Android * Bug tor-browser-build#41679: Android tor-expert-bundle archives missing version in filename * applications * releases
blog.torproject.org
January 14, 2026 at 2:49 AM
Code audit for the Tor Project completed by 7aSecurity
For the past three years, the Tor Project has been working to improve the tools, resources, and protocols used to monitor the health of the Tor network. This work aims to strengthen the Tor network's resilience and resist relay attacks. As part of this effort, in October 2025, 7aSecurity conducted a code audit of those tools. The code audit focused on the following projects: * TagTor is a Flask web app to display metrics about the Tor network and its nodes. * DescriptorParser is a small, standalone Java app to import Tor network descriptors into a PostgreSQL DB and a VictoriaMetrics time series. * Margot is a Rust command-line application using Arti that provides a series of commands for the network health team. * Exitmap is a fast and modular Python-based scanner for Tor exit relays. * Tor_fusion parses Tor network documents in the Rust programming language. * Simple Bandwidth Scanner is a Tor bandwidth scanner that generates bandwidth files to be used by directory authorities. * C Tor protects your privacy on the internet by hiding the connection between your Internet address and the services you use. This software is the one that runs on each relay of the Tor network. * Arti is the implementation of Tor in Rust. The code to be audited is the one that changed during this project. The audit found six vulnerabilities and highlighted eleven hardening recommendations. All findings have been reviewed by the Tor Project, and remediation work is being tracked as part of our ongoing security and maintenance processes. ### Read the full audit report For detailed findings and recommendations, please see the complete audit report here * reports * network
blog.torproject.org
December 18, 2025 at 10:48 PM
Transparency, Openness, and Our 2023-2024 Financials
Every year, as required by U.S. federal law for 501(c)(3) nonprofits, the Tor Project completes a Form 990, and as required by contractual obligations and state regulations, an independent audit of our financial statements. After completing standard audits for 2023-2024,* we added our federal tax filings (Form 990) and audited financial statements to our website. We upload all of our tax documents and publish a blog post about these documents in order to be transparent. (These documents have been available on our website for a while, but we are just now able to publish this blog post because of limited capacity. We hope you understand!) Transparency for a privacy project is not a contradiction: privacy is about choice, and we choose to be transparent in order to build trust and a stronger community. In this post, we aim to be very clear about where the Tor Project’s money comes from and what we do with it. This is how we operate in all aspects of our work: we show you all of our projects, in source code, and in periodic project and team reports, and in collaborations with researchers who help assess and improve Tor. Transparency also means being clear about our values, promises, and priorities as laid out in our social contract. We hope that by expanding each subsection of this post and adding more detail, you will have an even better understanding of the Tor Project’s funding, and that you will be able to read the audited financial statements and Form 990 on your own should you have more questions. *_Our fiscal years run from July through June instead of following the calendar year._ ## Fiscal Year 2023-2024 Summary The audit and tax filing forms we discuss in this post cover July 1, 2023 to June 30, 2024. During this fiscal period, the Tor Project realized some of the benefits of the organization’s investment in fundraising capacity with new staff, new policies and procedures, and a focus on diversifying the organization’s funding sources. **We’re happy to continue to see the results of this strategy pay off, and we could not have done this without your support and belief in the Tor Project’s vision.** ## Revenue & Support The Tor Project’s **Revenue and Support** in fiscal year 2023-2024, as listed in the **audited financial statement** , was **$8,005,661**. In our Form 990, our **Revenue** is listed as $7,287,566. **The difference between revenue on the Form 990 and the audited financials is not a mistake**. The different revenue totals reflect differences in rules about how you must report tax revenue to the IRS and how you must report revenue in audited financial statements. The Tor Project’s audited financial statements include in-kind contributions ($768,413) as a form of revenue, while the Form 990 includes the in-kind contributions as an expense. _In-kind contributions_ is a term to describe non-monetary donations from the community. **In 2023-2024, the Tor community contributed $768,413 in donated services or goods**. That's an estimated 7,614 hours of software development, 1,894,720 words translated, cloud hosting services for 23 servers, and 26 certificates. Right now, this estimation does not include relay operator time and cost, but it should. We are working to better estimate both the hours of software development and how to represent the contributions made by relay operators. Stay tuned for the coming years! Clearly, Tor would not be possible without you. Thank you. For the purposes of the following subsections of this blog post, **we’ll be looking at the Revenue total following the 990** , and breaking this total into the following categories: * U.S. Government (35.08% of total revenue) $2,556,472 * Corporations (21.59% of total revenue) $1,573,300 * Foundations (18.67% of total revenue) $1,395,494 * Individual Donations (15.61% of total revenue) $1,102,619 * Non-U.S. Governments (7.58% of total revenue) $552,387 * Other (1.47% of total revenue) $107,293 ### U.S. Government During this fiscal year, about 35.08% of our revenue came from U.S. government funds. For a comparison, in fiscal year 2021-2022, 53.5% of our revenue came from the U.S. government. You can see that our long-term mission to reduce our dependence on U.S. government funding has been coming to fruition. Of course there’s still more work to be done, and your support helps Tor realize this goal. We get a lot of questions (and see a lot of FUD) about how the U.S. government funds the Tor Project, so we want to make this as clear as possible and show you where to find this information in the future in these publicly-available documents. Let's talk specifically about which parts of the U.S. government have supported Tor, and what kind of projects they fund. Below, you can see a screenshot from the Tor Project's fiscal year 2023-2024 Form 990 on page 46 and 47, where we've listed all of our U.S. government funders. You will find text like this in all of our recent Form 990s: Now, we'll break down which projects are funded by each entity and link you to places in GitLab where we organize the work associated with this funding. **U.S. State Department Bureau of Democracy, Human Rights, and Labor ($2,121,049)** * Project: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibet * _Description_ : The goal of this project was to improve circumvention technology in the Tor ecosystem, specifically in China. Guardian Project was a subgrantee on this project. * Project: Tor VPN Client for Android * _Description_ : The goal of this ongoing project is to provide high-quality, device-wide privacy and censorship circumvention with a Tor VPN client on Android devices. * Project: Combating Malicious Relays * _Description_ : The goal of this ongoing project is to reduce malicious relay activity and improve the health of the network. * Project: Upgrading network relays to Rust * _Description_ : The goal of this ongoing project is to make users safer by ensuring the network is powered by a more secure implementation of Tor, called Arti. * Some of this funding passed through the Tor Project to Open Observatory of Network Interference. **National Science Foundation + Georgetown University ($14,715)** * Project: Expanding Research Frontiers with a Next-Generation Anonymous Communication Experimentation (ACE) Framework * _Description_ : This project's goal was to develop a scalable and mature deterministic network simulator, capable of quickly and accurately simulating large networks such as Tor. This project utilized the Shadow Simulator. **International Republican Institute ($80,029)** * Project: Localizing Tor tools and documentation into Arabic, Chinese, and Swahili * _Description_ : The goal of this project was to localize Tor Browser, Tor circumvention tools, Tor documentation and training materials, and a Tor-based file sharing tool called OnionShare into Arabic, Chinese, and Swahili. The project also created localized demonstration videos on using Tor, circumventing censorship, and using OnionShare. **Open Technology Fund ($340,681)** * Project: Support users to circumvent censorship against USAGM media sites * _Description_ : The goal for this ongoing project is to get more onion services set up in the world. To complete this goal, we will develop tools to help with setup and monitoring of onion services as well as help different USAGM media services to set up and monitor their onion services. You can read about some of the outcomes of the first year of this project, an effort to plant and grow more onions, on our blog. * Project: Rapid Response – Turkmenistan * _Description_ : The goal of this project was to ensure Tor tools and user support materials are available in Turkmen and that users in Turkmenistan have functional bridge options to connect to Tor. * Project: Tails Sustainability * _Description_ : The goal of this project is to support the sustainability of developing Tails. Whether related to research in the field of privacy and anonymity online, innovation in censorship circumvention, or advancing human rights, government funding is always the result of an extremely competitive bidding process. From start to finish, these projects are designed and controlled by the Tor Project, its core contributors, and members of the community in response to specific contract or funding opportunities. The National Council of Nonprofits has published many excellent resources for learning about how this process works in the United States. ### Corporations + Nonprofits The next largest category of contributions at 21.59% of the total revenue was donations from corporations and nonprofits. In the 2023-2024 fiscal year, $1,573,300 was generated from this category. That’s an increase of 68% over the fiscal year prior, and a 154% increase from two fiscal years prior. This is a result of our increased investment in a wider range of partnerships and support, including from organizations like OpenSats, Omidyar Network, and as part of our ongoing relationship with Mullvad VPN to develop Mullvad Browser and improve Tor Browser. This category is also where we account for membership dues from our members like DuckDuckGo, Proton, and Word Unscrambler. We haven't listed every single entity you will see in our Form 990 in this blog post, but we hope you have a better understanding of what you might find in the Form 990. ### Foundations Of the revenue in fiscal year 2023-2024, about 18.67% came from foundations, at $1,395,494. Some of these contributions are in the form of restricted grants, which means we pick a project that is on our roadmap, we propose it to a funder, they agree that this project is important, and we are funded to complete these projects. Examples in this category include Zcash Community Grants' support of Arti and Open Society Foundation’s support of the project to deploy a new bridge distribution system. Also in this category are unrestricted funds, like support from #StartSmall, Craig Newmark Philanthropies, and Ford Foundation. These unrestricted funds are not tied to a specific project. ### Individual Donations The next category of contributions at 15.61% of the total revenue was individual donors. In the 2023-2024 fiscal year, supporters gave $1,102,619 to the Tor Project in the form of one-time gifts and monthly donations. These gifts came in all different forms (including ten different cryptocurrencies, which are then converted to USD). Individual contributions come in many forms: some people donate $5 to the Tor Project one time, some donate $100 every month, and some make large gifts annually. The common thread is that individual donations are unrestricted funds, and a very important kind of support. Unrestricted funds allow us to respond to censorship events, develop our tools in a more agile way, and ensure we have reserves to keep Tor strong in case of emergencies. ### Non-U.S. Governments This line item represents funding that comes from Sida, a government agency working on behalf of the Swedish parliament and government, with the mission to reduce poverty in the world. Sida supports the Tor Project so that we can carry out user research, localization, user support, usability improvements, training for communities, and training for trainers. This support is how we are able to meet our users and to carry out the user experience research we do to improve all Tor tools. ### Other $107,293 of our revenue is from and for the Privacy Enhancing Technologies Symposium. Tor supports the yearly PETS conference by providing structure and financial continuity. ## Expenses OK, we've told you how we get funding (and which documents to look at to learn more). Now what do we do with that money? Based on the Form 990, our expenses were $7,343,602 in fiscal year 2023-2024. Like I discussed in the Revenue section above, the expenses listed in our Form 990 and audited financial statements are different. Based on the audited financial statements, our expenses (page 7) were $8,112,015. **Why the difference?** The Form 990 does not include in-kind contributions--the audited financial statement does. For the rest of this blog post, as above, we'll be looking at the Expenses total following the Form 990. We break our expenses into three main categories: * **Administration** : costs associated with organizational administration, like salary for our Executive Director, office supplies, business insurance costs; * **Fundraising** : costs associated with the fundraising program, like salary for fundraising staff, tools we use for fundraising, bank fees, postal mail supplies, swag; and * **Program services** : costs associated with making and maintaining Tor and supporting the people who use it, including application, network, UX, metrics, and community staff salaries; contractor salaries; and IT costs. If you want to learn more about the work considered "program services," you should read our list of sponsored projects on our wiki. In the 2023-2024 fiscal year, **84% of our expenses were associated with program services**. That means that a very significant portion of our budget goes directly into building Tor and making it better. Next comes administration at 10% and fundraising at 6%. Ultimately, like Roger (the Tor Project's Co-Founder) has written in many past versions of this blog post, it's very important to remember the big picture: Tor's budget is modest considering our global impact. Compared to the cost of operating a VPN, Tor’s cost per user is much smaller, because of our distributed design and the contributions of thousands of relay operators. And it's also critical to remember that our annual revenue is utterly dwarfed by what our adversaries spend to suppress people's human right to privacy and anonymity, making the world a more dangerous and less free place. In closing, we are extremely grateful for all of our donors and supporters. You make this work possible, and we hope this expanded version of our financial transparency post sheds more light on how the Tor Project raises money and how we spend it. Remember, that beyond making a donation, there are other ways to get involved, including volunteering and running a Tor relay! * financials
blog.torproject.org
December 17, 2025 at 8:48 PM
Advancing digital rights in 2026 will take all of us
Earlier this year, I was asked about the connection between digital rights to human rights. I responded with my own questions. Today, I'm asking you those same questions: > _When was the last time you learned about a police or military force harming a community? Where did you learn that information? When was the last time you saw hundreds of thousands of people on the street, calling for legislative change? Where did you see those pictures? How did those people learn about that protest and decide to join it?_ In these examples, information is passed around with the help of the internet. Anybody fighting for human rights today is using technology: to share flyers or photos on social media, to communicate with a group on a messaging app, or to send messages to their representatives via email. The upside is that technology makes the fight for human rights possible on a more global scale, because we can see and connect our movements together; however, most tech that we use today is controlled by Big Tech. That often means companies are conducting surveillance of how you use that technology and controlling the information you are shown through straight up censorship, algorithm manipulation, and shadow banning. As if that weren’t enough, there are many governments out there exploring and developing technology to repress and censor people. ## There’s no democracy without digital rights That is the connection between digital rights and human rights: You cannot untangle the fight to exercise our rights in the modern world from the internet and technology. Once you see that all movements for change depend, on some level, on technology, you can also see that the fight to defend democracies worldwide is equally connected to digital rights. In 2025 that has become clearer than ever. From now on, there can be no defense of democracy where technology is not part of the conversation. This year we’ve heard a lot about “tech sovereignty” and the importance of breaking out from the dependency on Big Tech and centralization of services by one country. But tech sovereignty alone won’t save us if we don’t make digital rights a part of this plan. Otherwise, tech sovereignty can easily become authoritarian tech sovereignty, with each country creating its own walled-off internet, like Russia and China have been pushing for their citizens. ## There are no digital rights without your support 2025 was also a year where projects working on digital rights faced unprecedented financial challenges. Many digital rights projects lost their backing. Think about it: we are in a moment in the world where democracies are fragile, where resistance and the fight to protect democracy and human rights are incredibly important. And we are living a moment where it is almost impossible to do these things without the use of technology. At this crucial moment for the world, the main projects that are providing protection and tools for this resistance, are underfunded. > **This fight to secure a better future for the world needs to include the support for projects working on digital rights.** _So I am calling on our community to come together in 2026 and support these projects_. Not only the Tor Project, but all of the projects that are working to build tools that ensure your rights are protected in the digital world. So you can help the fight for our rights in the “offline” world. ## Tor's part in upholding our digital rights in 2026 Rights are upheld by people, communities, and technologies that adapt to a changing world. Here's what that looks like for Tor as we head into the next year. We're continuing with a clear vision: make it easier for people to exercise their right to privacy and access to information with tools that keep us connected, and make it harder for powerful adversaries to break that connection. In practice, this means refining how we respond to censorship events in real time: rolling out new features like Conjure and experimenting with new pluggable transports, and integrating effective circumvention tools into more Tor software like Tails and Tor VPN. At the same time, we're expanding the capabilities of battle-tested options that people can rely on when conditions change. We're working on a more efficient transport mode for Snowflake, so users can still reach it even as censors adapt, and we're making WebTunnel even more powerful, so it works in more environments where other circumvention tools struggle. We'll also double down on keeping the Tor network safe against evolving attacks. One priority is implementing Counter Galois Onion (CGO), a new cryptographic defense designed to mitigate attacks on the Tor network, into onion services, alongside other initiatives to counter abuses of Tor technology. Finally, we'll continue our work to make onion services more widely accessible, so publishing information in anonymous and secure ways, and reaching people in censored regions, becomes easier. Privacy-preserving technology has to be usable by the millions of internet users who depend on it for their protection. Ensuring their ease-of-use and continued availability is one of the most powerful ways we can defend ~~digital rights~~ human rights in 2026. * human rights
blog.torproject.org
December 17, 2025 at 8:48 PM
New Alpha Release: Tor Browser 16.0a1
Tor Browser 16.0a1 is now available from the Tor Browser download page and also from our distribution directory. This is **the first Tor Browser Alpha release based on Firefox Rapid Release** : read more about this important change in The Future of Tor Browser Alpha. This version includes important security updates to Firefox. ## 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.0a4 is: * All Platforms * Updated NoScript to 13.5.1.90101984 * Bug tor-browser#43792: Determine whether noscript_persist users need to have their NoScript settings migrated * Bug tor-browser#43998: Rebase Tor Browser Alpha onto 141.0 * Bug tor-browser#44118: Decide how to deal with upstream feature gates in a RR world * Bug tor-browser#44280: Test stream isolation * Bug tor-browser#44333: Add the "No AI" version of DuckDuckGo to available search engines * Bug tor-browser#44365: Fix CSS linting errors introduced for firefox 145 * Bug tor-browser#44391: Restrictions cascade blocks every capability in subframes (e.g. captchas) * Bug tor-browser#44408: Fix TorDomainIsolator in 146 * Bug tor-browser#44418: Update built-in obfs4 bridges * Bug tor-browser-build#41609: Move back to CDN77 for default snowflake bridge * Bug tor-browser-build#41646: Update lyrebird version to v0.7.0 * Bug mullvad-browser#483: Add the "No AI" version of DuckDuckGo to available search engines * Bug mullvad-browser#487: Search engines are sorted alphabetically rather than the desired order * Windows + macOS + Linux * Updated Firefox to 146.0a1esr * Bug tor-browser#44302: Fix the flags of some about pages * Bug tor-browser#44310: Default zoom always resets to 100% * Bug tor-browser#44411: DownloadsTorWarning.sys.mjs fails to load * Bug tor-browser#44419: Re-add the moz-toggle title attribute patch * Linux * Bug tor-browser#44273: Restore Noto CJK as Jigmo has a too low readability * Bug tor-browser#44315: Font/text issue with self-upgrade window * Android * Updated GeckoView to 146.0a1esr * Bug tor-browser#44303: Extension update job might never work on Android * Bug tor-browser#44324: Refactor the NSS no proxy-bypass patch on A-S to avoid -Wunreachable-code * Build System * All Platforms * Bug tor-browser#43951: Include product with the component in triage CSVs * Bug tor-browser-build#40903: Make xz multi-threaded * Bug tor-browser-build#41445: Better handle bugzilla "Web Compatibility" issues in generate-bugzilla-triage-csv * Bug tor-browser-build#41607: Fix regression from #41373 in tools/count-mar-downloads * Bug tor-browser-build#41608: Add per-platform numbers for incrementals in count-mar-downloads * Bug tor-browser-build#41643: Update toolchains for Firefox 146 * Bug tor-browser-build#41644: Self-hosted browser extensions support in relprep.py * Bug tor-browser-build#41647: Add a XZ_DEFAULTS to set_default_env * Bug tor-browser-build#41648: Add a mozconfig to projects/geckoview * Bug tor-browser-build#41654: Make relprep.py update Moat settings * Windows + macOS + Linux * Bug tor-browser-build#41662: Add python-zstandard to desktop containers * Windows + Linux + Android * Bug tor-browser-build#41580: Update Go major to 1.25.x * Updated Go to 1.25.5 * macOS * Bug tor-browser-build#41665: Update macos signing wrapper for new executable gpu-helper.app * Linux * Bug tor-browser-build#41601: Upstream droppped Linux i686 support * Bug tor-browser-build#41627: Firefox build system needs a more recent version of OpenSSL on Linux * Bug tor-browser-build#41632: Ship Linux aarch64 builds in Alpha Release Channel * Bug tor-browser-build#41639: Remove linux-arm target * Bug tor-browser-build#41640: Clean the GCC config file * Android * Bug tor-browser#44360: Patch the vendored Gradle Nimbus plugin * Bug tor-browser#44370: Always produce target.maven.zip * Bug tor-browser-build#41485: Retire get_gradle_dependencies_list and create a simple way to update gradle deps * Bug tor-browser-build#41573: Remove Android x86 support * Bug tor-browser-build#41617: Pass page size to zipalign * Bug tor-browser-build#41620: Do not rerun zipalign when signing * Bug tor-browser-build#41621: Remove support using older android build tools when signing 14.5 releases in tools/signing/wrappers/sign-apk * Bug tor-browser-build#41628: android_ndk_version and revision can be grouped together * Bug tor-browser-build#41636: Update the scripts to manage Gradle dependencies * Bug tor-browser-build#41666: Normalize the path to tor-expert-bundle.aar * Bug tor-browser-build#41669: Restore UglifyJS but for Android x86_64 * applications * releases
blog.torproject.org
December 16, 2025 at 6:48 PM
Fighting for Internet Freedom: Ramon's Story from Cuba
In our ongoing fight for internet freedom, it's important to remember who we're fighting for. That’s why in this blog post, we’re highlighting a story submitted by a Tor user and how Tor helps them circumvent government censorship. Ramon* is a Tor user living in Cuba who faces challenges accessing information from blocked websites, grapples with slow internet speeds, and encounters sanctions limiting his access to specific platforms and software. These obstacles make it difficult for him to prepare effective curriculums for his students. In Cuba, the government controls the internet infrastructure, the formal media sector, and tightly regulates content. The independent press operates outside the law, and journalists face regular harassment, detention, and interrogation. A social communication law was approved in May 2023, stating that public information is solely accessible through state media, further restricting internet freedom in Cuba. This means all digital platforms must be registered with the government, and all of their content must align with the government ideology. People and independent press that share opposing views of the government on social media and the internet will face legal consequences. When governments deny access to the free internet by blocking sites and services, people like Ramon are stripped of their human right to access information. > “I am a software developer and programming teacher and I live in Cuba,” Ramon told us in his response to a survey of Tor Browser users. “There are many sites with information that I need to be able to do my work that are blocked due to absurd laws.” Ramon is one of billions of people living in countries where internet freedom has declined for more than a decade. Tor tools help Ramon circumvent blocked sites and access essential information to educate others. He responded to one of our requests for stories through an anonymous survey, and consented for us to publish his story in order to highlight the importance of Tor for free expression. As a nonprofit, the Tor Project relies on donations to continue supporting millions of people like Ramon. Join us in this fight – donate today and help us secure a free internet. *=pseudonym. * fundraising
blog.torproject.org
December 11, 2025 at 4:58 PM
Twenty contributors, three days, one goal: Bringing the Tor community together
Tor, in no small part, runs on the many contributions from our community of global volunteers. Since we all collaborate remotely, it was important to us to make time to see each other face-to-face and socialize. Having regular real-world meetings is especially crucial for integrating new volunteers into and maintaining existing relationships in our community. It's been a while since we last had such a meeting and therefore a bunch of Tor folks stepped up trying to get one organized. We wanted to figure out whether we as a community can actually get such a meeting off the ground, what it would cost and what lessons we could draw for similar gatherings yet to come. This blog post is a report back from our experiences and will hopefully inspire the community to set up similar meet-ups in the future. ## Before the meeting The Tor meetings in the past have typically been organized by the Tor Project, Inc., focusing on staff while some community members were invited to join. Coordination for those events happened via Tor project channels, using Tor infrastructure. How would it work not using any of those means to get our meeting off the ground? That was one of the questions we asked us when we thought about the meeting idea in spring this year. It turned out it was not that hard using a mix of a dedicated website, a form for collecting information about folks who wanted to join and finally a mailing list and Signal group for communication among attendees. On the invitation list were all of the Tor Project's core contributors and a list of people provided by the community team, given that we thought it was easier to organize a successful first community meeting if it would be invite-only including individuals and groups we already have some kind of relationship with. The other important question was related to how we could keep the budget low so that as many people on our invitation list as possible could make it. To that effort we used the same venue, Hylkedam in Denmark, where the annual BornHack hacker camp is happening. Bringing along tents was optional as there was a reasonable amount of bunkbeds available. Vegan breakfast, lunch and dinner was prepared together. All in all we ended up at 200$ per person for 3 days of connecting, meeting and socializing. > > > _I liked how everyone had the chance to speak up and influence the schedule each day during our opening and closing circles. Personally, I also enjoyed cooking dinner with some fellow Tor folks. It helps with bonding on a different level! - rgdd_ But getting people to show up was one thing. Creating an engaging, productive three day program was another challenge entirely. ## 3 days of excitement about Tor Preparing the structure of our gathering followed models we saw at previous meetings and events: we polled potential session topics and interests on our form and created structured sessions for the 3 days between breakfast and lunch and kept the afternoons open for ad hoc unstructured sessions and hacking time. Thus, the days followed the following cycle: opening session -> structured sessions -> unstructured sessions -> closing circle, which worked pretty well. We made sure we had note-takers for the structured sessions available so that folks interested could follow along from home by reading the notes on our website > > > _Had we not gotten into the same room, our conversations about how to make the Tor consensus more robust with transparency probably wouldn't have happened. I'm looking forward to see what happens next---a few people are prototyping! - rgdd_ We were a bit hesitant as to whether we could provide an inclusive and productive gathering for everyone given the different backgrounds of our participants. However, we got a good mix of Tor staff, relay operators and other volunteers working on Tor and in related areas at our gathering, which made the collaboration on different topics easy: the Tor staff was able to provide context on planned future work and missing pieces which we then could think through and work on together, which made a productive meeting for everyone. That way we were able to work on a wide range of topics quickly, from policies related to Directory Authorities over improving Grafana dashboards for relay operators to Tor and IPv6 and starting the Tor consensus transparency efforts, to name just a few. ## What's next? This community meet-up was (hopefully) not a one-off event, but rather the start of a series of similar ones. They don't have to be at Hylkedam (we'd like to see other venues as well!), nor does it have to be the same group of people sharing the organization workload. Thus, if you are excited about what you read in this blog post and want to help out with future community gatherings, get in touch! We'd be happy as well to get feedback about this format and how we can make such events more inviting and inclusive in the future. Want to be invited, too? Let us know! A good next opportunity to get in touch will be a at the upcoming Chaos Communication Congress. We'll have a relay-operator and community meet-up. Please drop by if you are around and interested! * community
blog.torproject.org
December 11, 2025 at 2:44 PM
New Release: Tor Browser 15.0.3
Tor Browser 15.0.3 is now available from the Tor Browser download page and also from our distribution directory. This version includes important security updates to Firefox. ### Tor-hosted NoScript updates From this release on, NoScript versions for Tor Browser are hosted on Tor's infrastructure, allowing us to deliver more timely and reliable updates. Distinguished by a version number ending with ".1984", they are otherwise equivalent to their AMO (stable) or pre-release counterparts: e.g. **13.5.2.1984** (Tor) = **13.5.2** (AMO). ## Send us your feedback If you find a bug or have a suggestion for how we could improve this release, please let us know. ## Full changelog The full changelog since Tor Browser 15.0.2 is: * All Platforms * Updated NoScript to 13.5.2.1984 * Bug tor-browser#22974: Self-host NoScript Updates * Bug tor-browser#44348: Backport Bugzilla 1999126: Protect whether PDF.js is enabled/disabled to improve fingerprinting protection * Bug tor-browser#44391: Restrictions cascade blocks every capability in subframes (e.g. captchas) * Bug tor-browser#44399: Rebase Tor Browser 15.0 stable onto 140.6.0esr * Bug tor-browser#44409: Backport Security Fixes from Firefox 146 * Bug tor-browser-build#41646: Update lyrebird version to v0.7.0 * Windows + macOS + Linux * Updated Firefox to 140.6.0esr * Bug tor-browser#44414: Disable Zucchini for the 15.0 series. * Android * Updated GeckoView to 140.6.0esr * Bug tor-browser#44346: Webrender broken on Adreno 510 devices with esr140 * Build System * All Platforms * Bug tor-browser-build#41644: Self-hosted browser extensions support in relprep.py * Windows + Linux + Android * Updated Go to 1.24.11 * applications * releases
blog.torproject.org
December 9, 2025 at 1:37 PM
Fighting for Internet Freedom: Ramon's Story from Cuba
In our ongoing fight for internet freedom, it's important to remember who we're fighting for. That’s why in this blog post, we’re highlighting a story submitted by a Tor user and how Tor helps them circumvent government censorship. Ramon* is a Tor user living in Cuba who faces challenges accessing information from blocked websites, grapples with slow internet speeds, and encounters sanctions limiting his access to specific platforms and software. These obstacles make it difficult for him to prepare effective curriculums for his students. In Cuba, the government controls the internet infrastructure, the formal media sector, and tightly regulates content. The independent press operates outside the law, and journalists face regular harassment, detention, and interrogation. A social communication law was approved in May 2023, stating that public information is solely accessible through state media, further restricting internet freedom in Cuba. This means all digital platforms must be registered with the government, and all of their content must align with the government ideology. People and independent press that share opposing views of the government on social media and the internet will face legal consequences. When governments deny access to the free internet by blocking sites and services, people like Ramon are stripped of their human right to access information. > “I am a software developer and programming teacher and I live in Cuba,” Ramon told us in his response to a survey of Tor Browser users. “There are many sites with information that I need to be able to do my work that are blocked due to absurd laws.” Ramon is one of billions of people living in countries where internet freedom has declined for more than a decade. Tor tools help Ramon circumvent blocked sites and access essential information to educate others. He responded to one of our requests for stories through an anonymous survey, and consented for us to publish his story in order to highlight the importance of Tor for free expression. As a nonprofit, the Tor Project relies on donations to continue supporting millions of people like Ramon. Join us in this fight – donate today and help us secure a free internet. *=pseudonym. * fundraising
blog.torproject.org
December 9, 2025 at 10:22 AM
Staying ahead of censors in 2025: What we've learned from fighting censorship in Iran and Russia
From internet blackouts in Iran to Russia's evolving censorship tactics, 2025 has tested Tor's anti-censorship tools like never before. These are the moments where the work of Tor's anti-censorship team is more important than ever, to fulfill our mission of preserving connectivity between users in affected regions and the rest of the world. In this blog post, we want to talk about what we've learned, how we've adapted, and what other internet users can do to keep Tor users connected. ## Iran In June, during the war between Iran and Israel, the censorship in Iran intensified up to a point where internet was disconnected for few days. Presumably to impede espionage-related communication while simultaneously consolidating political power. ### Monitoring the censorship landscape During this period, we were constantly monitoring the situation using our in-region vantage-point system. This vantage-point system is a network of monitoring locations inside Iran that provides more recent and accurate information about censorship than is available from public data. One clear example is domain-fronting data. Domain-fronting is a technique that makes Tor traffic look like other popular, harder-to-block websites (like major cloud services). To determine which domain-fronting configurations perform best across the most locations, we deployed an automated testing tool that detects and reports the accessibility of the Snowflake broker and the Moat service for each domain-fronting configuration at each of our vantage points. This information is then aggregated by the log collector and subsequently used to monitor the domain-fronting configurations currently in use and to select the configurations to use in the future. ### Strengthening Snowflake Snowflake is the most used network traffic obfuscation tool in Iran. Over the past year we have been working on improving it to ensure that it remains strong and accessible to users. We have upgraded the web extension to Manifest Version 3 (the latest browser extension standard), to be compatible with modern browsers. We improved the NAT checking logic which helps us figure out what kind of network setup each user has. This way, the proxies are more accurately assigned to the clients depending on their network capabilities. And we enhanced the metrics reported by the standalone proxy, providing better tooling for proxy operators to assist what is happening with their proxies. Under the hood we have created a staging server for Snowflake, so we have a robust infrastructure to stress test new features making sure they're fit for real deployment. This will help us bring big changes in the coming year to improve the efficiency of the protocol where networks are severely disrupted and to create better mechanisms to prevent censors from blocking Snowflake. ### Deploying Conjure Censorship agencies like those in Iran often attempt to block bridges by obtaining bridge information in bulk and then inputing the network address of these bridges to their censorship gateways to block them. That's why we developed Conjure. Conjure is a pluggable transport designed to stay ahead of proxy-listing-based blocking by leveraging unused address space within cooperating ISP networks, thereby limiting the damage caused by blocking individual network addresses. Think of it like the act of generating temporary email addresses to avoid spam emails, by making sure the address is temporary and easy to regenerate, anything blocked at that address won't affect your ability to get new ones. We are working on distributing Conjure in places with strong censorship. To make it hard for censors, we have improved Tor's implementation of Conjure by extending the protocols used both for bootstrapping the connection and transport the data. We added multiple registration methods (DNS and AMP-cache), making the bootstrap of the conjure connection more censorship-resistant and the connection will look as if the user is connecting to widely used service. We also integrated additional transports from upstream (DTLS and prefix) that makes the Tor traffic look like common protocols–meaning regular internet traffic. ## Russia Another region that has experienced many changes this year is Russia. With continued conflict and attrition, internet censorship has intensified, including increased allowlist-based censorship and address-block-based censorship. Last year, we introduced WebTunnel as a new pluggable transport. We have seen this year how WebTunnel has become a key tool for users in Russia, thanks to its ability to blend into regular web traffic. As the severity of censorship in Russia has increased, WebTunnel has also received several fixes, such as SNI imitation and safe non-WebPKI certificate support with certificate-chain pinning to ensure it can withstand more kinds of censorship, including SNI allowlisting and the rapid blocking of distributed bridges. Many of these improvements come from volunteers or are shaped by user feedback. Our community of users and supporters makes all this work possible and helps us stay ahead at Tor. Thanks to our Tor community team, we have first-hand insights into what works and what doesn't. This gives us access to the best information in the region. Additionally, through the community team's work with people on the ground, we receive support in testing and identifying the best technology for each censorship scenario. ### Experimenting with bridge distribution When we started distributing WebTunnel bridges in December they were a very useful tool to connect to Tor. They worked well for months, and Tor Browser users got them configured automatically over Connect Assist if they were located in Russia. However, in June, the Russian censors began listing most of our WebTunnel bridges, prompting us to shift strategies. In recent history, our Telegram distributor has proven to be a useful tool in Russia, as the censor has a harder time extracting all the bridges from it. This is why we have now added support for WebTunnel in our Telegram distributor. We are always trying to meet our users where they are, and while Telegram might not be the safest place for your online communications, many users in Russia already uses it. And is not only useful for Russian users, but also for Iranian ones that are currently using webtunnel bridges distributed over Telegram. All these fast changes of bridges distribution are possible thanks to rdsys, Tor's new bridge distribution system that we introduced last year. This year we kept improving rdsys adding a staging server, so we can stress-test it in a similar environments to the ones used in production. For our censored users that means that by the time new and updated anticensorship features arrive, we have already been able to fix many stability issues. ## Where do we go from here? Supporting our users to continue fighting censorship is what our work is all about. Making it possible to connect to the Tor network on censored networks–whatever they are. Whether it is your university, your internet service provider, or your government trying to keep you from getting the information you are entitled to. Next year we'll start rolling out Conjure, keep improving WebTunnel,and prepare Snowflake for the next big censorship events. You too can help us fight censorship today, by sharing your bandwidth and running your own Snowflake. The easiest way is to install a snowflake plugin in your browser to help others access the Tor network. And if you have a website consider running a webtunnel bridge.
blog.torproject.org
December 4, 2025 at 8:20 AM
Arti 1.8.0 released: Onion service improvements, prop 368, relay development, and more.
Arti is our ongoing project to create a next-generation Tor implementation in Rust. We're happy to announce the latest release, Arti 1.8.0. This release introduces a new, usage-based, timeout for strongly isolated circuits, as specified in proposal 368. Arti now has experimental `tokio-console` support for development and debugging purposes. To use this feature, you will need to build Arti with the experimental `tokio-console` cargo feature **and** `--cfg tokio_unstable`, and enable the `tokio_console` option in the config. This release also brings some of quality of life improvements for onion services, with the new experimental `arti hsc ctor-migrate` command for migrating C Tor client restricted discovery keys (previously known as "client authorization keys") to Arti's keystore, and a configuration option for controlling which onion services to launch. Behind the scenes, we have continued development of functionality required to support relays and directory authorities. This development has focused on the routing architecture and protocol implementation (circuits and channels), parsing and generating Tor network documents, directory cache support, and on implementing the OR port listener and the associated configuration. For full details on what we've done, including API changes, and for information about many more minor and less visible changes, please see the CHANGELOG. For more information on using Arti, see our top-level README, and the documentation for the `arti` binary. Thanks to everybody who's contributed to this release, including Dimitris Apostolou, hashcatHitman, hjrgrn, Mynacol, Neel Chauhan, nield, Nihal, NoisyCoil. Also, our deep thanks to our sponsors for funding the development of Arti! * announcements * releases
blog.torproject.org
December 3, 2025 at 6:21 AM
The Future of Tor Browser Alpha
With the recent release of Tor Browser 15.0, we have come out of yet another ESR-transition season whereby Tor Browser has been updated to the latest version of Firefox Extended Support Release (ESR). Historically, we have spent several months each year on this work. It is a very important and methodical process which ensures Tor Browser remains secure and private through upstream security updates from Mozilla and by testing and updating our own features and customizations. You can find a somewhat detailed overview of this process and why it is so important in our previous Tor Browser 14.0a1 release blog post. Starting with Tor Browser 16.0a1, rather than being based on Firefox ESR 140 (as would have been the case in the past), the Tor Browser Alpha release will instead be based on the latest Firefox Rapid Release. The Tor Browser Stable release (starting with 15.0) will remain on the latest Firefox ESR Release. **This change will only affect Tor Browser Alpha users**. # Release Channels _NOTE: This is a simplification of the available browser release channels offered both by Mozilla and the Tor Project, but these are by far the most relevant release channels to the majority of users._ Mozilla has two different release channels for shipping Firefox updates: Rapid Release and Extended Support Release. The basic idea is that the Rapid Release channel receives major features with each new version every four weeks, while the Extended Support Release channel only receives security updates every four weeks while receiving a year's worth of features roughly every 52 weeks (you can read about the differences in this Mozilla Support article). The Tor Project also has two different release channels for shipping Tor Browser updates: Alpha and Stable. The Alpha channel is where the Tor Browser developers spend most of their time working on new features. To the end-users, this is where most of the visible changes happen throughout the development cycle. The Stable channel typically receives security updates with each release and only occasional new features through targeted backports from the Alpha channel. Up until now, both of these channels (i.e. Tor Browser Alpha and Stable) have been based on Firefox's Extended Support Release channel. For the next release cycle, we are going to conduct an experiment whereby Tor Browser Stable will continue to be based on Firefox Extended Support Release while Tor Browser Alpha will instead be based on Firefox Rapid Release. Traditionally, we would now be working on Tor Browser 15.5a1 based on Firefox ESR 140. Instead, we are already working on Tor Browser 16.0a1 and every Alpha from the 16.0aX series will be based on the Firefox Rapid Release channel. Tor Browser 16.0 will stabilize when Firefox 153 is ready next year and, once released, will follow the ESR channel for the remainder of its life-cycle. # Ramifications for Users and Testers ⚠️ If you are an at-risk user, concerned about your privacy, or just need a reliably working web-browser, you SHOULD NOT use Tor Browser Alpha and instead stick with Tor Browser Stable ⚠️ If you are an alpha tester running Tor Browser Alpha, you can expect the following changes: * **Quicker access to new upstream features developed by Mozilla** : Rather than waiting until the next major ESR version for newly shipped features in Firefox, Tor Browser Alpha users will receive these features shortly after they are introduced upstream. This will allow our alpha-testers to evaluate how new upstream features interact with (or break) our privacy and security patches over a much longer development and stabilization period. * **_Potentially_ Less Secure and Private Tor Browser Alpha Releases**: One side-effect of quickly shipping upstream features to users, is that we will also be quickly shipping upstream bugs to users too. These bugs could have security and privacy implications. The upside is that we _should_ also get bug reports from users more quickly as well, which will give us more time to develop proper fixes than we would otherwise. Therefore, users should only use Tor Browser Alpha for testing purposes! At-risk users should migrate to and remain on Tor Browser Stable. * **A Less Predictable Release Cadence** : Sometimes the intersection of upstream changes, our build system, and our patches introduce rather difficult problems for us to solve. It is entirely possible resolving such problems may take longer than the available four week window of time between scheduled Rapid Release versions. Therefore, Tor Browser Alpha releases may be delayed relative to Firefox's release schedule. The consequence of this is that Tor Browser Alpha may not receive upstream security updates as promptly as it has in the past. * **Faster Platform Deprecation** : Because we are following Mozilla directly, we will also be dropping support for platforms in the Alpha release channel sooner than we would have in the past. Previously, Tor Browser Alpha's minimum supported platforms would follow Firefox ESR, which would change on a yearly basis after the ESR Transition. In the general, Tor Browser Alpha will drop support for legacy platforms at the same time as Firefox Rapid Release. Specifically, the following platforms will no longer be supported by Tor Browser Alpha starting with 16.0a1: * **x86 Linux and Android** : As described in our Tor Browser 15.0 blog post, upstream has dropped support for Linux and Android running on 32-bit x86 processors. As such, we will not be releasing builds for these platforms in the Tor Browser Alpha 16.0 series. * **Android older than Android 8.0** : Also described in our Tor Browser 15.0 blog post, upstream has dropped support for Android versions 5.0, 6.0, and 7.0. This means to upgrade to the Tor Browser Alpha 16.0 series you will need a mobile device running at lest Android 8.0. If you are an end-user running Tor Browser Stable, you can expect the following changes: * **One major feature release per year** : Previously, we have had two feature releases per year: one in Q2 and one in late Q3. With this new development model, we expect to have only _one_ major feature release per year. Therefore, with Tor Browser Stable 15.0 just released, users can expect Tor Browser Stable 16.0 (based on Firefox ESR 153) to be released about halfway through Q3 of 2026 (i.e. there will not be a Tor Browser 15.5). # Developer Rationale So why are we changing things? We believe changing our development model in this way will allow us to be both more effective at developing and maintaining Tor Browser while also reducing contributor stress. For the past several years we have _tried_ to divide the annual Tor Browser development cycle into two phases: a six month feature phase and a six month ESR transition phase. During the feature phase, we would work on new developments to be shipped during Q2 in the .5 release. During the ESR transition phase, we would work almost exclusively on ESR transition related work to be shipped during late Q3/early Q4 in the .0 release. This division of the year into two distinct phases introduces problems: * **Cascading Delays** : If something is scheduled for a particular feature phase, then inevitable development and project management surprises can drive back the day we ship. However, doing so would also drive back when we _begin_ the next ESR transition phase. This delay would of course pay it forward and further delay the next feature phase and so-forth. Unfortunately, we cannot just let these delays pile-up release upon release because we have a fixed window of time each year on the calendar where we _must_ complete our annual ESR transition. This is because Mozilla offers only a four release overlap between major ESR versions where both the previous ESR and the new ESR receive security updates. This means that if we were to begin the ESR transition work only when the new major ESR version is released, there would be only about 16 weeks of calendar time before the old Tor Browser version would stop receiving security updates from upstream. We therefore have a responsibility to our users to get the ESR transition work done as quickly as humanly possible before this window closes. Unfortunately, we never _really_ hit the desired six-month release cadence. In reality, we usually have more of a seven to eight month feature phase and a four to five month ESR transition phase. So, if we cannot let our development windows slide then the only recourse we have to remedy delayed features is to either kick them to the next major feature release or to try to finish them during the ESR transition phase. * **Developer Stress** : The 16 week ESR window is a very small amount of time for us to do our due-diligence and properly serve our users. There is a ton of work that has to happen (as described in our Tor Browser 14.0a1 release blog post) and not a whole lot of time to do it. As a result, this part of the Tor Browser release cycle has historically been quite stressful and a major contributor to developer burnout. * **Poor Feature Development Continuity** : Context switching in general is the bane of many developers. It is quite difficult to make consistent progress on a task when you are being constantly interrupted by other things. With our previous on-again/off-again development model, nearly everyone on the team had to switch from feature work to ESR transition work for an entire release cycle in order to make the ESR deadline. As a result, in the past we have had to take extra care to split large features across multiple feature release cycles, rather than naturally working on them incrementally across one. This process increases complexity and mental overhead when developing features to make sure that what we ship to users works even when not fully complete. It also adds an extra 'remembering what we were doing months ago' tax when coming back to a feature after an ESR transition and further complicates planning and scheduling. The hope is that by spreading the ESR transition-related work out over the entire year, we will be able to: * Increase the number of major features shipped each year * Increase our confidence in the ESR transition itself * Trade the high-intensity/high-stress 16-week ESR transition window for lower-intensity/lower-stress over the entire year # Next Steps It is yet to be seen whether this process change will have the intended results, but initial experiments have been promising. The first step in this process was experimenting with iterative Rapid Release to Rapid Release rebases (rather than a single large ESR to ESR rebase which we have traditionally done). This process has not only been easier to perform, but also _much_ easier to code-review. It turns out rebasing after 4 weeks of changes is significantly easier than rebasing after 52 weeks of changes! For the ESR 140 transition, this process also allowed us to catch several runtime bugs in Tor Browser for Android individually as they were introduced, rather than having to debug and disentangle them all at once. We have continued this iterative-rebase process throughout the ESR 140 cycle and will be releasing Tor Browser Alpha 16.0a1 based on Firefox 146 or 147 soon. The big challenge for us this release cycle will be keeping up the slow incremental progress each release while interleaving this with our regular feature work. The nice thing about making this change now is that if there ends up being major problems or unintended consequences, we can always revert to the old ways next year without our Tor Browser Stable users noticing much of a difference. The worst-case scenario is that we already have a head-start on the ESR 153 transition. # Become a tester! Now is a great time to become a Tor Browser Alpha tester! However, if you are at risk or need strong anonymity, please stick with Tor Browser Stable. * applications
blog.torproject.org
December 2, 2025 at 4:20 AM
Keeping the internet free together: State of the Onion Community Day
Fighting for a free internet requires collective action. And the Tor Project is proud to be in the company of many likeminded organizations that work to maintain and restore access to trustworthy information for millions of people globally. Tune into the **State of the Onion: Community Day** livestream to hear directly from other members of the Tor community about their efforts to defend your privacy, protect you from surveillance and censorship, and how they are making an impact in 2025. ### Community Day - December 10, 2025, 17:00 UTC Join us on Day 2 as organizations from the wider Tor ecosystem discuss how they are providing privacy preserving technologies on the most trusted anonymity network. Here is a little preview of who to expect: * **OONI** : Working to advance transparency of internet censorship globally by collecting and publishing empirical network measurement data that serves as open evidence for research, advocacy, and litigation. * **The Guardian Project** : Keeping mobile users connected to sites and apps they need in times of crisis, making design choices that prioritize users' physical security, and bringing "Kindness" to more platforms and users. * **Hushline** : Providing a safe way for whistleblowers to reach someone who can help-- with a focus on lawyers, journalists, and mental health professionals--while providing native Onion Services for high-risk sources. * **Freedom of the Press Foundation** : Looking at the challenges of building open-source tools that facilitate journalism in dangerous situations and the future of technology-enabled whistleblowing. * **And many more to come...** ### How to watch * **Youtube:** https://www.youtube.com/watch?v=tZVk0kb7lhw * **Onion Service:** http://xgsobitduxv7gcc5qlveigwiku7qcjn5exf4ayusw4mwq7kfrapmrjyd.onion/ * **X:** https://x.com/torproject Engage in the conversation on social media with the hashtags #Tor #StateOfTheOnion2025 or post questions and comments in the chat during the event. **Did you miss Tor's State of the Onion 2025 Day 1 broadcast?** Watch the recast. See you there! * * * We couldn't do the work we're sharing at this year's State of the Onion without your support! This event is part of our year-end fundraising campaign. You can fund the Tor Project's work by making a donation today. Right now, if you make a donation to Tor, your donation will be matched by a generous supporter. That means if you donate $25, they will also donate $25 --- effectively doubling your gift and raising $50 for our teams. You can check out our previous State of the Onion streams on our YouTube channel or replay some other virtual events we've participated in earlier this year like the Anonymity for a healthy democracy with Isabela Fernandes or IGF 2025: Truth Under Siege.
blog.torproject.org
November 27, 2025 at 2:19 AM
Counter Galois Onion: Improved encryption for Tor circuit traffic
It's always a good day when we can talk about cryptography. Especially when we are sunsetting one of the oldest and most important encryption algorithms in Tor and replacing it with a research-backed new design, called Counter Galois Onion. This overhaul will defend users against a broader class of online attackers (described below), and form the basis for more encryption work in the future. ## Which cryptography are we talking about here? The algorithm in question is Tor's _relay encryption_. While Tor uses the standard TLS protocol for communication between relays, and between clients and relays, it needs a specialized algorithm for encrypting user data as it traverses multiple relays in a circuit.1 That's the relay encryption algorithm. The client shares a symmetric key with each relay on its circuit, and encrypts an outgoing message, or "relay cell" with each one of those keys. Each relay can remove a single layer of encryption, until the client's cell reaches the exit relay. Of course, we need to make sure that the data isn't modified on the way from the client. For that, we include a cryptographic digest in the cell. The digest covers not only the cell itself, but also _all previous cells sent through the circuit_ (to prevent re-ordering) and another secret shared key (to make the digest unpredictable). So with the digest added, clients behave as follows: they calculate and set the digest, then they use a stream cipher (AES-128-CTR in Tor's case) multiple times to encrypt the cell for each relay. If we simplify _a lot_ , then a relay cell looks a little like this: Field | Width ---|--- Zero | 2 bytes Digest | 4 bytes Other stuff | ... The "zero" field is there so that nodes other than the exit can avoid checking the digest: If a relay gets a cell with a value other than zero, then it can tell that it isn't the recipient of that cell, so it doesn't need to check the digest: it just decrypts the cell and forwards it to the next relay. When we designed this algorithm, we didn't give it a name. Now that we're replacing it, it helps to have some way to identify it, so we're calling it "tor1". Figure 1. The tor1 encryption algorithm, as used at a middle layer. The input is a message M. A counter CTR is expanded via a psueodrandom function (PRF, instantiated with AES-128-CTR), to produce a stream of bytes. These bytes are xored with M to produce a ciphertext C. Figure 2: The tor1 encryption algorithm, as used to originate a message. The message M is mixed with the hash state HS, and a portion of the digest is appended to the message. The whole thing is then xored with the PRF (AES-128-CTR) to produce our ciphertext C. ### Wait, that design looks funny! Yeah, you wouldn't build it that way nowadays, would you? That's why we're replacing it. In today's world of high-quality online courses and excellent introductory material, it's easy to forget the general state of accessible cryptography resources when Tor was getting started. AES was brand new, and authenticated encryption as a separate field of study had just started to emerge. Existing designs weren't suitable for Tor's needs. The original onion routing paper didn't specify a means for authentication. Designs like mixmaster and mixminion were optimized for larger message sizes, and required a separate full digest for every _possible_ layer of encryption. (For example, Mixmaster supported up to 20 remailers, so had to reserve space for 20 digests (and other stuff) in _every message_.) Some of the "weird things" in the current tor1 design are outdated, but not _awful_ ; others are things that are more valuable to resolve. ### So, what _are_ the problems with the tor1 design? There are a few. First the big one: #### Problem 1: Tagging attacks Tagging attacks enable an active adversary to trace traffic by modifying it in one place on the network, and observing predicatable changes in another. Even when tagging attacks don't succeed immediately, their side effects can give the attacker more and more opportunities to retry. > This is the most important attack we're solving with CGO. Even without the other problems below, this one would be worth fixing on its own. The main version of this attack arises because tor1's use of AES-CTR encryption with no hop-by-hop authentication means that the relay encryption is malleable. Since counter mode derives its ciphertext C by XORing a secret key stream S with the plaintext P (C = S ⊕ P), an attacker who can XOR their own pattern M in to the ciphertext will produce C' = (S ⊕ P) ⊕ M = S ⊕ (P ⊕ M) — that is, a valid encryption of (P ⊕ M). An attacker can use this attack to ensure that they control both ends of the circuit. They XOR a pattern onto a cell at one end, and then see if any garbled cells at the other end become clear when whey remove that same pattern. Any circuits with an honest endpoint will fail (and not be deanonymized), but the client will retry them until they eventually choose a malicious endpoint. If the attacker chooses a known-plaintext portion of the relay cell for their marker (such as the header or slack zero space), then they can use their marker to communicate an identifier across the circuit, by retrieving it at the end: M = (P ⊕ M) ⊕ P. M can then be used to transmit an IP address or unique identifier for the user. In comparison to probabilistic traffic correlation, this attack provides definite results immediately, with a strength multiplier: it also allows the attacker to ensure that all the traffic they successfully carry is fully deanonymized, before the circuit is used for any application traffic at all. The downside for the attacker is that the resulting failure rate of circuits can be detected by the client. Currently, Tor clients emit log notices and warnings when circuit failure rates are excessively high. Unfortunately, as vigilant users have noticed, when the DDoS attacks on Tor become severe, these detectors give false alarms. This class of attacks (where an adversary is able to abuse the Tor Protocol to transmit information between relays _before_ application activity) is known as Internal Covert Channel attacks. Tor is in the process of updating its threat model to cover these attack vectors explicitly, along with two other categories of attack vectors. #### Problem 2: Forward secrecy begins when a circuit closes > This attack and the one after it are much less severe than the tagging attack above; we mention them for the sake of completeness. In many modern online protocols, including messaging apps like Signal, the keys used to decrypt a message are destroyed as soon as the message is decrypted, so that nobody can steal them and use them later on. But Tor's old encryption algorithm (tor1) doesn't provide this property: the same AES keys are used for the entire life of the circuit. That means that if a key was stolen while the circuit was still alive, all previous traffic on the circuit could be decrypted. When a circuit's lifetime is on the order of minutes, that's not so bad, but sometimes circuits stay around for days. (What's more, longer-lived circuits may be better for anonymity, especially when the user is maintaining a persistent identity, so it's a good idea to make them stronger.) Although this attack is minor in comparison to the tagging issue, we may as well address it while we are updating our encryption. #### Problem 3: A 4-byte authenticator? Seriously? Yeah, that's not great. The use of a mere 4-byte digest means that there's a one-in-4-billion chance to forge a cell undetected. That isn't a very good attack in practice: if the attacker _doesn't_ get lucky with their guess, then their invalid message causes the circuit to fail, and they can't try again unless the client builds another circuit through them. The same pathbias mechanisms that help resist tagging attacks also help here, but it would be better not to need them. (Also, it's using SHA-1, which is showing its age, to say the least.2) ## So, how did we think about replacing this in the past? We've wanted to replace this algorithm a few times, but we've been hung up on issues of design and efficiency. We definitely don't want to follow remailer designs by adding one authenticator per layer of encryption: that way lies big overhead. If we tried something like that with onion services, we'd be devoting something like 15% of our bandwidth to authenticator fields. One promising design element has been _wide-block ciphers_ : these are ciphers (or modes of using ciphers) that encrypt an entire message as if it were a single opaque block: any change in the ciphertext garbles the entire message as if it were a single block in a regular block cipher. (Technically, this needs to be a "strong pseudorandom permutation" (SPRP) if it's going to resist tagging attacks.) You can make a wide-block cipher into an authenticated cipher by reserving some portion of the plaintext for a known value -- say, 16 bytes of zeros. But most wide-block cipher designs are comparatively expensive. Nearly all of the strong ones (BEARESS, LIONESS, biIGE, HHFHFH) require two full encryptions and two hashes over the data. Newer modes like HCTR2 require only one encryption pass, but still need two hashes. (For comparison: tor1 requires 3 encryptions and one hash for a cell on a 3-hop circuit, whereas one of these designs requires on the order of 6 encryptions and 6 hashes.) We're willing to pay _some_ CPU cost for improved cryptography (and we should expect to pay some cost, since authentication doesn't come for free) but we need to keep the cost to a minimum. Now, multiple passes are necessary for any wide-block design: it's provable that there's no way to make sure that changing any bit will potentially garble every other bit unless there are at least two passes. But we'd like to make these passes as cheap as possible! There has also been excellent work on other wide-block designs built from scratch, rather than from an underlying cipher (notably AEZ). ## What are we going with? For years now, cryptographers have been looking for good solutions here. Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch, and Martijn Stam have a design that they're calling Counter Galois Onion (CGO). It's based on a kind of construction called a Rugged Pseudorandom Permutation (RPRP): essentially, it's a design for a wide-block cipher that resists malleability in one direction (for the encrypt operation, but not the decrypt operation). If we deploy this so that clients always decrypt and relays always encrypt, then we have a tagging resistant3 cipher at less cost than a full SPRP! Using a RPRP that they call UIV+ (see the paper), the authors achieve all of our goals (tagging resistance, immediate forward secrecy, longer authentication tags, limited bandwidth overhead, relatively efficient operation, and modernized cryptography). (Shortly before this blog post went up, they revised their paper and released a new security proof.) We've written a specification which matches their paper and their reference implementation. ### How does it work? CGO makes it so that if anybody tampers with any part of your encrypted data, the entire message, and all future messages, become unrecoverable. Here's how! (If you don't like reading cipher diagrams, you may want to skip this section. And if you _really_ like reading them, you should check out the specification and the paper!) The figures below present the UIV+ building block, and show how it is used to build CGO encryption. Figure 3: UIV+ encryption The input X is split into two parts: A short X_L, and a longer X_R. X_R, and a "tweak" value H, are themselves passed as tweaks to a tweakable block cipher E_T (instantiated with LRW2), which is then used used to encrypt X_L. The output of this encryption seeds a PRF, which is xored into X_R to encrypt it. Figure 4: Middle-layer CGO encryption. CGO treats every message as a 16-byte tag T, and a 493-byte ciphertext C. These are passed as X_L and X_R to the UIV+ encryption algorithm above. The tweak value (H in UIV+) is here called T': each cell's "T" value, after encryption, is taken as the T' for the next cell. Figure 5: Originating a CGO message When _originating_ the message, CGO initializes its tag as a nonce value N. The value of N, _and the encryption keys_, are all transformed using an "Update" algorithm as the message is encrypted. The new N, and the new encryption keys, will be used to encrypt the next cell. Okay, but how does all of this cryptography solve the problems we began with? First (and most importantly) **tagging attacks** are prevented by two factors: 1. When encrypting4, the message is transformed in a wide-block construction, so that any change to the input renders the entire output unrecoverable. 2. The chaining of T' and N values means that a message's encryption depends on _all previous messages_ , so if a single message is garbled, all subsequent messages will be unrecoverable. Second, **forward secrecy** is achieved with the Update construction in figure 5. Every time a new cell is originated or received, the keys used to originate or receive it are transformed unrecoverably, so that the encryptor/decryptor no longer holds the keys necessary to decrypt earlier cells. Third, the **truncated digest** is now replaced with a nice long 16-byte authenticator, like sensible people use. ### Aside: What if we're wrong? CGO is a fairly new design, and it's reasonable to ask whether there could be weaknesses in it that would make it worse than it's designed to be. I'd answer: There might be! Attacks only get better with time, and although the cryptographers behind CGO are skilled and well regarded, even the best cryptographers can make mistakes. There _is_ a security proof, but it's fairly recent, and and it hasn't yet gotten intensive scrutiny. With time, as CGO gets attention from more cryptographers, we'll (hopefully) gain more confidence in its strength. (And if we do decide that we need to replace it, the work we've done to add it to Arti and the C Tor implementation will make it much easier to do a later migration to a different system later on.) But what we _are_ pretty sure about is that there aren't likely to be any weaknesses in CGO that would make it _worse_ than tor1. ## Where does our implementation stand? It's underway! We've implemented the cryptography for Arti, the Rust Tor implementation. We've also implemented it in C, since it won't do us any good unless relays support it too, and the Arti relay project is still a work in progress. In order to build this implementation, we've had to refactor a lot of code to revise its existing assumptions: for example, we've had to revise all the places where we assumed anything about the layout of a relay cell, or where we assumed that there was only one way to do relay encryption. These changes will help us with any other changes to relay cell formatting and encryption in the future. Our next steps are: * Enable CGO by default in Arti. (It's currently marked as experimental because of some of its dependencies.) * Implement CGO negotiation for onion services. (This feature is likely to be be Arti-only, due to its complexity.) * Tune the performance for modern CPUs. (The CGO authors got impressively good results for their optimized implementation, but some of the tricks they used will be pretty hard to deliver in the C Tor implementation without big refactoring. Fortunately, there are some low-hanging fruit in optimizing what we have today.) ## Thanks for your help! Thanks to all the cryptographers, programmers, researchers, and cypherpunks who have contributed to this work over the years. Thanks also to all the researchers who have advanced this work, and the state of modern cryptography; we all stand on the work they have built. And thanks to Mike Perry for helping me write this and get the parts of the threat model right. And finally, thanks to everybody who has donated to Tor over the years! A lot of this work is done through a grant from the Bureau of Democracy, Human Rights, and Labor, but many critical parts of this work (including years of past groundwork, and all the parts related to onion services) have been paid for out of our unrestricted funds, which rely on donors like you. Thanks for believing in our mission, and thanks for helping to make Tor better! `<3` * * * 1. Why not just use multiple layers of nested TLS? First, because each layer of TLS adds bandwidth overhead, and that overhead adds up fast. Second, because TLS implementations aren't aiming for anonymity, they tend to do things like generate records of different sizes, making it hard to cause traffic to appear uniform. Third, because the TLS protocol exists in many different flavors that client implementations are often distinguishable from one another: we would need to take special care to keep every client on the same TLS implementation, with locked-down flags and options. That would make upgrading and portability highly difficult.↩ 2. Yeah, the tor1 algorithm uses SHA-1. It was 2002, and OpenSSL didn't have SHA-256 support yet. This isn't as bad as it looks, though: we don't actually need collision resistence here, and the attacker doesn't actually get to _see_ the digest under relevant circumstances, so the regular weaknesses of SHA-1 don't apply in full force. Nonetheless: we will be quite glad to say goodbye to SHA-1 once tor1 is finally replaced.↩ 3. Technically, the client can tag their own traffic, but they wouldn't gain anything by doing so.↩ 4. Remember the RPRP property: encryption resists malleability, but decryption is malleable.↩ * announcements * releases
blog.torproject.org
November 24, 2025 at 10:19 PM
Mexican government partially unblocks secure internet
* * * ### _This is a guest post from our friends atGlobal Voices._ * * * _Across at least the last two six-year presidential terms in Mexico, and through the first year of the current administration, access to the federal government's primary websites for information and public services over the Tor network was blocked._ A study by the authors of this article published October 9, 2023, reports that 21 government agencies blocked access from the Tor network. The blockage was partially lifted in the first days of July 2025. The Tor network is used by millions of users daily to securely access the internet, safeguard their right to information and free speech, and evade censorship or government surveillance. In Mexico, an estimated 20 thousand people use it, according to data published by the Tor Project. In Mexico, Tor has been adopted by civil society organizations and collectives, including the implementation of anonymous mailboxes in journalistic outlets and digital safeguards in human rights advocacies. Under the previous administration, the Mexican government acknowledged the benefits of using Tor for the purposes of combating corruption. It established a mailbox for the Ministry of the Civil Service using Tor. Thus, the government established a regulatory framework which acknowledges the need to guarantee anonymity for whistleblower activities within the civil service. A notice published in the Official Gazette of the Federation stated: > > _Safeguarding confidentiality: [...] is an obligation for all persons assigned to the Bureau[;] the Coordinator General, assisted by the Coordinator, shall supervise, control, and evaluate all activities of the System [to ensure that] they guarantee anonymity of whistleblowers and information, taking the measures they deem necessary, and shall implement actions for improvement in furtherance of such efforts._ The administration of [former] President Enrique Pena Nieto (2012-2018) did not acknowledge the blockage, whereas under Andres Manuel Lopez Obrador (2018-2024) the government acknowledged that it maintained the blockage and explained that it did so for security reasons. > > _(...) protective measures are taken, such as blocking network traffic considered malicious, automated, or potentially threatening, which affects users of the Tor network, since its very nature makes it impossible to distinguish between ordinary and automated users, which is considered a risk to gob.mx, for which reason access over that network is restricted._ Juan Carlos Guerrero Torres, Director of Legal Analysis and Document Management in the president's office, which is responsible for digital strategy and the development of lines and operation of digital infrastructure, replied to Global Voices. Regarding this response, the Tor Project, through its spokesman Pavel Zoneff, informed us that there are workarounds which show that it is possible to achieve a balance between minimizing risks for both users and websites without denying internet access to parties that depend on the Tor network. In his words: > > _"Blocking entire sections of the internet based on the outdated belief that all traffic from the Tor network is indistinguishable or malicious is a mistake and puts people at risk. There are many ways for websites to defend against threats such as DoS attacks, bots, and other malicious actions without isolating a significant part of the global online community." Zoneff_ ## Current administration reverses policy On the other hand, on May 6, the current administration under President Claudia Sheinbaum Pardo declared that it has no policy position or documented justification to block access by Tor users to the website www.gob.mx. As (sic) stated by Gabriela Ignacio Vazquez, Coordinator of Digital Infrastructure and Liaison for Transparency of the National Bureau of Digital Infrastructure in the Digital Transformation Agency, responsible for orienting the relevant policy. On July 5, in the course of routine monitoring for research purposes, we confirmed that the block on www.gob.mx had been lifted. Thus, it is now possible to access the Mexican government's primary information site -and by extension information from the different government agencies concentrated there- from the Tor network. However, we also found that datos.gob.mx maintains the blockage, and the whistleblower mailbox, which previously admitted support for Tor users, was disabled and replaced with the SIDEC platform, which does not permit access from the Tor network. * * * **To learn more about Global Voices' coverage of digital rights, internet freedom, and online privacy issues around the world, visitGlobal Voices.** * circumvention * community * reports * global south * partners
blog.torproject.org
November 18, 2025 at 4:08 PM
New Release: Tails 7.2
## Changes and updates * Update _Tor Browser_ to 15.0.1. _Tor Browser_ 15.0 is based on _Firefox_ 140 and inherits from it several new features that are particularly useful if you use many tabs: * Vertical tabs * Tab groups * New address bar with improved search * Update _Thunderbird_ to 140.4.0. * Update the _Linux_ kernel to 6.12.57. * Remove _Root Console_. To open a root console, you can execute the following command in a _Console_. sudo -i * Show _Don't ask again_ notifications only after the clock has been synchronized. ## Fixed problems * Disable connections that _Thunderbird_ was making to telemetry services run by Mozilla. (#21275) For more details, read our changelog. ## Get Tails 7.2 ### To upgrade your Tails USB stick and keep your Persistent Storage * Automatic upgrades are available from Tails 7.0 or later to 7.2. * If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade. ### To install Tails 7.2 on a new USB stick Follow our installation instructions: * Install from Windows * Install from macOS * Install from Linux * Install from Debian or Ubuntu using the command line and GnuPG The Persistent Storage on the USB stick will be lost if you install instead of upgrading. ### To download only If you don't need installation or upgrade instructions, you can download Tails 7.2 directly: * For USB sticks (USB image) * For DVDs and virtual machines (ISO image) ## Support and feedback For support and feedback, visit the Support section on the Tails website. * tails * releases
blog.torproject.org
November 13, 2025 at 2:06 PM
New Release: Tor Browser 15.0.1
Tor Browser 15.0.1 is now available from the Tor Browser download page and also from our distribution directory. This version includes important security updates to Firefox. ## Send us your feedback If you find a bug or have a suggestion for how we could improve this release, please let us know. ## Full changelog The full changelog since Tor Browser 15.0 is: * All Platforms * Updated NoScript to 13.4 * Bug tor-browser#44319: Rebase Tor Browser onto 140.5.0esr * Bug tor-browser#44325: Backport Security Fixes from Firefox 145 * Bug tor-browser#44333: Add the "No AI" version of DuckDuckGo to available search engines * Bug mullvad-browser#487: Search engines are sorted alphabetically rather than the desired order * Windows + macOS + Linux * Updated Firefox to 140.5.0esr * Bug tor-browser#44310: Default zoom always resets to 100% * Bug tor-browser#44314: Upgrade message not shown in about:tor * Linux * Bug tor-browser#44273: Restore Noto CJK as Jigmo has a too low readability * Bug tor-browser#44315: Font/text issue with self-upgrade window * Android * Updated GeckoView to 140.5.0esr * Bug tor-browser#44303: Extension update job might never work on Android * Build System * All Platforms * Bug tor-browser-build#41618: Restore the expert bundle's version in the final release directory * Windows + Linux + Android * Updated Go to 1.24.10 * Android * Bug tor-browser-build#41617: Pass page size to zipalign * Bug tor-browser-build#41620: Do not rerun zipalign when signing * Bug tor-browser-build#41621: Remove support using older android build tools when signing 14.5 releases in tools/signing/wrappers/sign-apk * applications * releases
blog.torproject.org
November 11, 2025 at 10:06 AM