15:57:46 <meskio> #startmeeting tor anti-censorship meeting 15:57:46 <MeetBot> Meeting started Thu Sep 7 15:57:46 2023 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:57:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:57:52 <meskio> hello everyone!!! 15:57:55 <cohosh> hi 15:57:56 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:06 <onyinyang[m]> hihi o/ 15:58:14 <meskio> feel free to add what you've been working on and put items on the agenda 15:59:10 <meskio> we can wait few minutes for people to fill up what they being working on 15:59:58 <shelikhoo> Hi~ 16:00:41 <meskio> the first topic is 'No webtunnel and conjure options at https://metrics.torproject.org/userstats-bridge-transport.html ' 16:00:50 <meskio> I think that was already last week, but I missed it 16:01:26 <meskio> is it already talked? did someone opened an issue on the metrics repo about it? 16:01:33 <cohosh> there's an open issue at https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40092#note_2935782 16:02:13 <meskio> nice 16:02:39 <meskio> then I guess we can move to the next topic, or is there something to discuss? 16:03:13 <meskio> Upgrading Go toolchain for snowflake 16:03:17 <meskio> shelikhoo: ??? 16:03:38 <shelikhoo> yes! that's me 16:04:13 <shelikhoo> so, right now snowflake's more recent version of dependencies requires a more recent version of go language toolchain 16:04:34 <shelikhoo> however, these more recent version of go tool chain is not supported by debian 16:04:57 <shelikhoo> (but support by tor's rbm/tor browser build system) 16:04:58 <shelikhoo> so 16:05:18 <meskio> what version is the needed one? 16:05:34 <shelikhoo> if we upgrade go language tool chain version, then debian package support will break 16:06:15 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/162 16:06:19 <shelikhoo> maybe 1.21 16:06:31 <shelikhoo> as indicated by some module 16:07:05 <shelikhoo> utls requires 1.20+ https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/164 16:07:54 <meskio> mmm, keeping up with uTLS might be important to avoid being blocked... 16:08:04 <shelikhoo> there are many other breaks for other dependencies 16:09:03 <shelikhoo> there are about 5 broken dependencies updates from bot 16:09:04 <hiro> @meskio it's developed already... t should be released this week or early next week 16:09:16 <meskio> I think debian support should not be a blocker, I see it as it might be harder for people to contribute to if we need the latest version of go 16:09:21 <meskio> hiro: nice, thank you 16:10:11 <shelikhoo> meskio: I don't think it is going to be that huge an issue, as it is not hard for developers in typical environment to update their build toolchain 16:10:21 <meskio> cohosh, dcf1: do you have opinions here? 16:10:39 <cohosh> i was most worried about the debian packaging 16:10:50 <cohosh> if that's not an issue i think we should keep our dependencies up to date 16:11:05 <meskio> yes, it will make harder to make a package for backports 16:11:11 <meskio> but I'm not sure how many people use those 16:11:19 <cohosh> it's unfortunate we're being forced to abandon versions of go that are still supported 16:11:54 <cohosh> but i'm more worried about creating more headache later in the case of security vulnerabilities 16:13:42 <meskio> I hear most voices saying 'let's update'... 16:13:42 <shelikhoo> yes, if should be less an issue if we have snowflake in let's say apt.torproject.org 16:14:24 <meskio> I agree, we should get it the package there, and I'll try to figure out it 16:14:38 <shelikhoo> I think we should update now, and give priority to have snowflake into apt.torproject.orf 16:14:47 <shelikhoo> or something similar 16:14:55 <meskio> +1 16:15:21 <meskio> anything more on this topic? 16:15:51 <shelikhoo> EOF 16:15:56 <meskio> release new snowflake version 16:16:09 <shelikhoo> yes, it is from me 16:16:51 <shelikhoo> so right now the support for android is broken for android API 30+ 16:17:08 <shelikhoo> and based on my testing, it is not related to package's targeted version 16:17:27 <shelikhoo> so we will need to release a new version of snowflake to fix that 16:17:29 <shelikhoo> cohosh: I see you have been generating Changelogs for past snowflake releases, Would you mind sharing it with me? 16:17:29 <shelikhoo> Would you mind sharing the command to generate it with me? 16:18:08 <shelikhoo> this issue will be fixed when we release a new version with workaround in it 16:18:24 <cohosh> oh I just write them manually 16:18:59 <shelikhoo> dcf: you have an merge request ready to be merged. Do you mind I merge it on your behalf? 16:18:59 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/154 16:19:16 <dcf1> I am planning to revise !154 16:19:38 <shelikhoo> okay, I will go ahead and release new version of snowflake without this merge request 16:19:50 <shelikhoo> it can be included in new release 16:19:55 <shelikhoo> is that okay? 16:20:01 <dcf1> it's for the bridge anyway, it doesn't make a difference for clients really 16:20:36 <shelikhoo> cohosh: okay... I will try to write it myself... it will be in a slightly different format 16:20:48 <shelikhoo> dcf1: yes, it won't matter for client 16:20:59 <shelikhoo> okay, I think that all I have for this topic 16:21:02 <shelikhoo> EOF 16:21:14 <meskio> great, thanks for making the release 16:21:26 <meskio> snowflake-02 outage https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000311.html 16:21:52 <dcf1> I just found the cause of the outage, a whole university campus was disconnected for a few days 16:22:21 <dcf1> The timing matches up with the increase in client polls talked about on the mailing list, so I'm pretty sure that was the cause 16:22:22 <onyinyang[m]> oh, yikes! 16:22:40 <meskio> wow 16:22:48 <shelikhoo> oooh! that is a hard problem to solve 16:23:18 <dcf1> that's all on that 16:23:38 <cohosh> woah 16:24:22 <meskio> in the interesting links it seems to be a discussion point: 16:24:25 <meskio> Firefox planning to ship ECH by default. Think about resurrecting meek-esni? 16:24:30 <shelikhoo> yes! ECH! 16:24:40 <meskio> https://github.com/net4people/bbs/issues/280 16:24:42 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/28168 16:24:53 <dcf1> yes, back when ESNI was under development, I made a version of meek (using the Firefox helper) that could use ESNI 16:25:21 <shelikhoo> I think it is too early for us to do anything, as otherwise ech will be blocked before it gain popularity 16:25:26 <dcf1> we could of course do the same thing with ECH, when it's judged that it's prudent to start trying that 16:25:54 <meskio> I agree with shelikhoo, but we should keep it in mind to do it at some point 16:25:58 <meskio> what I'm not sure is when 16:26:05 <shelikhoo> https://here.news/post/1b17e6fe-b45c-465f-a416-c8fac066bf37/%E4%B8%AD%E5%9B%BDgfw%E5%B0%81%E9%94%81%E4%BA%86cloudflare%E7%9A%841-1-1-1-%E5%92%8Cwarp%E5%AE%98%E7%BD%91%E7%9A%84https (Chinese) 16:26:06 <meskio> I guess we should keep an eye to the adoption 16:26:17 <shelikhoo> actually the block have already started 16:26:30 <shelikhoo> ECH requires the usage of DNS over HTTPS 16:26:49 <shelikhoo> and china is starting to block DoH providers like cloudflare 16:26:57 <meskio> ohhh :( 16:27:30 <dcf1> I don't think it's "starting" really, my impression was that lots of DoH was already blocked in China and had been for a long time 16:27:31 <meskio> we could always do the same the browser do of trying ECH and fallback to non-ECH if it fails 16:28:01 <dcf1> There's the recent BBS thread claiming that blocking of 1.1.1.1 is new, but I'm not so sure it's really new. I'm not familiar with the telegram channel they got their information from. 16:28:42 <shelikhoo> 1.1.1.1 is one of the DoH server that is often used by browser 16:28:58 <shelikhoo> while others are used by dns resolver 16:29:05 <dcf1> Also, side note, there may be good alternatives to using the Firefox helper for ECH. I learned of this project: https://github.com/SagerNet/sing-box which uses ECH via https://github.com/sagernet/cloudflare-tls which is forked from some Cloudflare TLS repository. 16:29:23 <dcf1> I don't think 1.1.1.1 per se is actually used by browsers. 16:29:59 <dcf1> Firefox uses, I think, mozilla.cloudflare-dns.com. It's the same service as 1.1.1.1 but different IP address (I believe) and obviously different SNI. 16:30:30 <dcf1> Anyway, there are other reasons to block 1.1.1.1 other than attacking ECH, it's also used by the Cloudflare WARP tunnel service. 16:31:20 <dcf1> (Which incidentally is problematic for circumvention, because as I understand it, Cloudflare will try to exit you from another place in your own country, if they have egress nodes there.) 16:31:29 <dcf1> WARP, that is. 16:32:32 <shelikhoo> I think in WRAP's case, cloudflare don't have any datacenter in china 16:32:34 <dcf1> This is the thread we're talking about btw. I'm not fully caught up on it. https://github.com/net4people/bbs/issues/280#issuecomment-1706267069 16:33:05 <shelikhoo> (for oridinary users) 16:33:25 <dcf1> shelikhoo: yes, that is my impression too, in China WARP works more like a proxy that gets you out of the country. 16:34:47 <shelikhoo> yes... 16:36:06 <shelikhoo> EOF from me 16:36:13 <meskio> ok, so I read that we should do ECH at some point in meek (and I would say as signaling channel for snowflake/moat too), but not yet 16:36:28 <dcf1> yes, not yet, just know that it's a possibility 16:36:54 <meskio> +1 16:37:35 <meskio> moving on, there is an update of the daily operations of snowflake-01: https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2023-august-update 16:38:18 <meskio> and I think this is all in our agenda, any last topics to discuss? 16:39:19 <meskio> then, I will close the meeting 16:39:24 <meskio> #endmeeting