anti-censorship-team

anti-censorship-team@lists.torproject.org

May 2026

1 participants
2 discussions

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 07 Aug '26

07 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