15:59:29 <meskio> #startmeeting tor anti-censorship meeting 15:59:29 <MeetBot> Meeting started Thu Mar 17 15:59:29 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:33 <meskio> hello!! 15:59:36 <shelikhoo> Hi~ 15:59:40 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:48 <meskio> feel free to add what you've been working on and put items on the agenda 16:00:06 <itchyonion> hello 16:00:13 <cohosh> hi! 16:00:15 <shelikhoo> Welcome itchyonion! 16:00:19 <shelikhoo> Welcome to the team! 16:00:26 <itchyonion> thanks! 16:00:39 <meskio> yeah!!! wellcome 16:00:47 <cohosh> \o/ 16:00:52 <meskio> for everybody itchyonion is a new member of the Anti Cenrsorship team, starting today :) 16:00:54 <itchyonion> ql`v`lp 16:02:10 <meskio> we have a pretty empty agenda today, anything to talk about? 16:02:59 <itchyonion> What's a good place for me to start? 16:03:28 <anadahz> Welcome itchyonion! 16:03:41 <itchyonion> thanks! 16:03:45 <meskio> itchyonion: I guess you can start with the team wiki: https://gitlab.torproject.org/tpo/anti-censorship/team/ 16:04:14 <meskio> and having a look to snowflake: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake 16:05:34 <meskio> on monday we'll have a proper meeting to talk about it, just start slowly and read the documentation 16:05:50 <itchyonion> ok :) 16:06:02 <meskio> I wee we have one point in the agenda: "dnstt bridges" 16:06:30 <meskio> who added it? 16:07:08 <anadahz> I have some news to share, together with Guardian Project we are working on iplementation of dnstt for iOS and Android. 16:07:22 <meskio> ohh, nice 16:07:41 * anadahz searches for a git commit 16:08:13 <anadahz> https://github.com/tladesignz/IPtProxy/commit/e2ce9d113c412f9baa436f641a61d6af465a3043 16:08:37 <cohosh> anadahz: cool! 16:09:01 <meskio> for context for others, dnstt is a plugable transport that uses dns traffic: https://www.bamsoftware.com/software/dnstt/ 16:09:15 <anadahz> threeletteracronym[m]: Mentioned that it is relatively easy to add it also on Orbot as a failover to obfs4 and snowflake. 16:10:29 <anadahz> The big question now is how can we support dnstt and include it in tpo's infrastructure (metrics, moat, ...)? 16:10:48 <anadahz> What could be the best strategy to do this? 16:11:20 <meskio> wow, interesting 16:11:59 <meskio> mmm, I'm not sure I have in my head all the needed steps 16:12:14 <cohosh> anadahz: these don't need to be done all at once for what it's worth 16:12:56 <cohosh> metrics will automatically collect info for new transports, as long as you publish your descriptor to BridgeDB 16:13:47 <anadahz> cohosh: is there a doc with details on how to do this? 16:14:21 <meskio> bridgedb and rdsys will require being configured to support those kind of bridges, but might not even need changes in the code (or trivial ones) 16:15:22 <anadahz> ok so perhaps opening an issue first? 16:15:32 <meskio> yes, I think that should be the first step 16:15:54 <cohosh> anadahz: yeah opening an issue is the best call, there's no central documentation for all you want to do 16:17:02 <anadahz> I guess also some work will be needed for dnstt to be supported in Tor Browser? 16:17:15 <meskio> how slow is dnstt in practice? I guess we'll prefer always using obfs4 or snowflake as dnstt might be fairly slow, isn't it? 16:17:52 <shelikhoo> I think that shouldn't be difficult to support DNSTT in Tor Browser, considering in most case it is just a bridge line 16:18:10 <anadahz> meskio: https://www.bamsoftware.com/software/dnstt/performance.html 16:18:24 <cohosh> yes you can use it in tor browser now just by pasting the bridge line into it 16:18:36 <cohosh> oh wait sorry 16:18:40 <shelikhoo> NONONO 16:18:47 <cohosh> tor browser needs to ship the client side binary 16:18:48 <shelikhoo> I think it is not now 16:18:55 <shelikhoo> but, it would be possible 16:19:08 <cohosh> you can hack it to use a different path but it requires manually editing tor browser's torrc files 16:19:17 <meskio> yes, I think the hard part in TB is to figure out how everything fits together and how to communicate things 16:20:20 <anadahz> Sounds like a good start will be to open a ticket for TB as well. 16:20:48 <ggus> anadahz: who would run dnstt bridges? it would be something like the default built-in obfs4 bridges or the open relay operator community? 16:21:36 <anadahz> ggus: That's a good question and I would hope that dnstt bridges should be deployed by the community similarly to obfs4. 16:21:43 <shelikhoo> I think we could make it possible for community to run it..... 16:22:10 <anadahz> I can setup a short how-to if relay operators would like to host any bridges with dnstt. 16:22:48 <ggus> so include in the estimation: writing dnstt guides for all platforms (*bsd, linux..) and writing tor browser user documentation too. 16:23:08 <anadahz> ggus: yep! 16:23:31 <cohosh> anadahz: the big thing for tor browser support is getting reproducible builds 16:23:52 <cohosh> if you're doing time estimation, this can be a lengthy process 16:24:27 <anadahz> Do you know any way we could use to simulate or measure performance impact of multiple dnstt bridge clients using a relay? 16:24:55 <cohosh> hmm, the easiest way is to just deploy something 16:25:35 <cohosh> what we did for snowflake was set up a bridge, get some cli users, then get tor browser alpha users, then finally tor browser stable after a looong ramp up process 16:25:38 <anadahz> cohosh: Was this an issue for obfs4 and snowflake to get faster reproducible builds? 16:25:59 <cohosh> faster reproducible builds? 16:26:17 <cohosh> ah, for snowflake it took some time because of the number of libraries involved 16:26:37 <cohosh> i am not sure about obfs4 since that was set up for reproducible builds before my time 16:27:02 <cohosh> also for snowflake we had issues with building some of the libraries and had to switch which ones we used 16:27:29 <cohosh> i suspiect dnstt won't have that particular issue 16:27:41 <anadahz> That's really useful to know the process with snowflake. 16:27:53 <shelikhoo> I think this process will be easier for pure go program 16:28:04 <anadahz> In which repo do you track the reproducible build code? 16:28:05 <shelikhoo> since there would be a standardized process 16:28:21 <shelikhoo> this is not so for program that requires CGO 16:28:30 * cohosh nods 16:28:38 <anadahz> (I wish dcf1 was here today) 16:28:47 <cohosh> anadahz: https://gitlab.torproject.org/tpo/applications/tor-browser-build/ 16:28:56 <meskio> looking at the code it doesn't seem to have many dependencies, and kind of common ones like kcp or utls, but we'll see 16:29:07 <cohosh> yeah, in that case it could be really quick 16:29:21 <anadahz> cohosh: thx 16:30:05 <meskio> amazing, thanks for the work there, is great to have more pluggable transports 16:30:14 <keroserene> hi folks 16:30:23 <shelikhoo> Hi~ keroserene 16:30:28 <meskio> hello 16:30:30 <anadahz> ggus: Do you think it makes sense to announce this in the forum and ask for volunteer dnstt bridges and testers? 16:32:15 <meskio> I think will be nice to do that once we have rdsys/bridgedb handling those kind of bridges and some documentation on how to setup and use them 16:32:31 <ggus> anadahz: do you mean now? or when users can test it? 16:32:59 <shelikhoo> We can have a default test bridge and get some test client users first. 16:33:20 <ggus> because right now you can install other PTs in your bridge, but that doesn't mean clients will use it since BridgeBD only shares obfs4 and vanilla bridges 16:33:25 <anadahz> I have already some documentation for Debian and a test bridge that is available now. 16:34:48 <anadahz> The setup is pretty easy. 16:34:57 <ggus> i like the default test bridge approach before pushing to the whole operator community 16:35:13 <keroserene> dcf and I had a long chat / catch-up a few days ago, on snowflake, alternate rendezvous, dnstt & everything 16:36:09 <anadahz> ggus: sounds like a good plan 16:36:12 <meskio> anadahz: let's go step by step, open the issue in anti-censorship/team and lets start discussing the steps on our side there and after we can look on how to communicate it 16:36:26 <anadahz> Anyhow here it is: https://pad.riseup.net/p/WraKJFLJ54lxKLeSeYKF 16:36:42 <meskio> nice 16:36:54 <ggus> anadahz: we have a tor relay operator meetup on April 2, it would be nice to introduce the dnstt topic there, explain the current usage limitations (bridgeBD and Tor Browser) 16:37:00 <anadahz> meskio: great 16:37:54 <meskio> keroserene: pretty cool, any interesting conclusions on it? 16:37:56 <anadahz> ggus: will try to join 16:39:41 <keroserene> meskio: dnstt and amp-cache may be important soon, and there's a bunch of stuff we need to do soon to keep up w/ demand in ru and everything 16:40:13 <keroserene> fastly / domain fronting maybe doesn't have much longevity.. 16:40:41 <keroserene> i'm also in the process of possibly bringing in a whole bunch more resources for this thing 16:40:50 <shelikhoo> It is worth noting that AMP cache don't work in China, as google and its AMP cache is blocked in China 16:41:16 <keroserene> shelikhoo yes :/ 16:42:09 <meskio> thanks for the summary 16:42:24 <meskio> anything else to discuss? should we move to the reading group? 16:44:04 <meskio> we have for this week: Throttling Twitter: an emerging censorship technique in Russia 16:44:09 <meskio> https://dl.acm.org/doi/pdf/10.1145/3487552.3487858 16:45:05 <meskio> the paper analizes how russia was doing censorship on twitter by throttling the connections to it in 2021 16:45:56 <meskio> is a new way of doing censorship, by making it slow to connect, so users give up but there is no backlash of people complaining of services being blocked 16:46:06 <meskio> also hard to prove that is happening 16:46:17 <meskio> scary 16:46:21 <shelikhoo> This kind of censorship is triggered by Twitter's SNI 16:47:14 <anadahz> I read an interesting approach to detect throttling of Twitter in Russia. 16:47:16 <meskio> yep, was interesting to see how they could circumvent it just by splitting the SNI field into two packets 16:47:26 <anadahz> Not sure if this is the same as in the paper: https://ooni.org/post/2022-russia-blocks-amid-ru-ua-conflict/#twitter-throttled 16:48:01 <meskio> might be related, as OONI is also part of the authors of the paper 16:49:07 <meskio> we discussed some weeks ago another paper about ching doing throttling of connections exiting the country 16:50:12 <meskio> but the russian one is easier to avoid as they SNI parser is not perfect 16:51:10 <meskio> also with ECH they will have a harder time to do this kind of things 16:51:35 <shelikhoo> it is possible to just block ECH and let browser downgrade 16:51:38 <meskio> ECH == Encrypte Client Hello (the SNI is encrypted and the censor can not see the domain the user is visiting) 16:51:52 <shelikhoo> This have been done in China to ESNI 16:51:52 <meskio> shelikhoo: yep, isn't china doing that currently? 16:52:04 <meskio> I see 16:52:07 <shelikhoo> Yes 16:52:39 <meskio> we'll we ever have an internet where ECH is mandatory and browsers don't downgrade? 16:53:01 <meskio> it took decades to get to https being the default in the browsers and we are not there yet, so... 16:53:18 <shelikhoo> need to rebase our universe to do that... sadly 16:54:02 <meskio> :( 16:54:27 <meskio> some days I consider if geminy or any of those retro looking protocols are not the solution... 16:54:39 <meskio> s/geminy/gemini/ 16:55:32 <meskio> but AFAIK ESNI was working for tunnel bear to avoid being blocked in Iran 16:55:40 <meskio> so there is still hope 16:56:09 <meskio> https://www.tunnelbear.com/blog/tunnelbear-circumvents-iran-vpn-block/ 16:56:25 <meskio> september 2020, not sure if still works 16:57:30 <shelikhoo> It is not difficult to get something works, but it is difficult to get it keep working when authority really hates it 16:58:01 <meskio> yes, all this cat an mouse games 16:58:55 <meskio> anything else on this paper? 16:59:24 <itchyonion> will be interesting to see how much domestic pushback russia gov will face now that it blocks twitter, or if it matters at all 16:59:25 <meskio> I'll give it an extra minute to see if someone has something else and close the meeting 16:59:27 <shelikhoo> Oh, and now I read this paper, I though about China's approach to make throttle network 17:00:11 <meskio> itchyonion: are they totally blocking it now? I'm a bit lost with news latelly 17:00:34 <itchyonion> i thought that's what I read, but not 100% sure 17:00:50 <anadahz> itchyonion: I think it's easier for Russia to block more things, now that the parts of the world are also blocking their services to Russia. 17:01:03 <shelikhoo> In China, most of the traffic to network traffic from residential network to foreign IP address are deprioritized and transferred with congested network 17:01:24 <meskio> yep, is probably true, we'll see, but it looks like being at war they don't allow much pushback from people 17:01:32 <shelikhoo> in reality it means even if a website is not blocked, it would be really slow to Chinese users 17:02:37 <meskio> shelikhoo: yes, but the solutions they found in the twitter paper will not work in china, as they basically throttle everything 17:02:39 <shelikhoo> And to increase the connectivity, the foreign ISP will need to buy expensive transit with Chinese ISP 17:03:18 <shelikhoo> which means most VPS commonly found have bad connectivity to china 17:03:51 <itchyonion> i know russia has their own version of facebook (VK), but not sure about others popular platforms. While China already has their own version of everything 17:04:06 <shelikhoo> and one need to look for uncommon provider that have purchased transit from chinese ISP to increase its speed 17:04:35 <shelikhoo> and this cost will be transferred to the VPS operator 17:04:54 <shelikhoo> this is the reason why meek-azure is popular in China 17:05:17 <shelikhoo> it is because Azure's connectivity to China is better 17:05:43 <shelikhoo> than most of obfs4 bridges or snowflake proxy 17:06:06 <shelikhoo> as bridge operators often look for VPS will cheap traffic cost 17:06:33 <shelikhoo> but that means it is not paying Chinese ISP to increase its connectivity with Chinese user 17:07:11 <shelikhoo> we can either use special protocol to compensate for packet loss as a result of this, like the thing we are trying to do with snowflake 17:08:08 <ggus> shelikhoo: i remember last year some folks from HK telling me that tor and vpn traffic was being throttled in some residential ISPs. https://gitlab.torproject.org/tpo/community/support/-/issues/40029 17:08:12 <shelikhoo> or find expensive VPS that have better connectivity to host other bridges like obfs4 17:09:48 <shelikhoo> Yes. I think it would be wise to try to setup a vantage point in Hong Kong as well to detect network connectivity issue. 17:10:30 <meskio> yes, that will be nice 17:10:39 <shelikhoo> Hong Kong's network environment is different than China mainland's 17:11:39 <ggus> if you look hk metrics graph there are some interesting dips and spikes - https://metrics.torproject.org/userstats-relay-country.html?start=2021-12-17&end=2022-03-17&country=hk&events=off 17:13:00 <meskio> related to that, the paper we had in the reading group some months ago: Characterizing Transnational Internet Performance and the Great Bottleneck of China https://censorbib.nymity.ch/#Zhu2020a 17:13:27 <meskio> anything else here? 17:14:29 <meskio> I'll close the meeting then 17:14:33 <meskio> #endmeeting