- anti-censorship-team - lists.torproject.org

Proposal: Rust-pt development
by pryty26 22 Sep '26

22 Sep '26

Proposal: rust-pt - A Rust Framework for Tor Pluggable Transports Dear Tor Project team, anti-censorship-team and other community contributors I have developed recently a new library which is called rust-pt. It is a Rust-based framework for Tor Pluggable Transports. I anticipate everyone knows rust, it's a modern, powerful, fast and safe programming language. And Pt requires performance and safety. That's why, Rust would be an important language for Pt developing. Now I have developed the rust-pt for 3 month, ExtOrPort ConfigParsing, Errors, Macros and Log system is ready. Of course, I'm still actively developing. The code is already published in: https://gitlab.torproject.org/pryty26/rust-pt and https://codeberg.org/pryty26/rust-pt I believe that both community and Tor team, would like to have a Rust-Based Pt library. But currently, there is not a official Pt library for Rust. And most of the community framework, is not well maintained. (ptrs last update is on 2024) I was wondering if anti-censorship team would like to review. If there is any possible, I would like to kindly assign all code ownership to the team. Of course, anyone interested in helping with development is more than welcome. Best regards, pryty26 Sent by pryty26 Sent with [Proton Mail](https://pr.tn/ref/YFS2568X) secure email.

2 3

Inquiry Regarding the Deprecation of Azure CDN (azureedge.net)
by tmsimregph＠gmail.com 19 Sep '26

19 Sep '26

Subject: Inquiry Regarding the Deprecation of Azure CDN (azureedge.net) Dear [Recipient's Name or Anti-Censorship Team], I hope this email finds you well. I came across the discussion regarding the early deprecation of Azure CDN services (azureedge.net) by Edgio/Verizon and its replacement with Azure Front Door (azurefd.net) I understand that this unexpected change poses significant challenges for users and services relying on domain fronting for critical operations. The shutdown highlights the need for reliable alternatives during such transitions. Could you provide further insights or recommendations for mitigating service disruptions, especially for those still using snowflake-broker.azureedge.net or similar configurations? Additionally, any updates regarding the migration process to Azure Front Door would be greatly appreciated. In the meantime, I also recommend visiting my website, https://tmsimreg.ph/, for helpful resources and discussions related to similar transitions. Thank you for your time and efforts in addressing these challenges. I look forward to your guidance. Best regards, Leandro tmsimregph(a)gmail.com

3 2

Strange 1–2-day spikes in Snowflake users in August 2026
by David Fifield 12 Sep '26

12 Sep '26

There's a weird feature in the Snowflake user graphs for August 2026 (attached). On 2026-07-31, there's a 1-day spike in users of the snowflake-02 bridge. It seems to affect all countries (the top 5, anyway) proportionally. From 2026-08-21 to 2026-08-23, there's a spike in users of the snowflake-02 bridge, but it only affects the "??" country. Do you have an idea of what these are about?

2 2

Request for a team PGP key
by Ded Moros 29 Aug '26

29 Aug '26

Dear Tor Project team, I have important proposals for the Anti-Censorship team. In order to send them, I needed to encrypt my message. However, I could not find a public PGP key for this team, so I was forced to encrypt my first message with rgdd's public key. Apparently, it was not decrypted by the recipient, and therefore I kindly ask you to generate and send me your public PGP key as soon as possible, so that I can securely start a correspondence. My public key is attached to this email.

1 0

Data compression on Snowflake rendezvous messages
by David Fifield 06 Aug '26

06 Aug '26

I did some experiments to evaluate the potential of compressing Snowflake rendezvous messages. This is looking forward to a DNS-based rendezvous, where the size of messages is important. I patched snowflake-client and the standalone proxy to record offer/answer rendezvous messages, then measured the sizes of the messages before and after compression. Compressing rendezvous messages straightforwardly with zlib reduces the median size of offers by 50% and of answers by 60%. Adding a preset dictionary containing frequenly occurring strings saves another 20% in offers and 15% in answers. Overall it's possible to reduce the median size of messages by about 75%. Compression also makes the distribution of sizes narrower. type=offer treatment=uncompressed Min. 1st Qu. Median Mean 3rd Qu. Max. 630 882 1181 1251 1458 4533 type=offer treatment=zlib Min. 1st Qu. Median Mean 3rd Qu. Max. 433 527 560 563 599 937 type=offer treatment=zlib+dict Min. 1st Qu. Median Mean 3rd Qu. Max. 232.0 276.0 311.0 316.3 340.0 652.0 type=answer treatment=uncompressed Min. 1st Qu. Median Mean 3rd Qu. Max. 758 1519 1646 1522 1800 1880 type=answer treatment=zlib Min. 1st Qu. Median Mean 3rd Qu. Max. 450.0 594.2 608.5 583.3 617.0 665.0 type=answer treatment=zlib+dict Min. 1st Qu. Median Mean 3rd Qu. Max. 265.0 370.0 381.5 363.4 394.5 416.0 A zlib preset dictionary lets you start compression with a non-empty context window. The compressor and decompressor need to agree on the contents of the dictionary. I made a dictionary of about 700 bytes by inspection of commonly appearing strings in my sample of messages. The byte after "1.0" is a newline character. I don't claim this dictionary is optimal, but its effect is pretty good. 1.0.{"offer":"{\"type\":\"offer\"{"answer":"{\"type\":\"answer\",\"sdp\" :\"v=0\\r\\no=- IN IP4 127.0.0.1\\r\\ns=-\\r\\nt=0 0\\r\\nc=IN IP4 0.0.0 .0m=application 9 UDP/DTLS/SCTP webrtc-datachannela=sendrecva=setup:acti vepassivea=mid:0a=group:BUNDLE 0a=fingerprint:sha-256 a=extmap-allow-mix eda=candidate:3263612507 1694498815 udp 2130706431 typ host tcptype acti ve generation 0 network-id 1 network-cost 10 ufrag typ srflx raddr 0.0.0 .0 :: rport a=ice-ufrag:a=ice-pwd:a=ice-options:tricklea=end-of-candidat esa=sctp-port:5000a=max-message-size:1073741823a=msid-semantic:WMS *\\r\ \n\"}"},"nat":"unknownrestricted","fingerprint":"2B280B23E1107BB62ABFC40 DDCC8824814F80A72"}8838024498816A039FCBBAB14E6F40A0843051FA"} This is the source code, with the patch and analysis programs: https://gitlab.torproject.org/dcf/snowflake-rendezvous-zlib Currently at this commit: https://gitlab.torproject.org/dcf/snowflake-rendezvous-zlib/-/tree/6da5f2b2…

1 1

The format of snowflake-stats descriptors and collector-rs
by David Fifield 08 Jul '26

08 Jul '26

For the past 3 months, collector-rs has been making snowflake-stats tarballs in an incorrect format. The recently committed fix for this problem implies that the incorrect format was the result of the Snowflake broker changing the format of its metrics. But this is not the case: Snowflake broker metrics have always (since 2019) contained multiple days of metrics. This was by design, and Java Collector was always able to parse that format. Since the recent fix, collector-rs treats snowflake-stats as a special case ("skip_seed_for_archive"), but Java Collector didn't treat snowflake-stats as exceptional—it parsed snowflake-stats in the same way as other types that have multiple days of data in one file, like bridgedb-metrics and bridgestrap-stats, using a method called parseOneOrMoreDescriptors. In summary, the problem was with collector-rs not parsing the metrics files in the same way as Java Collector did, not because of any change in the output of the Snowflake broker. snowflake-stats is not really a special case, but the collector-rs code now treats it as a special case, which makes me wonder if it could be handled in a more uniform way. This is the issue for collector-rs serving an incorrect format for snowflake-stats tarballs: "Snowflake stats format is broken for April" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/wor… This is the merge request that closes #48 along with many other things: "Rework archive/publish/sync pipeline; add bridge import; vote & dirauth fixes" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… I understand that the fix has two parts: 1. Changing the collector-rs to ignore all but the last "snowflake-stats-end": https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… 2. Running a one-time fix_snowflake script that rewrites past downloaded files so that they contain only the last "snowflake-stats-end": https://gitlab.torproject.org/juga/collector-fixes/-/commit/7b0aa3170313cb4… I'll quote from fix_snowflake.rs, because I think it reveals the misunderstanding on the collector-rs side: //! `fix-snowflake` - trim bloated snowflake-stats files down to a single //! reporting period, both in `out/recent/snowflakes/` and in the monthly //! `out/archive/snowflakes/snowflake-stats-*.tar.xz` tarballs. //! //! ## Background //! //! The snowflake broker's `/metrics` endpoint is meant to return a single //! `snowflake-stats-end <date> <time> (86400 s)` reporting block per fetch. //! Starting around collector-rs's deployment in 2026, the broker began //! returning the **entire cumulative history** since 2024-09-19 on every //! fetch instead: every previous day's block concatenated, with the new //! day's block appended at the end. Every file collector-rs wrote during //! that window inherited that bloat verbatim - both the daily files in //! `out/recent/snowflakes/` and the entries written into the monthly //! archive tarballs. The format emitted by the broker /metrics endpoint is not "bloat" and it is not "incorrect". Nor did the format change at any point. Here's a Wayback capture that shows it worked like that in 2020: https://web.archive.org/web/20200619131042/https://snowflake-broker.torproj… The format was intentionally designed this way. Here is part of a conversation with Karsten when the metrics feature was originally designed: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/work_i… To answer your earlier question above: having just the last 24 hours of data might be problematic if the metrics host goes down for, say, a weekend. Ideally, there would be at least a week of statistics available. Or maybe just accumulate new statistics forever, given the tiny amount of statistics per day. This is the way it is intended to work and the way it worked before. collector-rs should not treat the format as anomalous or unexpected. The old metrics/library had a test case with 2 descriptors in it, since 2019: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… This is how the old metrics/library handled snowflake-stats descriptors: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… } else if (firstLines.startsWith("@type snowflake-stats 1.") || firstLines.startsWith(Key.SNOWFLAKE_STATS_END.keyword + SP) || firstLines.contains(NL + Key.SNOWFLAKE_STATS_END.keyword + SP)) { return this.parseOneOrMoreDescriptors(rawDescriptorBytes, sourceFile, Key.SNOWFLAKE_STATS_END, SnowflakeStatsImpl.class); } It called parseOneOrMoreDescriptors with "snowflake-stats-end" as a delimiter. Then it iterated over parsed descriptor and handled each one individually: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/blob/0… DescriptorParser descriptorParser = DescriptorSourceFactory.createDescriptorParser(); SortedSet<LocalDateTime> snowflakeStatsEnds = new TreeSet<>(); this.outputPathName = config.getPath(Key.OutputPath).toString(); for (Descriptor descriptor : descriptorParser.parseDescriptors( downloadedBytes, null, null)) { ... The important thing to note is that Snowflake is not at all a special case; the detectTypeAndParseDescriptors method calls parseOneOrMoreDescriptors for many different descriptor types (with different delimiters): https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6…

2 2

Call for Testers: Snowflake Volunteer Android app
by Sérgio Santos 13 Apr '26

13 Apr '26

Me and my partner have built a new way for Android users to run Snowflake proxies and help others access the Tor Network. Android users can already use the Kindness mode inside the Orbot app to turn their phones into Snowflake proxies. But we felt a single-purpose app could help grow the number of volunteers. We invite you to test the new Snowflake Volunteer Android app and provide us feedback. You just need an Android device and be in a region where your Internet access if not heavily censored. STEP 1 - Install the app You can install it from one of these places: - Google Play: https://play.google.com/store/apps/details?id=io.bloco.snowflake - Github: https://github.com/blocoio/snowflake/releases/latest (download APK and install) - Build and run from source: https://github.com/blocoio/snowflake (for those with Android development experience) STEP 2 - Enable it Open the app and enable the proxy through the big "Enable" toggle button in the main screen. You can configure if you only want it to run on Wi-Fi (default), and/or while the device is charging, in the Settings screen. Soon you should start getting connections from people who are trying to access the Tor Network (check the stats in the bottom part of the main screen). STEP 3 - Share feedback Let us know what do you think of the app by replying or sending us an email at hello+snowflake(a)bloco.io We want to know specifically if: - is it clear what the app does and how to use it? - are you able to get connections? - the app is using significant battery while in the background? (there's a battery usage screen inside Android's Settings) - is any feature missing? Thank you! Sérgio Santos

1 0

Engineering collaboration inquiry -- Go/Infrastructure (Remote)
by Gustavo Fring 08 Apr '26

08 Apr '26

Hi anti-censorship team, I was referred here by the Tor Project Community Team regarding potential engineering collaboration. I am an infrastructure engineer based in Russia, working under active network restrictions including DPI, protocol blocking and traffic analysis. My focus is Go microservices, WireGuard forks, transport layer automation and observability under censorship constraints. Recent work includes a probe service that detects seven types of blocking and enables dynamic config updates for Xray based proxy networks. The architecture follows a Client → Relay → Uplink pattern with node specific health checks: Relay performs nine checks including DNS, SNI and TLS fingerprinting, while Uplink focuses on transport with four basic checks. This design delegates detection logic upstream to keep the edge lean. Architecture reference: https://github.com/roberttkach If there is room for collaboration on tooling, testing or infrastructure hardening, I am happy to discuss a small scoped task. Happy to continue privately if preferred. Format: remote, flexible, results driven. Robert Telegram: @roberttkach GitHub: https://github.com/roberttkach

2 1

Create a tor bridge distribution that hides from the tor browser user the bridge but allows use new kind pluggable transport so china cannot request/block bridges.
by Kester Pembroke 10 Feb '26

10 Feb '26

Below is a clean, high‑level system design for a Tor bridge distribution model where the user never sees the bridge, yet can use new pluggable transports (PTs). This stays architectural (not exploit‑level), which is how Tor itself discusses these ideas. ------------------------------ Goal Design a bridge distribution system that: 1. Hides bridge details from the Tor Browser user 2. Supports new / experimental pluggable transports 3. Reduces bridge enumeration by censors 4. Works under heavy DPI and HTTPS‑only regimes 5. Fits Tor’s existing trust and threat model ------------------------------ Core idea: Brokered, capability-based bridge access Instead of giving users bridge addresses, give them temporary access capabilities that let Tor connect without the user ever knowing where. Think: “I have permission to use Tor right now” not “Here is a bridge IP:port” ------------------------------ 1. High-level architecture Tor Browser | | (Capability request) v PT Broker (trusted, rotating) | | (Ephemeral routing info) v Hidden Bridge Network | v Tor Network The user: - Never sees IPs, domains, fingerprints - Just toggles “Censorship Mode” or “Transport X” ------------------------------ 2. Step-by-step flow Step 1: Capability request (not a bridge request) Tor Browser requests: “I support PT-X, need access” This request: - Looks like normal HTTPS - Is indistinguishable from other web API calls - Contains no identifying Tor metadata ------------------------------ Step 2: Broker returns a capability, not a bridge Instead of: bridge 1.2.3.4:443 fingerprint=... The broker returns: Signed capability token: - Valid for N minutes - Bound to PT-X - One-time or rate-limited The user cannot: - Reuse it - Share it - Inspect it meaningfully ------------------------------ Step 3: PT resolves bridges internally The pluggable transport: - Uses the capability to: - Discover a relay internally - Or connect via indirection (proxy mesh, rendezvous, relay lottery) - Bridge details exist only inside the PT process Tor Browser: - Never logs - Never stores - Never displays bridge info ------------------------------ 3. Why this defeats mass bridge enumeration China can: - Request capabilities ✔ - Use them ✔ But they cannot: - Bulk harvest bridge IPs - Build blocklists - Learn topology - Distinguish user vs censor requests reliably Blocking becomes: - Reactive - Noisy - Collateral-heavy ------------------------------ 4. Enabling new pluggable transports This model is PT‑agnostic. A new transport just needs: - Capability verification - Broker interface support Examples of future PTs this enables: A. HTTPS semantic PTs (Webtunnel++) - PT pretends to be: - REST API - WebSocket app - Video streaming backend - Broker rotates semantics, not just IPs ------------------------------ B. Relay lottery PT - Capability unlocks: - One of many hidden bridges - Randomly chosen - Short-lived - Censor can’t predict which bridge they’ll hit next ------------------------------ C. Multi-hop PT - Capability allows: - Entry via CDN → hop → hop → Tor - No single blocking point ------------------------------ 5. Why hiding bridges from users is important Today: - Users copy/paste bridges - Bridges leak via screenshots, logs, malware - Support forums leak them - Censors scrape everything With this design: - No bridge strings exist - Nothing human-readable - Nothing stable to leak This is zero-knowledge bridge usage from the user’s perspective. ------------------------------ 6. Trust and failure model (important) This does not require trusting the broker with identity. Broker knows: - “Someone asked for PT-X access” - Nothing about browsing - Nothing about destination Even if broker is: - Monitored - Partially blocked - Compromised Worst case: - Access degrades - Tor safety remains intact ------------------------------ 7. Why Tor hasn’t fully done this (yet) Real constraints: - Backward compatibility - PT ecosystem maturity - Operational cost - Risk of centralisation - Need for multiple independent brokers But Snowflake is already halfway there: - User doesn’t see proxies - Dynamic routing - Indirection-based access This proposal generalises that model. ------------------------------ 8. One-sentence summary Replace “bridge distribution” with “capability distribution”, and let pluggable transports resolve bridges invisibly and ephemerally. ------------------------------ Next we can: - Map this design onto existing Tor components - Show how Snowflake already approximates it - Design a concrete PT using this model - Explain how this resists China specifically - Discuss centralisation vs censorship trade-off.

3 2

New User
by techforce.adenton1＠gmail.com 24 Dec '25

24 Dec '25

Hello all, I am a new member. I have a passion for anti-censorship, I have the snowflake extension installed as of now, I'm building a spare PC and will setup a Tor bridge or relay. My point in this thread im hoping that I will be welcomed and mentored! I want to be a part of this!

2 2