The paper surveys the rendezvous channel design space and identifies at least six prior carrier approaches: domain fronting via CDNs, AMP cache proxying, Amazon SQS queues, push notification services, email tunneling (Mailet, SWEET), and cryptocurrency covert channels (MoneyMorph). Pub/Sub adds bidirectional real-time messaging with broad IoT/enterprise adoption as a new carrier class not previously evaluated for circumvention rendezvous.

Separating the Broker role (a server that holds and manages bridge information) from both the rendezvous channel and the censorship evasion system enables modular protocol design: the rendezvous carrier can be swapped independently of the proxy system. The authors identify broker authentication and multi-broker load distribution as open problems not addressed in the current prototype.

§3.1, §5 defense

Google Cloud Pub/Sub is blocked entirely in China, limiting the system's applicability in the highest-censorship environment. Azure Pub/Sub is a structurally weaker candidate for rendezvous channels because each created resource receives a unique per-resource domain, enabling censors to block it with minimal collateral damage compared to blocking a shared Google or AWS endpoint.

§4.1 deployment

Using Google Pub/Sub as a rendezvous channel adds 7.17 seconds of bootstrapping overhead vs. a 1.32-second direct baseline when establishing a TorKameleon WebRTC bridge connection (total: 8.49s vs. 1.32s). The dominant bottleneck is subscription creation time (5.23s), not the message exchange itself (3.26s), averaged across 10 samples with 113 ms cross-Atlantic latency.

§4.2, Table 1 evaluation

The system uses a shared Pub/Sub topic for all users, where session IDs (SIDs) are visible to all subscribers on the broker topic. The paper argues this does not compromise user anonymity because SIDs are randomly generated per-session by client-side software with no link to user identity, and all subsequent bridge-info payloads are encrypted under a session-specific symmetric key exchanged via asymmetric encryption.

§3.2 defense

Article 19 documents that Iran's National Information Network (NIN / SHOMA) was designed with explicit reference to China's Great Firewall as a model, with institutional mirroring: Iran's Supreme Council of Cyberspace parallels China's Cyberspace Administration of China, and both governments share a "cyber sovereignty" doctrine used to justify domestic content controls and cross-border technology transfer. The report frames Iran's filtering infrastructure as deliberately architected to replicate GFW capabilities, not as an independently developed system.

2026-article19-tightening-the-net §2, §3 dpisni-blockingdns-poisoningip-blockingbgp-hijackthrottling

DNS censorship of encrypted protocols is inconsistent in both China and Iran. In China, Yandex resolvers are censored only when the SNI extension is present; omitting SNI bypasses censorship for these resolvers. In Iran, DoH requires SNI omission for Quad9, Google, Adguard, CleanBrowsing, and NextDNS resolvers, but works with SNI for Yandex and Cisco resolvers. These inconsistencies suggest resolvers have been accidentally missed by censors, highlighting the value of automated tools that trial all resolver-mode combinations rather than hard-coding a single strategy. The support evaluation found 47 resolvers supporting DoH, 16 supporting DoH3, and only 8 supporting DoQ out of ~65 tested.

2026-lange-towards §6.2, Table 2 dns-poisoningsni-blockingip-blocking

DPYProxy-DNS tested 8 circumvention modes against DNS censorship from vantage points in Iran (AS201295, Mashhad) and China (AS4837, China Unicom). In Iran, DoQ was entirely uncensored even with the SNI extension present; DoH3 worked for all Cloudflare and NextDNS resolvers. Iran's censor operates in-path (not on-path like the GFW), making the "Last Response" mode (wait 3s for the last UDP reply) ineffective in Iran but highly effective in China. Auto-mode averaged 12.32s (median 8.28s) in Iran and 13.78s (median 12.90s) in China to discover a working combination.

2026-lange-towards §6.2, §6.3 dns-poisoningsni-blockingip-blocking

DPYProxy-DNS's automated probe-and-select mode identified a working DNS circumvention in an average of 13.78 seconds (median 12.90s) in China and 12.32 seconds (median 8.28s) in Iran across 100 runs each; best-case startup was 0.32s (China) and 0.47s (Iran) when the first-tried combination succeeded, while worst-case exceeded 30.72s in China and 58.16s in Iran due to the slow Last Response mode (3s fixed wait per attempt) being selected early in the randomized probe order.

2026-niere-dpyproxy-dns §6.3 dns-poisoningsni-blockingip-blocking

The GNL reveals that Geedge actively maintains dedicated VPN-infrastructure tracking datasets. The China-specific component includes 7,016 domains in a "vpn-finder-plugins" repository (mesalab_git/intelligence-learning-engine), 4,810 NordVPN server domains, and a Pakistan-specific file listing 68 Psiphon CDN domains (geedge_docs/TSGEN/.../Psiphon-CDN_20240430.json) dated April 2024. A Myanmar deployment file (M22-VPN List.html, 27 domains) further confirms country-specific VPN blocklists are operationally maintained. The "Appsketch" program reverse-engineers VPN apps to extract domains and IP addresses for blocking.

2026-sheffey-geedge §4.2, Table 3 dpisni-blockingip-blocking

Pakistan's PECA (Prevention of Electronic Crimes Act) and PTA (Pakistan Telecommunication Authority) regulations grant authority to block content without court orders, enabling the deployment of a persistent national filtering infrastructure. The report documents 11,000+ URLs blocked by PTA and confirms that VPN use and circumvention tools are among the targeted categories, with blocking orders issued under national security grounds.

2025-amnesty-pakistan-shadows §2, §4 ip-blockingsni-blockingdns-poisoning