14:58:18 <richard> #startmeeting Tor Browser Weekly meeting 2023-11-27
14:58:18 <MeetBot> Meeting started Mon Nov 27 14:58:18 2023 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:58:18 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:58:25 <richard> le pad: https://pad.riseup.net/p/tor-tbb-keep
14:58:26 <ma1> o/
14:59:04 <jagtalon> o/
14:59:17 <dan_b> o/
14:59:51 <richard> good morning everyone
15:00:04 <boklm> o/
15:00:59 <thorin> /o
15:01:11 <clairehurst> o/
15:01:45 <richard> so I don't have an discussion points this week \o/
15:02:40 <richard> I'm working on prepping the 13.5a2 releases and should have that MR out sometime relatively shortly after this meeting in time for us to build overnight and sign tomorrow
15:02:59 <richard> PieroV: happy to hand over to you re your two points
15:03:19 <PieroV> ack, thanks!
15:03:25 <PieroV> First point should be short
15:04:01 <PieroV> I think we could add an item about updating also tor-browser-build after the rebases to the rebase templates
15:04:34 <PieroV> (and to specify whether this needs a MR, I never remember if this is a kind of stuff for which we can skip the MR - but we can open one and set the same reviewer of the rebase)
15:05:20 <PieroV> It takes always a while to us to update the repo, and I think it'd be good to formalize to reduce this time
15:06:52 * boklm thinks it's a good idea
15:08:07 <richard> in general i'm fine with skipping MRs for trivial documentation updates
15:08:32 <richard> i literally pushed a changelog fix earlier today to MB
15:09:13 <richard> do you mean to update the main to build the new nightlies?
15:09:20 <PieroV> Yes
15:11:09 <richard> ah yeah wfm
15:11:57 <PieroV> ack, I will open a MR for the template later then
15:12:25 <PieroV> Now, for my second point, do we want to discuss a little bit about priorities for S96?
15:12:44 <PieroV> (esp. connection assist on Android)
15:12:54 <richard> yes please!
15:13:27 <richard> so for context for the chat can you layout what's already been merged and the remaining work to be done for a functional prototype for Jan?
15:13:32 <dan_b> speaking of, I was reading the MR for GV last week, you have a firefox-android branch of the same name so I can try and test it all out this week?
15:13:57 <PieroV> Nothing has been merged so far ^_^
15:14:32 <PieroV> Well, only the movement of about:torconnect to toolkit, so that it's available on Android for experiments
15:14:39 <PieroV> (more on that later)
15:14:53 <richard> :3
15:15:11 <PieroV> I have a MR with many features implemented for GV, and I don't have anything on Firefox Android yet
15:16:19 <PieroV> The MR can start processes (both tor and lyrebird for domain fronting) on the Java side, and it has some plumbing to allow JS to start them and to nofity JS about their state
15:16:34 <dan_b> how are you invoking it for testing? so I can
15:16:47 <PieroV> I'll arrive also to that
15:17:02 <clairehurst> I have the base screen of connection assist set up with constraint layout
15:17:37 <PieroV> In addition to that, the GV MR also modifies TorProvider to use the desktop controller also on Android
15:18:28 <PieroV> You can pair a GV built on top of that branch with a change to skip the bootstrap screen on Firefox Android
15:18:48 <PieroV> Then you can load about:torconnect manually and launch the bootstrap there
15:18:57 <clairehurst> its not merged, and isn't wired up yet, but should be a good base to build from
15:19:45 <PieroV> I think we could make this change permanent on the nightly channel, and possibly make about:torconnect fullscreen until we have the native UI
15:20:20 <dan_b> gotcha
15:20:24 <richard> so basically we enable the fullscreen UI in nightly
15:20:34 <richard> whiel in parallell claire works on the new android-native frontend?
15:20:44 <richard> that should be how we spell parallel
15:20:48 <PieroV> about:torconnect looks quite ugly on Android, because we don't have some of the desktop CSS. However, that page needs some rework on the desktop side (especially some string change)
15:21:17 <PieroV> That could be done in parallel to Android developments, and I think that adding some quick CSS to make it less ugly should also be quite feasible
15:21:29 <PieroV> However, I think that settings have a higher priority than working on the torconnect UI
15:21:45 <richard> seems reasonable for the short-term/january deliverable
15:21:57 <PieroV> TorConnect uses TorSettings to write settings on prefs
15:22:02 <richard> yes
15:22:13 <PieroV> However this is a big problem for Android users for at least two reasons
15:22:30 <PieroV> One is that they can't see the prefs the connection assist applies
15:22:47 <PieroV> (and they can't restore their own as well)
15:23:04 <PieroV> Well, in general they cannot apply settings manually
15:23:18 <richard> ooh right, so the current Android settings are basically inoperable with above setup
15:23:24 <PieroV> Yes
15:23:27 <richard> since theyr'e talking to the deprecated tor backend
15:23:36 <PieroV> And the current Android settings are stored in native Android things
15:23:40 <richard> yes
15:23:53 <PieroV> We'd need to understand why Moz prefers that to preferences
15:23:59 <PieroV> And in case we might just keep using them as well
15:24:09 <PieroV> But we'd need to write some plumbing for TorSettings
15:24:10 <richard> so can we *just* (just doing a lot of work there I know) create observers on the prefs we *do* expose in the current UI
15:24:18 <PieroV> No
15:24:19 <richard> and pipe them up on change to the android native UI?
15:24:30 <PieroV> Yes
15:24:44 <PieroV> But to do things better we'd need to at least write some migration procedure
15:24:47 <richard> since we're goint to need to partially do that work for torconect lifecycle events anyway
15:25:22 <PieroV> Well, I'm not sure using prefs is a good idea
15:25:29 <richard> is there a good reason to not wait on migration logic until after january/before 13.5?
15:25:53 <PieroV> In general GV forces pref values in GeckoSettings
15:26:16 <PieroV> When it initializes GV, it reads a bunch of Android settings and uses their value to update prefs
15:26:45 <ma1> PieroV, does it mean GV prefs are volatile?
15:26:58 <PieroV> I'm not sure
15:27:09 <PieroV> They should be written normally
15:27:15 <ma1> mmm, we could ask moz dev why they do this
15:27:26 <PieroV> That could be a good idea
15:27:32 <richard> hmm
15:27:39 <PieroV> In general, we'd need to understand if we want to depart from Moz on this
15:27:50 <richard> is that how we're handling security level right now?
15:27:59 <PieroV> Yes and also onion location
15:28:00 <richard> stored in firefox-android but sync'd down to geckoview?
15:28:12 <richard> well, push'd down
15:28:27 <PieroV> Exactly, and we even restore a default until the initialization happens
15:29:32 <dan_b> also ideally then we can preserve folks' prefs from before that'd be good
15:30:07 <PieroV> dan_b: yes, that's why I was proposing a migration logic
15:30:25 <dan_b> 👍
15:30:50 <richard> ok that sounds reasonable
15:31:32 <richard> so we would need to create firefox-android settings for whatever torconnect uses but isn't stored there
15:31:50 <richard> and we'd need a way for geckview to sync torconnect populated settings back to firefox-android
15:32:06 <PieroV> That isn't a big problem
15:32:12 <richard> right
15:32:31 <PieroV> For fun and exploration I've plumbed the circuit display data from GV to Firefox Android
15:32:46 <PieroV> The main caveat is that it happens in a sort of promise
15:32:53 <richard> so we've a proof of concept for that pipeline already then?
15:33:04 <PieroV> And we need to invoke the then from the main thread
15:33:11 <PieroV> Well, it's more complicated than that
15:33:15 <PieroV> (err, * ui thread)
15:33:37 <PieroV> The class is GeckoResult, and it sets a dispatcher (that's the term they use IIRC)
15:34:04 <PieroV> Anyway, technicalities we don't need to discuss here
15:34:18 <richard> right right
15:34:26 <PieroV> The long story short is that yes, getting data is feasible
15:34:40 <PieroV> And we have a proof of concept for browser-specific things
15:35:06 <PieroV> Which is harder than non-browser-specific things (browser as XUL's <browser>)
15:35:51 <PieroV> Plumbing is a bit boring, because of some OOP stuff that we don't really use but is there
15:35:56 <richard> so what are the last remaining questions/mysteries about this?
15:36:05 <richard> it sounds like we have a solid lead on all the important bits
15:36:28 <PieroV> So, we also have some UI refactor for settings
15:36:37 <PieroV> But donuts removed the S96 label from it
15:37:01 <PieroV> I don't know if we want to reconsider, or if we want to do this work on the old settings anyway
15:37:23 <PieroV> Doing it on the old thing has the advantage it might be a smaller task, thus easier to handle
15:37:51 <PieroV> But doing everything might give us a bigger view of the work to do
15:38:08 <PieroV> And change some of the possible choices we'll do
15:38:22 <richard> what needs to happen on settings page for connect assist to work?
15:38:38 <PieroV> Nothing
15:38:55 <richard> (apart from plumbing work)
15:38:59 <PieroV> Except synchronizing the settings
15:39:02 <richard> right
15:39:24 <richard> in that case i saw we worrya bout it after january, or after all the january required work is done
15:39:30 <richard> esp if we have no new designs
15:39:36 <PieroV> We have the designs
15:39:46 <PieroV> But I don't know if they're final
15:39:52 <richard> then after the s96 deliverable then
15:39:54 <PieroV> I've added a couple of comments earlier today about them
15:40:15 <PieroV> (mainly, that I don't know if we're going to make all the settings available before the bootstrap)
15:40:27 <PieroV> Oh, I've just remembered also of another important thing to do
15:40:45 <PieroV> We should check the current tor integration commit
15:40:55 <PieroV> My POC branch only sets the proxy preference
15:41:20 <PieroV> Proxy preference as network.proxy.socks
15:41:31 <richard> mmhm
15:41:35 <PieroV> We'd need to understand if we also need to call some Java code
15:41:40 <jagtalon> here are the designs for reference there's some organization stuff as well to make it more consistent with desktop: https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=218-10620&mode=design
15:41:43 <dan_b> if you dont take a look I'll be back there this week taking a few notes too to by pass it and run your stuff in a worker thread
15:41:45 <PieroV> Or if the network goes all through GeckoView
15:44:03 <richard> jagtalon: nice
15:44:58 <PieroV> jagtalon: good job, I've added a comment also on the issue :)
15:45:04 <richard> jagatalon: do you have a link for connect assist handy on the figma?
15:45:10 <jagtalon> open to paring it down further if y'all decide to work on it cc donuts
15:45:25 <PieroV> I wonder if we want to keep having a specific fragment for these settings
15:45:39 <jagtalon> richard: yes! https://www.figma.com/file/rWgMwiiFTDFp4ujuP3PKbq/Tor-Browser-13.5?type=design&node-id=4-11150&mode=design
15:45:45 <PieroV> Or if we want to let users access all the settings from the bootstrap
15:47:48 <dan_b> I kinda suspect we do, that prolly falls in line with the s96 goals?
15:47:51 <dan_b> i think?
15:48:00 <richard> PieroV: what about tor logs?
15:48:18 <PieroV> richard: that's a delicate topic
15:48:19 <richard> do we have a way to pipe those out of TorProvider easily?
15:48:35 <PieroV> Well, I don't think they should be on the TorProvider on the first place
15:48:54 <richard> controversial
15:48:56 <richard> what's your reasoning?
15:49:14 <PieroV> If we re-initialize the provider (which we currently do when tor exits) we also lose logs
15:49:38 <richard> (8 min time check)
15:49:52 <richard> oh interesting
15:50:30 <richard> so we need to store the logs to some more persistent storage
15:50:42 <richard> some other js module
15:50:46 <PieroV> Yep, I've opened tor-browser#42300
15:51:01 <richard> that seems reasonable
15:51:24 <PieroV> Anyway, apart from that it should be easy to plumb just like the rest
15:51:26 <richard> i do a similar thuing with gosling's torprovider; itj ust reports tor log lines doesn't store; up to the embedding app to persist them
15:52:34 <richard> anyway seems to make sense
15:52:37 <PieroV> The only problem with plumbing from GV is that it's all async
15:52:49 <PieroV> I don't know how much it complicates the things in Java land
15:53:10 <PieroV> The alternative is to actively keep the logs updated also on the Java side
15:53:15 <richard> in terms of getting events in order?
15:53:24 <richard> yeah honestly i think that makes sense
15:53:34 <PieroV> I think it's just easier to manage
15:53:35 <richard> just bubble up log evenst to the frontend, and store the logs there
15:53:44 <PieroV> All the plumbing is event driven
15:53:51 <PieroV> And handled by C++
15:54:02 <PieroV> So that the JS engine can easily access it, and so can Java through JNI
15:54:05 <richard> on desktop we could do similarly, adn store the logs on w/e persistent thing exists for about:preferences
15:54:11 <richard> (or create a doesktop specific module)
15:54:51 <richard> ok we're about to the hour
15:55:24 <richard> lets plan on focusing on s96 checkin's in this meeting throughout the rest of the year (unless something more urgent comes up)
15:55:25 <PieroV> I think we can continue in #tor-browser-dev if needed
15:55:39 <PieroV> Especially for more practical coordination
15:55:43 <richard> yes please!
15:56:11 <ma1> see you on the other side :)
15:56:20 <richard> ok see you all on the internet
15:56:20 <richard> o/
15:56:22 <richard> #endmeeting