16:01:24 <onyinyang> #startmeeting tor anti-censorship meeting
16:01:24 <MeetBot> Meeting started Thu Feb 26 16:01:24 2026 UTC.  The chair is onyinyang. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:01:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:24 <onyinyang> hello everyone!
16:01:24 <onyinyang> here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469)
16:01:26 <Shelikhoo[mds]> I can host the meeting...
16:01:44 <Shelikhoo[mds]> okay, thanks onyinyang
16:01:48 <meskio[mds]> hello
16:02:20 <Shelikhoo[mds]> hi~
16:02:23 <ggus> hi o/
16:03:35 <onyinyang> I think there's only one new discussion point which is: orbot asked us about using snowflake assets for their kindness mode improvements
16:04:54 <meskio[mds]> I guess we can remove the others
16:05:13 <onyinyang> yep, thanks
16:05:55 <cohosh> oh i have an update on the go1.22 stuff
16:06:09 <onyinyang> cohosh, I think you added the orbot point? did you want to say anything about it before that?
16:06:10 <cohosh> it needs more discussion
16:06:19 <cohosh> yeah the orbot thing is quick
16:06:24 <onyinyang> ok cool
16:06:33 <cohosh> they asked us if they could use the snowflake assets for the kindness mode UI
16:06:52 <cohosh> the assets are permissively licensed so no trouble on that front
16:07:06 <cohosh> but they wanted a quick check with the team to see if anyone has reservations about it
16:07:24 <meskio[mds]> sounds good to me
16:07:24 <cohosh> i don't see any issue with it
16:07:43 <meskio[mds]> they are using snowflake logo for an app that has snowflake support, sounds like the right use for it
16:07:55 <Shelikhoo[mds]> I think it is nice too
16:08:06 <cohosh> cool
16:08:27 <onyinyang> ok that _was_ quick :)
16:08:36 <onyinyang> so the next point is snowflake client go 1.22 support
16:08:45 <Shelikhoo[mds]> hehe >~<
16:08:50 <cohosh> yeah so last week we decided to roll back the kcp library
16:09:11 <cohosh> it turns out it's not that simple, and there was a golang.org/x/net update for a security fix that required a version bump to 1.23
16:09:18 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40490#note_3354767
16:10:10 <cohosh> we're running into a limitation of having a single go module for multiple projects
16:10:11 <meskio[mds]> have you checked that we are actually afected by that security fix?
16:10:46 <cohosh> i did a quick assessment at the time: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/605#note_3241953
16:11:47 <cohosh> it was probably not, but we do use that part of th code and since I didn't think it would affect Tor Browser builds we went ahead and deployed the update
16:11:48 <meskio[mds]> I see
16:12:17 <cohosh> one way we could handle this is to split snowflake into multiple modules, each with their own go.mod
16:12:41 <cohosh> but it's not even trivial to deal with local changes across multiple modules there unless you use workspaces
16:12:51 <dcf1> https://go.dev/ref/mod#workspaces
16:12:55 * dcf1 reads
16:13:00 <Shelikhoo[mds]> I think if we do not update any code, and only update go.mod for the new dependencies, we could just have a overlay go.mod and so.sum for macos
16:13:36 <cohosh> yeah that's the other option, which is to apply a manual patch to go.mod and go.sum for tor browser builds
16:15:37 <meskio[mds]> it might not be a bad idea to produce a go.sum/mod just for the OSX build of TB, and be able to update the rest
16:16:07 <cohosh> that's probably the quickest fix
16:16:45 <cohosh> restructuring snowflake would require deprecating the current module and would require library users to change how they import snowflake libraries
16:17:27 <meskio[mds]> we'll need to check with them how will that fit in their building process
16:17:28 <meskio[mds]> but we'll need to be careful to don't make any changes in the code that uses new APIs
16:17:54 <Shelikhoo[mds]> Yeah, I think this legacy check can be made using CI without too much issue
16:18:31 <cohosh> maybe i'll try a tor browser patch first so we can update snowflake in TB finally
16:18:32 <meskio[mds]> agree
16:18:34 <Shelikhoo[mds]> so this check is pretty easy to be automated
16:19:14 <meskio[mds]> cohosh: sounds good to me, let's see if you encounter any problems with that
16:19:21 <Shelikhoo[mds]> yeah, I think we should expect the macos issue be gone soon
16:19:47 <cohosh> we're eventually going to have to deal with this for 1.23 -> 1.24
16:20:02 <Shelikhoo[mds]> yeah! thanks cohosh!
16:20:21 <cohosh> there's a golang.org/x/net security fix that requires 1.24. It looks like it doesn't affect us now but maybe there will be something later
16:21:27 <cohosh> ok that's it from me on this i think
16:21:51 <Shelikhoo[mds]> EOF from me as well
16:22:28 <onyinyang> ok cool
16:22:39 <onyinyang> the next topic is:     snowflake proxy pool depleted
16:22:52 <meskio[mds]> I added there to see if there is anything to discuss
16:23:06 <meskio[mds]> so, the snowflake proxy pool is basically depleted
16:23:14 <meskio[mds]> but proxy operators are reporting not much use
16:23:37 <meskio[mds]> it looks like Iranian clients are failing often to connect to the proxies they got from the broker
16:23:44 <meskio[mds]> and keep retrying
16:24:14 <meskio[mds]> Shelikhoo is investigating it and I expect there is no results yet on this
16:24:49 <Shelikhoo[mds]> yes, this task is queued after dns tunnel for ssh port
16:25:05 <meskio[mds]> is it too soon to discuss startegies to mitigate the implications of this situations for the global snowflake network?
16:25:06 <Shelikhoo[mds]> I think a quick fix we could do now
16:25:16 <Shelikhoo[mds]> is to reduce minPollInterval for snowflake proxy
16:25:25 <Shelikhoo[mds]> while keeping the default
16:26:03 <Shelikhoo[mds]> so if a proxy operator wants its proxy to get more client match, there will some some manual step they could take
16:26:27 <Shelikhoo[mds]> and maybe have a failed match/successful match stats
16:26:51 <Shelikhoo[mds]> but is to reduce minPollInterval for snowflake proxy
16:26:51 <Shelikhoo[mds]> while keeping the default is the easiest step
16:27:01 <Shelikhoo[mds]> and shouldn't take too much time
16:27:23 <meskio[mds]> you mean recommending proxy operators to set this flag? or to modify the default value in standalone/webextension?
16:28:06 <Shelikhoo[mds]> at least for the standalone proxy
16:28:16 <Shelikhoo[mds]> the current default polling interval is 5s
16:28:36 <Shelikhoo[mds]> we can suggest them to temporarily decrease it to 2s
16:29:02 <Shelikhoo[mds]> to try more match
16:30:49 <meskio[mds]> I wonder if is not more effective to make a release with the default been changed, not sure how many operators do upgrade...
16:32:50 <Shelikhoo[mds]> I am not sure we should adjust the default... let's say some user's network has paid traffic
16:33:13 <Shelikhoo[mds]> if we adjusted this value and their auto update get broken somehow
16:33:29 <cohosh> sorry, just tried snowflake a few times and i'm getting a proxy pretty quickly
16:33:46 <Shelikhoo[mds]> then we eventually fix the snowflake, they will be hit with unexpected bill
16:34:05 <cohosh> i don't think the pool overload is too bad right now
16:34:26 <meskio[mds]> ohh, ok, so even if the graphs claim that there is a lot fo denied clients, the user experience is not that bad?
16:34:36 <cohosh> i see an increase in clients getting denied but i suspect this isn't having a terrible effect on usability yet
16:34:42 <meskio[mds]> confusing
16:34:54 <Shelikhoo[mds]> But for any concerned proxy operators, we should give they some advise to take home
16:34:54 <cohosh> well, we try two bootstraps at once
16:34:56 <Shelikhoo[mds]> pollInterval := flag.Duration("poll-interval", sf.DefaultPollInterval,
16:34:56 <Shelikhoo[mds]> fmt.Sprint("how often to ask the broker for a new client. Keep in mind that asking for a client will not always result in getting one. Minumum value is ", minPollInterval, ". Valid time units are \"ms\", \"s\", \"m\", \"h\"."))
16:35:00 <Shelikhoo[mds]> can be one of thatg
16:35:24 <cohosh> the spikes in denials were worse a few days ago
16:35:46 <meskio[mds]> ok, good with me
16:35:56 <cohosh> at the worse spike it was ~4x the number of denials as matches
16:36:25 <meskio[mds]> so I hear your proposal shell not as in let's make a call right now, but let's reply to the ones that asks that they can reduce the poll interval
16:36:27 <cohosh> which means if you're bootstrapping two connections you're probably waiting 2-3 rendezvous fetches, which is a little slow but still ok
16:36:41 <cohosh> now it's more 1-2 rendezvous attempts
16:37:06 <Shelikhoo[mds]> meskio[mds]: yes... this is my plan right now. But I am happy to hear what everyone else says
16:37:07 <cohosh> it's not great but i don't know that it warrants a change in default poll rate given how difficult that currently is
16:37:35 <cohosh> yeah i would agree that increasing the poll interval manually is a reasonable thing to do
16:37:47 <meskio[mds]> make sense
16:38:06 <meskio[mds]> we can give it some more days and see if things improve, while we investigate what is the situation in Iran
16:38:16 <cohosh> sounds good
16:38:27 <Shelikhoo[mds]> cohosh: do you mean decrease the poll interval aka poll more often
16:39:54 <cohosh> yes, sorry
16:40:07 <cohosh> increase the poll rate ^_^`
16:40:14 <cohosh> that was your proposal, right?
16:40:17 <Shelikhoo[mds]> hehe >~<
16:40:20 <Shelikhoo[mds]> yes
16:40:39 <Shelikhoo[mds]> don't worry I make more typos
16:40:54 <onyinyang> hehe
16:41:04 <onyinyang> anything more on this topic?
16:41:17 <Shelikhoo[mds]> EOF from me on this topic
16:42:01 <onyinyang> ok, so that's it for discussion points. There is an interesting link: https://nordvpn.com/blog/nordwhisper-protocol/ 2025
16:44:01 <Shelikhoo[mds]> for these protocols, is there something like source code?
16:44:53 <dcf1> I don't know, from nordvpn likely not
16:45:28 <meskio[mds]> I recall seen the announcement some months back, but not much information on what it does
16:45:56 <dcf1> seems like another webtunnel type thing, tunnel over https
16:46:57 <Shelikhoo[mds]> I don't have a subscription to get a packet capture
16:47:10 <Shelikhoo[mds]> but tunneling over https is rather know design pattern
16:48:13 <Shelikhoo[mds]> "NordVPN's newly launched NordWhisper VPN protocol aims to bypass VPN restrictions by mimicking traditional web traffic"
16:48:17 <dcf1> the "interesting" part is just the knowledge that commercial vpns are doing some kind of circumvention-like transports. not that what they're doing is devastatingly novel or something we need to try to do ourselves
16:48:21 <Shelikhoo[mds]> I see this from google search
16:49:26 <Shelikhoo[mds]> yeah, but I think we do have plan to upgrade webtunnel with a new transport mode based on http single duplex request system
16:49:34 <Shelikhoo[mds]> to work with http2 or 3
16:49:45 * dcf1 thinks not every "interesting link" has to turn into a discussion or
16:49:52 <Shelikhoo[mds]> which could benefit from some inspirations
16:49:56 <Shelikhoo[mds]> EOF
16:50:17 <onyinyang> ok, that's it for this week then
16:50:28 <onyinyang> Thanks everyone!
16:50:38 <Shelikhoo[mds]> thanks
16:50:41 <meskio[mds]> thanks
16:50:42 <onyinyang> #endmeeting