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