15:57:37 <shelikhoo> #startmeeting tor anti-censorship meeting 15:57:37 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 15:57:37 <shelikhoo> feel free to add what you've been working on and put items on the agenda 15:57:37 <shelikhoo> the read-write link for meeting pad can be requested via direct message 15:57:37 <MeetBot> Meeting started Thu Mar 14 15:57:37 2024 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:57:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:57:41 <shelikhoo> Hi! 15:57:41 <meskio> hello 15:57:44 <theodorsm> hi! 15:57:51 <cohosh> hi 15:58:13 <onyinyang> hello 15:58:13 <ggus> o/ 16:01:15 <shelikhoo> I have removed ireland election entry, it is finished with constitution amendment rejected: https://www.washingtonpost.com/world/2024/03/08/irish-vote-update-constitutions-women-home-clause-gets-complex/ 16:01:59 <shelikhoo> okay, let's start the meeting 16:02:28 <shelikhoo> the first topic for discussion is: 16:02:28 <shelikhoo> PTs removed from ios onionbrowser because of RAM constraints 16:03:07 <shelikhoo> from onyinyang? 16:03:12 <cohosh> i added that 16:03:14 <theodorsm> which PTs? 16:03:19 <cohosh> all of them 16:03:20 <shelikhoo> okay sorry.. 16:03:37 <ggus> https://github.com/guardianproject/orbot/issues/1106 16:04:12 <shelikhoo> I think it mostly come to iOS restriction on VPNs 16:04:34 <cohosh> exactly 16:04:36 <shelikhoo> it used to have the limit of 15 mb memory 16:04:39 <shelikhoo> and then 50 mb 16:04:46 <cohosh> i don't think there is something we can do about this in the short term 16:04:55 <shelikhoo> and they also restrict who could submit vpn app to app store 16:05:11 <shelikhoo> we already have the socks5 proxy support in both pt 16:05:34 <shelikhoo> so we could bypass this memory restriction by running pt outside vpn context 16:06:15 <meskio> I guess they use iptproxy, so merging PTs into a lyrebird or whatever so there is no multiple go runtimes will not improve anything there, isn't it? 16:06:25 <cohosh> for some definition of "we", that's up to the orbot developers i guess 16:06:35 <cohosh> meskio: that's right, yeah 16:06:53 <shelikhoo> cohosh: yes... I mean we as the developer of iOS app 16:07:04 <shelikhoo> but not as Tor anti-censorship team 16:07:21 <cohosh> they asked me if we were going to reimplement everything in rust soon lol 16:07:32 <ggus> hehe 16:07:37 <meskio> we could reach out the guardian project and see if we can help anyway there 16:07:47 <meskio> I can drop them an email 16:07:53 <cohosh> but i guess some of the arti developers were experimenting with an obfs4 implementation 16:08:13 <cohosh> so maybe that will happen, i just have no idea what timeline that is on 16:08:23 <shelikhoo> It would be a significant task to rewrite snowflake or obfs4 in rust 16:08:28 <cohosh> yeah 16:08:36 <meskio> cohosh: I see, you are already talking with them, nice 16:09:03 <cohosh> i'm not sure there's much we can do here for now :/ but it's good to know 16:10:14 <shelikhoo> I think the only feasible way forward is to run pt in a separate context and let orbot connect to it 16:10:32 <shelikhoo> I don't think writing everything in rust will magically fix things 16:10:43 <shelikhoo> or at least it would be quite expensive 16:10:49 <shelikhoo> for the gain 16:10:54 <shelikhoo> over 16:11:03 <cohosh> me neither, i don't have a good sense for the difference in RAM usage between the go runtime and like, tokio runtime 16:11:54 <cohosh> i'd believe it could be less but it's too far out to consider this moment 16:12:31 <cohosh> nothing more from me on this 16:12:37 <shelikhoo> this would be something need a lot of work to do, and obfs4 rewrite in rust have been previously rejected by funder 16:12:50 <shelikhoo> eof on this 16:13:09 <shelikhoo> the next topic is: 16:13:10 <shelikhoo> snowflake-webextension still (2024-03-12) being rejected from Mozilla add-ons? https://paste.mozilla.org/kOCS6sFe 16:13:10 <shelikhoo> Error: Command failed: git submodule update --init -- translation 16:13:10 <shelikhoo> fatal: not a git repository (or any of the parent directories): .git 16:13:10 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/89#note_3007959 16:13:34 <cohosh> sorry, this was assigned to me and i wasn't actively checking the reviewer response 16:13:56 <cohosh> we tried a fix but it didn't work in their build environemtn for several reasons: 16:14:00 <dcf1> sorry, this was just me being lazy, putting it in the meeting agenda instead of updating https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/89 like I should 16:14:25 <shelikhoo> yes... sorry there was so many colors, I could no longer tell who submitted the topic... 16:14:27 <cohosh> i noticed it separately last night and then panic uploaded a new version but didn't take the time to look at it closely 16:14:50 <cohosh> there's a human problem and a technical problem 16:15:01 <cohosh> the human problem is that they are still running the wrong commands to build the extension 16:15:12 <cohosh> which i tried to fix last night by slightly modifying the README 16:15:36 <dcf1> Re Go and Rust, I did both a Go and Rust implementation of exotr-static-cookie, and the Rust version used more memory. Don't know how meaningful that is, as it's essentially just a no-op TCP pipe program. https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000228.html 16:15:50 <cohosh> this process is very frustrating because i can't tell when we are interacting with a bot/script and when we are interacting with a human 16:16:12 <cohosh> but i do have some work to do with getting the git commands to run properly so I'll address that before trying again 16:16:33 <dcf1> would it help to have other developers commenting on the failure log? or is this happening through email? 16:16:57 <cohosh> you mean more than just me? i have no idea, maybe 16:17:00 <shelikhoo> dcf1: I think the concept of rust use less memory come from it does not have a gc, which in go's case delay returning memory to OS and delay GC scanning 16:17:50 <shelikhoo> and it also have a huge, and opinionated runtime 16:19:03 <cohosh> dcf1: i think for now, i will attempt to fix the other errors and then if i receive the same problems with running the wrong commands i'll ask someone else to jump in and take a look or comment to see if that helps 16:19:41 <cohosh> i haven't noticed a drop in proxies fwiw, so i think already installed addons are still ok 16:20:01 <cohosh> but i'll make this a priority this week 16:20:07 <dcf1> I'm just thinking, if it's a human process, sometimes they get solved more quickly if the human gets more people bugging them in their inbox 16:20:08 <cohosh> the review process is also frustratingly slow 16:20:53 <cohosh> true, okay let's try it :) 16:21:24 <shelikhoo> no human response is what big corporation do... 16:21:58 <shelikhoo> and it does work when it comes to profit and avoiding responsibility 16:22:10 <shelikhoo> and contribute to the hate of techs in many case 16:22:28 <dcf1> I realized I have been slightly confused about this... I saw the git errors and I thought it was because the build process started requiring git in order to embed a commit id in the version number, but that happened in the snowflake code, not the proxy code, correct? 16:22:50 <dcf1> And the "git submodule" error is a consequence of the reviewer running the wrong command? 16:22:56 <shelikhoo> yes, it is about snowflake webextension 16:23:25 <cohosh> dcf1: it's both 16:23:36 <cohosh> that's what i meant by human and technical 16:23:41 <cohosh> i was focusing on the human problem 16:23:57 <cohosh> but there is still the technical problem of the right commands will also try to use git in a similar way 16:24:47 <cohosh> so i uploaded an attempted fix to the human problem last night by modifying the README, but forgot to check whether the .git folder fix worked and it didn;t 16:25:25 <cohosh> so i will work on that now and upload a new version again before trying new things to solve the human problem 16:25:57 <dcf1> do you know what has changed in the build process that it now requires git and seemingly didn't before 16:26:09 <dcf1> like I said, I was mentally thinking https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40285, but that's not the webextension 16:26:22 <cohosh> the change is that their review has a build process 16:26:30 <dcf1> ah ha, ok 16:27:59 <cohosh> we could also change our build script to not require git 16:28:29 <shelikhoo> I think it would nice to reduce dependencies 16:28:40 <cohosh> but that would require the source code archive to change because the needed translations are in a git submodule which needs to have been intialized 16:29:07 <cohosh> i think we still want the git commands in make.js somewhere for that reason and for making some processes easier and more automated 16:29:26 <shelikhoo> the build script try to create commit or tag has been an issue when I try to develop it 16:29:28 <cohosh> but we could factor it out of what they'd need to run for this review process 16:29:49 <cohosh> shelikhoo: yeah i had the same issue with my local git settings signing tags by default 16:29:50 <dcf1> so are you proposing we ship the addons reviewers an "easy mode" build script that has the translations directory baked in and fwer possible failure paths? 16:30:05 <cohosh> dcf1: yeah something like that 16:32:29 <shelikhoo> cohosh: in my case it is in an isolated container so there some other issue with that, but anyway write access to git make command less reproducible 16:33:02 <shelikhoo> anything more we would like to discuss about this topic? 16:33:22 <cohosh> if you all think this is a good idea, i'll move ahead with making a more minimal easy mode build command 16:33:25 <cohosh> thanks! 16:33:29 <cohosh> that's it from me on this 16:34:27 <shelikhoo> okay! now is the time for announcement! 16:34:28 <shelikhoo> - Elections in Russia (March 14 - 17) 16:34:54 <shelikhoo> personally I don't expect anything big when it comes to new kinds of censorship 16:35:05 <shelikhoo> but we should keep a closer look 16:35:15 <shelikhoo> anything we wants to discuss about this topic? 16:35:35 <shelikhoo> finally, there is a interesting link: 16:35:36 <shelikhoo> https://github.com/getlantern/broflake Lantern's new Snowflake-like, uses QUIC, WASM, WebTransport 16:35:59 <ggus> it seems ntc.party was blocked today in russia 16:36:12 <ggus> https://ntc.party/t/%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-ntcparty/7480 16:37:03 <meskio> :( 16:37:34 <shelikhoo> oh! too bad... anti-censorship bootstraping has always been an issue 16:38:31 <shelikhoo> anything we would like to discuss about ntc.party or broflake? 16:38:39 <onyinyang> wait. . .broflake? hmmm. 16:38:45 <cohosh> lol 16:39:02 <dcf1> they said the name is perhaps not final 16:39:03 <meskio> XD 16:41:23 <shelikhoo> okay, anything else we would like to discuss in this meeting? 16:41:46 <meskio> not from me 16:42:13 <theodorsm> I have a question about uTLS usage 16:42:34 <theodorsm> I was reading some old IRC logs, and there was some talk that the uTLS lib are slow to add fresh fingerprints of client hellos. 16:43:42 <theodorsm> Have there been any isses with uTLS being fingerprinted with snowflake? 16:44:29 <meskio> I don't know of any case where uTLS has being the triger of a fingerprint 16:45:15 <dcf1> me neither 16:45:16 <shelikhoo> I think in iran they have at least once censored some fingerpint utls was using 16:45:30 <dcf1> how old, theodorsm? there was a time when utls was not being as actively maintained 16:45:32 <shelikhoo> but it can be avoided by... change to another fingerprint 16:45:58 <theodorsm> dcf1: early 2022 16:46:09 <dcf1> shelikhoo: if you have a reference for that, it's something we should have mentioned when writing about Iran 16:46:48 <shelikhoo> https://github.com/net4people/bbs/issues/153 16:47:55 <theodorsm> So for implementing similar mimicking of DTLS fingerprints there is no data for that now. I know uTLS uses tlspringerprint.io to collect fingerprints 16:48:19 <dcf1> ok, fair 16:48:47 <shelikhoo> I also experienced it when I was testing v2ray's utls support in iran 16:50:16 <shelikhoo> anything more we would like to discuss in this meeting? 16:50:46 <dcf1> theodorsm: this is an example utls issue for adding new fingerprints: https://github.com/refraction-networking/utls/pull/269 16:50:50 <ggus> there is an interesting issue here about webtunnel: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/32 16:50:56 <dcf1> https://github.com/refraction-networking/utls/graphs/commit-activity 16:52:18 <shelikhoo> ggus: there is no amount of pretending that would make it non-detectable, so maybe we could just add them as needed 16:52:40 <shelikhoo> as there is no encryption once the outer tls is terminated 16:53:09 <shelikhoo> the cdn provider can always inspect the content of the traffic, unprotected 16:53:36 <theodorsm> dcf1: yes, they seem to keep the fingerprints somewhat fresh 16:53:39 <shelikhoo> in V2Ray it is possible to send both httpupgrade or real full websocket 16:53:44 <theodorsm> To keep mimicked fingerprints up to date I am working on CI/CD jobs for the pion lib which could generate a DTLS handshake with common up-to-date browsers and use the collected fingerprint in the lib. 16:54:37 <ggus> thanks, shelikhoo! 16:54:52 <shelikhoo> ggus: I will reply this to the ticket 16:55:04 <shelikhoo> anything else we would like to discuss in this meeting? 16:55:33 <shelikhoo> #endmeeting