14:58:14 #startmeeting Tor Browser Weekly Meeting 2023-04-03 14:58:14 Meeting started Mon Apr 3 14:58:14 2023 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:58:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:58:32 pad per usual: https://pad.riseup.net/p/tor-tbb-keep 14:58:36 o/ 14:59:01 Hi! 14:59:05 hi 14:59:48 o/ 15:00:49 ok everyone 15:01:16 today is release day, and by all accounts Mullvad Browser 12.0.4 seems to have been well received :) 15:01:51 \o/ congrats! 15:01:56 o/ 15:02:10 Great job everyone! 15:02:12 i know it's been said elsewhere, but I'll say it again: y'all have absolutely killed it working on this from start to finish 15:03:10 good job, everyone! very nice. 15:03:17 and generally please please take some time off before the in-person dev meeting 15:03:22 a wild GeKo appears! 15:03:24 o/ 15:03:27 i'd been talking with fredrik about that project years ago 15:03:27 congrats! 15:03:45 Congrats everyone! 15:03:51 and i am glad to see it finally happening 15:04:14 (fredrik being one of the mullvad ceos) 15:04:37 👏 15:05:12 congratulations! 15:05:36 iirc next Monday is an official holiday in Italy and some folks have mentioned taking it off so if there's on objetions I think we should either move (or outright cancel) next week's browser meeting 15:06:55 this friday is a canadaian stat so since it's already off, I'll prolly switch it to monday next week? 15:07:09 richard: if the next meeting is cancelled (which is fine for me), what do you want me to do with the circuit display recommendations that I've *almost* finished coordinating on with the Whonix team? (I was thinking I could cover it at the next meeting, but I don't mind an async IRC discussion or a GitLab thread) 15:07:28 If you want to simply push it back by 1 week that should be OK too I think 15:07:43 jeremy: so we're planning on having those changes in alpha for testing on the 17th 15:08:16 so there shouldn't necessarily be any harm in delaying any proposal/fixes/etc for whonix until after that (since stable isn't do for several months) 15:08:24 yeah a push back should be fine 15:08:54 dan_b: perfect 15:09:25 richard: OK, so if it'll be that soon, maybe it would be good to have some kind of discussion before 2 weeks from now 15:09:33 It doesn't sound like the requests are going to be too hard to implement, but still will maybe need a bit of discussion 15:09:43 ah I see 15:10:13 As I was saying in #tor-browser-dev, I initially thought of taking only next Monday, but things happened and richard asked so nicely, so I'll take the full week 15:10:25 hehe 15:10:26 So canceling works for me :) Otherwise I'll catch the logs 15:11:02 OK yeah, let's plan on having a discussion about it in the meeting 2 weeks from now. 15:11:26 That'll also give me and the Whonix guys a little breathing room to properly figure out the recommendations without any rush. 15:11:40 perfect 15:12:14 ok looks like we've a big section on S30 15:13:00 henry-x, dan_b, donuts: how has this work been progressing, do we have any major blockers/risks leadin gup to the user testing in two weeks? 15:13:34 I've just added a list of priorities to the pad that links to the tickets we 100% need finished (pretty please) ahead of w/c April 17th 15:13:45 i'm waiting on review the seconding on my MR and need some extra info/help from PieroV on the schemeflood stuff cus i'm not sure what i'm supposed to be seeing in stock TB so i cant tell if the changes affect it (i think not?) 15:14:03 dan_b and henry-x are already aware (and in some cases, already doing) most of these issues 15:14:11 then i'll try and get one more ready for then, but its the bridge enhancement one, its a bunch of small things, so no garuntees it'll be ready in time, but hopefully 15:14:17 dan_b: the C++ changes went away, so no problem with schemeflood for sure 15:14:23 are you including tor-browser#41608? 15:14:27 we'll just need to make sure that with the tight turnaround times we leave time for UX and MR review 15:14:38 PieroV: ah i just didnt push it again yet, 15:14:51 was testing as you asked but couldn't figure out what base condition was 15:15:13 i was seeing random apps be detected some time by schemeflood even in stock TB 15:15:15 oh, okay. With the current TB the schemeflood PoC is very confused (told me I have iTunes on my Linux system). As long as it keeps being confused I think we're okay 15:15:23 yes 15:15:25 ok cool 15:15:30 That's expected IIRC 15:15:32 thats all I needed to know 🙂 15:15:41 i'll readd those today after the meeting hten 15:15:46 and then undraft the MR 15:16:55 donuts: what about tor-browser#41608? 15:17:09 richard: that's on my list, at the bottom 15:17:17 henry-x and I talked about it on IRC last week 15:17:18 ack 15:17:55 once I finish tor-browser!587 I was going to work on that 15:18:13 we also have tor-browser#40552, but I was thinking adding anything else is a little unrealistic for the next two weeks 15:18:27 so I've left it off the list of priorities along with a couple of other smaller issues 15:19:27 anyway, I _think_ everything that's a priority should have an April 17th deadline on the ticket now 15:20:34 ok 15:20:49 PieroV: on to your discussion points! 15:20:55 Yep! 15:21:13 So, in the last release meeting, we found May 20-25 as a candidate period for 12.5 release 15:21:26 So that if we have catastrophes we will have another release + rebase soon 15:22:02 (12.5.1 could be around June 6 in this way, since Firefox 102.12 is released on that day) 15:22:26 Another day to save is May 8: it's when 115 becomes nightly 15:22:39 So, we have around one month of developments before the big ESR rebase 15:23:03 I think we should try to uplift patches in this period 15:23:26 I think we have mainly the LB changes? 15:23:42 But I still have to go through the whole patchset and on the old uplifting issue 15:23:47 that seems like a reasonable plan 15:23:54 the webrtc patches too 15:24:15 Uplifts in May are okay, too, since 115 is going beta on June 5 (and soft freeze on June 1) 15:24:33 Oh, right! The WebRTC, how could I forget them? ^_^; 15:25:14 Getting patches uplifted after June 1 is going to be difficult, because they will need to be approved to go land beta on Moz side 15:25:48 sounds like a good plan to me 15:25:57 the more patches that aren't our problem the better :D 15:26:04 Another point is that we have around 1 month for developments that we might not want in 12.5 15:26:56 For example, the torbutton refactors I've started doing (well, I also think that we could discuss offline about some of them, but realistically, there will be something that we won't want in 12.5) 15:27:29 agreed 15:27:34 and the arti prototyping as well 15:27:46 How do you feel about creating a 13.0 branch already, and target it with some MRs? 15:28:16 It will be yet another branch to maintain, but we could limit the 12.5 changes to only the things that are safe enough (or S30 changes) 15:28:54 is it a tor-browser-build, or tor-browser branch? 15:29:24 boklm: at a certain point it could be both :) 15:29:26 I think an other option is to merge things in the main branch, but disabled by default 15:29:44 I meant a tor-browser.git branch, especially 15:29:59 But it might be that we start updating the toolchain very soon 15:30:12 TBA might need a lot of love this time 15:30:22 (well, it always needs a lot of love, but this time even more) 15:30:42 I would think that unti 12.5, the 13.0 alpha branch could be purely a dev branch 15:31:10 for the risky/in-process refactors and prototyping we don't need for 12.5 15:31:42 IIRC, we don't have many TBA-specific patches in the patchset specific to Tor Browser, so if we're quick enough with rebasing Base Browser, we could maybe start with the Java parts before getting the Tor Browser part rebased 15:31:56 I think for the toolchain and other tor-browser-build changes we can avoid a separate branch with things like '[% IF c("var/release13.0") %]' 15:31:58 If we can work on that in more people, and we might need to update toolchains before 12.5 is released 15:32:42 I hope the build part of 12.5 to be stable enough at that point :) 15:33:02 Anyway, it's something we could see in the future 15:33:09 For now I'm mostly concerned about tor-browser.git 15:34:20 We could wait the next rebase, at that point it will be only one additional rebase, but we will have to make sure all the patches get cherry-picked wherever needed 15:36:37 sounds reasonable to me 15:38:22 donuts: re quick wins for Android, tor-browser#30573 might be doable (or it may already be fixed) since we recently patched a similar issue in tor-browser#40536 15:38:22 Okay, I think I'm done if nobody has observations about this 15:38:51 richard: yeah, I realize we don't have any android UX improvements in this release yet 15:39:14 we'll be doing an Android blitz from Q3 onwards but will need to keep the people happy in the meantime :) 15:39:27 I was actually wondering about this instead... 15:39:32 in general though i think we should avoid any major UX changes, since they will need to ported over to the combined firefox-android repo from their respective places with ESR115 15:39:34 tor-browser#41230 15:39:41 ah okay 15:40:04 I do have an updated onionsites icon that we can update on both desktop and android 15:40:14 that shouldn't be too problematic 15:40:37 ok 15:41:04 yeah i think 15:41:10 but I am conscious it's now been a full year (maybe more?) since our "things are gonna change soon for android" blog post 15:41:14 i just noticed that racently, that android doesnt have it 15:41:20 a year and a half maybe? 15:41:23 I think depending on how the esr115 rebase goes, will determine how much capacity we have for android improvements in the 13.0 series 15:41:46 wow really 15:41:47 I'm happy to look at some when it makes sense in the schedule 15:41:48 i guess that tracks 15:41:55 this is a topic we have on the pad for costa rica 15:42:08 we really need to switch focus to mobile from Q3 15:42:12 in terms of feature development 15:42:17 very agreed^ 15:42:47 if things align nicely w/ arti and android then Q3 could see some real android progress :) 15:42:53 sounds great :D 15:43:02 okay so for 12.5, we can do the new onionsite icons 15:43:08 what do you think about onion location? 15:43:35 (I'm cringing at suggesting that given the turnaround, but I'm not sure what else UXy we can do) 15:44:17 artroid ftw 15:44:27 I guess we could give the connection and start screens a visual tidy-up instead? similar to what desktop's getting? 15:44:35 i'm very much all ears for suggestions here :) 15:44:45 donuts: +1 for improvements on the connection page 15:44:52 It has a few major issues, imho 15:44:55 yeah 15:45:00 Like cut text, not scrollable logs etc etc 15:45:10 + inability to change settings before bootstrapping 15:45:11 plus the limited settings menu has always bugged me 15:45:15 haha exactly 15:45:21 (and these are the first ones I can think of) 15:45:28 nothing else? lol 15:45:33 circuit display 15:45:48 Well, maybe that could be even easier than onion location? :) 15:45:53 really 15:45:55 ? 15:45:58 I assumed the opposite 15:45:58 A panel that comes up and it's the same as desktop 15:46:18 Oh well, I haven't thought about the API side to check circuits 15:46:42 connection screen improvements sound good to me tbh, if it's cool with richard 15:46:53 hmm 15:47:08 although we're gonna be doing connection assist soon anyway 15:47:08 i think some surgical quality of life improvements there make sense 15:47:34 richard: specifically to the connection screen, or to the app in general? 15:47:42 i'm a bit torn because if everything works out the current connection screen will b ea thing of the past, and replaced with conneciton assist 15:47:55 yeah :/ 15:48:02 works out w/ regard to arti integration 15:48:58 And what about replacing the Enhanced Tracking Protection with the circuit display? 15:49:06 If we see implementing it in Android is feasible 15:49:19 It's maybe something that will be easier to reuse 15:49:34 At least on the frontend side 15:49:56 honestly that work scares me a little, given we barely have enough time to test stuff in alpha between now and release 15:50:02 (but my uncertainty here is very high) 15:50:18 donuts: and what if connection goes wrong? 15:50:24 It'd be much worse :/ 15:51:13 pierov: I guess it depends how surgical we're being, i.e. not touching anything to do with bootstrapping – but fixing the logs, settings link and replacing the illustration? 15:51:36 ^that sounds resonable 15:51:43 and at a high level form what i've seen doing android backports 15:52:04 Oh, okay, I thought you wanted to do even more 15:52:11 the new android-firefox repo is not a major architectural change, but rather just a merging of the former fenix and android-components 15:52:27 so any work we do there *shouldn't* be too difficul tto migrate to the 115 combined repo world 15:52:36 pierov: no, we'll hold fire on the harder stuff until we get to connection assist 15:52:43 ack 15:52:48 and just stick to a few quick wins/visual updates for now 15:53:00 yes, that makes sense 15:53:13 okay lovely, thanks everyone :) 15:53:29 alright then 15:53:39 Are we doing the release meeting later? 15:54:23 in 5m? 15:54:24 we could do if we want to keep chatting on this 15:54:36 dan_b: nope, the one at 1800UTC 15:54:51 (required are richard and donuts, everyone else can join or lurk) 15:54:53 yeah I've got the release meeting in my cal 15:54:59 aaaah 15:55:23 do we have stuff to talk about today? 15:55:33 oh yeah and we can cancel the s131 UX review meeting today 15:55:38 i see that's on my calendar 15:55:44 richard: yes 15:55:47 donuts: not sure 15:55:59 Unless we want to make a plan of what we still want for 12.5 15:56:03 I don't have a clear idea 15:56:27 yeah we could do that 15:56:30 alright 15:56:30 might be time for a voice catchup anyway 15:56:55 ok it's a date 15:56:59 for everyone else 15:57:11 have a good week! 15:57:16 a'ight see you in a couple of hours then ^^ 15:57:19 #endmeeting