Tor’s Trust Problem: Browser 14.5, a Broken Security Slider, and a $53 Kill Switch

For over a decade, Tor has been the default answer to “how do I browse without being tracked,” especially for journalists, dissidents, and researchers working under hostile surveillance. Routing traffic through several encrypted relays, so no single point knows both who you are and where you’re going, has held up against a lot of state-level tracking attempts.

Lately, though, a string of architecture changes, some unpatched infrastructure problems, and murky decision-making from the Tor Project have left a lot of people in the security community uneasy. The most visible flashpoint is Tor Browser 14.5, which removed a privacy protection that had been part of the browser’s threat model for years, defended in ways that don’t match the project’s own commit history. On top of that sit two infrastructure problems that predate 14.5 by years: a security slider that doesn’t do what its UI claims until you restart the browser, and a directory consensus protocol that a $53-a-month DDoS attack can apparently take down. This piece works through all three, plus the BGP hijacking research that complicates Tor’s guard relay selection, and what a high-threat user should actually do about it.

The end of OS spoofing in Tor Browser 14.5

To understand why removing OS spoofing matters, start with browser fingerprinting. Trackers identify and follow users across the web not just with cookies but by collecting details like browser version, installed fonts, screen resolution, and operating system, then combining them into a profile that’s often unique to one person. The EFF’s Panopticlick project showed years ago that most browsers end up with a fingerprint unique enough to track.

Tor Browser’s core defense is uniformity: force every user’s browser to report the same characteristics, so individual users disappear into a large, indistinguishable crowd. One pillar of that uniformity was OS spoofing in the HTTP User-Agent header. Whether you were running macOS, Linux, Qubes, or OpenBSD, Tor Browser told the server you were on Windows.

In October 2024, with Tor Browser 14.0, and again in April 2025 with 14.5, the developers removed this. Their stated reason was entropy: if HTTP headers claim Windows but JavaScript APIs reveal the real Linux or macOS environment, that mismatch itself becomes a fingerprinting vector. Removing HTTP spoofing “harmonizes” the two, so JavaScript and HTTP headers report the same OS family (Windows, macOS, Linux, or Android) instead of contradicting each other.

HTTP headers versus JavaScript, and who actually relies on which

That justification assumes JavaScript is running. Anyone operating under a serious threat model, a dissident avoiding a state intelligence service, someone visiting a darknet market, disables JavaScript, which is exactly what the “Safest” security level does: it neuters JavaScript to stop canvas fingerprinting, hardware enumeration, and JIT exploits.

With JavaScript off, the server can’t query navigator or run a fingerprinting script. The only thing left that can reveal the operating system is the HTTP User-Agent header. OS spoofing used to close that gap entirely; a Linux user with JavaScript disabled looked identical to a Windows user with JavaScript disabled. Take the header spoofing away, and server logs on a seized hidden service or a compromised clearnet site now record the user’s real OS in plaintext.

Being an outlier is the actual danger

Developers have argued the entropy cost is negligible, since Windows users make up something like 60 to 80 percent of the Tor user base and the rest are a rounding error. But anonymity networks don’t punish you for being in the majority. They punish you for standing out. If an adversary is hunting someone known to run Qubes, OpenBSD, or a custom Linux build, removing OS spoofing is a flare specifically for that person. Windows users stay hidden in the crowd; the tiny fraction running hardened operating systems get isolated instantly. Optimizing for the median user penalizes exactly the people who rely on Tor the most.

The removal also happened without much room for user choice. Contributors suggested keeping spoofing as an opt-in, or limiting it to “Safest” mode. Developers rejected both, on the grounds that letting users toggle it in about:config would itself add entropy and ran counter to the project’s mission.

The May 29 newsletter and a semantic dodge

The technical regression came with a communication problem attached. On May 29, the Tor Project published a newsletter responding to the backlash: “OS spoofing has never gone away and is here to stay.”

Security researchers and network engineers called this a deliberate redefinition. The newsletter’s “OS spoofing” meant version spoofing: Tor Browser still hides whether you’re on Windows 10 or 11, or which macOS build you’re running. It no longer hides the OS family in HTTP headers. Version masking and OS family masking aren’t the same thing. Version masking blocks patch-level tracking; family masking blocks the adversary from narrowing the target pool to Linux users in the first place, and losing it undoes exactly that. The newsletter’s claim that the feature “never went away” contradicts the commit logs and developer comments in Tor’s own GitLab repository, where the removal was discussed in terms like “ripping out the machinery.”

When a privacy project’s official communications contradict its own source code, that’s a real problem for trust. If the maintainers will use semantic misdirection to describe a documented removal, it’s fair to wonder what else has been quietly buried in an alpha release note.

The security slider: hardened in the UI, not in the browser

Tor Browser’s Security Slider toggles between Standard, Safer, and Safest, and it’s the main way users reduce the browser’s attack surface by disabling risky JavaScript features, blocking certain media types, and hardening memory management. The most important thing Safer and Safest do is disable JIT compilation and the IonMonkey optimizer. JIT makes JavaScript run faster by compiling it to native code at runtime, but JIT compilers are complex and have historically been the main source of memory corruption bugs and sandbox escapes. Turning JIT off trades speed for a slower, heavily audited interpreter.

An 11-month gap between the UI and the actual browser

Here’s the problem: when you move the slider mid-session, the interface updates immediately, but the underlying engine doesn’t actually disable JIT or change the JavaScript execution environment until you restart the browser. So a user who hits a suspicious site, panics, and slides to “Safest” is still running the JIT compiler they were trying to turn off. The browser tells you it’s protected before it actually is. This has sat in the Tor Project’s issue tracker for over 11 months. In a high-threat environment, a sandbox escape here could mean spyware deployment or an unmasked IP address, and the developers haven’t fixed it.

Removing the slider instead of fixing it

Rather than force a restart when the slider moves, or just show a “restart required” warning, developers have floated removing the slider altogether and replacing it with a single default “Safer” setting, with “Safest” (full NoScript) buried in about:config. It’s the same logic used to justify pulling OS spoofing: treat the complexity of the feature as the problem, not the bug that undermines it. Burying the highest security tier where most users will never find it means most users operate with a bigger attack surface than they need to, a strange trade for a tool built to protect people against serious threats.

BGP hijacking and the RAPTOR attack

The browser controversies get the attention, but there’s a bigger problem sitting at the network layer. Tor’s security assumes the internet’s routing infrastructure is reasonably trustworthy. It isn’t, really: BGP, the protocol that governs how traffic gets routed across the internet, was designed in the 1980s with essentially no cryptographic authentication.

BGP is how Autonomous Systems, ISPs and large hosting providers, announce which IP ranges they control and how to reach them. Because BGP runs on implicit trust, any AS can announce ownership of IP prefixes it doesn’t actually control, and if neighboring networks accept the announcement, traffic gets redirected to the attacker. That’s a BGP hijack.

Where Tor’s guard relay selection falls short

Princeton researchers built RAPTOR (Routing Attacks on Privacy in Tor) to show that BGP hijacking can deanonymize Tor users at scale. When a user connects, they build a circuit starting at a Guard Relay. An adversary controlling an AS between the user and that guard can hijack BGP to intercept traffic before it enters the Tor tunnel, quietly copying it and forwarding it on so the user notices nothing. Combine that with control over exit nodes, and a state-level adversary can run traffic correlation attacks that tie a real IP address to a hidden destination.

Tor’s relay selection weighs bandwidth and uptime, which pushes the network toward large hosting providers like OVH, Hetzner, and AWS. Those providers often sit in vulnerable spots in the internet’s routing hierarchy, dependent on a small number of Tier-1 upstream providers, and the Princeton researchers found that a meaningful share of Tor relays on these networks score poorly on BGP hijack resilience.

Counter-RAPTOR exists and isn’t deployed

The same researchers built Counter-RAPTOR, a guard selection algorithm that factors in a relay’s BGP resilience (an alpha parameter) alongside its bandwidth, steering users toward more resilient routing paths. The code is public. The threat has played out in real incidents, including the 2014 Indosat hijack and the 2023 AWS routing anomalies. Tor still hasn’t integrated it into the mainline client, and bandwidth continues to outweigh routing security in relay selection. RPKI, the cryptographic framework that would let network operators sign their routing announcements and close this hole at the internet level, sits under 40 percent global adoption. Until that changes, Tor’s bandwidth-first relay selection leaves users exposed to state-sponsored routing attacks.

The $53 kill switch

Purdue researchers recently found a single point of failure in Tor’s directory protocol that’s arguably worse than anything above. Tor relies on nine volunteer-run Directory Authorities that vote on which relays are active and trustworthy, sign a consensus document, and distribute it to clients. It’s bandwidth-efficient, and it’s a bottleneck.

A voting protocol that assumes good conditions

The directory protocol runs on a synchronous timing model: four voting rounds, each with a 150-second timeout, assuming all nine authorities have the bandwidth and stability to exchange votes in that window. Purdue’s researchers showed that assumption breaks under adversarial conditions. Flood just five of the nine authorities with a DDoS attack, saturate their bandwidth, and they can’t exchange votes in time. Since consensus requires a strict majority, five failed nodes means no consensus document gets produced. Tor clients reject consensus documents older than three hours, so a sustained DDoS of a few hours degrades the whole network: new users can’t connect, and existing circuits fail to rebuild.

What it costs to pull off

The number that makes this alarming is the cost. Dropping a directory authority’s usable bandwidth below the 10 Mbps threshold needed for voting takes a sustained flood of around 240 Mbps. Using a commercial DDoS-for-hire service, that costs roughly $0.07 an hour against five servers, or about $53 a month to keep the Tor network permanently crippled. For less than a dinner out, someone can take down the most widely used anonymity network in the world.

Purdue proposed a fix based on partial synchrony, a model that separates bandwidth-heavy document transmission from the consensus agreement itself, letting the authorities reach consensus even under heavy packet loss. It hasn’t shipped in the legacy C codebase, and Arti, the ongoing Rust rewrite, doesn’t yet have a full Directory Authority implementation. The network’s most critical bottleneck remains unaddressed.

Governance and the Privacy Guides dispute

The technical issues connect to a broader governance problem. The Tor Project is a well-funded nonprofit that draws on government, human rights, and private grant money, and its handling of criticism increasingly resembles a closed-source vendor’s: feedback gets dismissed, and pushback gets stonewalled.

That played out visibly with Privacy Guides, a nonprofit that curates privacy software recommendations. After the backlash over OS spoofing, Privacy Guides defended the Tor Project’s decision, echoing the entropy argument and adding that HTTPS mitigates passive fingerprinting risk, which misses the point that HTTPS protects data in transit but does nothing to stop a destination server, including a compromised hidden service, from logging the plaintext User-Agent header on arrival.

GrapheneOS developers publicly called Privacy Guides’ position “thoroughly dishonest” and accused it of running PR cover for the Tor Project. It’s a useful data point about the privacy advocacy space generally: large donor-funded groups sometimes prioritize institutional alliances over the technical merits, which shields established projects from the accountability they’d otherwise face. Questions raised in GitLab issues and public forums about the $53 DDoS attack or the broken security slider have mostly gone unanswered, even as the project continues fundraising campaigns that project confidence the technical record doesn’t fully support.

What high-threat users should change

None of this makes Tor useless, but it means the default install isn’t enough against a targeted or state-level adversary, and a few adjustments now matter more than they used to.

Run it inside an amnesic or isolated OS instead of your normal machine. Since HTTP header OS spoofing is gone, running Tor Browser on a daily-driver Linux, macOS, or Qubes install flags you as an outlier in server logs. Tails boots from RAM and routes everything through Tor by default, and because it’s a standardized environment its headers blend into the crowd; it also leaves no forensic trace on the host if compromised. Whonix goes further with a two-VM setup, a Gateway that handles Tor routing and a Workstation for browsing, so even a browser zero-day with full remote code execution stays trapped in an isolated network segment and can’t easily find the host’s real IP or hardware.

Consider Tor over VPN. Tor’s official guidance has leaned against chaining a VPN with Tor, but given the BGP hijacking and guard relay risks above, connecting through a trusted no-logs VPN before launching Tor Browser masks your real ISP and home IP from the guard relay. If an adversary hijacks BGP locally or compromises the guard node, they unmask the VPN server instead of you, which buys a layer of deniability.

And harden the browser manually. NoScript and uBlock Origin in hard mode still help block third-party tracking, and the security slider should be treated as cosmetic until you restart the browser: it isn’t actually doing anything before that.

Where this leaves Tor

Tor remains one of the more important tools for resisting surveillance and censorship, which is exactly why its recent decisions are worth taking seriously. Removing OS spoofing, leaving the security slider’s restart bug unpatched for nearly a year, and sidelining Counter-RAPTOR and the partial synchrony fix all point the same direction: user agency and infrastructure resilience losing out to UI simplification. Combined with a newsletter that doesn’t match the commit history, the project has some real transparency work to do.

Anonymity isn’t something you set up once. It’s an ongoing fight against people actively trying to break it, and when the people building the defenses start treating user choice as a liability, the whole ecosystem is worse off for it. Until Tor patches the directory consensus protocol, restores opt-in spoofing, and starts being straight about what changed and why, high-risk users are better off assuming the defaults aren’t enough and building in isolation and obfuscation on their own.