16:00:08 <onyinyang> #startmeeting tor anti-censorship meeting
16:00:08 <MeetBot> Meeting started Thu Sep 11 16:00:08 2025 UTC.  The chair is onyinyang. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:08 <onyinyang> hello everyone!
16:00:08 <onyinyang> here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469)
16:00:15 <Shelikhoo[mds]> hi~hi~
16:00:27 <shelikhoo> hi~hi~
16:00:43 <cohosh> hi
16:00:55 <onyinyang> there are 2 shelikhoos o_o
16:01:00 <meskio> hello
16:01:24 <meskio> multiplicity of shelikhoos :D
16:01:30 <Shelikhoo[mds]> haha~ they are different pointers to the same object
16:01:39 <Shelikhoo[mds]> hahaha
16:01:47 <onyinyang> XD
16:02:31 <cohosh> lol
16:03:25 <onyinyang> ok let's get started with the first discussion point
16:03:31 <onyinyang> it seems to be a follow up from last week
16:03:52 <onyinyang> Rechecked webtunnel bridge extra info intensity(before=3011):
16:04:05 <onyinyang> I guess it's from Shelikhoo[mds]
16:04:24 <shelikhoo> yes, that's from me
16:05:04 <shelikhoo> this Monday, I have deployed the setuid script for webtunnel state migration
16:05:56 <shelikhoo> and the bridge extra info intensity for webtunnel bridges have recovered to per  breakage level
16:06:11 <shelikhoo> and I am planning to remove the setuid script in 5 weeks
16:06:15 <shelikhoo> from now
16:06:18 <shelikhoo> over
16:06:46 <meskio> sounds good
16:06:48 <onyinyang> ok, thanks for the update
16:06:48 <cohosh> thanks for the update and plan shelikhoo!
16:07:04 <shelikhoo> hehe! no problem
16:07:22 <onyinyang> there is another discussion point from meskio I think: tor#7349 and proposed changes for bridges
16:07:22 <tor> Uhm, which one of [tpo/core/debian/tor, tpo/core/tor] did you mean?
16:07:33 <meskio> it is actually from dzwdz
16:07:36 <dzwdz> \o
16:07:41 <onyinyang> ah, sorry sorry!
16:08:00 <dzwdz> i was typing up the tldr
16:08:07 <meskio> (but I did add it to the pad, so you are right gessing)
16:08:30 <dzwdz> basically - i was working on some somewhat related patches and i wondered if i could help with that issue too
16:09:14 <dzwdz> it seems (?) that the only thing preventing us from recommending bridge operators from disabling ORPorts is metrics stuff
16:10:12 <dzwdz> part of the issue is that onionoo gets the running status both from bridgestrap (which uses the actual bridge lines), and Serge (which only uses the ORPort)
16:10:56 <dzwdz> there's also another issue on DescriptorParser about it not being clear when a bridge is marked as up
16:12:08 <dzwdz> IMO the best way to handle this would be to only take bridgestrap results into account when deciding if a bridge is up
16:12:22 <dzwdz> i talked to hiro, they're willing to accept patches
16:12:30 <dzwdz> do y'all think this would be fine?
16:12:53 <meskio> yes, I think this is fine
16:12:54 <cohosh> by disabling the OR port do you mean firewalling, or a setting in the torrc config?
16:13:17 <dzwdz> iirc the recommended setup is ORPort 127.0.0.1:auto, AssumeReachable 1?
16:13:25 <dzwdz> it was in some old anticensorship meeting notes
16:13:39 <meskio> related issue: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
16:13:41 <cohosh> oh got it, that would work
16:13:48 <shelikhoo> I think removing the exposed OR port makes sense
16:13:49 <meskio> I think we should start recommending that config
16:13:53 <shelikhoo> yes, it should work
16:14:08 <meskio> bridge operators can use bridges.tpo/status to see their bridge status until metrics is fixed
16:15:06 <dzwdz> yay, i'll start working on the MR then
16:15:14 <shelikhoo> nice!
16:15:19 <onyinyang> cool, thanks for your work on this dzwdz!
16:15:35 <meskio> thank you for putting energies on this problem
16:15:45 <dzwdz> i don't really like how we're squashing the bridgestrap results into a single "reachable" boolean
16:16:01 <dzwdz> since this doesn't make /that/ much sense if you have multiple transports/addresses
16:16:24 <dzwdz> but it's good enough for now probably
16:16:48 <meskio> true, and it might be flacky if you have multiple transports, as I think it will just publish the last test
16:17:03 <meskio> bridges.tpo/status does do a bit of a better work there
16:17:20 <meskio> but we should rethink at some point this reports
16:17:47 <meskio> maybe the assignments.log are a better source, as they do include transport and not just bridgestrap but also onbasca results
16:18:03 <meskio> and also includes information on if the bridge is being distributed or not by rdsys
16:18:05 <dzwdz> is that in collector too?
16:18:09 <meskio> yes
16:18:17 * meskio searches the link
16:18:45 <meskio> https://metrics.torproject.org/collector.html#type-bridge-pool-assignment
16:19:01 <meskio> and for dual-stack bridges there should be two lines one per ip version
16:19:24 <meskio> BTW, onbasca is broken right now, so the results are ignored anyway
16:19:28 <dzwdz> onionoo's kinda dead so i want to avoid large changes though, and right now it uses the bridgestrap-stats
16:19:36 <dzwdz> also i don't think it has one line per ip version actually
16:19:40 <dzwdz> lemme check
16:19:46 <meskio> sure, let's do the simple fix, we can improve it in the future
16:19:50 <dzwdz> yup
16:20:17 <shelikhoo> compromise is often necessary...
16:20:26 <dzwdz> i just checked a few of my (dual-stack) bridges
16:20:35 <dzwdz> one only has an ipv4 line, another only has an ipv6 line
16:20:45 <meskio> ohh, this is a bug then
16:20:55 <dzwdz> curiously there are also a bunch of bridges with "ip=6,4"
16:21:13 <meskio> I'll create an issue
16:21:22 <GeKo> meskio: is there are ticket for the broken onbasca filed already?
16:21:23 <meskio> and investigate it
16:21:27 <dzwdz> only vanilla ones though
16:22:24 <meskio> BTW, collector reads bridgestrap and assignments.log once per day, but they are published every 30min, so it could have more up to date data
16:23:36 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/285
16:24:06 <dzwdz> also, the reproducible metrics for bridges need to be reworked
16:24:38 <dzwdz> apart from the Serge/bridgestrap thing, it's also measuring e.g. how many bridges have a v6 ORPort
16:25:03 <dzwdz> which is an useless statistic, it doesn't have much to do with v6 transports
16:25:54 <meskio> yep, there are many things in metrics that were general for relays and don't apply directly to bridges
16:26:02 <dzwdz> and that number will drop when we start recommending disabling ORPort / when tor!786 gets merged (because i'm making bridges default to IPv4Only ORPorts there)
16:26:02 <tor> Uhm, which one of [tpo/core/debian/tor, tpo/core/tor] did you mean?
16:26:09 <dzwdz> tpo/core/tor!786
16:26:23 <meskio> GeKo: let me look for it, is being months that is being unreliable
16:27:39 <meskio> this one is one: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/157
16:27:54 <meskio> but I think now is something more than that, I haven't investigate
16:28:05 <meskio> maybe this: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/174
16:29:48 <onyinyang> is there anything else on this topic we'd like to discuss?
16:29:57 <meskio> not from me
16:30:15 <shelikhoo> EOF from me
16:30:49 <dzwdz> one more question - does rdsys#285 mean the bridge line with the other ip version isn't distributed right now?
16:31:23 <meskio> dzwdz: that is a good question, I believe it is being distributed, but I might be wrong
16:31:31 <meskio> I'll need to look into it to know more
16:32:26 <dzwdz> hm, where did you see both my bridge lines?
16:32:30 <dzwdz> because you confirmed you were seeing both earlier
16:32:46 <dzwdz> https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/786#note_3252310
16:33:33 <meskio> dzwdz: in bridges.torproject.org/status?id=<fingerprint>
16:33:37 <dzwdz> ah, ok
16:33:54 <dzwdz> okay, that's all from me then
16:33:56 <GeKo> meskio: ack
16:34:37 <onyinyang> ok, the action item from shelikhoo was addressed earlier
16:34:42 <shelikhoo> yes
16:34:43 <onyinyang> so we have some interesting links
16:35:13 <onyinyang> a lot of interesting reports came out this week
16:35:34 <onyinyang> There was another one from Amnesty International, let me add that one too
16:36:02 <dcf1> there's a roundup of primary reporting at https://github.com/net4people/bbs/issues/519
16:36:13 <dcf1> I am working on notes on the InterSecLab report
16:36:46 <onyinyang> amazing, thanks for your ongoing work on the bbs dcf1 :)
16:37:25 <meskio> <3
16:37:41 <shelikhoo> amazing!
16:38:49 <onyinyang> maybe we could have a reading group or discussion about (some of) these reports in a future meeting
16:39:32 <onyinyang> but on that note, we do have a reading group planned for today
16:39:37 <meskio> yeah
16:39:54 <dcf1> I have not read them all yet, but "The Internet Coup" by InterSecLab is very good.
16:40:20 <meskio> yes, this might be a nice one for a reading group
16:40:41 <onyinyang> dcf1, nice, maybe we can plan for that one next
16:41:07 <shelikhoo> nice!
16:41:38 <onyinyang> so today's reading group paper is: IRBlock: A Large-Scale Measurement Study of the Great Firewall of Iran
16:41:44 <onyinyang> https://www.usenix.org/system/files/usenixsecurity25-tai.pdf
16:42:14 <onyinyang> there are some additional links to data in the pad if anyone is interested
16:42:30 <onyinyang> Does anyone want to share a summary of the paper?
16:42:38 <dcf1> (actually links to missing data)
16:43:16 <onyinyang> yes, this is why I didn't specify or post them lol >.<
16:44:17 <meskio> I can give it a try to make a summary
16:44:29 <dcf1> This paper is another in the line of GFWatch and GFWeb (which had to do with China). The angle is doing measurements on every (or nearly every) IP address in a country.
16:44:35 <meskio> or go ahead
16:46:06 <dcf1> It measures HTTP, HTTPS, DNS, and non-DNS UDP for a span of 2.5 monts.
16:47:06 <dcf1> As far as I can tell, most of it is confirmation of features that were already known about the Iran firewall, though there are some details that are new.
16:47:28 <dcf1> It uses the usual technique of external scanning and relying on the firewall to be bidirectional.
16:48:23 <dcf1> There is a trick for measuring UDP by combining a UDP probe with a DNS query
16:48:50 <dcf1> I think that's all
16:49:23 <onyinyang> thanks for the summary dcf1
16:49:36 <dcf1> There is some kind of subtlety about responsive versus non-responsive IP addresses and scanning or not scanning them, which I didn't fully understand.
16:50:24 <dcf1> It seems they do some kind of pre-filtering using Censys data (i.e., let someone else do the scanning for them), but then in 6.1 they talk about scanning every IP address for certain scans.
16:52:14 <meskio> yes, that was not clear, but I kind of understood they did avoid using responsive addresses on their full test, only in the first fase of discovering censored IPs, but I might have made it up
16:52:54 <meskio> they talk about measuring UDP, but if I understand correctly they only measure QUIC, isn't it? they said they send a QUIC Initial connection packet
16:53:54 <meskio> so if I understood correctly they found QUIC being blocked in most IPs
16:54:15 <meskio> but seeing the wide use of snowflake I assume the block only affects QUIC and not other protocols
16:55:44 <onyinyang> that was my understanding re: QUIC/UDP
16:56:28 <dcf1> This study has a larger scale (in breadth if not in time duration) than other similar studies (see Table 3 on page 16), but by my reading the additional scale unfortunately did not buy a whole lot in terms of observations. They found some significant IP addresses that are isolated and treated differently, which is great (4.1 on page 7), and they can make line graphs like Figure 4 on page 8 (which
16:56:34 <dcf1> however is a little weird because they are also changing their list of domains constantly), and Table 1 on page 10 shows interference rates in different ASNs.
16:57:39 <dcf1> I guess what I was more hoping for was an analysis of like network paths, to maybe understand the reason why some ASNs have different behavior, differences in mobile vs. residential vs. commerical networks which have been widely discussed in the context of Iran, that kind of thing.
16:58:06 <meskio> the long term study might be more interesting, to see how figure 4 changes over time when there are censorship events, 2.5 months is not that long
16:59:01 <onyinyang> dcf1, yeah I was wondering if there are already known reasons to explain the interference rates in different ASNs
16:59:01 <meskio> the isolated IPs and how they were used for cyber espionage is a fun fact
16:59:33 <cohosh> meskio: their reasoning for using quic seems to have been an assumption that quic is not yet targeted for blocking
16:59:50 <meskio> but I will be surprised if that is true
16:59:57 <cohosh> it also looks like the IPs for which quic packets were dropped correlated with IPs that were blocked for other protocols
17:00:19 <dcf1> https://gfwatch.org/ and https://gfweb.ca/ have a link to https://drive.google.com/drive/folders/1911y0-rLfTjrcoDdgKLhMj4c8rqd0Iyd, which if you sort by date, the most recent data is from 2024-11-19. But yeah, this kind of thing could provide even more insight if continued for a long period.
17:00:57 <meskio> cohosh: true, but if QUIC was not specifically blocked, what are they claiming? that 6M IPS have all UDP packets being dropped? this doesn't seem to be true
17:01:05 <cohosh> i also think it's a big leap to have made, but i wouldn't necessarily take snowflake's success to mean that it's specifically quic blocking either
17:01:07 <onyinyang> is it a matter of paying more for censorship-free connections or is it a possibility that the apparently less restrictive ASNs will employ censorship somewhere else down the line?
17:01:32 <cohosh> yeah the claim is a leap from what they measured
17:02:12 <dcf1> One significant change here is TCP handshake statefulness, page 4, which is a distinct difference from what has been measured as recently as 2020.
17:03:04 <meskio> yes, I found that weird, why will they add state to the HTTP filtering? it looks like extra work and I can't imagine what you gain
17:04:35 <dcf1> It could just be that they replaced one piece of hardware with another, and that's what it does by default.
17:05:54 <shelikhoo> or maybe a software update... something like that
17:05:55 <dcf1> I'm wondering if this discovery that so many national firewalls are operated by Geedge (not Iran, mind you) might be a blessing in disguise, as now that we know some of Geedge TSG's behavioral characteristics (such as the ability to switch between mirrored mode and in-line mode), we might be able to develop remote measurements specifically taking advantage of them.
17:06:26 <dcf1> shelikhoo: yeah or maybe a bug fix, like maybe it was supposed to be stateful the whole time but there was a wrong "if" statement somewhere.
17:06:50 <meskio> but the latest paper we read was claiming that not all censored sites they found were bidirectional
17:06:56 <cohosh> there was this paper on UDP blocking in Iran from 2021 https://censorbib.nymity.ch/#Elmenhorst2021a
17:07:31 <cohosh> it's old but in section 5.2 they have this line:
17:07:34 <cohosh> Thus, we believe that censors have deployed middle box soft-
17:07:36 <cohosh> ware, which applies IP address filtering only to UDP traffic
17:08:16 <cohosh> sorry, the paper was on quic censorship, but that was their conclusion
17:08:59 <dcf1> meskio: that's right, there was some post-facto questions about the Turkmenistan (TMC) study and whether what they measured actually matched what you would get from direct measurement in the country, something like that?
17:09:25 <meskio> I think it was in the china regional censorship paper
17:09:37 <meskio> they mentioned finding some websites being censored non-bidirectional
17:10:20 <dcf1> meskio: oh right, that too.
17:10:23 <dcf1> I was thinking of
17:10:25 <dcf1> https://ntc.party/t/testers-wanted-to-validate-external-censorship-measurements-in-turkmenistan/5249
17:10:31 <dcf1> https://ntc.party/t/measuring-and-evading-turkmenistan%E2%80%99s-internet-censorship-a-case-study-in-large-scale-measurements-of-a-low-penetration-country/4902/3
17:11:01 <meskio> (ntc.party has move to IPv6 only, and now I can only access it from tor :)
17:11:18 <shelikhoo> okay, I was thinking why I could not open it...
17:11:37 <dcf1> oh haha, it's possible I have never tried to access it without tor
17:11:59 <dcf1> https://tmc.np-tokumei.net/filtered_ips seems to have stopped updating data on 2024-06-28.
17:12:01 <meskio> I recall some announcement about it, but I forgot the details
17:13:26 <onyinyang> we're almost 15min over time, do we have any concluding thoughts on the paper or anything else we'd like to discuss?
17:14:02 <shelikhoo> EOF from me
17:14:18 <meskio> I think the most important things were said
17:14:45 <meskio> let's see if they keep measuring
17:14:56 <meskio> and if their website starts working at some point
17:15:58 <onyinyang> ok, thanks for the discussion today everyone!
17:15:59 <onyinyang> #endmeeting