16:00:01 <shelikhoo> #startmeeting tor anti-censorship meeting
16:00:01 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:01 <shelikhoo> editable link available on request
16:00:01 <MeetBot> Meeting started Thu Jun  6 16:00:01 2024 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:03 <shelikhoo> hi~
16:00:05 <meskio> hello
16:00:07 <theodorsm> Hii!
16:00:18 <cohosh> hi
16:00:27 <gaba> hi
16:01:02 <onyinyang> hello!
16:03:15 <shelikhoo> dcf1: just let you know that the broker needs IPv6 address configured to continue its configuration with probetest(NAT Type Type assist) https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40349#note_3035222 (It is not urgent at all!)
16:03:46 <dcf1> shelikhoo: I am checking it now.
16:04:11 <shelikhoo> Okay, let start with the first topic
16:04:13 <shelikhoo> can we retire monit in favor of prometheus?
16:04:13 <shelikhoo> https://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/merge_requests/41
16:04:13 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/commits/main/?r
16:04:27 <shelikhoo> it is from meskio?
16:04:35 <meskio> yes
16:04:57 <meskio> we have monit testing things like the builtin bridges if they are up
16:05:15 <meskio> I believe monit is actually not working since a while, because I didn't see any alerts comming from it
16:05:22 <meskio> it was mantained by philip
16:05:40 <meskio> I'm trying to replace it by our prometheus maintained by TPA
16:06:09 <meskio> as a first step I added all the current monit targets to the blackbox exporter (see the merge request in prometheus-alerts)
16:06:24 <meskio> and I'm talking with TPA on how to make the alerts
16:06:57 <meskio> the missing piece will be that monit at some point was testing that gettor emails were responded, but this is disabled since a while
16:07:09 <meskio> TPA said they will support something like that in the future, but not there yet
16:07:20 <meskio> I guess is fine, as this test was disabled in monit
16:07:38 <meskio> anyway, I wanted to hear from you how to do feel about retiring monit and moving into prometheus
16:07:48 <meskio> I'll check with philip about it
16:08:18 <shelikhoo> yes, and in theory testing gettor with email could be done with a custom tool as well
16:08:42 <meskio> yes, TPA wants to build this tool for their usecase, so I'm hoping they will do that for us :)
16:08:49 <cohosh> sounds good to me
16:08:54 <shelikhoo> yeah
16:08:58 <shelikhoo> sounds good to me
16:09:25 <meskio> nice, once we have the alerts in place I'll talk with philip on how to coordinate the retiring of the service
16:09:42 <meskio> BTW, looking into this I think there are some builtin bridges that are offline since a while
16:09:51 <meskio> one was not even present in metrics.tpo anymore
16:10:04 <meskio> I'll try to look into this
16:10:37 <meskio> this is all from on this
16:11:02 <shelikhoo> okay, I think we can move to the next topic
16:11:13 <shelikhoo> do we wish to include snowflake into lyrebrid?
16:11:13 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40015
16:11:33 <shelikhoo> a little context is what the tor browser apk is hitting google's quota
16:11:47 <shelikhoo> a little context is what the tor browser apk download size is hitting google's quota
16:12:24 <shelikhoo> so we wants reduce the size of pluggable transport binary we are shipping with it
16:12:41 <shelikhoo> one way to do that would be merging them into a single library
16:13:01 <shelikhoo> to avoid shipping many copies of runtime and standard library
16:13:24 <shelikhoo> and one thing we could merge is snowflake
16:13:35 <meskio> s/single library/single binary/ I guess
16:14:00 <shelikhoo> one way to do that would be merging them into a single binary
16:14:03 <shelikhoo> sorry...
16:14:40 <shelikhoo> and the primary limitation with a merging into a single Golang binary is we could only ship one version of the library in a single binary
16:15:07 <shelikhoo> so if different projects depends on different version of the same library, then it won't work
16:15:45 <shelikhoo> one example without any research is that snowflake use a recent kcp version that require very recent golang toolchain
16:15:59 <shelikhoo> but recent golang toolchain does not support windows 7
16:16:37 <shelikhoo> this particular issue would be gone once we drop support for windows 7 in tor browser
16:17:28 <shelikhoo> insert: (but obfs4 works on windows 7 right now with a older go toolchain)
16:17:36 <meskio> we agreed with TB to hold updating the go version in lyrebird until mid-september, when mozilla will drop windows 7 support
16:18:00 <shelikhoo> yes, this is only an example, there could be other library with the same issue
16:18:33 <shelikhoo> so we could decide if we wish to do that after mid-sep or not consider it for now
16:18:34 <meskio> I hope we can sync library version by then, keeping using all the latest versions in both projects, renovate should help there
16:19:19 <cohosh> there are a few open issues for different options on how to reduce APK sizes
16:20:20 <cohosh> when i last asked the applications team, they mentioned that they will start esr128 builds in mid-June and might need some space-saving tricks for that release, depending on what upstream changes were made
16:21:19 <cohosh> i think we even discussed compiling to wasm, let me see if i can find it
16:22:00 <cohosh> https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41152
16:22:25 <cohosh> ah, here is the meta issue that links to a few other ideas: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42607
16:23:11 <shelikhoo> yes...
16:23:28 <meskio> merging snowflake into lyrebird sounds easier that that compiler tricks, if it really gets us there
16:23:57 <meskio> and if applications want this change sooner thant september they will need to decided if we can drop win7 support
16:24:21 <meskio> but I guess the question here is, are we ok moving or duplicating the snowflake client in lyrebird?
16:24:27 <meskio> if lyrebird uses the snowflake client library, the duplicated code will be 314 lines of code that are currently in the client binary, or we could drop completely the client binary in the snowflake repo if we don't want to maintain that code duplication
16:25:07 <shelikhoo> I believe things could get more complex if there is library version conflict
16:25:13 <shelikhoo> which I have not checked yet
16:25:51 <meskio> we try to use the latest version of everything, the only conflict I expect right now is uTLS that lyrebird is not updating to don't update the go version
16:26:11 <shelikhoo> the wasm compiler trick probably won't really work well as there is no AES-NI support in wasm, which will be polyfilled with software implementation
16:26:33 <shelikhoo> as a result the wasm version of the pt would be slower
16:26:47 <shelikhoo> and sometime there are operation that are not supported by wasm
16:27:41 <shelikhoo> yes, if everything is already almost latest then the effort required would be very manageable
16:27:56 <shelikhoo> yes, if everything is already almost latest then the effort required would be more manageable
16:28:29 <cohosh> i think it's okay to add snowflake support to lyrebird, this is what iptproxy is trying to achieve anyway
16:29:08 <meskio> lyrebrid is not a library that can be used from outside, so is not a replacement of iptproxy, but I guess it could get there...
16:29:27 <cohosh> right
16:30:00 <shelikhoo> another issue with snowflake is that the proxy support for obfs4 might not support udp
16:30:02 <meskio> I guess we could sacrify not having conjure in android for now, maybe is not there yet anyway...
16:30:27 <shelikhoo> so there will be work required
16:30:55 <meskio> yes, we'll need to look into that work
16:31:05 <cohosh> oh that's right, i forgot about proxy support
16:31:38 <meskio> ok, so I guess we are open to the idea but depends on win7 deprecation when we can do that
16:31:40 <cohosh> in any case, we could even merge conjure with lyrebird first since that would be simpler if we want to keep supporting it in android
16:32:03 <cohosh> there is also snowflake#40362
16:32:03 <tor> Uhm, which one of [tpo/anti-censorship/pluggable-transports/snowflake, tpo/web/snowflake] did you mean?
16:32:16 <cohosh> pluggable-transports/snowflake#40362
16:32:24 <meskio> sure, is conjure something that we can use as a library from lyrebird?
16:32:34 <cohosh> i don't know if there's any space saving thing we could do there, but it's worth a look
16:33:33 <shelikhoo> I think patching poin webrtc to include less thing is quite complex
16:33:34 <cohosh> meskio: it wouldn't take too much effort to make it into a library
16:34:14 <meskio> nice
16:34:19 <shelikhoo> there is so much effort and engineering goes into V2Ray to make it support selective compile
16:34:42 <shelikhoo> it is not something that can be easily done based on my personal experience
16:34:48 <meskio> cohosh: do you want to give it a try with conjure?
16:35:16 <cohosh> meskio: sure
16:35:30 <cohosh> shelikhoo: i don't think it's about patching, if i understood the intent correctly
16:35:34 <meskio> great
16:36:12 <meskio> I'll respond the issue saying that cohosh will work on the conjure integration and snowflake requires work and a decision on win7 support
16:36:17 <shelikhoo> cohosh: yes... let's research more about snowflake and its webrtc selective compile when it becomes absolutely necessary
16:36:27 <shelikhoo> yes
16:37:11 <shelikhoo> anything more we would like to discuss about this issue?
16:37:42 <shelikhoo> here is an interesting link:
16:37:43 <shelikhoo> https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2024-may-update
16:38:01 <meskio> yes, I have something more on this topic
16:38:18 <meskio> applications team is also asking if we can drop support for old PTs in lyrebired
16:38:26 <meskio> I love deleting code, and happy to do that
16:38:42 <meskio> but anybody oposes to remove obfs[1-3], scramblesuit, fte,...
16:38:55 <meskio> and keep only meek, obfs4 and webtunnel?
16:39:24 <meskio> not sure how much space we will actually gain with that, probably not that much
16:39:49 <meskio> so if people feel that those should stay I can check how much gain there is and don't remove them if there is not much
16:40:23 <shelikhoo> no objection from shell, but I think it would not save too much size unless it means we could drop some library
16:42:38 <shelikhoo> if anyone wish to comment please do it now or send something now
16:42:41 <meskio> ok, I'll explore it and see how much it changes things
16:42:47 <shelikhoo> yes
16:42:53 <onyinyang> is there any usage of scramblesuit or fte at this point?
16:43:04 <onyinyang> I assume obfs[1-3] are not useful anymore anyway
16:44:02 * dcf1 is suprised to learn lyrebird supports fte
16:44:37 <dcf1> ok, lyrebird doesn't support fte, I wasn't mistaken
16:44:39 <meskio> maybe lyrebird doesn't support fte
16:44:49 <meskio> sorry, my mistake, I didn't even look into it
16:45:04 <cohosh> i don't think it does
16:45:07 <dcf1> np, original fteproxy was python, it would have had to be a reimplementation
16:45:37 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/blob/main/transports/transports.go?ref_type=heads#L88
16:46:54 <cohosh> we recently updated the glossary to say it is not used anymore: https://gitlab.torproject.org/tpo/web/support/-/merge_requests/216
16:47:39 <cohosh> i don't think we have bridges that support obfs[2,3],scramblesuit and not also obfs4
16:48:40 <cohosh> we occasionally hear that they work, so maybe there are users with their TB configured to use those bridge lines, but i'm guessing that is a pretty small group
16:49:44 <meskio> I see, so what I hear is we should not drop support if it doesn't bring any real gain
16:50:11 <shelikhoo> yes... I agree
16:50:20 <cohosh> sounds good to me, the structure of the repository is such that it's not really contributing to clutter there
16:50:38 <meskio> yes
16:50:57 <onyinyang> makes sense to me too
16:51:15 <shelikhoo> okay here is the interesting link again:
16:51:15 <shelikhoo> https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2024-may-update
16:51:24 <shelikhoo> anything else we wish to discuss in this meeting?
16:51:38 <meskio> not from me
16:51:41 <dcf1> theodorsm is looking for a venue for DTLS handshake fingerprint research
16:52:03 <cohosh> nice theodorsm!
16:52:06 <dcf1> so if you think of a good one
16:52:58 <shelikhoo> nice!
16:54:03 <meskio> usenix?
16:54:41 <meskio> I think is also somehow in the north hemisphere summer, so maybe same problem than FOCI
16:55:21 <cohosh> the deadline for PoPETS 2025 issue 2 is at the end of August
16:55:54 <meskio> anyway, congrats for the work there, I'm eager to see that paper
16:56:34 <shelikhoo> if there is any additional comment please send something now
16:56:44 <shelikhoo> #endmeeting