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