In June 2025, Cure53 completed a penetration test and source code review of TorVPN for Android and its underlying Rust networking layer, Onionmasq. The Tor Project published the results in April 2026. The headline finding: Tor's core tunnel establishment and routing logic held up well. But there are specific technical issues worth understanding if you're recommending or deploying this tool in Taiwan's context.
The Tor Project post, A Server That Forgets: Exploring Stateless Relays, is grounded in real operator experience from Osservatorio Nessuno in Italy. It is not just a technical tour. It asks a basic trust question: if a relay can be seized, searched, or physically cloned, what exactly can an adversary still learn?
First, the article starts from actual seizure and raid precedents. That makes the threat model concrete. Relay operators are not debating abstract malware only; many are planning for legal process and physical hardware exposure.
Second, it gives a rare end-to-end map of the stack: TPM, measured boot, remote attestation, RAM-only runtime, VM images, and tooling paths such as Patela and stboot. Most discussions in our region cover one layer at a time. This one connects them.
Third, it keeps the hard parts visible. Re-sealing after updates, conflicts between stateless images and unattended upgrades, memory ceilings without swap, and the risk of losing a Stable flag due to restarts are all left as open engineering work, not hidden in marketing language.
A stateless system reboots into a known image and does not keep writable disk state. In security terms, this shifts defaults:
physical seizure yields less forensic material;
configuration drift is constrained by declarative rebuilds;
persistence across reboots becomes harder for attackers;
reproducibility and auditability become more realistic goals.
For Tor relays, there is one unavoidable tension: identity must survive reboots. Relays build reputation over time through long-term keys. If keys disappear on every boot, the node loses its standing and utility.
That is where TPM-backed key handling matters. Keys can be bound to measured boot state and used without handing raw private key material to the operating system. Remote attestation can then let an external verifier check what software stack actually booted. But the limitations are real too, including key-type mismatches and operational complexity.
Arti is Tor’s next-generation Rust implementation. The 2.2.0 release is notable because it pushes a previously experimental access path into day-to-day usability: HTTP CONNECT is now included in full builds and enabled by default, sharing the same port as SOCKS.
For teams operating in filtered enterprise, campus, or public networks, that matters immediately. For developers embedding Arti, this release also expands RPC ergonomics with non-blocking requests, event-loop integration, and a new superuser administration path. In one version, Arti improves both network practicality and operational controllability.
We follow Tails releases because they ship the same building blocks many of us recommend in real life: Tor, a hardened desktop, and tools for people who cannot assume a “normal” network path. 7.6, dated 2026-03-26, is worth translating not for one killer feature, but for two changes that affect how people get online and how they store secrets on a live system.
Tor bridges are not exotic; they are often the difference between “Tor works” and “Tor never connects.” In places where Tor traffic is filtered or throttled, users learn to hunt for bridges through side channels—paste sites, trusted contacts, or ad‑hoc instructions. Tails 7.6 brings that guidance into the Tor Connection assistant: pick Connect to Tor automatically, and if the network blocks Tor outright, the bridge screen can Ask for a Tor bridge based on your region, pulling candidates via the Tor Project’s Moat service—the same family of tech Tor Browser has used since 11.5—with the fetch disguised using domain fronting.
For readers in Taiwan and across East/Southeast Asia: censorship models differ, but the pattern is familiar—TLS interception, routing games, or “soft” blocking that fails open only for some apps. A Tails image that surfaces bridge acquisition in-product lowers the bar for journalists, lawyers, and civil‑society volunteers who already juggle operational risk; they should not also have to memorize bridge workflows from blog posts.
The second headline is Secrets replacing KeePassXC. That is a product decision, not a security downgrade by default: Secrets is tighter with GNOME, which matters on Tails because accessibility regressions (on‑screen keyboard, cursor sizing) are real blockers for some users. KeePassXC power users can still add it via Additional Software; the database format overlaps, so migration is meant to be frictionless.
In February 2026, anarcat from the Tor system administration team (TPA) published a post titled \"Keeping track of decisions using the ADR model\".
After reading it, we felt it offered a very practical way to think about proposals, decision-making, and how to write things down so that people can actually find and understand them later.
This post is not a translation of the original article. Instead, it is our own summary and reflection on:
what problem TPA was trying to solve with ADRs,
what they actually changed in their process,
how other projects handle proposals and decisions, and
how this connects to the context we are familiar with.
In mid-September, you may have noticed something significant: approximately 500GB of data was made public. This data pertains to China's Great Firewall (GFW) technology and how this system is exported and implemented in other authoritarian regimes.
InterSecLab, a digital security-focused laboratory, became aware of this leaked data around December 2024 and promptly took action. Over the course of 10 months, they collaborated with several organizations and tech communities to verify and analyze the leaked data. The findings were published in a report released on September 12, 2025.
Although we (Anonymous Network Community) did not assist in the initial stages, after the report was released, we quickly reviewed its content. The report confirmed many of the long-suspected capabilities of the Great Firewall. Furthermore, the report provided a clearer picture of the teams and organizations operating behind the scenes. Their development environment is similar to that of modern startup teams, with operations and maintenance for international deployments being remotely executable. In other words, the Chinese Communist Party government and other client countries can activate customized or general rules with a single click!
