15:57:33 #startmeeting tor anti-censorship meeting 15:57:33 Meeting started Thu Dec 21 15:57:33 2023 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:57:33 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:57:36 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 15:57:38 ask me in private to give you the link of the pad to be able to edit it if you don't have it 15:57:44 I'll wait few minutes for everybody to add you've been working on and put items on the agenda 15:58:00 hi 15:58:48 shelikhoo: I've removed the discussion point on your changes for snowflake, let me know if I should bring it back if there is something to discuss there 15:59:21 I think we can remove it 15:59:29 :) 15:59:40 let's discuss it again once there are some review on the merge request 16:00:00 sounds good 16:00:08 for the next two weeks we are taking a break 16:00:23 there will not be meetings on December 28 neither January 4 16:00:54 I'm also planning to be AFK until februrary 16:01:15 the first discussion point is: 16:01:19 Tor Browser users on Windows 7/8 have started having problems with PTs because Go 1.21 removed support 16:01:38 o/ 16:02:23 go ahead ggus 16:03:55 ggus: did you add that discussion point? 16:04:02 oh i added it 16:04:08 because it seemed like something to be aware of 16:04:13 :D 16:04:14 though i'm not sure we want to make changes 16:04:35 it's really unfortunate how difficult it is to keep old hardware/software up to date 16:04:38 we could create a polyfilled random source library 16:04:56 whot? 16:05:07 and most library accepts a random source input in config 16:05:57 and we implement os detect and use appropriate random source in the random source library 16:06:24 https://pkg.go.dev/crypto/tls#Config 16:06:31 there is a rand we can set 16:06:41 is the random source the only problem in win7? 16:06:55 and we could implement this interface ourself to fix this issue 16:07:59 I wonder if is worth the effort, if go doesn't support win7 I expect future versions to become less compatible, and it looks like by our dependencies we keep being pushed into newer versions 16:08:37 yes, we don't know how many resource are required to keep win7 work in long term 16:09:00 otoh if it's not too invasive and extends the life of snowflake for a while it's worth considering 16:10:28 i might take a try at it just to see what it looks like and if it works 16:10:39 sounds good 16:11:21 anything else on this topic? 16:11:31 not from me 16:11:43 manifest v2 16:12:01 chrome seems to plan to stop supporting it in June 2024 16:12:18 we have ~6months to fix the snowflake webextension 16:12:25 or be ready to loose chrome users 16:13:00 the chrome store claims that this will mean loosing 80k snowflakes 16:13:27 there's been some changes to service workers since i last looked at this 16:13:27 compared to less than 20k firefox ones 16:13:28 o.O 16:13:57 the last time i looked, we can still make this work with manifest v3 16:14:12 but it involves having the webextension open a tab with a snowflake badge 16:14:14 ahh, cool, so we don't need the hacks around 16:14:22 well, that's pretty hacky 16:14:32 I see, yes, that is what I mean by hacks 16:15:13 but better that nothing 16:15:24 the main problem was that service workers go to sleep and when that happens the webrtc connection the proxy had open closes 16:15:37 which happens pretty quickly 16:15:56 there was some discussion about making the threads aware of open connections and preventing them from idling in that case 16:16:03 so if that was implemented we might be okay 16:16:22 i'll pick this up in the new year 16:16:31 yes... did you try return a promise that never resolve? 16:17:26 in js sematic, this means the event never finished processed, and this works in some environment to keep the js active 16:18:37 i didn't think that was sufficent but i'll make sure to try it 16:19:13 yes... that was just a suggestion and may not work... 16:19:37 anything else on this topic? 16:19:41 this is the discussion of what triggers the background page to idle (for firefox): https://bugzilla.mozilla.org/show_bug.cgi?id=1771203 16:20:08 :) 16:20:18 though i think firefox will continue to support v2 indefinitely 16:20:29 nothing more from me for now 16:20:41 yes, seems to be a chrome only issue 16:20:43 this would affect brave browser too, right? 16:21:00 ggus: yes, and edge and whoever uses chrome 16:21:20 I don't think they will be able to keep supporting manifestV2 if chrome drops it 16:21:37 but brave could hide our hacks, so users don't see the tab 16:21:59 yeah, we talked briefly with them and they said something about being willing to continue supporting it but i'm not sure how much we should rely on that if it requires extra work from them 16:23:32 let's move on to the next topic 16:23:36 validation for bridgelines 16:23:53 there is a discussion about how to validate bridgelines in TB at https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41913#note_2978927 16:24:12 I went ahead without thinking much saying things like a bridgeline should always have a fingerprint 16:24:24 and I just found out that our conjure bridgeline doesn't have one 16:24:41 AFAIK c-tor does support bridgelines without a fingerprint 16:24:50 I think armored bridgeline design should be the best solution to this issue 16:24:56 but we tend to use it so the connection cannot be MitM 16:25:25 although it would take some work to get anther version of it finished and approved 16:25:26 shelikhoo: I agree, but the grant we wrote to support it is ~1year away :) 16:25:30 iirc arti needs a fingerprint in its bridgelines 16:25:36 i don't think i had a good reason for not including the fingerprint other than the bridge was a test deployment and i wasn't sure how the interaction with the station would go and whether the deployment would change 16:26:26 but it would be annoying for users who didn't have a fingerprint to find their bridge settings suddenly stopped working 16:27:06 I think a validation failure should not block a user to put whatever they want in the bridgeline 16:27:15 I think it should be a warning and not a heavy error 16:27:34 that sounds reasonable 16:27:39 and it should validate 'common' usage of bridgelines but leave space to manually push uncommon ones 16:27:49 like non-fingerprint 16:27:58 or a PT that we didn't listed yet 16:28:23 I thought vanilla bridges should fit in the 'uncommon ones', but ggus convinced me of the oposite 16:29:42 yeah, tor-relay-scanner is big in russia> https://github.com/ValdikSS/tor-relay-scanner 16:30:11 yes, I forgot that mean using a relay as vanilla bridge 16:31:33 and sometimes we use this trick (relay as vanilla bridge) for network health debugging 16:32:37 I guess for now is a good idea to support non-fingerprint bridgelines, so there are not surprises in the future 16:32:51 but maybe we want to add a fingerprint in the future on conjure bridgelines 16:33:01 yeah 16:34:32 there is nothing more in the agenda 16:34:42 something else to discuss before we go for a break 16:35:44 nope, but just want to say thanks ac-team for all the hard work this year! 16:36:04 <3 16:36:06 <3 16:36:14 thank you ggus too for all support you give us and to push us in the right direction :) 16:36:14 next year we will have more than 40 elections :) 16:36:15 happy new year! thanks for everyone's work this year! and see you next year! 16:36:20 thank *you* ggus! 16:36:22 fun 16:36:31 happy new year and enjoy the break!!! 16:36:36 and looking forward see you next year! 16:36:52 #endmeeting