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

Fwd: Scheduled Client Panel & API Maintenance on December 3, 2024
by meskio 02 Oct '25

02 Oct '25

I got this email forwarded to me. It looks like there will be downtime in the Client Pannel of CDN77 what we use for domain fronting. > ---------- Forwarded message --------- > From: CDN77 <news(a)cdn77.com> > Date: Tue, Nov 26, 2024 at 9:35 AM > Subject: Scheduled Client Panel & API Maintenance on December 3, 2024 > To: accounting(a)torproject.org <accounting(a)torproject.org> > > > Due to schedule upgrades and maintenance, the CDN77 Client Panel and API > will be temporarily unavailable. > View in browser > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > Docs & API > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > Client > Panel > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > > Dear Client, > > Due to schedule upgrades and maintenance, the CDN77 Client Panel and API > will be temporarily unavailable. Other affected services include purge & > prefetch requests, as well as attempts to modify or change CDN Resource > settings and configurations via API. > > Please schedule any important changes before this time, and plan ahead with > this scheduled maintenance in mind. This maintenance *will not affect your > traffic flow*; all content delivery will continue as normal. > > *When:* December 3, 2024, starting at 10:00 AM UTC > > *Expected Downtime:* Up to 15 minutes > > *Need assistance?* Our 24/7 support team will be available through our > website at www.cdn77.com > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > . > > We apologize for any inconvenience and thank you for your understanding. > > Best Regards, > > *Juraj Kacaba* > > Head of Client Implementations > Email: support(a)cdn77.com > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > > Sent by DataCamp Limited > 9 Coldbath Square, London, United Kingdom > Unsubscribe > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > Contact > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> > Privacy > policy > <https://news.cdn77.com/tb/cl/eyJ2Ijoie1wiYVwiOjUwNjYwMyxcImxcIjoxMzkwNzQzNj…> -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

3 4

Mac app / Safari extension for Snowflake
by David Fifield 02 Oct '25

02 Oct '25

Browsing through some search results, I found: https://apps.apple.com/us/app/torproject-snowflake/id1597501940 (https://web.archive.org/web/20220222083316/https://apps.apple.com/us/app/to…) https://github.com/jayluxferro/snowflake It looks like a repackaging of the Snowflake JavaScript proxy code for Mac and Safari environments. Maybe we could get in touch with the developer and find a way to adopt it into the main repository?

3 2

SQS rendezvous exceeded free tier usage
by Cecylia Bocovich 06 Jun '25

06 Jun '25

I got a notification from AWS that our SQS rendezvous service exceeded the free-tier usage this month with over 1,000,000 SQS API requests. This is in some sense exciting news, because it shows that the rendezvous channel is effective and getting some use. It does, however mean that we will have to start paying for the service. The current billing period falls on month boundaries, from January 1st to January 31st. The budget action fired on January 9th, which is pretty early in the month. Looking at our broker metrics[0,1], there were approximately 38,608 client polls using SQS. That's approximately 2.5 requests per poll, which is about what I'd expect. It's reassuring to know that the budget actions work. I'm going to set them a little higher, to something I can reasonably afford. I don't yet know how the cost will scale with the number of polls, and how that will compare with the cost of domain fronted requests. [0] https://snowflake-broker.torproject.net/metrics [1] https://metrics.torproject.org/collector.html#type-snowflake-stats

4 7

Deprecation of Azure CDN from Edgio (azureedge.net), replaced by Azure Front Door (azurefd.net), affects snowflake-broker.azureedge.net
by David Fifield 22 Apr '25

22 Apr '25

I got an email on 2024-12-05 saying that that Azure CDN from Edgio/Verizon is going to shut down sooner than expected. The shutdown date was supposed to be 2025-11-04, now it is 2024-01-15 (about one month from now). This affects (at least) snowflake-broker.azureedge.net, which was first set up and is still on Azure CDN with Edgio. I think that snowflake-broker.azureedge.net has not been used by this team since 2021 and https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re…. But it is still getting some use from somewhere, as evidenced by the nonzero monthly bills: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… Whatever is out there that is still using snowflake-broker.azureedge.net will likely stop working after 2025-01-15. > Date: 5 Dec 2024 17:03:50 +0000 > From: Microsoft Azure <azure-noreply(a)microsoft.com> > Subject: Urgent action required: Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 January 2025 > > Migrate to Azure Front Door or other CDN services as soon as possible > to avoid service disruptions. > > Migrate workloads on Azure CDN from Edgio (formerly Verizon) before 15 > January 2025. > > You're receiving this notice because you're currently using Azure CDN > Standard/Premium from Edgio. > > All Azure CDN from Edgio customers must migrate their workloads to > Azure Front Door or other CDN services before 15 January 2025 as Edgio > has advised their platform is currently scheduled to be shut down by > that date. Migrate as soon as possible to avoid an imminent service > shut-down. > > On 31 October 2024, we sent you a notice advising that Azure CDN > Standard/Premium from Edgio (formerly Verizon) will be retired on > 4 November 2025, and that customers of this service must migrate their > workload(s) to a comparable service before this date to avoid service > interruptions. In that email we also advised given that Edgio filed > for Chapter 11 Bankruptcy on 9 September 2024, Microsoft cannot > guarantee that Edgio will continue to support this service through > 4 November 2025 as previously stated. Online references about Azure CDN with Edgio retirement: https://learn.microsoft.com/en-us/azure/cdn/edgio-retirement-faq https://azure.microsoft.com/updates?id=467688 I did try setting up a Front Door CDN profile (which is the recommended replacement for Edgio), following the migration instructions: https://learn.microsoft.com/en-us/azure/frontdoor/migrate-cdn-to-front-door I got the hostname: snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net It works as an alias for the broker: curl -i https://snowflake-broker-hadmaqbnc4dmcffs.z03.azurefd.net/debug However, it apparently does not work with domain fronting, so is likely not actually useful. Front Door not working with domain fronting is consistent with prior announcements by Azure: https://github.com/net4people/bbs/issues/67

8 22

Snowflake bridges using SQS
by Michael Rogers 27 Mar '25

27 Mar '25

Hi all, After updating Briar's bridge config to use the current settings from Moat, we're seeing two Snowflake bridges consistently failing in our CI tests. They're the two bridges that use SQS. Here's a snippet from the log: ``` INFO: NOTICE Managed proxy "/builds/briar/onionwrapper/onionwrapper-java/test.tmp/35/lyrebird": offer created Feb 04, 2025 1:12:34 PM org.briarproject.onionwrapper.AbstractTorWrapper message INFO: NOTICE Managed proxy "/builds/briar/onionwrapper/onionwrapper-java/test.tmp/35/lyrebird": broker failure operation error SQS: GetQueueUrl, https response error StatusCode: 400, RequestID: 60e91cfa-a2a0-55db-beb0-7ce6b621d324, AWS.SimpleQueueService.NonExistentQueue: The specified queue does not exist. ``` Does the queue really not exist, or does this point to some other issue, like the bridges being geoIP restricted or the app needing to pass some extra information to the transport? Thanks, Michael

2 6