16:00:15 #startmeeting tor anti-censorship meeting 16:00:15 Meeting started Thu Nov 12 16:00:15 2026 UTC. The chair is onyinyang[mds]. Information about MeetBot at https://wiki.debian.org/MeetBot. 16:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:15 hello everyone! 16:00:15 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 16:00:15 please let me know if you need a link to have write access the pad. 16:00:18 hi 16:00:26 hello 16:02:31 The discussion topic in the pad is from last week, Is there anything new to add there or should I remove it? 16:03:12 i can give a short update if there's nothing else to talk about 16:03:28 i made an issue for it: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/40583 16:03:39 I'll be happy to hear if you found something 16:03:55 It doesn't seem like there's anything else :) 16:04:03 i think the overloading polls are coming from RU 16:04:33 when an overload happens, polls from every region increase, because if there are no proxies clients everywhere need to try again 16:05:23 but the overwhelming majority of polls are from RU, whereas outside of the spikes, polls from RU are pretty comparable to IR and US 16:06:06 what i can't tell is if this spike is due to an enumeration attack, a DoS attack, or censorship 16:07:16 I just checked and there is not reports from our vantage point in russia for a month, so I can't correlate it 16:07:17 i'm thinking the best way to handle this is some sort of client poll rate limit, but it's difficult to tell what that should look like 16:07:53 do you know why this issue was closed? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/40466 16:08:44 I don't recall all the details, I think I was convinced by you or shell that it was not a great idea 16:09:04 we have two potential situations: the overload is caused by honest clients using our implementation, or the overload is a custom client that is either too aggressive or malicious 16:09:44 but can be reopened if you do think it makes sense 16:10:10 ok i might open a more generic issue and leave this closed and reopen if we decide it's a good idea 16:10:27 sounds good 16:10:56 yes, be able to differenciate malicious clients from well behaving ones will be nice 16:11:28 i wouldn't want to implement or deploy something without some lightweight simulations like the ones in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/work_items/25598#note_3392744 16:13:18 makes sense 16:13:49 maybe something to include in a funded project, but I guess will need some more material to produce a full snowflake project 16:14:00 i might update our research page :) 16:14:17 i've geen getting a lot of emails asking about snowflake research projects lately 16:14:27 nice :) 16:14:52 ohh, nice 16:16:24 that's it from me on this topic, thanks for the discussion 16:17:20 thanks for the update @irc_cohosh:matrix.debian.social 16:17:30 I guess there's nothing else today 16:17:31 thanks for investigating it 16:18:06 so everyone can have the rest of the time back and we can reconvene next week :) 16:18:21 Same UTC time, same channel hehe 16:18:27 :) 16:18:47 :) 16:18:48 #endmeeting