14:59:38 #startmeeting Tor Browser Weekly Meeting 2022-08-02 14:59:38 Meeting started Mon Aug 8 14:59:38 2022 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:52 here's the pad: https://pad.riseup.net/p/tor-tbb-keep 15:00:02 so the way we typically do this weekly meeting thing 15:00:27 is we each have an entry in the pad, with a sort of rolling record of planned weekly activities vs what actually happened 15:00:57 there's a section for announcements and any discussion points people wish to bring up 15:01:16 and traditionally we've also *bolded* any items in your individual seciton that you may want to discuss 15:01:31 o/ 15:02:04 we also tend to take this time at the start of the week to update our boards, make sure our assigned issues are in the 'right' columns, etc etc 15:02:38 as that helps gaba and I a lot with planning and more importantly making sure you all aren't overloaded with too many random asks 15:06:05 done 15:06:25 welcome back to the browser meeting donuts :) not too early I hope ;) 15:06:43 tyvm, this is a lovely time lol 15:06:47 :) 15:08:00 * Jeremy_Rand_Talos_ likes this new timeslot 15:08:10 ya right 15:08:21 i think i made it to the old one twice 15:08:55 :) 15:10:29 alright let's start with the discussion points 15:11:05 PieroV: what's the current status of your various 102 rebases, and what work is stil outstanding? 15:11:47 I've decided to switch to Rust official binaries as a workaround, and wait for boklm to see together what we can do 15:12:05 I've chatted also with GeKo earlier, to understand some history behind why we compile Rust 15:12:23 TL; DR: it may be needed for reproducibility, in case we need to add patches. 15:13:25 Long-term it might be interesting to use Guix instead of Debian in that container, since they bootstrap Rust entirely from source. (I talked to boklm about this in 2019.) 15:13:43 Anyway, I've also opened a thread on Rust forum to ask if someone knows how rustc official binaries are created. The plan is trying to reproduce their builds (probably not byte by byte, but at least the same config) and then try to get our usual rustc build by steps 15:14:49 are we blocked on anything else beyond Rust for getting some test builds? 15:15:06 No. With this workaround I have both a working base browser and Tor Browser 15:15:28 well that's just great 15:15:37 ok now what about for Android? 15:15:38 Base browser has a pair of things to fix (the NoScript icon is visible, and the Tor Browser name is used in the Security Level strings) 15:16:07 (yes we do have a few more 'tor' mentions here and there in the base-browser source) 15:16:10 Also, the settings contain a new "More from Mozilla" page, which is enabled/disabled by Nimbus and Moz experiments. We'll have to investigate about them 15:16:44 About Android, I'd like to test the new branch to build also GeckoView. I'll have to check a pair of things, first 15:17:17 One is the preferences in 000-tor-browser.js. Then I think we could add the mozconfigs like we do for desktop 15:17:51 mmhm, we need to do a similar pref split between base-browser and tor-browser there like we do for desktop right? 15:17:54 Also, I'd prefer the Android tor-browser-build MR to be merged before the one for 102 desktop 15:18:38 richard: it could be. But also I'd like to check if GeckoView has some preferences that weren't added to desktop files. Both in the shared preferences, and in the mobile preferences 15:18:55 ok 15:19:36 richard: anyway, do you thing we can merge tor-browser!337, and then proceed with fixups, or would you prefer to wait until everything has been fixed? 15:20:35 yeah that sounds good to me 15:21:07 Which one? :) 15:21:29 sorry, i'm ok with comitting and doing subsequent fixups 15:21:45 PieroV, switching to Mozilla Rust binaries will disrupt my ARM branch, but I can just not rebase it for a while if you want to get 102 into tor-browser-build ASAP. 15:22:35 Jeremy_Rand_Talos_: I'd switch to Rust binaries, not Mozilla's 15:23:00 so yeah, I'd like to get 102-based alphas going asap, and optimistically hope for an esr102 alpha release for end of aug/start of sept 15:23:01 Anyway, I'd still need to review that workaround, to enable it only on Linux 15:23:23 Err, about "esr", Mozilla still hasn't added an esr102 branch 15:23:37 To gecko-dev, I mean, they have one in hg. 15:23:44 PieroV, same thing for me :) My branch assumes we're building Rust from source with custom build flags 15:24:12 and the sooner we can find and fix reproducibility issues the better 15:24:44 Pierov: yeah it's an open issue apparently, i don't see anything wrong with basing off of the hg branches 15:25:04 It will include a lot of history we already have 15:25:22 s/include/add/ 15:26:09 ugh that is true 15:26:43 Unless the hg-git branch is smart enough to start from the newest common commit 15:27:31 err, sorry, I meant hg-git bridge 15:27:36 yeah 15:27:53 i'm not sure there's anything we can really do to fix that 15:28:36 anyway 15:28:52 donuts: i'll get an updated release schedule out today promise 15:29:03 richard: ty <3 15:29:15 and re apple arm builds, that should be doable, last I checked we have a branch that gets it working we just haven't merged it yet 15:29:33 donuts: My linux-arm port is 32-bit, and Apple Silicon ARM chips only support 64-bit, but my port is designed intentionally to make additional linux-cross targets easy to add. 15:29:50 I recently got my hands on some ARM 64-bit hardware (PinePhone) so I should be able to do a linux-arm64 port once the linux-arm and linux-ppc64le/linux-ppc64 ports are merged. I would exxpect that port to run fine on Apple Silicon, unless the Apple Silicon 16 KiB page size tickles some bugs. 15:30:00 awesome! ok – let me know if there's anything I can do, I have an M1 mac I can do some ultra rudimentary testing on 15:30:03 (like, designer level testing) 15:30:25 Jeremy_Rand_Talos_: oooh good to know 15:30:34 there will be a bit of work needed to update the website to point to the arm mac builds too 15:30:46 Jeremy_Rand_Talos_: in my dream I'd love to compile Clang once for all platforms 15:31:09 If we add ARM maybe we can compile it for all ARM targets, including Linux, macOS and Android 15:31:11 richard: right, it could be messy 15:31:27 I'm planning to completely redesign /download but that won't be ready until end of Q4 at the earliest 15:31:41 so maybe it'll just need to be messy until then 15:31:41 once we have 102 initially working/building we should get multi-locale builds working 15:31:50 was about to write it :) 15:31:52 because while i love supporting lots of hardware 15:32:13 yeah :) 15:32:33 ok 15:32:40 finally 15:33:04 it would be super nice if Mac ARM and the new Mac application icon land at the same time 15:33:12 our apple users will like that 15:33:28 nightly builds are broken, and incrementals have been broken for awhile (which is somewhat surprising given alpha worked fine) 15:33:54 so I think i'll be looking into that this week 15:34:12 alright let's move on to dan_b and ma1's entries :) 15:34:28 dan_b: how goes tor-browser#41075 ? 15:34:57 good 15:35:07 I think I found the issue friday 15:35:34 in SSLServerCertVerification.cpp 15:35:49 oh neat 15:35:52 not what i was expecting 15:36:07 looking to test this morning to see if I can force a fix or if it's reporting certerror but not the cause 15:36:44 but my next questions are: if it's there, do we have preferences for where to fix things? like at the root as often as possible so less side effects, or higher up in the code anywhere? 15:37:09 and secondly do I need to be looking at fixing this in an existing patch or will a new commit be ok? 15:37:24 ok 15:38:03 so in terms of 'where' to fix there are a couple of trade-offs I try to consider in these types of patches 15:38:41 so in general you'd want to fix things as close to the root cause of the problem as possible 15:39:03 but we're working on an ever shifting pile of code we don't control 15:39:36 so 'ease of rebasing' is maybe an equally important consideration 15:40:16 how does one determine what makes better rebase targets? 15:40:49 like if I can find somewhere we're already patching rather than adding a new point? 15:41:09 i think it kind of depends 15:41:19 one sort of heuristic is looking at the commit history for a potential fix location 15:41:41 if it's a fairly stable piece of code then that's better than something with a lot of churn 15:41:47 cool! 15:42:40 as you can imagine, the UX parts of the onion communication expectations patch (that adds the onion icons) has probably had to be fixed with each rebase as mozilla fucks around with the idenity-block 15:43:02 right 15:44:13 but really it varies from patch to patch and we can hash i tout in review 15:44:17 in my experience, adding is always better than removing/replacing 15:44:18 in terms of new commit vs fixups 15:44:31 ^ true 15:44:46 removing will lead to conflicts 15:44:52 ok cool. Well, once I confirm I have the right location I can start looking at what fix will look like and ask more questions :) 15:45:08 So, adding some ifdefs is better. It will lead to conflicts anyway, but they're usually easier to fix 15:45:43 in general too, in the JS layer we sort of have converted to a sort of pattern for adding new major functionality (see the TorSettings, TorConnect, commits) 15:45:59 converged to* 15:45:59 (I tend to try to accept all Moz changes and then reapply ours when rebasing, so I prefer add things because it's easier with this workflow) 15:46:54 ok re commits vs fixups 15:47:23 if it is an 'upliftable' bug (ie if it's an underlying issue in firefox) we tend to keep them as separate individual commits 15:47:58 which get shuffled to early to the 'base-browser' section of tor-browser.git after the monthly rebase 15:48:46 if we're fixing an issue in on of our added components (so the TorSettings module for example) then we'd commit that as a fixup! to that feature's commit, which get's autosquashed during the monthly rebase 15:49:41 so which route we go with your particular patch depends on which bucket the fix falls into 15:50:00 See also this comment to understand how patches are ordered: https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/242#note_2769048 15:50:16 cool! thanks 15:50:37 oh a good comment indeed :3 15:51:08 ok finally 15:51:10 ma1! 15:51:30 Ehy, so: I've got the backend of the anti-leak feature ready. 15:52:07 I hoped to come here with a working beta, but was slowed down by an on-the-fly (literally!) XSS filter fix release ( https://twitter.com/ma1/status/1556570471948292097 ) 15:52:49 lol 15:52:50 OTH, I get this chance to ask for suggestions about the UX aspects. 15:53:05 donuts^ 15:53:39 In their paper they talk about exceptions for "legitimate use cases like ads and trackers" (sic!), but I'm more concerned about popup-based oAuth workflows. 15:53:52 mmhm 15:55:05 Anyway, I'm surely going to limit the feature to private browsing windows (i.e. all the TB ones, right?) and strip cookes from any request in tabs that have been opened or or opened other tabs cross-site. 15:55:35 ma1: the default configuration for TBB is to have only PBM 15:55:45 But some users tend to disable this setting 15:56:15 yes 15:56:18 Indeed. If you think tor browser / incognito users are likely to perfom oAuth in their "private" sessions, some kind of warning and "disable for this transaction" interaction should be included. 15:57:11 btw, is it something related to tor-browser#14085? 15:58:06 PieroV: no, but I'm taking note to look into that as well. 15:58:15 (I think we'll have to continue on #tor-browser-dev) 15:58:23 yes we have 1 minute 15:58:32 OK. 15:58:42 let's migrate! 15:58:46 #endmeeting