14:58:50 <richard> #startmeeting Tor Browser Weekly Meeting 2023-07-03
14:58:50 <MeetBot> Meeting started Mon Jul  3 14:58:50 2023 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:58:50 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:55 <jagtalon> o/
15:00:03 <richard> hello everyone!
15:00:17 <richard> the pad as usual: https://pad.riseup.net/p/tor-tbb-keep
15:01:33 <richard> this week we should be releasing tor|mullvad browsers 12.5.1
15:01:42 <PieroV> richard: already building TBB
15:01:51 <PieroV> I need review on the MB rebase
15:02:03 <PieroV> But I already prepared it when preparing TBB
15:02:09 <richard> ma1: i remember seeing your q about backports in email, but I don't remember if i answered
15:02:33 * Jeremy_Rand_36C3[m] notes that the Riseup onion isn't loading for me today (seems to be timing out on JS-issued network requests), so won't be able to fill out the pad today
15:02:47 <ma1> richard, yep. Question about desktop ESR-wontfix bugs
15:02:47 <richard> PieroV: I can review later today
15:02:59 <PieroV> richard: ack, thanks
15:03:12 <richard> ma1: I should probably update the issue template but
15:03:31 <ma1> richard, there's nothing Android specific. I flagged ~3 bugs which we might have wanted to look closer if interested.
15:04:35 <richard> my approach for security backports has been: backport all the android fixes that apply cleanly and look into the difficulty of backporting hte ones which don't and make an arbitrary'ish decision re risk/reward, for desktop I look through all of the issues that are fixed in RR but not ESR an figure out why they haven't been backported
15:04:57 <richard> generally for desktop, if the patch applies, is part of a slow moving system, etc I will bring it back to ESR
15:05:24 <richard> usualy Mozilla doesn't backport patches for developer things (like the inspector/debugger)
15:05:34 <richard> but we brought a copule of those back over the past year
15:05:57 <richard> but i'll look at the specific bugs with further guiance later today
15:06:42 <ma1> Yes, probably just the couple of bugs I flagged because fuzzying-found stuff which was not obviously unrelevant to ESR.
15:06:58 <richard> boklm: anyway, I'll plan on signing+publishing the stable releases this week once they are ready
15:07:27 <richard> this week i'm going to try and focus on gitlab and get our roadmap into issues an labeled and all of that fun stuff
15:07:57 <PieroV> richard: could you also review the final 115 rebase, or reassign it?
15:08:06 <richard> if anyone is wondering wtf they should be doing let me know
15:08:17 <richard> PieroV: will do
15:08:29 <PieroV> Thanks! Once it's merged we should be able to move further developments there
15:08:30 <boklm> ok
15:08:43 <PieroV> However, if any of you did developments on b5, rebasing to it should be trivial
15:11:27 <richard> ok i don't have any further topics so let's hand over to discussion
15:13:14 <PieroV> It seems I'm the only one with discussions?
15:13:30 <richard> (I think so)
15:13:54 <PieroV> So, in my refactor work of the tor integration stuff, I've noticed that at some point IPC on Linux+macOS became the norm both for SOCKS and for the control port
15:14:37 <PieroV> At least, several comments says so. However, TCP is the norm at the moment. I've found that the reason was to allow TorBirdy to use the tor instance of the browser
15:15:09 <PieroV> This reason doesn't hold anymore, but the advantages of IPC still do (esp. having multiple Tor Browser versions at the same time :))
15:15:44 <PieroV> Or even having multiple profiles of the same instance, since multiple profiles are possible now that we ship NoScript in the distribution directory also on Linux (and Windows, which doesn't support IPC)
15:15:57 <PieroV> (IPC as Unix sockets, which is what Firefox and Tor support)
15:16:17 <PieroV> ((except that maybe Windows 10 started supporting it, but Firefox and Tor still don't))
15:16:33 <richard> iirc there's *some* support for windows pipes
15:16:39 <PieroV> So, what about switching to IPC by default on Linux and macOS?
15:16:41 <richard> I think i touched that coe some years ago
15:16:59 <Jeremy_Rand_36C3[m]> As noted in #tor-browser-dev earlier today, with my Outreachy mentor hat on, I would very much be in favor of switching to Unix sockets wherever possible, due to their much better support for proxy leak auditing/blocking
15:17:16 <Jeremy_Rand_36C3[m]> richard: Windows Unix sockets and Windows named pipes are totally different API's
15:17:50 <richard> so my only worry here is potentially breaking some users that are using tor browser's tor daemon in a similar way tor birdy used to
15:17:50 <PieroV> richard: I skimmed only through man tor, and quickly checked the function we use to open a control port on unix sockets, I haven't checked further
15:18:13 <Jeremy_Rand_36C3[m]> (The Unix socket support in Win10+ is designed to exactly mimic what Linux/macOS have; named pipes are a much older thing in Windows that isn't designed to be cross-platform)
15:18:14 <PieroV> richard: so, they are already passing variables for the password, or modifying the torrc
15:18:29 <PieroV> they can keep doing it
15:18:59 <Jeremy_Rand_36C3[m]> richard: the only such app that hijacks Tor Browser's tor daemon that comes to mind is OnionShare, and it supports Unix sockets
15:19:34 <Jeremy_Rand_36C3[m]> (I'm not sure if it can automatically hijack a Tor Browser launched Unix socket, but if not that should be a trivial patch for Micah to do)
15:19:43 <PieroV> We can also wait to properly support Arti
15:20:05 <richard> another concern is that we'd be running different code-paths on winows vs the unixes
15:20:08 <PieroV> At that point people will go looking at the docs, and surprise surprise, we change something also for little-t-tor :)
15:20:13 <henry-x> What is the advantage of using IPC if we still have to use TCP for windows?
15:20:28 <ma1> yes, having 2 different code paths was my concern as well.
15:20:39 <Jeremy_Rand_36C3[m]> henry-x: Unix sockets are much better in terms of sandboxing, e.g. you can rig AppArmor to automatically block proxy leaks
15:20:55 <PieroV> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20111
15:21:14 <Jeremy_Rand_36C3[m]> Also different app instances won't interfere with each other
15:21:44 <ma1> otho we could just say "to hell windows users, they're already backdoored anyway" :P
15:22:21 <richard> i'm also slightly hesitant to invest too much into the legacy tor backend when if all goes well we'll be throwing it out in a year w/ arti integration
15:22:21 <Jeremy_Rand_36C3[m]> ma1: I mean, I do think we should aim to support Unix sockets on Windows, but I don't think the difficulty of doing so should dissuade us from doing it earlier for Linux/macOS
15:22:58 <Emil[m]> Haven’t paid attention earlier, but unix sockets offer the fd passing between processes. A sometimes fundamental concept in sandboxing. ^^
15:23:55 <Jeremy_Rand_36C3[m]> richard: shouldn't be much investment to do it on Linux at least, since it's just flipping a default, and the code paths are well tested since I believe it's the default on Whonix
15:24:08 <Jeremy_Rand_36C3[m]> Not sure how well tested the macOS code paths are
15:24:13 <richard> that said, I'd be fine with investing in this (or similar work to switch to a control port file and a dynmic tpc socks listener for the multi-profile/tor-bowser scenario for all desktop platforms) after we've made some headway in the planned sponsored work for this summer
15:24:33 <PieroV> richard: it's a preference flip
15:24:47 <richard> ah
15:25:04 <PieroV> Unix sockets are already a thing, just not the default
15:25:26 <richard> so no dev work really needed? just a matter of testing in alpha?
15:25:39 <PieroV> Yes
15:26:03 <richard> well that's another thing entirely then
15:26:07 <PieroV> And testing in alpha will be needed anyway because of my changes, but the differences between TCP and Unix sockets are minimal
15:26:27 <PieroV> They're exactly the same code for the control port, except the creation of the transport object on which read and write are called
15:26:27 <richard> let's aim for flipping it in 13.0a1 and test over the summer
15:26:38 <Jeremy_Rand_36C3[m]> +1
15:26:51 <ma1> sounds like a solid plan :)
15:26:59 <PieroV> For the SOCKS part, just changing Firefox's pref for the server host
15:27:15 <PieroV> + the args passed to tor
15:27:23 <richard> let's just make sure Tails folks are looped in just in case we accidentally break the linux TCP path somehow
15:27:30 <PieroV> Apart from that, they're exactly the same
15:27:38 <boklm> sounds like a good idea
15:27:46 <PieroV> richard: I think they pass environment variables
15:27:58 <PieroV> So they skip our changes
15:28:16 <richard> yeah it should be fine
15:28:22 <Jeremy_Rand_36C3[m]> Whonix definitely passes env vars, I'd be very surprised if Tails doesn't as well
15:28:24 <PieroV> But we can ping them anyway. Since we have a decision I'll create an issue and make sure to ping them
15:28:43 <Jeremy_Rand_36C3[m]> But yes still good to keep them in the loop
15:29:21 <boklm> (maybe they are already using unix socket)
15:30:04 <Jeremy_Rand_36C3[m]> I kind of hope they are, seeing as Tails uses AppArmor all over the place, it would be a shame if they're not benefiting from AppArmor's support for Unix sockets
15:30:06 <PieroV> I don't know for SOCKS, I don't think for control, it depends whether onion grater supports it
15:31:15 <richard> ok sounds like a plan
15:33:39 <richard> any further topics to discuss today?
15:33:45 <Jeremy_Rand_36C3[m]> So, funded work has begun on our NLnet grant covering Electrum-NMC. Main thing that'll interest you is that Robert is adding .onion domain validation to the Electrum-NMC GUI, so if you try to point a .bit domain to a .onion that you fat-fingered, it'll yell at you rather than silently making your domain stop resolving.
15:34:16 <PieroV> nice :)
15:34:48 <Jeremy_Rand_36C3[m]> That's all from me, I think
15:35:12 <PieroV> Jeremy_Rand_36C3[m]: do you think you will update the namecoin tor-browser-build stuff sooner then?
15:35:29 <PieroV> IIRC it's still disabled
15:36:40 <Jeremy_Rand_36C3[m]> PieroV: I'm planning to at least send in a PR that nukes the TorButton patch and re-enables Namecoin in Nightly; Arthur is also still working on the rewrite of the TorButton patch, last I heard he's been bogged down with $DAYJOB and has had less time to work on it than hoped. Hoping we'll have something to submit there in a few weeks.
15:37:33 <PieroV> ack. Please, take into account that I have some changes for the circuit display on hold
15:38:17 <PieroV> They'll probably won't affect what you do, they're mainly about moving the circuit collection to the domain isolator file (that is "more privileged" in a certain sense, because it knows the browser for which it's hijacking the credential)
15:38:33 <Jeremy_Rand_36C3[m]> PieroV: OK. Is there a branch I should point Arthur to, so that he's aware of what's in-progress?
15:39:11 <PieroV> It's a giant branch because I've been doing the whole torbutton refactor/removal work there: bug_41842. I will create new branches to split it into at least 3 MRs
15:39:57 <PieroV> Jeremy_Rand_36C3[m]: also, I thought that for eTLD we don't need to change the code of the automaton: we can add an immediate check for .onion files and then skip Firefox's builtin code completely
15:40:04 <Jeremy_Rand_36C3[m]> PieroV: ok. When you create new branches, it would be great if you could ping me so I can relay that to Arthur
15:40:14 <PieroV> Jeremy_Rand_36C3[m]: ack, I'll ping you in the MRs
15:40:57 <Jeremy_Rand_36C3[m]> PieroV: so, Namecoin uses both the .bit.onion and .bit eTLD's. It would be great if whatever solution we find works equally well for both.
15:41:12 <PieroV> ack, we can continue offline for that :)
15:41:19 <Jeremy_Rand_36C3[m]> yep, sounds good
15:42:34 <richard> ok
15:43:05 <richard> also a reminder tomorrow is a America day and an official holiday so it shoul be pretty quite around here :)
15:43:13 <richard> official tor holiday*
15:43:21 <richard> quiet*
15:43:34 <richard> and with that, have a goo week everyone o/
15:43:36 <richard> #endmeeting