15:17:19 #startmeeting Tor Browser Weekly Meeting 2024-05-06 15:17:19 Meeting started Mon May 6 15:17:19 2024 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:17:19 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:17:23 pad per usual -> https://pad.riseup.net/p/tor-tbb-keep 15:17:28 and look at that it's May already 15:17:35 o/ 15:19:19 So 3 things from me this week, before we move onto discussions 15:19:46 first of all, i'm doing some gitlab spring cleaning, triaging and punting for the 13.5 release 15:20:12 so don't be surprised by all the activity there, or if i'm suddenly assigning a million tickets to you 15:20:23 i'll go back and load balance after my first pass 15:20:37 second of all, it's a release week \o/ 15:20:48 relprep, more than release :) 15:21:18 and backports. And MB release? 15:21:21 boklm: unless there are any risky patches in-flight atm I can sign TB and MB 15:21:43 richard: ok, I don't think there is risky patches now 15:21:55 thx! 15:22:06 tor-browser-build!962 shouldn't be risky 15:22:45 and third of all, juniper is starting this week, so you may have been invited to an onboarding session or two this week 15:23:05 oh right woo. whens day1? 15:23:34 today! She's meeting w/ bella and hr today 15:23:58 maybe she'll be on IRC later ? vOv 15:24:09 oh woo. and the engaging in all the systems setup and such? so we'll see her popping into irc some time? 15:24:10 cool 15:24:21 i'm trusting in the process 15:24:50 apart from that, thats' all the announcements for this week 15:25:01 so we can move onto discussion points 15:25:28 the immediate concern atm is 15:25:59 we have 2 weeks until Lisbon, and then some few weeks after before the scheduled 13.5 release in June 15:27:28 so the question atm is how's Android connect-assist looking? can we reasonably expect to have it working with confidence before then, or should we settle on a subset of our desired features and push the rest to 14.0 at the end of summer? 15:27:40 dan_b, clairehurst^ :D 15:28:32 (also we have no sponsor obligations for this work so if it needs to bake that's completely fine) 15:28:41 i dont think connection assist for 13.5? but hte native bootstrap is doing pretty well? 15:28:51 we have that out in alpha now 15:29:37 Yeah native bootstrap is in a good spot, just missing the connection assist part 15:29:46 its partly implemented, but needing some more work 15:30:09 ok in that case, shall we focus on ripping out the legacy backend over the next few weeks we have before 13.5 stabilizes? 15:30:21 (and html backend) 15:30:37 oooh 15:30:46 ok cool 15:31:02 whens the next alpha ship? 15:31:09 2 weeks? 15:31:10 since yeah 13.5a7 *seems* to have parity w/ stable at this point 15:31:14 hmm, html backend has connection assist working 15:31:46 yeah it'll have to be like 15:31:50 code-freeze next wednesday 15:31:57 to ship on thursday 15:32:02 for alpha 15:32:21 not taht i don't enjoy the idea of shipping an alpha by the pool the following week 15:32:49 Oh, right, I forgot about that ^_^ 15:33:15 wouldn't be the first time :p 15:33:45 ok how about this as a target for 13.5 stable: 15:34:07 - remove the legacy bootstrapping from TBA 15:34:14 - purge the old stuff from tor-browser-build 15:34:26 - use the new expert bundle in tbb 15:34:53 yeah i'm happy to take that on 15:34:58 - gate enabling the HTML connect-assist on alpha/nightly so it's hidden in stable? 15:35:50 clairehurst: that sounds like a you task. just hiding that menu on stable? 15:36:05 are there complications here I'm missing? 15:36:20 Why hide it instead of removing it? 15:36:43 it could be potentially useful for debugging native connet-assist in the next release cycle 15:37:16 to have something we know works on the platform already 15:37:43 the moz way 15:38:04 ma1: well now you got me doubting myself 15:38:20 :) 15:39:00 I don't think removing/hiding legacy bootstrap and html would take a ton of time, once we agree on what to do 15:39:43 you want to take a crack at removing the old backend from tor-browser-build after the UX stuffs? 15:40:36 ah, yeah that might be harder. I'm much less confident and familiar with tbb stuff 15:41:01 :D 15:41:02 I was just thinking for firefox-android 15:41:24 I think it'd be quite easy 15:41:39 should be a good 'intro to tor-browser-build' task 15:41:45 Just delete the projects, delete any reference to them in the varous projects/*/config 15:41:47 remove projets is easier than authoring new ones 15:42:07 Then remove the related commands in projects/firefox-android/build 15:42:08 (and edit build scripts that reference them) 15:42:12 efb 15:42:13 then the last bit will be adding a dep on tor-expert-bundle to get the new tor artifacts 15:42:22 (even though we'll need to add something new for the new aar) 15:42:45 but the hard part, generating the .aar, is done, and i manually tested it works as a drop in replacement 15:42:57 and i m happy to answer questions 😄 15:43:26 same :) 15:43:40 All this being said, I don't think we're too far from having connection assist working on native 15:44:00 Though there are some unknowns 15:44:26 alright, let's hear em 15:45:26 How to safely detect which country the user is in (also need to get the list of countries (localized)) 15:45:46 How to safely detect if the user has no internet connection 15:46:11 The requests to Moat are on the clear net (since you haven't bootstrapped, yet) 15:46:27 So, the server reads your IP and checks its location in a GeoIP database 15:46:46 PieroV: do we need to plumb the geolocation and the connectivity test APIs out to Android? 15:46:52 We save this information in TorConnect, we just need to plumb down the information 15:47:10 Same for the connectivity test. It's run automatically, we just need to plumb the result down 15:47:43 However, the connectivity test doesn't work very well. For the future, we might use the OS API (if they're compatible with our expectations, i.e., not calls to Moz or something similar) 15:48:01 Some users were mad also that we did phone home to Moat for this check ^_^ 15:48:13 indeed 15:48:17 But if the OS tells us we're in flight mode, we should hear to what the OS says 15:48:51 there are android APIs you can check 15:49:14 for connectivity. for Cwtch i found a flutter/dart module that did them and wired them into our app. 15:49:16 dan_b: do they need special permissions? 15:49:34 Or is the one for Internet connection enough? 15:49:40 ACCESS_NETWORK_STATE i think 15:50:13 at least the way the module we use on android works 15:50:34 We comment that out 15:50:46 mobile/android/geckoview/src/main/AndroidManifest.xml 15:51:05 well, if we want to ask android about its network state/health/connectivity, we might not want to 15:52:21 also i can't 100% garuntee it's needed, the module we use we had to strip down a bunch cus it was giving us connection type info like is it wifi or data or vpn etc 15:52:30 we third partied that module and ripped a lot out 15:52:44 its possible the limited use we have for it doesnt need ACCESS_NETWORK_STATE 15:52:55 but if i was asked to guess I'd say it's still prolly needed 15:53:53 it doesn't seem important if we can just plumb the result from geckoview's implementation (in the short term) 15:54:18 As for the localized names, desktop has an API to get them 15:54:33 But we don't include l10n in GeckoView... So I wonder if there's an Android API we can use instead 15:54:57 Like java.util.Locale 15:56:52 How do we localise the languages in the settings? 15:57:16 On Android? 15:57:20 yeah 15:57:55 firefox-andriod/fenix has its own localisation branch no? 15:58:07 yes 15:58:10 Yes, but we don't touch that part of the settings 15:58:14 We inherit from Moz 15:58:20 That's why I say that we could use some Java facility 15:58:24 Or other Moz facility 15:58:44 Locale seems to do indeed what we want: https://stackoverflow.com/questions/14275868/get-country-name-in-english-from-country-code 15:59:31 (the question says in English, but I believe it returns the localized name, or you can even pass a language code to getDisplayCountry() to get the name localized in that language) 16:00:59 ok, then lets plan on prioritising the work that needs to happen regardless: ripping out the legacy backend from firefox-android, tor-browser-build updates, hiding HTML connect assist in stable 16:01:28 if we still have time after all of that, then we can potentially complete the remainder of the work 16:01:52 we've 15 mins left, and I beleive pierov has a discussion point next 16:02:02 A couple, related to the ESR work 16:02:13 One is that in a week 128 is going nightly 16:02:22 We might want to start reviewing the rebases soon 16:03:21 Not sure if we have some bandwidth to before the 13.5 release (or even before PT, in that case we might just postpone the discussion to the PT session about ESR transition) 16:03:26 can you point us to your MR where all this work has been hapening? 16:03:39 No MR because I didn't create branches 16:04:06 But I added comments (with the branch names and the hash of the respective bases) in tor-browser#42441 16:04:39 (well, the bases can be found also with `git merge-base $moz_remote/release pierov/$branch_name`) 16:05:10 does your branch have base/rapid-release tags? 16:05:23 No, but I can add them 16:05:30 yes please :) 16:05:45 In general, my branch has the RR history 16:06:10 So, no need for the moz remote actually 16:06:58 ok, i'll probably plan to begin review after PT 16:07:13 There's also the issue of making this based on the simulated censorship and I don't know if it will perfectly translate to actual censorship. For example, I currently basically just check if the TorError.reason == "noroute" to then go through the connection-assist flow and I don't know if this is a good idea or how to test if its a good idea because I only know how to check the 16:07:14 simulated censorship (we can talk about this more later) 16:07:43 clairehurst: I think you're missing the beginAutoBootstrap 16:07:57 Because you do get other errors when you use the automatic bootstrap 16:08:22 ah, good to know 16:08:42 I have also a second point about the ESR transition 16:08:52 (no need for an immediate answer, but it's something to think about) 16:09:20 We should decide whether we want to do a one-pass rebase like last year, or if we want to go through 125, which was the latest release on firefox-android.git 16:10:05 oh interesting idea 16:10:22 125 is buildable on desktop 16:10:27 (it was the first one I tried to build) 16:10:31 Well, on Linux desktop 16:10:33 yeah late last week i started surveying the firefox-android patches we have to look at a strategy for merging some and splitting ui one pre merge to tor-browser 16:10:49 given your success on desktop it seems like a similar strat for android may be smart? 16:10:53 i think prolly hitting 125 first before merging into tb sounds good 16:10:53 Yep, keep in mind it might make sense to --autosquash 16:11:14 But I expect you'll have some troubles with that ^_^ 16:11:24 haven't gotten that far 😕 16:11:37 but yeah, that'll have to be a step soon. 16:13:42 ok 16:13:50 we've 2 minutes to go, any last minute topics? 16:13:54 otherwise we can end this 16:14:13 Nothing from me 16:14:13 wfm 16:14:20 ok 16:14:24 cool 16:14:37 do we have a release meeting in 2 hours? 16:14:37 dan_b, clairehurst: I'll make some tickets for the android work discussed later today 16:14:38 o/ 16:14:41 cool 16:14:44 yeppers 16:14:51 thx! 16:14:55 👍 16:14:57 have a good week everyone 16:14:58 #endmeeting