Lox uses Chase et al.'s keyed-verification algebraic MAC anonymous credentials in a single-issuer/verifier setting with jointly-chosen credential IDs (neither party can unilaterally select them), so a fully compromised Lox Authority cannot link credential showings to specific users or reconstruct the social graph — the LA learns only that a shown credential was authentically issued.

Relying on third-party email providers to verify users was demonstrated by Ling et al. to leave Tor's BridgeDB vulnerable to censors capable of creating multiple accounts, enabling bridge enumeration via sock-puppet attacks at scale. Active and passive detection techniques — including traffic flow analysis, DPI, website fingerprinting, and active probing — have been demonstrated in prior work to reveal Tor bridges, making Tor inaccessible for the majority of users in some regions.

§2.2.1 detection

The Lox check-blockage protocol response size and time grow linearly with the number of blocked bridges — 6 kB / 11 ms at 5% blocked, 63 kB / 64 ms at 50%, and 126 kB / 122.5 ms at 100% — creating a bandwidth bottleneck a strategic and patient censor can exploit by triggering mass bridge blockages during a critical event (election, coup) to deny successful blockage migrations at the moment users most need them.

Figure 1, §5.2 detection

In a Rust implementation evaluated over 10,000 runs with 3,600 bridges (1,800 open-entry single-bridge buckets and 600 hot-spare three-bridge buckets), Lox's trust promotion protocol incurs the highest latency at 364.2 ms response time and 378 kB response size due to the encrypted migration hashtable, but this operation occurs only once per user. All other protocols complete in under 16 ms with request sizes under 3.4 kB.

Table 4, §5.2 evaluation

Lox's trust level scheme (L=0 through L=4, requiring 30, 14, 28, 56, and 84 days respectively per level before upgrading, per Table 2) with blockage inheritance — invited users inherit their inviter's blockage count d — prevents a censor from resetting their reputation through self-invitation after causing blocking events, while users with d ≥ 4 become ineligible to migrate, capping the damage a persistent infiltrator can do.

§4.2.1, §2.4.2, Table 2 defense

The blog author, drawing on evaluation experience, concludes that LetsVPN's failure was not caused by IP exhaustion or ordinary node instability but by precise protocol-signature identification: once the GFW extracts a client handshake feature, it can simultaneously block all connections sharing that signature across hundreds of thousands of users.

2026-anon-letsvpn-vpn §公告里的几句大实话 dpitls-fingerprintactive-probing

CensorLess's function refresher automatically retires serverless bridges and deploys fresh ones in batches across diverse regions; the expected time until a bridge is identified and blocked in practice is 2 days (per Fifield et al.), while Tor bridges in China are discovered within 2–36 days. The old bridge is only removed after all clients have completed live migration to a new URL, maintaining uninterrupted connectivity.

2026-kang-censorless-serverless §4.5 active-probingip-blocking

CensorLess's threat model explicitly relies on a rational-censor assumption: the censor will not block entire cloud-provider IP ranges or domain namespaces because the collateral damage to legitimate business services would be politically and economically unacceptable. AWS Lambda's inherent IP-address ephemerality (new IPs on each invocation, function lifetime up to 15 minutes) means even censors willing to attempt enumeration face a continuously shifting target distributed across the cloud provider's global address space.

2026-kang-censorless-serverless §4.2 ip-blockingasn-blackholingactive-probing

Re-testing in 2025 on a Pixel 10 Pro XL running Android 16 with October 2025 security updates confirmed that blind in/on-path VPN inference attacks remain fully viable despite CVE-2019-9461, CVE-2019-14899, and CVE-2024-49734 having been formally closed. All three core attack primitives—VPN-assigned internal IP discovery, active connection inference, and TCP reset injection via sequence/acknowledgment window scanning—succeeded across OpenVPN, WireGuard, and NordLynx.

2026-tolley-architectural §5.1–5.3 traffic-shaperst-injectionactive-probing

Six widely deployed VPN and circumvention tools—OpenVPN, WireGuard/NordLynx, NordWhisper, Orbot (Tor on Android), Lantern, and Psiphon—all failed to block internal IP inference, connection-state detection, and TCP reset injection under identical adversarial conditions on fully patched Android 16. Application-layer obfuscation in Lantern and Psiphon did not prevent TCP-layer disruption; Orbot's VPN-style encapsulation of Tor traffic was bypassed via the same tunnel-level side channels.

2026-tolley-architectural §5.2, §5.4–5.5 traffic-shaperst-injectionactive-probing

The paper proposes an Internet Freedom vulnerability registry with five design principles: persistent cross-vendor tracking under shared identifiers (e.g., IF-ARCH-2025-001) as long as a risk remains reproducible; human-centered impact ratings anchored to harm potential for journalists and dissidents rather than CVSS-style exploitability scores; timestamped re-verification hooks with linked PCAPs and minimal reproduction scripts; a structured media interface to counter vendor narrative capture; and open public APIs for integration into risk dashboards so that users of tools like Orbot or Lantern can directly query their configuration's exposure to known metadata-based attacks.

2026-tolley-architectural §6.1–6.5 traffic-shaperst-injectionactive-probing