15:58:26 <itchyonion> #startmeeting tor anti-censorship meeting 15:58:26 <MeetBot> Meeting started Thu Feb 23 15:58:26 2023 UTC. The chair is itchyonion. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:37 <itchyonion> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:37 <itchyonion> feel free to add what you've been working on and put items on the agenda 15:58:42 <itchyonion> hello 15:59:21 <meskio> hello 16:01:04 <itchyonion> The first topic on the pad "What is the status of activating the snowflake-02 bridge in Orbot?" I believe is something we discussed last week. We planned to have another discussion next week. 16:01:19 <meskio> this is a left over from last week 16:01:27 <meskio> I see dcf is not around 16:01:34 <meskio> I don't think there is any news here 16:01:38 <itchyonion> OK. Moving on to the next one 16:02:00 <itchyonion> The second topic: forking obfs4proxy, a new name? 16:02:00 <itchyonion> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/40010 16:02:08 <meskio> I added that one 16:02:28 <meskio> I believe we already talked about this in the past 16:02:43 <itchyonion> yes 16:02:46 <meskio> obfs4proxy upstream doesn't want to integrate some changes we need, basically the use of uTLS in meek 16:02:53 <meskio> we need to fork it 16:03:11 <meskio> we've being discussing names for the fork 16:03:27 <meskio> obfs4proxy is a confusing name, as the program is used for more things than obfs4 16:03:41 <meskio> and we might want to add other PTs to it in the futurue 16:04:17 <itchyonion> Sounds good. If anyone has anything to add feel free to do so in the ticket 16:04:19 <meskio> one proposal from micah is to call if lyrabird, a bird that can imitate sounds from other birds or many crazy things like car alarms... 16:04:30 <meskio> I'm happy to hear about other names for it 16:04:49 <meskio> I think it makes sense to come up with a completelly new name, but that is part of the discussion 16:04:52 <onyinyang[m]> that name seems appropriate and memorable 👍️ 16:05:00 <meskio> we could just call it obfs4proxy-ng or something like that 16:05:30 <meskio> cool 16:05:38 <itchyonion> Shall we move on to the next topic? 16:05:51 <meskio> feel free to talk in that issue 16:06:04 <itchyonion> The third topic is: rdsys is using onbasca to measure bridge bandwidth 16:06:07 <meskio> if we have an agreement with lyrabird I'll move on with the fork in a couple of weeks 16:06:10 <meskio> EOF 16:06:17 <meskio> ahh, that one is also me 16:06:42 <meskio> onbasca is the relay bandwith scanner 16:06:51 <meskio> https://gitlab.torproject.org/tpo/network-health/onbasca/ 16:07:00 <meskio> I've being integrating it into rdsys 16:07:06 <meskio> there is a merge request with the integration code 16:07:26 <meskio> the idea for now is to run it in parallel with bridgestrap (wich test if a bridge is reachable) 16:07:50 <meskio> and use the results of both if the are ok (if at least 50% of the bridges are good on them) 16:07:52 <shelikhoow> Does it actually send significant traffic?(impact other services on the same host/network) 16:08:11 <meskio> shelikhoow: I don't know much about the details, but I doubt so 16:08:25 <meskio> juga: if you are round? maybe can chim in here 16:08:32 <shelikhoow> Yes.. 16:08:59 <meskio> I have already deployed both onbasca and the modified rdsys, sorry for not waiting for the code review, as this needs to be delivered for a sponsor 16:09:16 <meskio> I will write a survival guide 16:09:28 <meskio> and send an email to our mailing list with instructions on how to roll back if this gives problems 16:09:33 <meskio> as I will not be around next week 16:10:07 <meskio> I've tested it as much as I could, and I don't expect problems 16:10:18 <meskio> but you never know... 16:10:57 <shelikhoow> It should be fine so long as the rollback works... 16:11:18 <meskio> my rollback plan is leaveing the previous binary in the server and replace the new with it 16:11:25 <meskio> there is no more needed changes :) 16:11:37 <meskio> the changes in the config file are backward compatible 16:11:55 <meskio> previous binary of the rdsys backend 16:12:58 <shelikhoow> Yes... 16:12:59 <meskio> for now rdsys is not doing much fancy things with onbasca, it gets a ratio on how fast is the bridge and has a configured threashold 16:13:02 <shelikhoow> Yes... 16:13:19 <meskio> if the ratio is below the threashold it doesn't distribute the bridge (as long as there is enough bridges with high ratio) 16:13:33 <meskio> but maybe in the future we can do more clever things 16:13:59 <itchyonion> Sounds good. Anything more on this topic? (p.s. I added an action item for the survival guide) 16:14:10 <meskio> thanks 16:14:13 <shelikhoow> (don't worry too much about shell's unreliable network... Shell is in transit...) 16:14:16 <meskio> nothing more from me 16:14:22 <shelikhoow> EOF 16:14:24 <meskio> but I have another related topic 16:14:39 <itchyonion> yes please 16:15:04 <meskio> bridgestrap is failing since yesterday 16:15:10 <meskio> or is it two days ago? 16:15:33 <meskio> anyway, it is reporing most of the bridges as non-functional, only 30% of functional bridges... 16:15:47 <meskio> it looks similar to an issue we already have in the past: 16:16:04 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/7 16:16:27 <meskio> but that issue was solved in c-tor, and we are using a tor version high enough 16:16:48 <meskio> I will keep investigating, but I might not find the problem before I leave for vacation next week 16:16:57 <meskio> I'll do my best to document what I know 16:17:06 <meskio> but is not a big deal if is broken until I come back 16:17:28 <meskio> rdsys ignores bridgestrap results if there is not at least 50% of functional bridges 16:17:41 <meskio> so right now rdsys is ignoring the results 16:18:01 <meskio> the only problem is that it might be distributing bridges that are not reachable, but hopefully those are few 16:18:16 <meskio> and anyway a year ago we didn't test if bridges were functional before distributing them 16:18:48 <meskio> what I mean is, if you see an alert saying that bridgestrap is failing is ok to don't act on it while I'm away 16:19:08 <meskio> but if you feel like investigating it I'm happy if someone solves the problem :) 16:19:33 <itchyonion> All makes sense 16:20:11 <onyinyang[m]> this looks interesting. Does the integration into rdsys help determine which resources are most appropriate for distributing (based on available bandwidth at the time)? 16:20:29 <meskio> kind of 16:20:45 <meskio> onbasca gives a ratio of how fast is a bridge compared to all the others 16:21:00 <meskio> 1 is the median 16:21:15 <meskio> rdsys will not distribute bridges with ratio below 0.75 16:21:29 <meskio> I wonder if we'll need to tune that and lower that number 16:21:46 <meskio> onyinyang[m]: am I answering your question? 16:23:49 <itchyonion> How was bridge distribution managed before onbasca integration? 16:23:57 <onyinyang[m]> meskio: I think so, sorry my matrix client had a meltdown so I got out of sync. I will catch up now 🤦 16:24:32 <meskio> :) 16:25:01 <meskio> itchyonion: before onbasca we only used bridgestrap, so we decided if distributing a bridge or not just based on if the bridge works or not 16:25:34 <meskio> now we'll try to use the bandwidth of the bridge as well, but for now just to decide if we do distribute a bridge or not 16:26:00 <itchyonion> Sounds like a nice improvement 16:26:13 <itchyonion> Anything more on this topic? 16:26:26 <meskio> we might want to give more often a bridge depending on the bandwidth of the bridbe, but that sounds complicated to prevent bridge listing, so it might be a bad idea 16:26:37 <meskio> we need to give it more thinking 16:26:44 <meskio> that is all from me 16:27:26 <itchyonion> Moving on to interesting links: https://explorer.ooni.org/chart/mat?probe_cc=IR&since=2023-01-20&until=2023-02-20&time_grain=day&axis_x=measurement_start_day&test_name=web_connectivity&domain=cdn.sstatic.net 16:27:26 <itchyonion> continued sporadic blocking of cdn.sstatic.net in Iran 16:27:52 <itchyonion> i think this is related: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40068 16:28:26 <meskio> yes, is scary as we do depend on that domain for both snowflake and moat 16:28:42 <ggus> i can see a drop on snowflake usage in IR (feb 21): https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-11-25&end=2023-02-23&country=ir 16:28:59 <meskio> but the good thing is that they don't seem to be willing to sustain that blockade for long 16:29:01 <shelikhoo> I think we have an existing effort to find a replacement domain 16:29:14 <meskio> we need to move the ampcache snowflake fallback forward 16:30:00 <shelikhoo> Yes... Even if they lifted the block later this time... 16:30:10 <shelikhoo> Does moat work over amp? 16:30:23 <shelikhoo> I think in theory it should be able to work 16:30:37 <shelikhoo> But we don't have a existing tool to do that? 16:30:45 <meskio> we don't have an implementation for moat over amp 16:30:48 <meskio> we should work on that 16:31:08 <meskio> there was that idea from arma2 to create a generic library for domain fronting, amp and so 16:31:16 <meskio> so we don't need to reimplement it on each project 16:31:42 <meskio> I wonder if that could be part of lyrabird/obfs4proxy or a separate project 16:31:46 <meskio> but we should move that forward 16:32:09 <shelikhoo> Yes... I was working on something like that in V2Ray, FYI 16:32:28 <shelikhoo> (it will be named request transport) 16:32:51 <meskio> ohhh, nice, maybe something we could use? 16:33:49 <shelikhoo> At least I will have experience on these kind of things. We can begin the discussion first... 16:34:37 <shelikhoo> The issue with V2Ray is that it would need a code review to be used... which would be costly consider its complexity 16:35:02 <itchyonion> Is there a ticket for ampcache snowflake fallback? 16:35:30 <shelikhoo> There is a team red lab from OTF that claims to provide no out of pocket money audit 16:35:40 <shelikhoo> But I was unsure how that works. 16:35:50 <meskio> itchyonion: yes, there is, let me find it 16:35:51 <shelikhoo> So the answer is let's see... 16:36:26 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250 16:36:42 <meskio> shelikhoo: I see, so the library is not an idepent library, but part of v2ray 16:37:05 <meskio> but your experience there will be really handy to create our own, yes :) 16:40:26 <meskio> I don't have anything else on this topic 16:40:41 <shelikhoo> Yes... I don't have it yet... It is work in progress... (The first part will be meek like) 16:42:38 <shelikhoo> EOF 16:43:37 <itchyonion> I'm reading https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115 looks like it's been like this for a while 16:43:49 <itchyonion> Added an action item to the pad 16:44:03 <meskio> thanks 16:45:10 <itchyonion> Reminder: We will have reading group discussion on March 9th 16:45:40 <itchyonion> I think that's all for today 16:46:03 <itchyonion> #endmeeting