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

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

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