16:00:02 <cohosh> #startmeeting anti-censorship team meeting
16:00:02 <MeetBot> Meeting started Thu Feb 19 16:00:02 2026 UTC.  The chair is cohosh. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:00:02 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:08 <onyinyang> hihi o/
16:00:09 <cohosh> hi everyone
16:00:17 <cohosh> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:20 <Shelikhoo[mds]> hi~
16:00:21 <gaba> hi
16:00:24 <meskio[mds]> hello
16:00:29 <theodorsm> hi^^
16:01:44 <cohosh> we've got a few items on the agenda
16:02:02 <cohosh> first an announcement, that FOCI starts in one hour :D
16:02:27 <meskio[mds]> \o/
16:02:27 <cohosh> the papers are available and linked from the FOCI site: https://foci.community/
16:02:38 <cohosh> https://www.petsymposium.org/foci/2026/
16:03:39 <cohosh> next up for discussion
16:03:46 <cohosh> Go version bump to v1.24 for snowflake?
16:03:54 <meskio[mds]> that was from last week
16:04:12 <meskio[mds]> but the updates is that we need to support go 1.22 for lyrebird for the time been
16:04:23 <meskio[mds]> TB doesn't have a plan to deprecate it for now
16:04:38 <Shelikhoo[mds]> wait a sec
16:04:39 <meskio[mds]> I believe theodorsm has done a backport of the security fix
16:04:47 <theodorsm> I have backported the pion stack indeed
16:04:51 <Shelikhoo[mds]> there was one thing I would like to add that discussion
16:04:52 <Shelikhoo[mds]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/662#note_3348004
16:05:08 <meskio[mds]> theodorsm: thank you for helping there
16:05:14 <theodorsm> ofc!:)
16:05:42 <Shelikhoo[mds]> So right now the ci is failing because of android related issue
16:05:58 <cohosh> oh did this include my patch from last week>
16:06:00 <meskio[mds]> mmm, didn't cohosh fix that?
16:06:01 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/18dacf41dca88974be1d568d0bfd75b3f805f13b
16:06:13 <cohosh> i'm not opposed to pinning the version of go-mobile though
16:06:25 <Shelikhoo[mds]> sorry for the noise
16:06:31 <Shelikhoo[mds]> I think we can just rebase it
16:06:39 <Shelikhoo[mds]> and proceed with merging
16:06:49 <Shelikhoo[mds]> thanks cohosh and theodorsm
16:07:00 <cohosh> ok no problem, thanks!
16:07:13 <meskio[mds]> also on this topic
16:07:28 <meskio[mds]> I believe the snowflake client library does already depend on go > 1.22
16:07:39 <Shelikhoo[mds]> EOF EOF
16:07:41 <Shelikhoo[mds]> let's continue
16:07:44 <meskio[mds]> I was trying to make a CI test for this and it fails, because kcp requires a newer version
16:07:45 <cohosh> ah that might be my bad, i bumped a KCP library
16:08:11 <cohosh> it must have been a while since we updated the snowflake client in Tor Browser
16:08:14 <meskio[mds]> I see we haven't release snowflake since the change of the go version in go.mod
16:09:02 <meskio[mds]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40490#note_3346875
16:10:49 <cohosh> ok, so our options are to roll back KCP again, wait to update snowflake in TB, or break it for some OSX users
16:12:27 <cohosh> i think we need to update snowflake in tor browser at some point and it's best to have that option available to us in an emergency
16:12:33 <meskio[mds]> yes, I think those are our options, looks like we might want to hand to users the DTLS fix soonish
16:12:34 <meskio[mds]> so maybe we should roll back KCP and try to make a lyrebird release
16:12:36 <Shelikhoo[mds]> let's rollback kcp...
16:12:47 <cohosh> that sounds fine to me
16:12:57 <Shelikhoo[mds]> we did spent a lot of energy on keep the old macos user float
16:12:58 <Shelikhoo[mds]> there is no reason we should break it now
16:13:02 <Shelikhoo[mds]> unless really necessary
16:13:27 <Shelikhoo[mds]> but I do hope we can bump the go version soon
16:13:38 <meskio[mds]> me too, but I didn't get a clear date from applications
16:13:50 <cohosh> ok i don't mind taking that on, i broke it by updating KCP earlier
16:14:09 <meskio[mds]> thank you cohosh
16:14:31 <cohosh> anything else on this topic?
16:14:39 <meskio[mds]> that is all on this topic from me
16:15:13 <cohosh> next up we have Certificate Issues in Rust-based QUIC Pluggable Transport (UAT) and Future Plans
16:15:36 <cohosh> M4i_un[mds]: i think this is you? and welcome :)
16:15:50 <Shelikhoo[mds]> welcome!!!!
16:15:57 <M4i_un[mds]> First and foremost, I am the author who created this PT (UAT). Simply put, this PT is a Rust-based implementation that mimics QUIC.
16:16:01 <meskio[mds]> 4i_un: nice work with the quic pt
16:16:10 <cohosh> awesome
16:16:19 <M4i_un[mds]> thanks
16:16:28 <M4i_un[mds]> The primary motivations for its creation are as follows:
16:16:28 <M4i_un[mds]> ・I wanted to add more bridges
16:16:28 <M4i_un[mds]> ・I wanted to create a PT that outperforms existing bridges and has no issues with censorship resistance
16:16:28 <M4i_un[mds]> The reason for implementing it in Rust is to support Arti.
16:16:57 <M4i_un[mds]> The main points I'd like to discuss with everyone at this meeting are the following two:
16:17:07 <M4i_un[mds]> Certificate Task
16:17:07 <M4i_un[mds]> How do I actually bundle it with the Tor Browser?
16:17:32 <meskio[mds]> rust is a nice choice, as in the future we'll need to make more PTs in rust to integrate better with arti, but we are very slowly moving on that front
16:17:35 <Shelikhoo[mds]> I do think we wants to discuss the timeline for adding a new rust pt binary to Tor Browser Mobile....
16:18:07 <Shelikhoo[mds]> BTW, I saw another rust based quic related proxy: https://lib.rs/crates/shadowquic
16:18:13 <cohosh> i made a wiki page for new integrations with Tor Browser: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Tor-Browser-Integration-Guide-for-New-Pluggable-Transports
16:18:35 <cohosh> it is very Go-centric, but you will need to follow a lot of the same steps with a rust PT
16:18:39 <M4i_un[mds]> Regarding Certificates
16:18:39 <M4i_un[mds]> Currently, UAT follows a policy of pinning self-signed certificates. While this represents the minimum implementation for PT certificates, it offers the advantage of low operational costs for administrators. The next level involves using WebPKI. This places a legitimate website on an actual domain in front of the bridge, using standard certificates (like Let's Encrypt). When an active attacker visits the bridge address, it becomes
16:18:39 <M4i_un[mds]> indistinguishable from a normal QUIC-enabled website. However, WebPKI requires bridge operators to bear costs such as domain acquisition and certificate issuance.
16:18:39 <M4i_un[mds]> Which approach do you think is better?
16:18:42 <cohosh> so it's a good place to get started
16:18:53 <meskio[mds]> each new PT requires a lot of effort to ask volunteers to run bridges for it, we have been very conservative on PTs added to TB
16:19:11 <meskio[mds]> I was wondering how much this PT makes sense separated from webtunnel, or if webtunnel should just support http3
16:19:31 <cohosh> yes, the applications team also has binary size restrictions
16:19:35 <meskio[mds]> I guess there is some performance penatly of doing websockets instead of straight QUIC
16:19:53 <M4i_un[mds]> Also, please be aware that I'm not very good at English and use translation tools, so my replies may be delayed.
16:20:23 <meskio[mds]> no problem we can slow down a bit the conversation, thanks for the warning
16:20:41 <M4i_un[mds]> meskio[mds]: i see?
16:21:10 <M4i_un[mds]> meskio[mds]: My apologies.
16:22:03 <cohosh> another posibility is to talk to the network team about bundling this PT with arti
16:22:42 <cohosh> all of our current PTs run in a separate process, but iirc they were experimenting with making rust PTs that could be included as libraries and called directly from arti
16:23:01 <cohosh> i haven't been keeping up with that conversation though
16:23:49 <meskio[mds]> I have no idea what is the status of this idea, but this could be nice, that will also mean that this PT will land first in TorVPN and might take a while to land in TorBrowser (as it doesn't use arti for now)
16:24:26 <meskio[mds]> but could be nice to have PTs in the backburner even if we don't make explicit calls for operators to run bridges for them, like we've discussed to do for dns based one
16:26:14 <cohosh> meskio does have a good point that a lot of the work of a new PT is in outreach: getting people to run new bridges. it takes a lot of team effort to do the integration itself, get bridge operators, and correspond with those operators on tor-relays and other forums
16:26:59 <cohosh> it's a big commitment to integrate a new PT and grow it
16:27:02 <M4i_un[mds]> <meskio[mds]> "I was wondering how much this PT..." <- Regarding the reason for separating WebTunnel, while testing has not yet been conducted and this is my personal opinion, performance improvements under adverse conditions are anticipated.
16:28:04 <meskio[mds]> I'm also concerned that blocking QUIC might be cheap for censors as browsers do fallback to http1.1 if is blocked, users might not notice it
16:28:23 <meskio[mds]> but I've been surprised in the past by censors not blocking things that seemed "easy"
16:28:28 <M4i_un[mds]> For the parts I can handle on my own, I plan to put in a lot of effort going forward, but I still haven't come up with a good idea for securing Bridge operators.
16:28:32 <cohosh> M4i_un[mds]: what we typically do is a call for users and testers using just commandline tor (or arti) first
16:29:52 <M4i_un[mds]> cohosh: I see?
16:31:14 <Shelikhoo[mds]> It does take a lot of effort to get a pt shipped in tor browser
16:31:37 <Shelikhoo[mds]> and we usually start with distribute the pt separately
16:31:42 <unic3rn> >> "blocking QUIC might be cheap for censors as browsers do fallback to http1.1 if is blocked, users might not notice it" hi all, in Russia many consumer websites use QUIC to transfer images faster, so there would be at least a small reason as that for it not to be blocked all the time
16:32:05 <meskio[mds]> ohh, good to know
16:32:17 <cohosh> unic3rn: oh nice, thanks for that insight
16:32:22 <M4i_un[mds]> Regarding censorship resistance, we won't know until we actually test it, but at the very least, I think there's a possibility that future web services will start supporting QUIC, and that censorship agencies like the GFW haven't caught up yet. What do you think?
16:34:25 <Shelikhoo[mds]> I think it is hard to say whether it will be blocked, but we are not in a position to say not to try it
16:34:30 <cohosh> M4i_un[mds]: it does sound like a great thing to try, the problem for us is that integration requires a lot of work across multiple teams
16:34:47 <cohosh> i think the best way to move forward is to open an issue about it and then reach out to the applications and network teams
16:35:01 <Shelikhoo[mds]> just we should have the good exception of difficulty of getting it into tor browser
16:35:19 <Shelikhoo[mds]> just we should have the good expectation of difficulty of getting it into tor browser
16:35:24 <Shelikhoo[mds]> sorry for typo
16:35:24 <cohosh> it's possible that Tor VPN would be the best first place to try it out, but we'll need to check
16:35:57 <cohosh> with Tor Browser i'm worried about binary size
16:36:13 <M4i_un[mds]> cohosh: Thank you. I'm a bit busy and haven't managed to do it yet, but I've already created a GitLab account and plan to create an issue soon.
16:36:36 <cohosh> so from that perspective, and the integration difficulty, a QUIC PT in lyrebird, or option in webtunnel would be the fastest, easiest way to try out QUIC with real users
16:36:51 <cohosh> M4i_un[mds]: thank you for your patience and commitment to this
16:37:41 <meskio[mds]> nice, create an issue and we can discuss this more there
16:37:49 <unic3rn> By the way, a user tipped me off with that on the forum, adding some more info: https://forum.torproject.org/t/proposal-rust-based-quic-pluggable-transport-uat/21124/6
16:38:13 <meskio[mds]> I think a good place to start with the issue is creating it here: https://gitlab.torproject.org/tpo/tpa/team/-/issues/
16:38:40 <M4i_un[mds]> unic3rn: thanks
16:39:41 <cohosh> anything else for today?
16:39:56 <meskio[mds]> nothing from
16:40:14 <Shelikhoo[mds]> EOF from me
16:40:37 <M4i_un[mds]> For more detailed discussions or specific information, I believe checking the forum is currently the best option. Once we create a GitLab issue, we'll also post a link to it on the forum.
16:40:47 <M4i_un[mds]> EOF from me too
16:40:54 <unic3rn> I don't know if it's worth a discussion, but I had something about the throttled IP's
16:40:57 <dcf1> M4i_un[mds]: thanks for getting in thouch :)
16:40:59 <unic3rn> more like a question
16:41:00 <dcf1> *touch
16:41:09 <cohosh> unic3rn: go ahead :)
16:41:44 <unic3rn> ok
16:42:33 <unic3rn> so according to an article, more than 225 million IP's are affected in a throttle in Russia. Seems like 16KB-blocking. A user made some tests. I have a link in the message. It's on a russian tech discussion site, mind you. https://forum.torproject.org/t/apparently-a-new-wave-of-tor-blocking-is-underway-in-russia/21006/41
16:43:51 <unic3rn> some failed snowflake bootstraps might be because of that. I'm not promoting censorship or anything, would it be possible to or even make sense to not give out such snowflake proxies with affected IP's to RU users?
16:45:02 <cohosh> that is a difficult thing to do
16:45:13 <cohosh> just in general
16:46:05 <cohosh> first, gathering and keeping up to date a list of blocked IPs in a region
16:46:28 <cohosh> secondly, figuring out whether a user is in a region affected by the block
16:46:40 <dcf1> regarding the 16KB blocking, there's a link about that in the interesting links
16:46:44 <unic3rn> ok, imaginable. so would it be good advice to give to affected users?: just clear the tor browser cache to get a new snowflake IP.
16:47:19 <cohosh> well, snowflake is pretty good at detecting if a conneciton is no good and polling the broker again for a different IP
16:48:05 <cohosh> oh but this is throttling
16:48:09 <cohosh> hmm
16:48:16 <Shelikhoo[mds]> I imagine if the connection is just slow
16:48:24 <Shelikhoo[mds]> snowflake would keep connected
16:48:26 <unic3rn> >> "secondly, figuring out whether a user is in a region affected by the block." well, this specific type of blocking is present on most residential connections. in fact the interesting part is that there are whole blocks of affected hosting providers, meaning that there is sort of a predefined list of hosts that might be "throttled"
16:48:35 <Shelikhoo[mds]> even if it is in a unusable speed
16:48:35 <cohosh> maybe we could consider a feature that detects if the connection is too slow
16:48:49 <cohosh> and tries to get another snowflake occasionally
16:48:51 <Shelikhoo[mds]> yeah... I agree
16:48:54 <cohosh> that would also be a good usability improvement
16:49:25 <unic3rn> >> "well, snowflake is pretty good at detecting if a conneciton is no good and polling the broker again for a different IP" that's good to hear, so maybe if the client waits a bit longer, then everything will get fixed, if they "hang a bit longer" for a bit?
16:49:27 <cohosh> in non blocking cases if there are snowflakes that perform less well due to distance or bandwidth
16:49:53 <cohosh> unic3rn: i take that statement back, in the case of throttling we don't currently detect it
16:50:03 <cohosh> so your advice is good, to retry the connection if it is too slow
16:50:46 <unic3rn> cohosh: ok, good to know
16:51:43 <cohosh> i will open an issue about improvements we could make, thank you for bringing this up in the meeting
16:51:49 <meskio[mds]> I wonder how we detect the difference between throtling and users in very slow networks
16:52:41 <cohosh> meskio: yeah that's a tough problem, ignoring for a second the strain on the proxy pool, we could have users opportunistically try to get a faster proxy occasionally and abandon the other one if it performs better
16:52:43 <unic3rn> thanks! I'd like to look into this some more later to understand how it affects the connection. (and if it even does)
16:52:58 <cohosh> unic3rn: aesome!
16:53:04 <cohosh> *awesome
16:53:26 <unic3rn> ok, eof from me
16:53:48 <unic3rn> thanks for replying!
16:54:01 <cohosh> ok, i'll end the meeting here and we can continue discussions on gitlab :)
16:54:06 <cohosh> thanks for joining everyone!
16:54:10 <cohosh> #endmeeting