16:00:26 #startmeeting tor anti-censorship meeting 16:00:26 Meeting started Thu Aug 29 16:00:26 2024 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:30 hello everybody! 16:00:32 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 16:00:34 ask me in private to give you the link of the pad to be able to edit it if you don't have it 16:00:36 I'll wait few minutes for everybody to add you've been working on and put items on the agenda 16:00:56 hi~ 16:02:11 hello i/ 16:02:15 um. . .o/ 16:02:58 u/ 16:03:16 I guess we can start 16:03:20 lol 16:03:24 we have a single discussion point in the agenda: 16:03:31 what to do with moat bridges once we turn off BridgeDB? 16:03:51 my plan is to switch BridgeDB off monday September 9th 16:04:03 once we do that rdsys will stop distributing moat bridges 16:04:22 I guess bridge operators will not see the difference for weeks, as users might stay using them 16:04:31 but gradually they will stop being used 16:04:40 should we hold those bridges for a while? 16:05:02 should we reassign them to the settings distributor? (which is also used by the moat API in rdsys) 16:05:07 should we assign them to lox? 16:05:21 I think we should hold them for a bit, but not sure how long that bit should be 16:05:34 but maybe is something we could monitor 16:05:39 I don't understand. Are the moat bridges now being used exclusively for moat, or were they also given to bridgedb requesters? 16:06:09 moat bridges are used exclusivelly by moat (the request bridge button in Tor Browser) 16:06:25 when we make the switch the request bridge button in Tor Browser will get settings bridges 16:06:34 and those moat bridges will not be distributed anymore 16:06:37 does it make sense? 16:06:51 Okay. So the existing moat bridges will have no new users, only the users they have already. 16:07:02 exactly 16:07:14 But you are talking about, in the future, reassigning them to some other pool where they will get new users. 16:07:36 I'll check that rdsys doesn't assign new bridges to that distributor once we do the deployment 16:07:46 yes, I'm asking if in the future we should reassign them 16:08:17 I think we could reassign them in the future 16:08:48 I can monitor metrics to see how usage goes down 16:08:49 let's say hold them in reserve for 30 days, and then let these bridges find a new home 16:08:53 and we can see in the future 16:09:50 this is a balance of making sure the user do not lost their recently got bridge to a more attacked distribution method, and make bridge useful over all 16:10:34 although I am unsure whether we could do this based on changing the config 16:10:38 yes, maybe we can decide on how long seeing how many users are still using them 16:10:58 this is a bit of a side-track, but the request bridge button will also no longer server a captcha with the change right? 16:11:36 it will serve a captcha, because Tor Browser hasn't updated yet, but the captcha is a dummy one 16:11:43 and any answer will be accepted as valid 16:12:27 shelikhoo: not just with the config, but rdsys does store assignments in a json, I can modify that json... 16:12:42 yes... that's nice 16:13:05 it would be possible if we wants to do it 16:13:24 cohosh: the catpcha: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/pkg/presentation/distributors/moat/captcha.jpg?ref_type=heads 16:13:48 and the discussion about it: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/182 16:13:56 oh nice, thanks 16:15:50 I'll keep an eye to see how much the usage of moat bridges decline, so we can make a decision in the future on when to move them 16:16:06 yes, nice! 16:16:11 I guess it might make sense to move them to the settings distributor, as not moving burned bridges to lox 16:16:17 but we can also change our mind 16:16:58 my plan is to communicate that to tor-relays once the switch is done 16:17:05 so operators are not surprised by it 16:18:15 anything more on this topic? or any other discussion topic? 16:18:37 eof on all topics 16:18:57 should we pick our next paper to read? 16:19:17 we were talking that maybe SpotProxy paper is worth reading: https://censorbib.nymity.ch/#Kon2024b 16:19:25 as we might want to use that project or ideas in the future 16:19:28 what do you think? 16:19:57 yes. let's add it to our reading to do list 16:20:59 sounds good 16:21:18 cool, we have a paper, in two weeks? september 12? 16:21:24 sounds great :) 16:22:09 cool, anthing else for today? 16:22:28 eof 16:23:15 then, I'll close the meeting 16:23:18 #end-meeting 16:23:29 #endmeeting