Skip to content

Perspective

Financial Companies as Censors: A Sinophone Asia-Pacific Reading of EFF's Transaction Denied

A piggy bank with its mouth taped shut, representing payment rails severed by financial intermediaries
Image from EFF Deeplinks article Former EFF Activism Director's New Book, Transaction Denied, Explores What Happens When Financial Companies Act like Censors (EFF Financial Censorship banner library), licensed under CC BY 4.0.

On 9 May 2017, the cross-border electronic payment service PayPal closed all domestic transaction functions in Taiwan. Two PayPal Taiwan accounts could no longer send money to each other. Cross-border transfers kept working. The streamer economy took the worst hit. Twitch Cheer, YouTube Super Chat, StreamLabs, and NightDev — tools that processed local audience tips through PayPal — went dark on the same day. Small organizations and independent media that relied on PayPal for domestic flows lost a payment rail overnight8.

The legal trigger was Article 3, Paragraph 1 of Taiwan's Electronic Payment Institution Management Act, passed in 2015. PayPal chose not to apply for a license and closed domestic functions instead9. Nearly nine years later, the U.S. online payment processor Stripe still does not allow individuals or companies in Taiwan to register. Stripe is the credit card collection layer behind Substack, many subscription SaaS products, and many open source sponsorship pages. Individual creators in Taiwan have to first register a U.S. LLC to use it10.

In Taiwan's payment conversation, these two facts have usually been filed under "compliance trade-offs" or "market size." EFF's former Activism Director Rainey Reitman, in her April 2026 book Transaction Denied12, compiles cases from 2012 onward across the U.S. and the Middle East. Stacked together, the cases reveal a cross-region, cross-issue pattern that's been running for more than a decade. Taiwan's two events belong in that record. So do parallel events from Hong Kong, mainland China, Macau, Singapore, and Malaysia, which Reitman's book — focused on U.S. and Middle Eastern material — does not yet cover.

A Server That Forgets: why this relay design deserves attention

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?

Why this is worth translating

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 Server That Forgets

What "stateless relay" changes in practice

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.

Three deployment paths, three trade-offs

The post compares three practical models:

  • minimal RAM-disk setups (simple, manual key operations);
  • VM-based RAM images (easier rollback and image lifecycle);
  • bare metal with TPM + verified boot (stronger trust chain, heavier operations).

No single model wins everywhere. The right choice depends on threat model, budget, hosting constraints, and team maturity.