16:00:00 #startmeeting tor anti-censorship meeting 16:00:00 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 16:00:00 editable link available on request 16:00:00 Meeting started Thu May 9 16:00:00 2024 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:05 hi~ 16:00:11 hello 16:01:38 cohosh: ah, so is there something else pending to get fixed after tpo/anti-censorship/pluggable-transports/snowflake-webext#93 ? 16:01:53 yeah there is a broken link 16:02:01 to the privacy policy 16:02:05 well, a link that never worked 16:02:06 oh privacy policy link, got it, thanks 16:02:55 I think the pad have been mostly updated, I think we can start with first topic 16:02:56 should we start assigning/distributing webtunnel bridges in the settings pool? 16:02:56 https://gitlab.torproject.org/tpo/web/community/-/issues/348#note_3026653 16:03:02 this is me 16:03:05 I think this one is from meskio 16:03:06 yes 16:03:25 we've being distributing webtunnel bridges over the HTTPS distributor for a while 16:03:33 and they seem to have being useful in some cases for people 16:03:53 we might want to start collecting bridges in the settings pool also, so we can use them if needed there 16:04:34 I'm planning to deploy the rdsys bridge storage next week, so rdsys will keep in disk the assignments of each bridge 16:04:50 I think webtunnel is ready, especially once the the one in LBird have proxy and utls support 16:04:58 I thought after that I could configure it to start collecting webtunnel bridges into the settings pool also 16:05:08 so existing bridges don't shift, but we have newer ones going there too 16:05:41 shelikhoo: nice, I agree, let's move it to the next phase then :) 16:05:48 yes! 16:06:36 anything more we wish to discuss on this topic? 16:06:50 not from me, just checking that my proposal makes sense 16:06:58 Reports that our CDN 77 front domains are blocked in Russia? 16:06:58 https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-115.11.0esr-13.5-1/browser/app/profile/000-tor-browser.js#L110 16:07:14 I think this is from cohosh? 16:08:02 not sure how active is cohosh, as was busy with another meeting at the same time 16:08:29 someone has reported in #tor-anticensorship that .ru is starting to block the SNIs that we use for domain fronting 16:08:29 I have see the report as well that right now there is a ISP in russia blocking the SNI we are using for snowflake and moat 16:08:45 looks like one ISP only for now 16:08:58 but that might be a problem 16:10:01 cdn77 is a smaller provider, so it may provide insufficient protection against "screw it" censorship 16:10:09 nina13[m]: have you heard any reports of snowflake or moat/circumvention settings not working in .ru recently? 16:10:36 where collateral damage is ignored 16:10:51 There is a few way we could bypass this 16:11:04 like having vastly more fronted domains 16:11:17 and if one is no longer working, switch to another one 16:11:39 in this way there won't be a few domains to just block 16:12:12 with the ability to store the fronting domain last used, this will not create a lot of delay in finding the domain that works 16:12:30 we currently support more than one fronting domains 16:12:43 but we are yet to support store the last fronting domain worked 16:12:56 and this have limited our ability so ship a lots of fronting domain 16:13:12 also the size of the bridgeline does limite it 16:14:04 yes... 16:14:29 it is more or less an artificial limitation 16:14:41 but yes 16:15:05 so do we wants to take any action here? 16:15:14 I guess we can wait to hear more confirmation on the problem, but we might want to start collecting alternative domain names 16:16:07 yes, I agree, get more info about this, and start preparing for another switch 16:16:42 now is the time for interesting links! 16:16:43 https://petsymposium.org/popets/2024/popets-2024-0027.php 16:16:43 Communication Breakdown: Modularizing Application Tunneling for Signaling Around Censorship 16:16:43 "The Raceboat framework simplifies using signaling channels for low-bandwidth and/or latency-tolerant tasks like bridge distribution and authentication. ... We also have a suite of non-decomposed channels that have been wrapped to support the Raceboat channel APIs. These include wrappers around several higher-bandwidth direct channels (Obfs, Snowflake, and Balboa)..." 16:16:43 (NB the demonstration application is using Obfs and Snowflake as a rendezvous channel, not providing a rendezvous channel for them. 16:17:08 this paper will be at the PETS conference in 2 months' time 16:17:50 I only skimmed it, but apropos of rendezvous, it looks like it's about modularizing rendezvous techniques, and it suggests a few new ones 16:18:35 yes, I have talked with the authors in the past, but at the time they didn't have much published 16:18:43 will be nice to read the paper 16:18:47 there is 2 thing we can look for; 1. the design of pluggable signaling channel 2. new design of signaling channel 16:18:54 should we schedule a reading group? is being a while 16:18:56 will have a read of paper later 16:19:04 oh yes... 16:19:37 we have a reading group at may 30 16:19:41 or alternatively 16:19:50 we have the reading group at in person meeting 16:19:57 may 30 sounds good 16:20:12 I assume we'll be too busy in the in person meeting to do the reading group 16:20:23 oh, that's for sure 16:20:55 speaking of the in person meeting 16:21:04 here is an announcement: No meeting May 23, we are at the tormeeting 16:21:12 "nina13: have you heard any..." <- I'm sorry for being late - but no. Though still most of the user prefer bridges (obfs4 or webtunnel) 16:21:40 repeat: No meeting May 23, we are at the tormeeting 16:21:40 nina13[m]: thank you, let us know if you hear anything, as some people say that some ISPs might be blocking our domain fronting 16:22:11 thanks nina13[m] ! 16:22:26 okay anything more we would like to discuss in this meeting? 16:22:32 not from me 16:22:44 meskio: sure, I'll keep an eye on this issue 16:23:42 #endmeeting