16:00:15 <onyinyang> #startmeeting tor anti-censorship meeting
16:00:15 <MeetBot> Meeting started Thu Feb 13 16:00:15 2025 UTC.  The chair is onyinyang. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:15 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:15 <onyinyang> hello everyone!
16:00:15 <onyinyang> here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469)
16:00:23 <meskio> hello
16:00:28 <WofWca[m]> 👋
16:00:38 <theodorsm> hi
16:00:41 <shelikhoo> hi~
16:01:35 <cohosh> hi
16:01:41 <onyinyang> I'll give everyone a few minutes to fill in the pad
16:05:59 <onyinyang> ok, let's start with the first announcement: FOCI is next Thursday! https://foci.community/
16:06:08 <shelikhoo> yeah!
16:06:10 <onyinyang> We will all be attending so there won't be a meeting
16:06:38 <onyinyang> Next a/c meeting will be the 27th
16:07:18 <onyinyang> Also, it's free and online so if you are reading this and can attend, maybe consider doing that! :D
16:07:45 <onyinyang> Next announcement: snowflake-graphs proxy CSV files (client-match.csv, proxy-country.csv, proxy-nat-type.csv, proxy-type.csv) are available again.
16:08:54 <cohosh> oh nice heh i missed then when i tried to make a graph of proxies yesterday
16:09:31 <meskio> pretty cool
16:09:32 <shelikhoo> nice...
16:09:43 <dcf1> there is a bad snowflake-stats metrics descriptor that has been there for months, and I finally just wrote some code to ignore that particular descriptor
16:10:39 <onyinyang> thanks for hunting that down and fixing it dcf1
16:10:53 <shelikhoo> yes! thanks!
16:11:24 <onyinyang> that's it for the announcements today, next is the discussion section
16:11:45 <onyinyang> The first topic is: moderation of mailing lists
16:11:48 <meskio> you might noticed that we we've being getting some spam in our mailing list, fairly annoying LLM spam that looks like is writting on the mailing list topic
16:12:05 <meskio> I have enabled moderation on the maling list but I want to check that we are all ok with it
16:12:21 <meskio> every account that was pressent in the mailing list last octover is unmoderated
16:12:21 <shelikhoo> I am fine with moderation
16:12:29 <meskio> only new subscribers will get moderated
16:12:40 <meskio> and we could unmoderate them on first post if is not spam
16:12:45 <meskio> what do you think?
16:13:10 <cohosh> did the spam come from subscribed accounts?
16:13:12 <meskio> I'm talking about anti-censorship-team and anti-censorship-alerts mailing list
16:13:22 <meskio> cohosh: yes, they did subscribe to the list
16:13:35 <meskio> unsubscribed emails were already moderated
16:14:02 <cohosh> ok this sounds fine to me, and i am in favour of removing the moderate flag after the first non-spam post
16:14:23 <meskio> +1
16:14:58 <onyinyang> +1 makes sense to me
16:15:10 <meskio> we'll see if this is extra work for moderation, but the people talking on those lists seems to be fairly stable
16:15:27 <meskio> I guess we have a consensus on this
16:15:36 <meskio> I don't have anything else on this topic
16:15:40 <onyinyang> Cool, ok let's move on to the next topic
16:15:43 <onyinyang> Whether to switch to debian fork of golang for CI
16:15:43 <onyinyang> https://gitlab.torproject.org/tpo/tpa/team/-/issues/42014#note_3159983
16:15:50 <shelikhoo> Yes, I have also mentioned that ref=nofollow would help
16:15:56 <shelikhoo> yes, this topic is from me
16:16:45 <shelikhoo> right now, snowflake and other projects we are running test/and or builds in CI is using the "offical" golang container
16:17:19 <shelikhoo> TPA provided a "apt-get" version of TPA managed golang container image
16:17:46 <shelikhoo> we could decided to switch to debian's fork of golang
16:17:56 <shelikhoo> or keep using the more commonly used version
16:18:27 <shelikhoo> do we wants to keep using the current version of golang, or switch to debian's fork
16:18:55 <meskio> now that TPA seems to be maintaining not only debian stable but also testing and sid I would be in favor of using them, we get few versions of golang to choose there
16:19:46 <shelikhoo> yes, the reason I rather not to debian's fork is that it can be different from the golang from its author
16:20:01 <shelikhoo> so we could only test on a few version of debian's fork
16:20:13 <meskio> I haven't notice it being different, I've being using debian's versions for years to develop in my computer
16:20:44 <shelikhoo> I have not checked if they what patch was applied
16:21:17 <shelikhoo> I have not checked if what patch was applied
16:21:51 <dcf1> it would surprise me if the debian packaged version of golang were surprisingly different
16:22:17 <shelikhoo> https://sources.debian.org/patches/golang-1.19/1.19.13-1~bpo11%2B1/
16:22:19 <dcf1> I'm not an expert, but this may be the patches applied to golang-1.19 https://sources.debian.org/patches/golang-1.19/1.19.8-2/
16:23:51 <meskio> looks like fixes to tests + the path of perl
16:24:20 <shelikhoo> there are also some changes to the binary generated
16:24:50 <shelikhoo> like [patch] cmd/dist: increase default timeout scale for arm
16:24:50 <shelikhoo> or
16:24:57 <shelikhoo> cmd/link/internal/loadelf: add additional relocations for riscv64
16:25:34 <shelikhoo> in my experience debian is really slow at updating to the most recent version of software
16:26:16 <meskio> yes, but because of that we've being trying to don't target the latest golang
16:26:36 <meskio> if TPA provides the image for sid this one usually contains the latest version of golang
16:26:39 <shelikhoo> and they don't even try to follow upstream's security fix, unless specifically told to do so
16:26:43 <meskio> (it usually takes few weeks to land)
16:27:13 <shelikhoo> at least they applied too many patch to v2ray, and is unable to sync to upstream change
16:27:25 <shelikhoo> let's say years behind
16:27:44 <meskio> true, there are some packages that are not that well maintained in debian
16:27:48 <meskio> but I do think golang is
16:27:57 <shelikhoo> Yes
16:29:59 <meskio> another good thing of TPA containers is that we (as in Tor) controll the whole build process and don't need to trust docker hub
16:30:08 <meskio> but in exchange we have to trust gitlab
16:30:29 <meskio> that tends to have serious security issues once in a while
16:31:10 <shelikhoo> My personal opinion is that we could keep using debian as the base image, but we can either build from source from author like rbm did, or use binary release from author either with container image or binary download
16:32:08 <shelikhoo> In V2Ray's case the build process of both executable binary and the container build process is fully reproducible
16:32:14 <shelikhoo> so there is no need to trust the builder
16:32:23 <meskio> I trust debian to check software, while downloading binaries from upstream looks more scary
16:32:44 <meskio> but I guess I have different trust ankors
16:32:52 <dcf1> I don't know what the containers and gitlab runner are even used for. My naive question is, what is the goal you are seeking? To reduce maintenance, increase compatibility, increase pace of updates...? What's the existing problem that is being fixed?
16:33:20 <meskio> our problem currenctly is the CI failing because we hit rate limits in docker hub
16:33:30 <shelikhoo> this problem is fixed
16:33:34 <meskio> TPA provides some base containers: https://gitlab.torproject.org/tpo/tpa/base-images/-/tree/main?ref_type=heads
16:33:45 <meskio> I added golang there thinking that we'll use it
16:33:57 <dcf1> shelikhoo: it sounds as if what you are looking for is for the team to support your position and say: we don't want to use debian images because of X, Y, and Z. But what is the deeper cause?
16:35:12 <dcf1> If it's some obstacle that is getting in the way of your progress, you should have some say in how it is removed. Or is it something that affects many people on the team?
16:35:59 <dcf1> I apologize, I feel my questions may be impertinent because I do not know the context or background.
16:36:42 <cohosh> it affects us in the sense that we all have to deal with CI failures, but i honestly don't have a strong opinion as long as the CI failure due to rate limits issue is fixed
16:37:03 <shelikhoo> yes, the deeper cause is I don't have many faith in debian in deciding what people should run
16:37:15 <dcf1> Aha! Rate limit failures, that's it. Thank you.
16:37:46 <shelikhoo> I have fixed the rate limit issue with https://gitlab.torproject.org/tpo/anti-censorship/duplicatedcontainerimages/
16:38:30 <shelikhoo> debian's issue is that they have a way of doing thing, and force software author to either comply with it or get delay in package update
16:38:31 <dcf1> Okay, fixed the rate limit issue, at the cost of some maintenance effort by the team to maintain duplicatedcontainerimages, presumably.
16:38:47 <cohosh> shelikhoo: and the only downside is that our team has to maintain these rather than TPA?
16:39:05 <shelikhoo> I think we can just add what we wants to mirror and it will just work
16:39:18 <dcf1> And the request is TPA is to move the duplicatedcontainerimages maintenance burden onto them? And TPA says, we would rather that you use what we already maintain and provide, rather than add to our maintenance list?
16:40:03 <shelikhoo> the downside is there is no debian authors checking these images
16:40:33 <shelikhoo> TPA wants to delegate the responsibility and decision making power of what one should run to debian
16:40:57 <shelikhoo> I don't like the way debian is delay update of packages
16:41:09 <shelikhoo> so i think we should just get images from author
16:41:11 <dcf1> it is clear that you have a vendetta against debian, yes :)
16:41:14 <shelikhoo> with mirroring if necessary
16:41:22 <shelikhoo> yes, I do
16:41:27 <meskio> :0
16:41:33 <meskio> ups I mean :)
16:42:09 <meskio> I prefer using TPA/debian, but I don't have that strong feelings there and I'm ok using our mirrors
16:42:17 <shelikhoo> but anyway as a employee I am happy with others's decision
16:42:52 <cohosh> shelikhoo: you have the strongest opinion here by far, as long as whatever route you chose doesn't increase unecessary CI failures or maintenance cost then i'm fine with it
16:42:55 <shelikhoo> but anyway as a employee I am happy proceeding with others's decision, whatever it may be
16:43:19 <meskio> looks like we keep using our mirrors for now
16:43:32 <shelikhoo> yes. I think we could keep the current approach until there it stop working
16:44:03 <onyinyang> ok, lets do that for now and move on to the next topic
16:44:06 <shelikhoo> eof...
16:44:27 <onyinyang> Would we like to support WASM version of proxy?
16:44:39 <WofWca[m]> Hey yall again!
16:44:39 <WofWca[m]> So, I ported the Go proxy version to WASM. It works nicely, serving clients (and they're not complaining hehe), I'm running it right now in an extension I hacked up real quick.
16:44:46 <WofWca[m]> There is some maintenance burden coming with it for the standalone version, but IMO it's not that big. Thankfully the Pion gamers did a great job of supporting WASM.
16:44:54 <WofWca[m]> But, I guess the support can be dropped at any time if needed. Should there be a change that is not compatible with the WASM version, the WASM build will simply stop working and that's it.
16:45:05 <WofWca[m]> The thing is that certain methods are not supported by the WASM version of Pion, such as "outbound address", `SetIPFilter`, so I add some conditions to only run them in non-JS builds.
16:45:05 <WofWca[m]> And the Gorilla WebSocket library also doesn't compile to WASM, so I added an option to compile with a different one, coder/websocket.
16:45:09 <WofWca[m]> You can see the change set [here](https://gitlab.torproject.org/WofWca/snowflake/-/compare/main...wasm?from_project_id=43). 351 additions and 49 deletions.
16:45:14 <WofWca[m]> Perhaps later we can consider migrating the extension version to this WASM build, so that we don't have to maintain two implementations at the same time, e.g. for the upcoming "unreliable WebRTC channels" patch.
16:45:17 <WofWca[m]> If you're interested, the reason I did this is, as you might have heard, I'm working on a fork of Snowflake and I thought it'd be easier to add WASM support than porting the changes to the pure JS version of the extension.
16:45:22 <WofWca[m]> And just FYI, porting the client to WASM should also be quite easy.
16:45:32 <WofWca[m]> Now the question: would you all consider merging an MR with this if I made one?
16:47:49 <shelikhoo> WofWca: It looks like you are targeting browser? rather than wasi?
16:47:49 <cohosh> so the wasm is based on the Go snowflake proxy code?
16:48:15 <cohosh> WofWca[m]: this is a very cool exploration, thanks for doing it
16:48:15 <WofWca[m]> shelikhoo: Uhmmm yeah, browser is the target
16:48:24 <WofWca[m]> cohosh: Yep
16:48:33 <WofWca[m]> cohosh: Thanks :)
16:48:58 <WofWca[m]> shelikhoo: Not sure what WASI is
16:49:38 <shelikhoo> WASI is a abi to run wasm outside browser
16:49:55 <shelikhoo> in wasi context there is no access to js
16:50:08 <shelikhoo> but have access to file systems, etc
16:50:21 <shelikhoo> currently there is no network support in wasi preview 1
16:50:38 <WofWca[m]> Interesting. Maybe this will help us support WASI, but the purpose of my work is to make it work in browsers.
16:50:51 <cohosh> so the main advantage for us would be the ability to move all of the snowflake logic to the snowflake Go repository and then the snowflake-webext repo would be mostly the extension and web-based UX implementation
16:50:53 <shelikhoo> but there are many other ABI like wasix etc that does support network
16:51:12 <cohosh> this also means that whenever we make proxy changes we don't have to make them in two repositories with two different languages
16:51:27 <cohosh> the downside is it makes the snowflake Go repository a little more complicated
16:51:45 <WofWca[m]> cohosh: Yep, basically
16:52:02 <cohosh> we will also lose the built-in fingerprinting defense from browser proxies but with covert-dtls that could be less of an issue
16:52:30 <shelikhoo> I think we are using browser api to run webrtc
16:52:33 <dcf1> cohosh: oh, good observation
16:52:37 <meskio> is there any performance change? WASM tends to be faster that pure js, isn't it?
16:52:40 <WofWca[m]> cohosh: The Pion version uses the raw RTCPeerConnection objects, not its own implementation
16:52:49 <cohosh> ah okay thanks
16:52:56 <shelikhoo> so it will be browser's fingprint
16:53:02 <WofWca[m]> So the fingerprint remains the same
16:53:11 <cohosh> that's good to know
16:53:15 <shelikhoo> so it will be browser's fingerprint when running in browser
16:53:32 <shelikhoo> there is no general purpose UDP socket support in webpage context
16:54:00 <shelikhoo> or TCP socket support for that matter
16:54:03 <shelikhoo> over
16:54:13 <WofWca[m]> meskio: I have not checked the performance extensively, but it uses more memory and might be slower with passing messages. But for passing messages I have an idea to outsource message passing to a pure JS function so that the data doesn't have to do through WASM
16:54:23 <cohosh> okay so the main impact on us is from a code maintenance perspective
16:54:46 <cohosh> and maybe performance impacts
16:54:49 <WofWca[m]> shelikhoo: Yes, build-in browser WebSocket and WebRTC are used
16:55:31 <dcf1> https://github.com/pion/webrtc/blob/v4.0.9/examples/README.md#webassembly "Pion WebRTC can be used when compiled to WebAssembly, also known as WASM. In this case the library will act as a wrapper around the JavaScript WebRTC API." I see, interesting.
16:55:39 <WofWca[m]> cohosh: Yea
16:56:24 <WofWca[m]> dcf1: Yeah, I also was really impressed by this. I was digging through the Lantern's Unbounded code and realized they do the same.
16:57:18 <WofWca[m]> But of course I'm not saying that we should migrate the extension to WASM right away.
16:57:28 <cohosh> i'm interested in looking at this more. i don't think we can promise a merge at this point, and any merge would take a long time coming because we'd want to look at what changes to the webextension could be and what the performance impacts are
16:57:32 <WofWca[m]> I'm planning to make my own extension first
16:57:43 <cohosh> nice
16:58:05 <cohosh> i'd say in that case, keep us updated :)
16:58:17 <WofWca[m]> I will
16:58:18 <WofWca[m]> !
16:58:22 <theodorsm> lets postpone the discussion point about covert-dtls to 27. I have to go now. please check out my last comment and feel free to discuss there.
16:58:34 <cohosh> theodorsm: thanks for the update!
16:58:46 <meskio> theodorsm: ok, let's keep this point for next week
16:58:51 <onyinyang> ok, thanks theodorsm
16:59:06 <shelikhoo> thanks!
16:59:08 <onyinyang> also, meskio means next 2 weeks :) since the next meeting is the 27
16:59:13 <meskio> yes, sorry
16:59:23 <onyinyang> hehe
16:59:31 <theodorsm> :) see ya then, ciao
16:59:42 <WofWca[m]> Bye!
17:00:00 <WofWca[m]> cohosh: Would you consider merging the MR if there was not an immediate plan to migrate the extension to WASM?
17:01:14 <WofWca[m]> That is to say that the WASM version wouldn't be used by any of the Tor Project's products
17:01:47 <WofWca[m]> Or is it a requirement that we definitely want to migrate the extension
17:01:58 <cohosh> i don't like the idea of merging code that isn't used just to have it there
17:02:08 <WofWca[m]> Got it
17:02:44 <WofWca[m]> OK, that's it for me, unless anyone has questions
17:02:49 <WofWca[m]> *from me
17:03:03 <cohosh> thanks for sharing this!
17:03:05 <meskio> keep us posted on how this project goes for you
17:03:10 <shelikhoo> personally I think the wasm idea is nice, so I am happy to see how is it going
17:03:15 <onyinyang> thanks for bringing this up WofWca[m]
17:03:29 <onyinyang> ok there are a couple of interesting links on snowflake daily operations before we close
17:03:30 <WofWca[m]> Thank you for the attention and consideration! ♥
17:03:51 <onyinyang> and a quick reminder that we will have a reading group as part of our next meeting on the 27th
17:04:13 <onyinyang> The paper is "Identifying VPN Servers through Graph-Represented Behaviors" https://dl.acm.org/doi/10.1145/3589334.3645552
17:04:24 <shelikhoo> yes! thanks for the reminder!
17:04:42 <dcf1> Yeah if you're curious, 4K Euros for snowflake-01 bandwidth in 2024.
17:04:49 <meskio> 4k on the snowflake bridge badwidth, I see that was also previous years, I forgot is that much
17:05:12 <meskio> nice that opencollective works to pay those bills
17:05:58 <shelikhoo> I wonder if there is a break down bill for snowflake server
17:06:43 <shelikhoo> so that we could know if there is a way to improve the situation
17:06:57 <dcf1> I think we are in a pretty good situation.
17:07:43 <shelikhoo> let's see if we wants to add a new feature that consume a lot of CPU for better speed
17:08:00 <meskio> :D
17:08:14 <shelikhoo> we could judge by the bill break down to see if we wants to spend time in working on that feature
17:09:03 <dcf1> You will have to ask the opencollective project admins if you want more details about the bill, but I am pretty sure it consists almost entirely of bandwidth.
17:09:19 <dcf1> Anyway sorry, I'll let you close the meeting.
17:09:23 <shelikhoo> yes!
17:09:25 <shelikhoo> eof from me
17:09:58 <onyinyang> Thanks everyone for your input on our discussions today :) See you at FOCI!
17:10:00 <onyinyang> #endmeeting