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