15:59:35 <meskio> #startmeeting tor anti-censorship meeting
15:59:35 <MeetBot> Meeting started Thu May 19 15:59:35 2022 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:37 <meskio> hello everybod
15:59:40 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:47 <meskio> feel free to add what you've been working on and put items on the agenda
16:00:22 <cohosh> hey!
16:00:30 <shelikhoo> hi~
16:00:40 <itchyonion> hello
16:01:23 <meskio> I kept from previous week the point about snowflake fingerprinting, just in case we have something else to talk about it
16:01:31 <meskio> is there anything new on that front?
16:02:14 <dcf1> valdikss confirmed the reported blocking patterns with the different offsets of supported_groups, but says Snowflake works anyway
16:02:35 <dcf1> it's a good idea for someone to do a packet capture of the snowflake-client in current Tor Browser and see what our offsets are
16:02:56 <anadahz> (hi!)
16:03:08 <dcf1> it's possible that the rule affects old versions of the standalone proxy that have not upgraded lately, or maybe the rule is not targeted at snowflake at all
16:04:24 <meskio> is my understanding that if is blocking old versions a client hitting a proxy with an old version will retry connecting to another proxy and at some point will hit one that is not blocked?
16:04:38 <meskio> so this might be only slowing the bootstrap
16:05:52 <dcf1> that may be so
16:07:11 <dcf1> for our own due diligence we should find out what our own offset is
16:07:31 <meskio> make sense
16:07:35 <dcf1> and remember that the side that sends the Client Hello may be either the snowflake client or the snowflake proxy, so it may be necessary to try a few times
16:07:57 <shelikhoo> yes, the question i would like to insert here is that do we have a tool to bisect which part of traffic trigger the censorship?
16:08:43 <dcf1> 2022-03-02 there was a report of WebRTC in Chrome not working, perhaps this is related
16:08:47 <dcf1> https://ntc.party/t/ooni-reports-of-tor-blocking-in-certain-isps-since-2021-12-01/1477/140
16:09:53 <dcf1> I don't know of such a tool.
16:10:07 <dcf1> A long time ago, OONI Probe had a module called daphn3 that did such bisection.
16:12:17 <shelikhoo> yes... such a tool would be quite helpful
16:12:34 <anadahz> re: daphn3 https://github.com/OpenObservatory/ooniprobe-debian/blob/master/ooni/kit/daphn3.py
16:13:06 <anadahz> and an old presentation from hellais https://speakerdeck.com/hellais/ooni-and-daphn3
16:13:56 <shelikhoo> yes... thanks, I will investigate it later
16:14:27 <meskio> cool, anything else on this topic
16:14:31 <meskio> ?
16:15:20 <meskio> next topic is mine
16:15:55 <meskio> polyanthum (where bridgedb, rdsys, bridgestrap and some others lives) got upgraded yesterday to debian bullseye
16:16:23 <meskio> I think everything is working fine except for bridgestrap prometheus metrics
16:16:53 <meskio> basically is saying that there is no functional bridges in the metrics, but answering to rdsys with functional ones
16:16:57 <meskio> I'll investigate it
16:17:26 <meskio> anyway, if anybody sees any problem with bridgedb please poke me and I'll investigate
16:17:44 <meskio> can we move to the next topic?
16:18:01 <dcf1> shelikhoo: oh and Geneva is a possibility as well https://geneva.cs.umd.edu/
16:18:34 <meskio> MCH2022
16:18:37 <anadahz> Is anyone going to attend MCH2022 (https://mch2022.org/)?
16:18:45 <meskio> I was not planning to attend
16:18:59 <meskio> anadahz: will you be there?
16:19:12 <shelikhoo> dcf1: Yes!  thanks! thanks for reminding me this
16:19:33 <meskio> I think there are some tor people going there, but I don't think anybody from the anti-censorship team
16:19:33 <anadahz> meskio: That's what I'm trying to find out. But will be interested in setting up an anti-censorship tent if other people join.
16:19:58 <meskio> nice
16:20:12 <anadahz> meskio: let's chat after the meeting/later
16:20:19 <meskio> cool
16:20:27 <meskio> anything else to talk about today?
16:20:34 <meskio> shoudl we move to the reading group?
16:21:00 <meskio> Understanding the Impact of Encrypted DNS on Internet Censorship, ACM WWW 2021
16:21:02 <meskio> https://shhaos.github.io/papers/www21-DoE.pdf
16:21:21 <meskio> the paper looks into two things related to encrypted DNS:
16:21:41 <meskio> * censorship on DoH/DoT providers
16:22:00 <meskio> * if DoH/DoT will work as censorship circumvention
16:22:47 <meskio> it looks like most of the hits they found on censorship on DoH/DoT is related to providers blocking adds or providing 'safe/non-porn' content
16:23:47 <meskio> for me is interesting to see that many famous DoH/DoT providers are already blocked in China and Iran
16:24:34 <shelikhoo> Practically speaking, DoH make blocking DNS an all or none thing
16:24:40 <anadahz> (dcf1: in case you haven't seen it yet, a new tool that could replace ooni-sync -- https://pypi.org/project/oonidata/)
16:25:08 <shelikhoo> But since DNS often just fallback to unencrypted dns
16:25:24 <shelikhoo> There is no consequences for blocking DoH
16:27:11 <meskio> yes, wich makes me how useful will be dnstt as PT if we want to use public DoH providers, I think censors will just block them
16:29:05 <meskio> another interesting thing of the paper is to see how SNI based blockade is common outside the tipical countries, here Denmark and US
16:29:06 <itchyonion> I like how they take into account DNS load-balancing when deciding if a resolver is doing DNS manipulation.
16:31:21 <shelikhoo> Yeah. That is also the reason why I often use relative term to describe amount of censorship
16:31:26 <shelikhoo> Rather than no censorship
16:31:44 <shelikhoo> I would often prefer 'less censorship'
16:31:50 <meskio> +1
16:32:41 <meskio> I guess most of the content of the paper is what we expect, but I'm happy people did look into it metodically
16:33:14 <shelikhoo> yes
16:34:16 <itchyonion> the paper says OONI's DNS manipulation detection is inaccurate. Is this confirmed?
16:34:36 <anadahz> meskio: Blocking of DNS resolvers hasn't been happening a lot lately. Not sure why but this wasn't the case in many large scale "network disruptions".
16:35:40 <anadahz> itchyonion: They cite an old paper, OONI has advanced a lot the web connectivity test since then.
16:35:52 <meskio> itchyonion: I don't know the details, but I expect they are right, the research on the paper did a lot of steps to validate if the DNS response is valid and I will be surprised if OONI does half of those
16:36:07 <itchyonion> ah cool. I also see there is a note in https://ooni.org/nettest/dns-consistency/
16:37:01 <meskio> anadahz: yes, I hope to be wrong
16:37:10 <meskio> I mean about the DNS blocking
16:37:23 <anadahz> itchyonion: This is actually a different test that is currently obsolete.
16:38:10 <anadahz> This the latest spec of the web connectivity test: https://github.com/ooni/spec/blob/master/nettests/ts-017-web-connectivity.md
16:40:52 <itchyonion> cool I see this "We will also mark the result as consistent if the IP addresses in the measurement and the ones in the control belong to the same ASN."
16:41:19 <anadahz> I added some of my thoughts about the blocking of DNS here: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/40001#note_2797846
16:43:34 <meskio> great, anything else on this paper?
16:43:38 <meskio> should we close the meeting?
16:44:02 <shelikhoo> EOF
16:44:10 <itchyonion> +1
16:44:28 <meskio> #endmeeting