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