15:57:55 <shelikhoo> #startmeeting tor anti-censorship meeting
15:57:55 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:57:55 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:57:55 <MeetBot> Meeting started Thu Jun 22 15:57:55 2023 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:55 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:57:59 <shelikhoo> Hi~
15:58:08 <onyinyang[m]> hello!
15:58:27 <shelikhoo> I have try to precisely time my message
15:58:39 <meskio> hello
15:58:50 <shelikhoo> so that the meeting starts at exact second
15:58:55 <meskio> pretty accurate timing :)
15:59:00 <shelikhoo> to a varying level of success
15:59:03 <shelikhoo> hahaha
15:59:14 <meskio> nerding the meeting start time....
15:59:45 <shelikhoo> hahaha yep
16:01:57 <onyinyang[m]> lol i support this XD
16:02:23 <meskio> do I need to write a bot to be precise on time
16:02:55 <shelikhoo> I did this manually... this is just a minigame so don't spent big chunk of time...
16:03:14 <meskio> XD
16:04:53 <shelikhoo> anything more update to the pad? let's start the meeting unless more time is still needed
16:05:55 <meskio> not from me
16:06:05 <shelikhoo> okay, let start the discussion of the first topic:
16:06:06 <shelikhoo> support non-public ORPort bridges by ignoring the running flag in rdsys
16:06:06 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/134
16:06:06 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/154
16:06:13 <shelikhoo> I think this is from meskio?
16:06:38 <meskio> yes, is me
16:07:03 <meskio> currently we don't support bridges without ORPort publicly available
16:07:43 <meskio> even though obfs4 bridges don't need to have the ORPort reachable for normal functionality
16:08:11 <shelikhoo> the same goes to webtunnel, I think in general it is not needed for pluggable transport to work
16:08:25 <meskio> having the ORPort reachable opens a door to active attackers to discover the bridge by proving all the ports and testing if the open port is actually tor
16:08:41 <meskio> so many bridge operators have being complaining about it
16:09:22 <meskio> AFAIK the main reason why we want(ed) the ORPort reachable is because the bridge authority tests that the bridge is actually running by connecting to it
16:09:44 <meskio> if the authority manages to reach the port it sets the 'running' flag
16:09:58 <meskio> and we use that flag in rdsys to only distribute bridges with it
16:10:11 <meskio> but we also test bridges ourselves in rdsys with bridgestrap and onbasca
16:10:28 <meskio> so we don't really need to rely on the bridge authority test
16:10:35 <meskio> all that long text to say:
16:10:44 <meskio> I'm proposing to ingore the running flag in rdsys
16:10:56 <onyinyang[m]> so is it correct to say that the RunningFlag is a proxy for whether a bridge is private or not?
16:10:58 <meskio> and I'm asking here to see if I'm missing some caveats if we do that
16:11:18 <dcf1> sounds great to me
16:11:47 <shelikhoo> Yes, I think OR port is just a way for Tor client without valid PT to communicate with the bridge
16:12:02 <dcf1> i seem to remember metrics uses fraction of Running for something, so if we start making it easier to run bridges without Running, we will want to make sure not to disturb that
16:12:28 <meskio> BTW, a bridge with an unreachable ORPort will be rejected by the bridge authority unless the torrc AssumeReachable flag is set, so it requires some manual configuration...
16:13:06 <shelikhoo> I think expose OR port have overwhelming disadvantage, so we should allow bridge operator to not do that
16:13:19 <meskio> dcf1: we use a fraction of running in rdsys to ignore bridge update that don't have enough running bridges, as when rdsys restart all bridges miss the running flag
16:13:20 <dcf1> https://metrics.torproject.org/reproducible-metrics.html#bridge-users
16:13:24 <meskio> but there might be somethine else in metrics
16:13:28 <meskio> I'll check with them
16:13:44 <hiro> yeah do let me know if we need to plan for a change
16:14:05 <hiro> the running flag is already "controversial" so to speak so we might think of something else altogether
16:14:19 <meskio> onyinyang[m]: I'm not sure I understand what you mean, a private bridge could not have ORPort exposed as they don't care to distribute it over rdsys
16:14:20 <dcf1> seems like bridges without Running just get ignored for metrics purposes, according to the reproducible metrics guide
16:14:54 <meskio> hiro: we can report in the assigments.log our results from bridgestrap and onbasca to know if the bridge is running
16:15:05 <meskio> or did metrics already get results from bridgestrap directly?
16:15:24 <hiro> we get the  bridgestrap tests
16:15:42 <meskio> ahh, cool, I expect those to be way more accurate than the running flag
16:15:43 <hiro> and use those to know if the bridge is reachable
16:16:03 <hiro> but we still use the runing flag too
16:16:09 <hiro> so maybe it is a matter to review all these rules
16:16:11 <onyinyang[m]> meskio: I meant does the RunningFlag indicate a private bridge
16:16:38 <onyinyang[m]> proxy is probably not a good word to use for anything other than a network related proxy in this group ^-^;
16:16:52 <meskio> onyinyang[m]: the running flag only indicates that the bridge authority has managed to connect to the ORPort
16:18:33 <meskio> hiro: I agree we should review all these rules, let me know if I can help there
16:18:55 <shelikhoo> It is being used at a lot of place, and some of them might be unintended...
16:19:25 <hiro> meskio we should start logging a ticket. I'll log one later and tag you in it
16:19:44 <shelikhoo> The good thing is I believe it would be easy for us to update our usage this data
16:19:55 <shelikhoo> since it does not require client or proxy side update
16:20:09 <meskio> hiro: thank you
16:20:40 <meskio> I understand the running flab might be pretty useful for relays, but for bridges not so much
16:21:25 <onyinyang[m]> meskio: ok, makes sense. It doesn't necessarily indicate anything. I was thinking that private bridges were less likely to expose the ORPort and so a lack of runningflag would indicate a private bridge (and running flag would indicate the opposite)
16:21:31 <onyinyang[m]> but I see this is not necessarily the case
16:22:01 <shelikhoo> a private should have distribution = none
16:22:18 <shelikhoo> which means it does not wish to be distributed over rdsys
16:22:47 <shelikhoo> I think this would be a better way to find out if a bridge is a private one
16:23:06 <meskio> onyinyang[m]: I see now, a private bridge could be configured to don't be shared in the bridge descriptors, so not even appear in metrics, but if they appear there they are clearly indicated by a 'distributor: none'
16:23:11 <shelikhoo> "BridgeDistribution none"
16:23:23 <meskio> ups, I see shelikhoo was faster than me...
16:23:48 <onyinyang[m]> yeah, I'm not arguing that it should be any particular way. I was just wondering
16:23:48 <shelikhoo> no no no, I just often send incomplete sentence just to be faster
16:23:57 <onyinyang[m]> sorry if it caused confusion >.<
16:23:58 <shelikhoo> and regard sending it 2 sec later
16:24:13 <shelikhoo> (just did so)
16:24:23 <onyinyang[m]> lol
16:24:41 <shelikhoo> okay, anything more we wants to discuss about this topic?
16:25:01 <onyinyang[m]> but yes, it seems more reasonable to have distribution=none as the indicator for private/not
16:25:02 <meskio> cool, so let's ignore the running flag, and anyway we'll have some time until bridge operators start doing that to catch up on the metrics side
16:25:20 <meskio> nothing more from my side
16:26:39 <onyinyang[m]> nothing from my side either
16:26:44 <shelikhoo> anything more we would like to discuss in this meeting
16:27:22 <shelikhoo> BTW, we have a bridge operator meetup this Saturday, and it is not required to attend at all
16:27:47 <shelikhoo> wait one more min....
16:28:47 <shelikhoo> okay thanks! no need to keep everyone here
16:28:47 <shelikhoo> #endmeeting