Tor Browser Hardening — Beyond the Security Slider

The Tor Browser security slider has long been marketed — and intuitively understood — as a convenience feature. Flip a switch, get more protection. Flip it back, resume normal browsing. It sits there in the shield icon menu, labeled with reassuringly simple choices: Standard, Safer, Safest. The implication is that your security posture changes the moment you click. As it turns out, that implication has been quietly incorrect for a while, and the flaw is significant enough that anyone relying on the slider for operational security needs to understand exactly what is — and isn’t — happening under the hood.

In May 2025, Privacy Guides published a detailed analysis of a flaw in the security level system affecting both Tor Browser and Mullvad Browser (which shares a significant portion of its codebase). The core finding is stark: not all protections advertised by the slider are actually engaged until the browser is fully restarted. This isn’t a minor UI quirk; it’s a false sense of security that can expose users to browser exploits precisely at the moment they believe they are most protected.

The JIT Problem: A Practical Demonstration

The most concrete proof of the flaw comes from a simple JavaScript benchmark test. Just-in-Time (JIT) compilation is a performance feature in modern browsers that is also linked to a disproportionate number of security vulnerabilities. The “Safer” security level is designed to disable JIT entirely, cutting off an entire class of potential exploits. The assumption is that the moment you switch to Safer, your browsing session is running without JIT.

The reality, confirmed on Tor Browser 14.5.1 (and Mullvad Browser 14.5.1) on macOS, is that switching from Standard to Safer mid-session produces virtually no performance impact when running a JavaScript benchmark like JetStream 2.2. JIT is still active. Websites can still access the technology, and the vulnerabilities that come with it remain exposed. Only after completely restarting the browser does the benchmark show the dramatic performance drop expected when JIT is properly disabled.

There is no visible indicator in the UI that anything is different. No warning icon. No prompt to restart. The slider moves, the browser looks the same, and the user is left with a completely false sense of what “Safer” mode is doing for them in that moment. The Tor Project’s own documentation does not note that a restart is required, nor does the browser prompt the user to do so — an oversight that Privacy Guides confirmed after finding no open GitLab issues or documentation mentioning the extra step prior to their report.

Beyond Safer: The Restart Problem Persists

The JIT demonstration is the easiest way to prove the flaw exists, but it is likely just the tip of the iceberg. Privacy Guides explicitly noted that they only tested JIT because it was the simplest feature to verify. They did not — and could not — confirm the full extent of security features that require a browser restart. “Safest” mode disables JavaScript entirely, so the JIT benchmark won’t demonstrate the issue there, but it is entirely plausible that other protections advertised by Safest mode also remain inactive until a restart.

The recommendation from Privacy Guides, which aligns with the community consensus that emerged after the report, is unambiguous: always completely restart the browser after changing the security level, regardless of whether you are moving to Safer or Safest. This applies even if a user switches up and then back down in a single session — the state of certain preferences at the time a page loads determines what protections are applied, and a restart is the only way to guarantee the new state is fully in effect.

Why Some Settings Require a Restart — and Why It’s a Fingerprinting Risk

According to discussions on the Privacy Guides forum following the published report, the issue is more nuanced than a simple bug. Some preferences governed by the slider require a restart to take effect, while others apply immediately. This creates a Frankenstein state where, depending on when you opened the browser and what toggles you’ve flipped, you are running a mix of old and new protections.

This is not just a security effectiveness problem; it is also a fingerprinting problem. As one forum participant noted, “Some prefs that require a restart and some slider prefs that don’t are fingerprintable.” The slider is designed to create uniformity — all users on “Safer” should present the same configuration to websites. But if some users have restarted after changing the slider and others haven’t, the actual browser state differs, creating entropy that wasn’t designed for. An observer could potentially distinguish between a user who just flipped the slider and one who flipped it and restarted.

Worst-Case Scenario: Tails Users

The community discussion surrounding the flaw flagged one group as being at particularly high risk: Tails users. Tails is a live operating system designed for anonymity, and users there are likely to be adjusting the security slider on every boot — often to “Safest” for high-stakes activities. But they are also, by the nature of a live OS workflow, the least likely to restart the browser after making that adjustment. The issue tracking this flaw was, notably, kept private for a period before being made public, meaning awareness of the problem was delayed even among the most security-conscious user base.

If you are on Tails and you set the slider to “Safest” at the start of a session, you are not actually getting the protections you think you are until you fully quit and relaunch the browser. In a threat model where the browser is the primary tool for anonymity, this is a potentially catastrophic gap in defense.

The NoScript Angle: Customization Is a Trap

For power users, there’s a related temptation: manually adjusting NoScript settings. The advice from the Tor Project community on this is consistent and clear — don’t do it. Changing NoScript’s per-site settings makes a user unique among the broader Tor Browser population. The security slider is designed to offer tiers of protection while keeping all users within a tier identical. Manually enabling specific scripts on specific sites creates a “weirdly configured Safest Tor browser” fingerprint that is trivially distinguishable from the standard configuration.

Furthermore, manual NoScript configuration persists even after you change security levels. The forum discussion highlights a scenario where a user temporarily enables scripts on a site while on “Safest” and then moves back to “Safer” — that manual config follows them, consistently differentiating their browser from others. The overarching behavioral recommendation from the Tor community is to run distinct sessions for distinct activities: restart the browser before changing tasks or security levels, rather than trying to do everything in one continuously modified session.

What Tor Project Says — and What’s Coming

In response to the Privacy Guides report (which was published on May 2, 2025), the Tor Project acknowledged the issue within hours. Their official statement confirmed that the problem is “being tracked and actively addressed” via a GitLab issue (tpo/applications/tor-browser/-/issues/42572). The acknowledgment goes further, stating that they are “exploring broader improvements to the security level system.”

The most meaningful of these improvements is an exploration of aligning the slider more closely with Tor Browser’s updated threat model. There is also talk of possibly delegating more of the back-end logic to NoScript for added flexibility. The key practical change being considered, however, is a restart prompt that would nudge users to fully relaunch the browser after changing settings — or, even more aggressively, forcing an automatic restart.

As with many Tor Project priorities, the proposed improvements may land in the upcoming 15.0 release cycle. That timeline means the flaw is not going away immediately, and users running current stable releases (14.5.x) need to operate under the assumption that the slider is a “recommendation for your next session” rather than an immediate-state change.

Operational Guidance for the Here and Now

Until the 15.0 cycle delivers a proper fix or a restart prompt, here’s what the flaw means in practice for anyone using Tor Browser, Mullvad Browser, or Tails:

• Treat the slider as a setting for your next session, not your current one. If you plan to switch to Safer or Safest before visiting a sensitive site, change the setting and then fully quit and relaunch the browser. Don’t flip it and continue browsing in the same window.
• Do not assume Safest mode fully disables all attack surface immediately. JavaScript is broadly handled, but other features may remain partially active until restart. The safest assumption is that the majority of protections are only fully live after a cold start.
• If you are a Tails user, incorporate the restart into your boot sequence. Launch the browser, adjust the slider first, restart the browser, then begin your actual session. It adds time, but it’s the only way to guarantee the settings are real.
• Avoid manual NoScript adjustments. The fingerprinting risk of a customized configuration far outweighs the convenience of getting that one script-heavy site to work. If a site doesn’t work at your security level, that’s the site’s problem, not yours.
• Keep an eye on the GitLab issue tracker. The Tor Project has committed to addressing this, and the 15.0 cycle is where meaningful changes are expected to land. Until you see a note about a restart prompt in the release notes, assume the flaw persists.

The security slider was never meant to be a silver bullet — no single UI control is. But it was meant to be a reliable control, and for a meaningful period of time, it simply wasn’t. The Tor Project’s rapid acknowledgment of the issue is a positive sign, but the fix is still pending. In the interim, the burden falls on the user to know that the slider is not a light switch; it’s a dial that takes effect slowly, and only after a full restart. The browser won’t tell you that. Now you know.

Research note: This information is provided for educational and research purposes only. Always consult the official Tor Project documentation and threat model for the most current guidance on browser configuration and operational security practices.