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