14:57:59 #startmeeting Tor Browser Weekly Meeting 2024-01-22 14:57:59 Meeting started Mon Jan 22 14:57:59 2024 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:57:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:58:05 le pad: https://pad.riseup.net/p/tor-tbb-keep 14:58:17 o/ 14:58:38 This week we'll be releasing Tor+Mullvad Browsers 13.0.9 14:58:48 (thanks for signing last week boklm) 14:59:18 I've signed TB this morning so we'll be ready to deploy tomorrow on time once again 14:59:25 /o brb in 5 14:59:29 o/ 14:59:37 but of course the big priority this week is S96 15:00:14 I ping'd those of you focused on s96 last week on IRC, but this is the last week we have beore we need to send code off for security review 15:00:32 o/ 15:00:40 my understanding is that the security people will be starting browser stuffs on the 29th 15:01:11 Hi! 15:01:26 typically the way this works is that we send them branches with commits/commit-ranges for them to look at 15:01:57 since our stuff is typically all squashed together in ever changing 'feature commits' this shouldn't be too taxing 15:02:55 cool, I had some good progress by the end of last week, I'm hoping to have my new TorController wrapped today/tomorrow and get out MRs with Settings and events working using the new geckoview stuff only 15:03:56 my current thoughts on this is to create a separate 'review' branch for each of our affected projects where it makes sense (tor-browser, firefox-android) which will basically be the latest alpha with any in-flight fixups! squashed together 15:04:55 henry-x, cohosh: how is the Lox integration going? 15:05:22 makes sense 15:06:31 (it sounds like you guys are all super busy this week, so whatever stuff I'm doing will presumably not get your attention?) 15:07:04 jeremy: basically we've been s96 non-stop since the end of october, but that's coming to an end one way or the other come the end of this month 15:07:16 (beyond resolving issues from the security review) 15:07:31 richard: got it, thanks. Good luck on the final push! 15:07:58 (thanks!) 15:10:36 Should I work on polishing up the html UI or try more to get Native to work properly? HTML right since thats what we're shipping? 15:11:20 if there are easy wins for the HTML then I 'd say we can take those this week 15:11:38 clairehust: my new torcontroller should get you a big step of the way there 15:11:43 the thing that comes immediately to mind is the white bar at the bottom of the page 15:11:51 in terms of 'visual impact' 15:12:35 but otherwise i would say focus on work we're planning on shipping in 13.5 come summer 15:12:39 (so Native :) ) 15:13:14 Cool! 15:14:02 iirc PieroV has a MR our for fixing a crash on older Android versions for you to review as well 15:14:21 richard: hey sorry just saw the ping 15:14:29 A decenlty big thing is if you leave the app running for *a while* you come back to a "File not found" screen (a broken about:tor page) 15:14:56 i'm working on henry's latest feedback and should be done with that today, and the eta for the genNextUnlock feature is tomorrow hopefully 15:15:06 * eta for the genNextUnlock feature 15:15:08 I've noticed it dogfooding 15:15:44 and you can swipe "back" on bootstrap and get to landing page with tor unloaded 15:17:08 cohosh: ack 15:18:39 ok does anyone else have topics to discuss? 15:19:06 What about stable releases on Tuesdays at 14 UTC? 15:19:34 ma1: that sounds like a solid plan 15:19:46 made easier by doing mullvad browser earlier 15:20:10 i.e. perfect sync theoretically with Firefox, and fixup release in the unlikely event that draft vs public advisories don't match 15:20:58 sounds like a plan to me 15:22:37 richard: sorry, I missed that the meeting started. I'm waiting on input from UX for tor-browser!890. Starting to write some of the other changes ready for the Lox backend 15:23:26 henry-x: ack 15:23:59 henry-x: hoping to get to that soon! 15:24:10 sorry for the delay 15:24:31 jagtalon: if you could prioritise it we're on a *bit* of a time crunch 15:24:41 richard: you got it! 15:24:49 ugh and speaking of crunches 15:24:55 we have a surprise android problem! 15:25:04 (our x86 apk is too big for google play) 15:25:11 lol 15:25:18 I'll take a look tomorrow too 15:25:22 thanks henry-x 15:25:24 Google Play: "Reduce your file size to 100MB or use expansion files" 15:25:48 clairehurst, dan_b: do either of you know anything about this^ 15:26:07 we aren't even currently packaging the lox bridge binary yet are we? which i assume will be adding a few more MB? 15:26:16 no hadn't seen that ever before 15:26:24 Off the top of my head no but I can look into it 15:27:07 apparently the solution is either use an App Bundle which has a higher limit than an apk or use an expasnion file which is a type of patch if I'm understanding correctly 15:27:15 Can we increase the zip compression? 15:27:27 in theory vOv 15:27:31 And are we sure we're stripping everything? Maybe we have some binary that isn't stripped 15:27:33 ooh lol we're still shipping an .apk to google not a .aab? 15:27:38 but that's either a PeiroV or a boklm problem 15:27:44 :D 15:28:02 dan_b: never heard of aab :) 15:28:09 me neither^ 15:28:11 yeah its googles new prefered format 15:29:01 i am lucky cus for cwtch builds the difference is `flutter build apk` to `flutter build appbundle` 15:29:34 and would it be retrocompatible (heard PieroV talking about retro-support on Android this morning)? 15:29:52 also a good point 15:29:57 but i don't think folks can manually install .aab? so open privacy publishes the .apk for folks and ships the .aab to google play store 15:30:30 which means we build both, which for TB is deeeeef gonna increase android build step time some, but maybe not too bad as it should mostly be packaging 15:30:35 boklm/PieroV: can you prioritise investigating if we have any easy wins for making our existing apk smaller? 15:30:44 tor-browser-android-x86-13.0.7.apk was 109M so I'm wondering why we didn't get the error before 15:31:16 there seems to be some different rounding involved 15:31:19 .aab being newer and more modular in some way means when google p;ay ships updates it can ship partials and leave unchanged bits alone, so they save on a lot of bandwidth, and its easier on users 15:31:24 the current x86 is 110mb 15:31:37 the only one less than 100 mb is armv7 15:31:48 and google play isn't complaining about them 15:32:30 new rule maybe, or unit rounding. 15:33:00 boklm: is there a MB / MiB confusion in the docs perhaps? 15:36:10 seems likely 15:36:12 anyway 15:36:27 we can move this discussion over to #tor-browser-dev and let folks go from here 15:37:37 sure 15:41:16 alright folks 15:41:18 have a good week 15:41:20 #endmeeting