14:57:53 #startmeeting Tor Browser Weekly Meeting 2023-12-11 14:57:53 Meeting started Mon Dec 11 14:57:53 2023 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:57:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:57:59 good morning/afternoon everyone 14:58:13 the pad per usual: https://pad.riseup.net/p/tor-tbb-keep 14:58:19 o/ 14:58:21 o/ 14:58:40 o/ 14:58:47 /o 15:00:01 o/ 15:02:13 this week looks like we're release prepping for 13.0.7 15:02:30 looks like we'll discuss that more thuroughly at tongihts release meeting at 1800 15:03:57 can we get an update on s96 progress from last week? 15:04:14 My MR for the backend has been merged 15:04:42 However, there's no way to access it from Andorid 15:04:53 * Firefox Android 15:05:26 I've drafted a PoC to check that the proxy settings were correctly restored when going back to the legacy Tor integration 15:05:39 o/ 15:05:46 However, either Dan or Claire should do something better than it 15:05:56 I tracked down how android stores/loads all the settings. it's all in tor-android-settings cus it had to be more agnostic, not use anything FF/TB specific cus it could be use in other apps, so I've migrated the relveant bits into geckoview and am now working on building the code to bridge it into TorSettings.sys.mjs so it can populate that, and then tell firefox-android the settings still, and then receive updates from firefox-anroid Java about 15:05:56 settings changes 15:05:57 We have an issue about the opt-in (and I have a discussion point about it) 15:06:43 I've also slipped in a JS module to use for more wiring. I've added a few events for TorSettings, so that Dan will be able to use them for the Java part (I can help on that, if needed) 15:09:30 ok great 15:09:39 how goes the frotnend work clairehurst? 15:09:49 PieroV: what changes have you made for TorSettings? I was doing a small refactor there 15:10:39 henry-x: no changes in TorSettings itself iirc 15:10:58 But I've exposed some calls on toolkit/modules/TorAndroidIntegration.sys.mjs 15:11:23 ok 15:12:26 so from the gitlab discussion last week it sounds like the previous implementation is basically opting out cloud settings sync? 15:12:30 iirc? 15:13:03 and migrating them down to geckoview will cmpletley bypass that system 15:13:38 well depends what i do with the bits i'm building. i could wire it so it just always reads/writes to the existing locations 15:14:00 my preference is to use it as a one time thing to migrate to the GV stores 15:14:02 but 15:14:02 Pretty good, started seting up a new fragment that should replace the old mess (but still able to be toggleable) and should also be way easier to follow in terms of complexity but also sheer number of files (3 ish files vs like 10 or something with the current setup) 15:14:35 if they make changes and want to revert back to the tor-android-settings using UI, then those new settings changes will be lost, so maybe we have to wait on that a little? 15:17:08 dan_b: would it make sense to create the new settings already and wire them to the GV thing? 15:17:43 And depending on the toggleable pref, we show the current fragment, or the new one 15:18:05 The final migration could be done when we remove the toggle 15:18:58 Or we could prompt the users if they want to sync prefs whenever they switch between the old implementation and the new one 15:19:03 yeah i don't think we specifically care about interoperability/sharing of settings for 'real' users 15:19:25 we're never going to ship the option to toggle between the two bootstrapping systems in stable 15:19:47 Yeah, but in stable we'll have to migrate the settings 15:19:54 yeah true 15:20:02 Unless eventually we decide to keep the old storage 15:20:14 pierov: wiring the new settings into the "legacy" bootstrap. esh. no cus the code the uses it the most is still in tor-android-service 15:20:33 it can be a single-way sync, for me 15:20:49 ok so one way migration right away is prolly the way to go. perfect 15:20:49 We just have to write it properly :) 15:21:27 Is there even a way for "normal" users to downgrade TBA? 15:21:27 yeah one-way in the 13.5 upgrade path, and then we can remove the relevant migration code in 14.0 15:21:28 (I think it'd be fine if we have only English if it's a temporary message only for alpha) 15:21:56 ma1: normally Android refuses to downgrade even when you do `adb install tor-browser.apk` 15:22:19 Indeed, hence no point in keeping the old storage around after migration 15:22:20 There's an integer that is bumped with every version, and it's more or less derived from the commit date 15:22:29 I don't know if there' 15:22:32 s a --force option 15:23:05 (unless we're afraid to corrupt the data on migration) 15:23:36 dan_b: clairehurst: is there a way to delete shared settings, so that once we migrate them we just delete them and never repeat the migration? 15:23:38 scrubbing the old storage would be a seperate task 15:23:51 E.g., for prefs there's clearUserPref 15:24:05 i mean i could write something to at least blank them all out 15:24:07 And you can verify if the pref has a default 15:24:37 Yeah seems like it PieroV https://stackoverflow.com/questions/3687315/how-to-delete-shared-preferences-data-from-app-in-android 15:25:09 Nice, that could work. There's even the .clear function, fantastic 15:27:26 ok, onto your dicussion points PieroV? 15:27:35 Yes 15:28:10 So, as I was saying, I implemented the GV pref to enable the new backend, and we should expose it somehow 15:28:22 But the opt-in for the new experience might have 3 states, not 2 15:28:31 1 state is the previous experience 15:28:52 One is the HTML UI I wrote to have something to click on and see that stuff is somehow working 15:29:14 Which is also plan B if native UX has problems and we end up pushing it 15:29:25 Third state is the native UX, but it depends on how we're planning to merge it 15:29:35 sounds reasonable 15:29:51 Because right now if I understand correctly it has a few things implemented, and it's wired to the old backend 15:30:07 we talked, the new native UI should be stand alone so yeah, toggleable between the existing legacy one, and yours as well 15:30:08 But we'd need to test the new backend to test the other developments (e.g., settings) 15:30:38 So, if it's just two states, we can do a toggle swich, very easy, I have a PoC because I needed to test the backend pref 15:30:47 (but it doesn't redirect to about:torconnect) 15:31:00 If we do a three-state thing we need to create some specific UI 15:31:27 is there not a combo-box android thing we can do? 15:31:32 in the settings 15:31:53 Maybe, but it isn't used 15:31:58 Even HTTPS only has its own fragment 15:35:47 so we'd need a whole new screen basically like what we have for the builtin bridge config? 15:35:51 What about two booleans? old / new , html / native? 15:36:10 richard: yes, more like the security level 15:36:17 donuts was suggesting 3 radios 15:36:28 ma1: I think a dedicated thing is cleaner at that point ^_^ 15:36:44 yeah i'd be fine with 3 radios 15:36:46 i think switch + two radios would be slightly better, since technically you're opting in to the experiment? but either's dine 15:36:50 yes, I agree, but my understanding was that this is a transitional / hacker-oriented UI? 15:36:52 *fine 15:37:09 yeah exactly ma1 15:37:36 honestly whatever is easiest i'm fine with 15:37:41 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42323#note_2974865 15:37:57 this UX is alpha only and 90% of users would never see it 15:38:03 So two switches (and maybe auto-disabling the second switch if the first is on "old") may suffice, if they're much simpler 15:38:17 wait that sounds cofusign 15:38:21 *confusing 15:39:30 the HTTPS-Only screen seems like a reasonable one to quickly copy 15:39:37 toggle for new experience, option for *which* one 15:40:03 yep that's the ux i'd like please 15:40:20 dan_b: so, you said you managed to load about:torconnect automatically? 15:41:19 i think, it's mainly a oneline change, you added back a redirect to onboarding, just do naviate to actionStartupHome instead 15:41:25 thats the actual fragment with the browser 15:41:33 in your branch 15:41:59 it's a little jank but i think then it loaded the about:torconnect from your prev call properly 15:42:30 That branch was a toy to check the GV pref, and if we do the 3 way we can delete it 15:42:54 It's probably better if I let one of you handle it :) 15:45:13 clairehurst/dan_b can one of you prioritise this today? 15:47:26 I kinda want to focus on the GV settings stuff, any change clairehurst you have time? 15:48:43 Sorry it's probably just early but what am I agreeing to? 15:49:01 tor-browser#42323 15:49:37 which is not a checkbox anymore :) 15:49:56 sounds like adding a new fragment similar to the https-only fragment to switch between legacy bootstrapping, pierov's bootstrapping, and your native bootstgrapping UX screens 15:50:00 But rather a duplicate of the HTTPS-only UI -> Fragment 15:50:07 yep exactly 15:50:39 Yeah I think I can start on that. I'll ask more questions after this meeting 15:51:20 ok great 15:51:25 7 minutes until the hour 15:51:35 is there anything quick to discuss/announce? 15:51:41 otherwise we can end this 15:51:48 I can continue in #tor-browser-dev for more Android coordination 15:52:01 Esp. regarding the GV stuff Dan wants to do today, I can probably help with that 15:52:05 But nothing for this meeting 15:53:09 ok then 15:53:21 have a good week and you all on the internet o/ 15:53:25 #endmeeting