15:58:35 #startmeeting tor anti-censorship meeting 15:58:35 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:35 feel free to add what you've been working on and put items on the agenda 15:58:35 Meeting started Thu Oct 13 15:58:35 2022 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:39 Hi! 15:58:51 hello 15:59:04 hi 16:06:31 I didn't see any new topic... 16:06:36 other than one 16:06:50 about Release a new version of snowflake webext proxy 16:07:29 if you are adding things to the upper part, I might miss it 16:08:34 okay, let begin the first topic 16:08:34 Release a new version of snowflake webext proxy 16:08:55 we have merged a few merge request in snowflake webext 16:09:05 it might be a good time to release a new version 16:09:14 any blockers? 16:09:23 yes 16:09:40 there's still some work to be done on getting translations working smoothly again 16:10:14 right now we have to manually pick which translations to update 16:10:24 i'm hoping this will be resolved in a week or two 16:10:50 yes, we could wait for a few weeks... 16:11:18 let's discuss this again in next weeks meeting and see whether we could move forward 16:11:36 Okay next topic is 16:11:37 loss of bandwidth at snowflake-01 bridge 16:11:37 dynamics are the same as at the time of 2022-10-06 meeting 16:11:37 the cause of the loss of bridge bandwidth is still unknown https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40207 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/96#note_2840481 16:12:24 I don't have anything to add other than what's in the links 16:14:35 If this issue is caused by server 16:14:43 rather than the proxy part 16:14:55 we could fix this by distributed snowflake proxy 16:15:21 I will begin the process to roll out the distributed snowflake proxy support to Tor browser 16:15:36 with the 02.snowflake.torproject.net server 16:15:38 well, I think it must be more complicated than that 16:16:07 but a second bridge is something we need to move ahead with anyway 16:16:40 yes, so we can remove a set of hypnosis at no extra cost to us 16:16:48 one thing I'm concerned about is that the hardware for snowflake-02 is not quite as fast as the hardware for snowflake-01 16:17:14 This should be fine, it is not going to receive a lot of users in the beginning 16:17:15 and 16:17:23 I think it's a good idea to push out support first in the alpha release only, in order to gauge capacity. 16:17:48 snowflake-02 is able to handle 50% of the users we have today, but probably not 50% of the users we had 10 days ago. 16:18:07 we would be able setup even more bridges without additional cost 16:18:30 other than coordination, maintenance, communication costs 16:19:08 I just saw a link from cohosh in #tor-dev: https://gitlab.torproject.org/tpo/core/tor/-/issues/40636#note_2819763 16:19:30 yes, I think the first step is to make it possible to use the second bridge with a custom bridge line 16:19:44 we would be able setup even more bridges without additional coding(fixed) 16:19:46 Probably unrelated, but I was not previously aware that snowflake-01's high usership might be interpreted by other relays as a DoS signal 16:21:12 linked to me, i don't know how to tell if this is due to snowflake's load balancing or if it indicates another issue 16:22:53 they seemed surprised at the number of connections even given the 12 instances, but that machine is seeing a lot of traffic 16:24:04 Just by pigeonhole principle, the snowflake bridge is going to be making (much) more than one connection to some relays, since there are many times more snowflake users than there are relays 16:24:48 * cohosh nods 16:25:11 https://share.riseup.net/#JWQAl-2UMIyak9FeP6OJ8A even back at the level of 20k 16:26:00 this goes with something I posted in my notes 16:26:02 https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40009#note_2841814 16:26:18 https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Research-ideas#calibrate-bridge-users-estimation-with-on-bridge-socket-counts 16:27:13 I suspect that the Tor Metrics estimation algorithm is inflating user counts, not hugely, maybe by about a factor of 2 at most 16:27:41 at this moment the number of open sockets is 16:27:42 # ss -n state established 'dst 127.0.0.1' 'dport = 10000' | wc -l 16:27:42 10656 16:28:22 but still, it's a lot of connections funneled through one IP address 16:29:30 yeah, wow 16:30:28 I think snowflake bridge should be given an exception when it comes to DoS protection, since it wouldn't work if that restriction is applied to it strictly 16:30:32 in its current form 16:31:06 but the good thing is that that restriction is not currently respected... 16:31:08 yeah I was wondering if maybe something changed with respect to DoS parameters in the consensus, or something like that, at 2022-10-04 17:15 16:31:22 but it still wouldn't explain the contemporaneous drop in client polling 16:31:52 which is why I rather suspect something to do with blocking of the broker than with something on the bridge or something to do with the Tor network 16:32:05 (though that still doesn't explain why not only Iran had a drop at that time) 16:34:42 There was a broker deployment that rejected old proxies... but there was a difference in time between two events 16:35:06 however, they are close enough I am unsure how timezone come into play 16:35:22 I thought about that possibility, but the time difference was more than 24 hours 16:36:00 I don't know, is it worth re-deploying the broker not to reject old proxies, just as a test, for 48 hours or so? 16:36:55 that sounds like a reasonable idea to me 16:37:12 okay, I will do this next Monday 16:37:39 still I'm baffled why it should have affected client polling rate 16:37:41 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40207#note_2840780 16:37:58 I guess I shouldn't let one piece of contradictory evidence override other pieces of contradictory evidence :) 16:38:41 It's possible, like, 2 different things happened near the same time and the effects can't be explained by a single cause 16:39:26 the only other avenue of investigation I had in mind is to run a proxy and try to see if the DTLS connections are getting interfered with 16:40:05 i agree this is really weird 16:40:24 a very sudden drop that doesn't align with a deployment *exactly* that affected everywhere at once 16:40:47 yes... anyway i will try to revert the change on broker next monday] 16:40:54 thanks shelikhoo 16:41:06 because there is only one way to find out.... 16:41:45 anything more on this topic? 16:41:52 now is the announcement time 16:41:53 snowflake-01 transferred 1.17 PB of Tor user data in the six months between 2022-04-08 and 2022-10-08 16:41:53 users with annotated events https://share.riseup.net/#JWQAl-2UMIyak9FeP6OJ8A 16:41:53 bandwidth https://share.riseup.net/#qpzsTgHxfG0Ar-JrDRfQEg 16:42:07 =================== 16:42:08 New release v1.1.3 of uTLS 16:42:08 https://github.com/refraction-networking/utls/releases/tag/v1.1.3 16:42:08 supports more and more recent TLS parrots 16:42:08 from https://github.com/net4people/bbs/issues/129#issuecomment-1276774330 16:42:13 =============== 16:42:34 do we wants to discuss about any of the announcements? 16:45:00 okay, anything else we wants to discuss in this meeting? 16:45:36 (awesome about the announcments) 16:45:40 but no more to add from me 16:47:21 okay, let's call it a meeting! Thanks everyone~~~ 16:47:22 #endmeeting