16:01:27 <onyinyang> #startmeeting tor anti-censorship meeting
16:01:27 <MeetBot> Meeting started Thu Jun 12 16:01:27 2025 UTC.  The chair is onyinyang. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:27 <onyinyang> hello everyone!
16:01:27 <onyinyang> here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469)
16:01:30 <meskio> :)
16:01:32 <meskio> hello
16:01:34 <shelikhoo> hi~hi~
16:03:11 <cohosh> hi
16:05:03 <onyinyang> I think there is a typo in the first discussion point. . .but maybe there was outrage about the outage?
16:05:35 <onyinyang> lol much better
16:05:36 <shelikhoo> maybe "outage"?
16:05:39 <cohosh> lol
16:05:40 <shelikhoo> hahaha
16:05:55 <meskio> lol
16:06:05 <meskio> sorry, my bad, one day I'll learn some spelling
16:06:37 <onyinyang> ok, let's discuss :)
16:06:54 <onyinyang> learning from the CDN77 outage
16:07:04 <meskio> sure, so there was the outage where we lost access to CDN77
16:07:22 <meskio> and a lot of things were done for it, like seting up alternative domain fronts
16:07:32 <meskio> or configuring other snowflake bridgelines in TB
16:07:40 <meskio> what should we actually apply?
16:07:46 <meskio> I guess we can go step by step
16:07:49 <meskio> what about snowflake?
16:08:05 <meskio> do we want to have two bridgeliens with different signaling channels?
16:08:09 <meskio> ampcache + domain front?
16:08:20 <meskio> instead of the two lines with the same?
16:08:39 <meskio> or do we want to wait to add the option in the interface for users to select their signaling channel?
16:08:51 <meskio> cohosh: do you have a sense on how long that option might take?
16:09:01 <shelikhoo> I think it make senses to have different signaling channels by default
16:09:25 <shelikhoo> and let user choose if they wants to use a specific one from UI if they wish to
16:09:28 <cohosh> i think the next step is to have seperate built-in options for different rendezvous methods
16:09:41 <cohosh> like we used to have with meek-google, meek-amazon, meek-azure
16:09:51 <cohosh> that's the easiest way to implement it
16:10:33 <dcf1> yeah, and the meek-* situation was basically because there was no time/interest for implementing a custom transport-specific configuration UI
16:10:38 <cohosh> making a totally different UI drop down menu would likely take a lot longer
16:11:14 <cohosh> yeah i think transport-specific configs we're looking at months
16:11:16 <dcf1> so you take the most important configuration options users are likely to want to change, and "bake them in" to the transport name
16:11:25 <cohosh> multiple snowflake bridge lines could be just a week or two
16:11:50 <cohosh> *multiple snowflake built-in bridges, that is
16:12:23 <meskio> ok, it sounds good, so we could just have snowflake-cdn77 and snowflake-google and maybe snoflake-netlify
16:12:48 <shelikhoo> snowflake-googleamp ?
16:13:02 <shelikhoo> I think google has more services than just amp
16:13:21 <shelikhoo> and in theory some of their other services also supports domain fronting
16:13:31 <cohosh> also, tor browser UX has tried to move people towards more automated configurations lately and less user choice, so there would likely be a discussion with the UX team on whether transprot-specific UI elements are a good idea
16:14:09 <meskio> I wonder if this will break circumvention settings support, as the browser now somehow expecting snowflake to be called snowflake-cdn77
16:14:14 <cohosh> shelikhoo: yeah good call, and snowflake-amazon-sqs, since amazon has multiple services as well
16:14:19 <meskio> circumvention settings calls meek meek-azure...
16:14:22 <shelikhoo> yes, in longer term, it makes sense for the signaling library to test all channels automatically
16:14:40 <meskio> agree
16:15:43 <meskio> ok, so do we have consensus on trying to have multiple options in the browser for the different rendezvous options?
16:15:52 <meskio> we can revisit this decision if this is taking to long
16:15:59 <meskio> I mean to don't modify the exsiting lines for now
16:16:01 <shelikhoo> we are about to have domain fronting testing support in logcollector
16:16:10 <meskio> :)
16:16:13 <shelikhoo> but currently it runs test every 24 hours
16:16:22 <dcf1> good point about possible dependency on specific transport name labels, meskio
16:17:08 <onyinyang> that seems fine to me
16:17:11 <cohosh> yeah, can you comment on the issue about it?
16:17:23 <cohosh> i agree that multiple built-in snowflake bridges is the best next step
16:17:29 <meskio> I'll do
16:18:15 <meskio> on the monitoring side of things I think we can create an alert in prometheus, for example we can monitor a big request drop or something
16:18:59 <shelikhoo> yes, we can test things from server side as well
16:20:08 <shelikhoo> i mean we can see if the domain fronting is working from server side as well
16:21:04 <meskio> I'm looking at grafana and there is a clear poll drop, I'll give it a try to create an alert
16:21:10 <onyinyang> nice
16:21:15 <shelikhoo> yes nice!
16:21:50 <onyinyang> ok, anything else on this topic or shall we move on to the next one?
16:21:55 <meskio> yes, domain fronting
16:22:01 <shelikhoo> eof from me
16:22:17 <meskio> we set up netlify, dos it make sense to move moat to it so snowflake and moat are not in the same domain front?
16:23:09 <cohosh> cost and sustainability is an important aspect here
16:23:25 <meskio> netlify for our usecase seems free
16:23:25 <shelikhoo> I think this would make sense, although I think we could wait a little to learn more about netlify
16:23:39 <cohosh> oh, is it free for a certain about of traffic?
16:23:39 <meskio> but I don't know if I'm reading their pricy well
16:23:45 <meskio> 100GB per month
16:24:09 <meskio> I don't expect that amount of traffic from our API, but maybe I'm wrong
16:24:23 <meskio> cohosh: do you have numbers of our traffic in CDN77?
16:24:35 <shelikhoo> sometime there will be surprise charges from these services
16:24:48 <cohosh> i'm looking them up now
16:25:35 <cohosh> just moat used 25.1 GB in May
16:26:01 <cohosh> snowflake used 92.4 GB
16:26:03 <meskio> sounds well below the 100GB
16:26:10 <meskio> snowflake doesn't sound that well
16:26:48 <shelikhoo> yeah, billing would be triggered in this case
16:27:25 <meskio> the problem with the moat domain front is that is not that easy to change, as we need a TB release for it
16:27:35 <meskio> I wonder if we can somehow battletest it before applying it
16:28:17 <shelikhoo> maybe we could ask if we could use netlify moat in alpha version of tor browser only for a while
16:28:37 <cohosh> i think that could work
16:28:44 <meskio> yes, I guess there will not be that many users of moat there, but let's start with that
16:29:26 <meskio> I can create an issue on TB side to request the change
16:29:26 <onyinyang> makes sense to me
16:29:57 <meskio> that are all the subtopics I have in mind for this outage
16:30:08 <onyinyang> did we discuss the ampcache topic and I missed it?
16:30:21 <onyinyang> s/topic/subtopic
16:30:43 <meskio> yes
16:30:55 <meskio> I think we agreed on not including an ampcache bridge for now
16:31:11 <meskio> and try to get it as an option in the configuration
16:31:24 <meskio> but maybe I missreaded the consensus
16:31:52 <cohosh> i think we are adding separate snowflake built-ins for domain fronting and ampcache
16:32:25 <onyinyang> ok, that's fine. Let's move on to the next topic then?
16:32:45 <shelikhoo> eof on the cdn77
16:32:55 <onyinyang> what do we do with moat bridges
16:32:55 <onyinyang> https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233
16:33:13 <onyinyang> this is also meskio I guess
16:33:22 <meskio> yes, I'm full of topics today
16:33:31 <onyinyang> :D
16:33:36 <meskio> 8 months ago we turned off bridgedb and stopped distributing moat bridges
16:34:03 <meskio> we put them on hold and didn't reasigned to let users enjoy them if they still work for them
16:34:19 <meskio> I keep hearing reports of bridge operators asking about their bridges not being used
16:34:36 <meskio> maybe is time to reassign them to another distributor or do something with those bridges
16:34:53 <meskio> there is also the danger that many of those bridges are already blocked in china or russia
16:35:29 <meskio> I'm asking trinity to get more data on the actual usage of moat bridges, but if they are as expected very much unused
16:35:39 <meskio> what do you think about reasinging them to other distributors?
16:36:07 <dcf1> why would the moat bridges be especially likely to be already blocked?
16:36:54 <meskio> I'm not sure they are more likelly
16:37:16 <dcf1> ok
16:37:22 <meskio> but few years ago when russia started blocking tor I did investigated it and most moat bridges where blocked there
16:37:32 <meskio> and other distributors where not blocked in that ammount
16:37:55 <meskio> but probably setting bridges are as blocked as moat ones by now
16:38:05 <meskio> or other distributors
16:38:13 <meskio> so maybe is not that big worry
16:38:38 <meskio> we've being careful to don't jump bridges between distributors, but I assume is better to do it with those now than to have them iddle
16:39:34 <meskio> ggus was proposing to assign 50% to telegram and 50% to settings
16:40:56 <shelikhoo> I think this makes sense...
16:41:14 <meskio> I agree, I'll work on the reasigning
16:41:33 <meskio> and I'll notify the bridge operators that have manually configure their bridge for moat to reconfigure it
16:42:17 <onyinyang> cool
16:42:46 <meskio> I think I'm done with this topic
16:42:50 <onyinyang> let's move on to the final topic then
16:42:54 <onyinyang> distribute webtunnel bridges over telegram
16:42:54 <onyinyang> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158
16:42:58 <onyinyang> also meskio :)
16:43:15 <meskio> currently webtunnel bridges are only distributed in the https and settings distributors
16:43:30 <meskio> the community team keeps getting reports of users happy with the telegram distributor
16:43:39 <meskio> and asks if we can also distribute webtunnel bridges there
16:44:00 <meskio> the first step will be to configure rdsys to start collecting webtunnel bridges on that distributor
16:44:16 <meskio> until we have enough bridges for it we can't start distributing them there
16:44:31 <meskio> so I'm planning to configure that and give it some time to see if we gather enough bridges
16:44:42 <meskio> if not we'll see if we need to make a call or think on redistribute bridges
16:45:16 <meskio> does it sound ok?
16:45:34 <shelikhoo> yeah, we can start allocating bridges to telegram, and see what happens
16:45:56 <shelikhoo> but if there is insufficient amount of bridges assigned to telegram
16:46:26 <shelikhoo> we might wants to temporarily increase the likelihood new bridges assigned to telegram
16:46:38 <meskio> yes, I was wondering on that
16:46:38 <shelikhoo> without explicitly asking users to do anything
16:47:03 <meskio> as we currently assign bridges randomly with a provability depending on the ratio we placed
16:47:22 <onyinyang> ah yeah, that would make sense for the time being
16:47:37 <meskio> I could change rdsys to use the knowledge on how many bridges are in the distributor, but I'm not sure how trivial will be this change
16:48:02 <meskio> or just assign a lot of bridges to telegram for a bit of a time, independently if they are obfs4 or webtunnel
16:48:12 <meskio> (ratios are not tight to distributors)
16:48:34 <meskio> s/distributors/transports/
16:48:48 <meskio> I mean I can't put a big ratio just for webtunnel
16:49:57 <onyinyang> I could take a look at it if you want
16:50:11 <meskio> that will be nice
16:50:25 <onyinyang> sure :D
16:50:27 <meskio> I'll assign you the issue, thanks
16:50:32 <shelikhoo> nice~
16:51:09 <meskio> that is all from my list of topics :)
16:51:13 <onyinyang> ok, I guess that's it for discussion, we have some interesting links otherwise
16:51:20 <onyinyang> thanks meskio for your contribution lol XD
16:52:09 <shelikhoo> hahaha
16:52:30 <onyinyang> Congrats to theodorsm on the paper acceptance! :D maybe a future reading group candidate :)
16:52:39 <theodorsm> Thanks!
16:52:54 <dcf1> congratulations theodorsm
16:52:56 <meskio> yeah, nice work
16:53:07 <shelikhoo> congrats!
16:53:11 <theodorsm> Still in draft, will be camera ready by 22 june. Some stuff to adjust
16:53:22 <cohosh> congrats!
16:53:54 <theodorsm> :D
16:55:01 <onyinyang> is there anything else anyone wanted to talk about today from the interesting links or otherwise?
16:56:06 <meskio> not from me
16:57:27 <onyinyang> ok, then we just have a reminder for the reading group next week
16:57:35 <onyinyang> We will discuss "A Wall Behind A Wall: Emerging Regional Censorship in China (Henan firewall)" on June 19
16:57:35 <onyinyang> https://gfw.report/publications/sp25/en/
16:58:24 <shelikhoo> eof from me
17:00:22 <onyinyang> #endmeeting