14:59:24 <richard> #startmeeting Tor Browser Weekly Meeting 2022-12-12
14:59:24 <MeetBot> Meeting started Mon Dec 12 14:59:24 2022 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:28 <richard> dang what a magical date
14:59:51 <PieroV> Yeah, I've noticed too this morning
14:59:53 <richard> i'll give a few minutes for folks to roll in
15:00:02 <boklm> hi
15:00:21 <msim> 2022-12-13 over here :(
15:00:25 <msim> i'm missing out on the magical date
15:00:25 <ma1> o/
15:01:08 <donuts> o/
15:02:12 <richard> ok then
15:02:39 <richard> so the 12.0 release last week seems to have gone off w/ very few problem
15:02:58 <PieroV> \o/
15:03:00 <Jeremy_Rand_36C3[m]> \o/
15:03:15 <richard> we're planning on a 12.0.1 tomorrowish and our first 12.5 alpha shortly thereafter
15:03:31 <boklm> \o/
15:04:05 <PieroV> (I've added a bold item re 12.5a1 and l10n changes)
15:04:06 <richard> we've had a few issues come in: namely the drag-and-drop protections patch perhaps protected too much and broke some actually safe scenarios; ma1 has a MR for that and will be in 12.0.1
15:04:36 <dan_b> \o/
15:04:57 <donuts> nice
15:05:00 <richard> and there seems to be a regression in some env variable setup for users with *intersting* configurations (namely socks via unix domain socket) which seems to be a bit of a mystery so far
15:05:15 <richard> but isn't a blocker for 12.0.1
15:05:48 <richard> well specifically socks via unix domain when configured by env variable, setting manually in about:config is apparently fine
15:06:23 <PieroV> There's some magic in torbutton for that :/
15:06:42 <PieroV> I can handle it, not sure about the priority
15:07:10 <richard> beyond the alpha releases this week, hopefully the only other major thing of note is our s131 meeting on Thursday where hopefully we'll nail down their requirements so we'll know exactly what work we'll be doing in the new year
15:07:21 <PieroV> But I can be happy enough if it's the only problem caused by the tor-launcher refactor, I expected fires
15:08:18 <ma1> we've got another meeting later today (17UTC) , right?
15:08:21 <richard> PieroV: if it's an easy fix i wouldn't say no to a patch for 12.0.1 but it's not a very commonly used feature so it can wait for january if it will cause stress
15:08:37 <PieroV> richard: def not 12.0.1
15:08:49 <PieroV> I thought you wanted to start building asap
15:09:23 <richard> only thing blocking 12.0.1 is the drag and drop fix which i think is currently good enough in its current iteration
15:09:28 <PieroV> ma1: two other meetings today, that one and then the release meeting at 1800UTC
15:09:40 <msim> PieroV: what's the 1700 one?
15:09:47 <PieroV> That's for desktop
15:09:51 <ma1> PieroV, right, pile of meetings :)
15:09:52 <msim> ah
15:09:57 <PieroV> msim: it's a S131 meeting
15:10:18 <msim> ah
15:10:39 <richard> i think it's more of an org strategy meeting around s131 and the future and all of that
15:11:29 <richard> and the tor browser release meeting at 1800 which y'all are welcome to join as well
15:11:44 <richard> if you just need more meetings in your life
15:11:57 <donuts> Oh the Future plans meeting? It's a mix of S131 and S101
15:12:18 <richard> yop
15:12:50 <richard> hm ok, donuts why don't you take the first discussion point
15:13:01 <richard> otherwise i think we'll fill up the hour with computer talk
15:13:16 <donuts> haha sure thing
15:13:48 <donuts> For reference, the point is: Quick recap of some fresh TB 12.0 bug reports/user feedback
15:14:07 <richard> oh right, the pad for the records: https://pad.riseup.net/p/tor-tbb-keep
15:14:10 <donuts> we've already covered drag and drop protection, but that and anti-virus complaints are probably the biggest two points of feedback we've received so dar
15:14:37 <donuts> I wanted to quickly bring a few random smaller things up too
15:15:08 <donuts> richard: has anyone emailed cloudflare?
15:15:15 <donuts> I know I brought that up in the meta ticket already
15:15:22 <donuts> but it was regarding this comment: https://forum.torproject.net/t/new-release-tor-browser-12-0/5820/17
15:15:41 <richard> iirc we did for 12.0 alpha, so I'll need to do again for 12.5
15:16:10 <donuts> oh, I assumed that user was talking about stable
15:16:18 <richard> yeah mailed back in october because of captchas in nightly
15:16:34 <PieroV> well, cloudflare should detect Firefox ESR update
15:16:43 <Jeremy_Rand_36C3[m]> Pretty sure I was the one who brought up the issue in Nightly back in October
15:16:47 <richard> yes, so we're good until June
15:16:52 <Jeremy_Rand_36C3[m]> Or maybe other people did too
15:16:52 <PieroV> But they should not really be able to detect 12.0 vs 12.5, that would be quite bad
15:16:58 <richard> or whenever we have our first esr115 nightlies
15:16:58 <boklm> yes, only when we switch 12.5 to the next esr
15:17:23 <boklm> (or 13.0)
15:17:48 <donuts> so, this user is reporting that media hosted on cloudflare isn't displaying for them – but that shouldn't be happening?
15:18:26 <boklm> I think cloudflare is still showing captcha in some cases
15:19:11 <donuts> I think they're talking about CDN type stuff
15:20:05 <richard> well i can check and see what the latest user agent is and see if its' changed in 12.0
15:20:18 <richard> i wouldn't expect it to have but vOv
15:20:26 <donuts> right, that could be it
15:21:03 <donuts> okay moving on – I spotted this post in the support section yesterday: https://forum.torproject.net/t/tor-process-says-alive-after-closing-browser/5895
15:21:22 <donuts> could it be tied to the tor-launcher changes pierov?
15:21:29 <PieroV> Yes
15:21:48 <donuts> would you like me to open a ticket?
15:21:51 <donuts> or shall I leave it with you?
15:22:13 <PieroV> Yes, please open an issue and assign to me
15:22:15 <richard> that's a weird one, tor should be managing that
15:22:24 <PieroV> If you can have the user doing so it would be even better
15:22:40 <donuts> sure thing, I'll ask them!
15:22:46 <PieroV> I think I've experienced something similar in the past with dev builds
15:22:49 <PieroV> But not reproducible
15:23:00 <PieroV> And I think it was like tor taking some more time than usual to close
15:23:08 <PieroV> Rather than remaining alive
15:23:59 <donuts> okay last thing: do you remember the bug with the browser chrome growing due to font changes?
15:24:01 <donuts> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41356
15:24:34 <PieroV> Sure, but I expected it to be solved :)
15:24:40 <donuts> was that fix multiplatform? i.e. does the browser chrome look more or less the same on Win and Linux?
15:25:01 <donuts> reason is, I'm seeing a spike in "what are these grey borders" reports from people who've discovered letterboxing for the first time
15:25:46 <PieroV> I'm not sure I see the link between these two questions :)
15:25:48 <donuts> I'm assuming the letterbox fixes shouldn't be changing the trigger-points, and that it could be due to differences in the browser chrome between 11.5 and 12.0?
15:26:23 <donuts> basically taller browser chrome = smaller canvas, and triggers letterboxing earlier
15:26:26 <donuts> but it's a guess
15:27:57 <PieroV> I think I don't set a font-size anymore in my patch
15:28:09 <PieroV> So, Linux and Windows should have different heights now
15:28:16 <ma1> donuts, we now letterbox about:blank. Also it might be tor-browser#41516
15:28:46 <donuts> oh interesting – why?
15:28:53 <henry-x> donuts: could it be the language notification?
15:29:04 <PieroV> I had the same problem a while ago with 11.0, but I could never reproduce it
15:29:05 <donuts> henry-x: that's a great point
15:29:10 <richard> doesn't seem likely; the only way users would suddenly see letterboxes is if the chrome calculation had changed and these users had never modifeid their window size before
15:29:16 <PieroV> And thought it was my system
15:29:34 <donuts> richard: it tends to be from users who fullscreen 100% of the time, I've noticed
15:29:39 <donuts> so their window size remains the same
15:30:18 <ma1> The new window thing seems to be a rounding issue, and it might be fixed by tor-browser!480 (well a lot of stuff might be changed, hopefully for the better, by that changeset)
15:30:49 <donuts> riiight okay
15:30:58 <donuts> well I suppose it could be many things causing the spike in user reports
15:31:05 <donuts> I'll see if it dies down after a couple of weeks
15:31:15 <donuts> thanks all!
15:31:19 <donuts> that's it from me
15:31:35 <richard> ok PieroV, all you then
15:31:49 <PieroV> richard: first is actually yours
15:32:01 <PieroV> I've just reported it since we've talked among us earlier this morning
15:32:04 <richard> hah well i didn't write it there :p
15:32:08 <richard> ok but y es
15:32:08 <PieroV> And I didn't want it to get lost in the backlog
15:32:15 <PieroV> I've written for you, I know you're shy :P
15:32:38 <richard> so we h ave a patch on the 12.5 series that just migrates torbutton src to tor-browser
15:33:28 <richard> with ma1's patches for drag and drop i envisioned a future where we'd be havnig to backport/refactor torbrowser patches to torbutton
15:33:33 <richard> which frankly doesn't sound like fun
15:34:18 <richard> if we've no objectiosn i propose backporting the migration patches to stable asap before the divergence becomes difficult to maintain
15:34:31 <richard> and since there's no added functionality in alpha now seems the perfect time
15:34:36 <msim> yea sgtm
15:34:45 <PieroV> +1 on that, but I'd do that after we merge localization to Weblate
15:35:04 <PieroV> Because that's another "no fun" thing of having the two versions of torbutton
15:35:06 <richard> so early next year then rather then for 12.0.1
15:35:12 <richard> ?
15:35:48 <PieroV> Yes, unless we want to backport tor-browser!475
15:35:58 <PieroV> Which could work, actually.
15:36:19 <richard> that's more code shuffle then i want to deal with for an 'easy' release
15:36:26 <richard> so let's push it back to early january
15:36:48 <richard> ok, now i hand it over to PieroV
15:36:52 <PieroV> Moz's release is a bit too early for my likings in January
15:37:04 <PieroV> But that isn't what I wanted to talk about :D
15:37:19 <PieroV> Though I'd like to talk about 12.5a1 and Rlbox
15:37:26 <richard> i'll forward your complaints about Moz's release schedule to moz hq ;)
15:38:05 <PieroV> Basically, Moz has decided to compile some native libraries to WASM
15:38:12 <PieroV> To then use JS as a sandbox for them
15:38:23 <dan_b> oh wow
15:38:34 <PieroV> Which could be a very good idea (a sandbox is always a sandbox) but we don't use it, yet
15:38:43 <PieroV> Because $stuff broke (but that happened before I arrived at Tor)
15:38:54 <PieroV> I've got it working again, but with a caveat
15:39:34 <PieroV> The upstream project builds a copy of Clang to build a few supporting libraries
15:39:56 <PieroV> Mozilla uses a hack not to. I could not use the same hack, so we'd need to build Clang only to build this project and then throw it away
15:40:21 <PieroV> It takes time, but we could build this project once for all platforms (it produces WASM code, so platform-independent)
15:40:40 <PieroV> So it isn't that bad for us
15:40:59 <PieroV> But it might be bad for nightlies (Android would re-use it very likely, but I don't know about desktop archs)
15:41:20 <PieroV> I'd love to get it in 12.5a1
15:41:39 <PieroV> So that we can think about backporting for 12.0.x (.3, maybe?)
15:42:08 <PieroV> I think official Firefox binaries have it enabled by default, so it should be pretty safe
15:42:14 <PieroV> Any opinions?
15:42:17 <msim> PieroV: what's the hack that mozilla uses?
15:42:46 <Jeremy_Rand_36C3[m]> PieroV: if the only downside is making build take 2 hours longer (which is what I recall Clang taking?) and it's necessary to get RLBox working with minimal pain, then that sounds like a good trade to me.
15:43:25 <PieroV> msim: it injects the Clang they've built and then touches a file so that the sandbox project's makefile doesn't build it
15:43:54 <PieroV> Jeremy_Rand_36C3[m]: well, it was 15 minutes in my machine to build the whole sandbox with also Clang
15:43:58 <Jeremy_Rand_36C3[m]> PieroV: I am curious though why Mozilla's hack isn't suitable
15:44:02 <msim> ^
15:44:19 <PieroV> Jeremy_Rand_36C3[m]: now that I think of it you're also a veteran in cross compilation :D
15:44:25 <PieroV> Can I ping you on the MR?
15:44:41 <PieroV> It's tor-browser-build!603
15:44:53 <PieroV> And msim too, if interested
15:45:10 <msim> PieroV: yes please :)
15:45:14 <msim> (also dan_b, if you're interested in reading more about rlbox: https://www.usenix.org/system/files/sec20-narayan.pdf)
15:45:21 <boklm> it sounds like a good plan
15:45:22 <Jeremy_Rand_36C3[m]> PieroV: I mean, if "veteran" means "having veteran-related PTSD from fighting the Mozilla build system" then yes :P  But sure, ping me in the MR, though I'm skeptical that I'll be very helpful
15:45:24 <dan_b> thanks!
15:45:47 <richard> so in terms of timelines, i'm slightly hesitant to introduce this to tor-browser stable before our march milestones, but we can see how january goes if we introduce it in the next alpha
15:46:00 <PieroV> So, in my machine it was 15 minutes, but they're needed only once, and if you can re-use it to compile firefox 10 times is like 1:30 mins on average for platforms
15:46:27 <PieroV> But I don't know if artifacts are actually shared between platforms in nightly
15:46:34 <PieroV> And if I understand correctly, nightly rebuilds everything
15:46:40 <Jeremy_Rand_36C3[m]> As much as I like RLBox, I agree with richard that this is going to need a lot of QA testing, as I think this kind of sandboxing is likely to cause weird bugs that are unpleasant to track down
15:47:02 <richard> yes, especially w/ our non-standard build setup
15:47:08 <Jeremy_Rand_36C3[m]> yeah
15:47:09 <PieroV> Jeremy_Rand_36C3[m]: true, but I am confident that Mozilla tested it a lot
15:47:22 <richard> on the other hand mingw for windows :D
15:48:02 <richard> we'll see how things go, but we should be prepared for this to be a 12.5 feature
15:48:23 <richard> of course, also depends on how effective our testing efforts are in the coming month to validate these changes
15:49:14 <msim> richard: wdym mingw for windows?
15:50:01 <richard> windows is probably our most divergent build target from the 'golden path' so probably more likely to have bugs
15:50:16 <richard> see screen reader support, webrtc, etc, etc :p
15:50:21 <msim> ahh
15:50:58 <richard> but we can always enable per-platform
15:51:17 <PieroV> Well, wasm is cross platform by definition :)
15:51:27 <Jeremy_Rand_36C3[m]> richard: that reminds me, has anyone at Tor Project reached out to the IceCat devs about MinGW support?  IIRC IceCat refuses to distribute Windows binaries because they're not willing to use the Microsoft compiler and they don't know how to use MinGW to build Firefox
15:51:39 <Jeremy_Rand_36C3[m]> Might be a cool opportunity for coordination
15:52:00 <PieroV> Jeremy_Rand_36C3[m]: I think we still have a MS thing
15:52:07 <PieroV> The d3dcompiler DLLs
15:52:41 <PieroV> But maybe Wine has an open source alternative that works
15:52:47 <Jeremy_Rand_36C3[m]> PieroV: hmm, are those not part of MinGW?  I just assumed all the TBB build dependencies for Windows were FLOSS
15:53:10 <PieroV> Jeremy_Rand_36C3[m]: https://github.com/mozilla/fxc2
15:53:29 <PieroV> We don't use them for building, but we ship them
15:53:39 <henry-x> Do we have time in this meeting to ask another question?
15:53:44 <PieroV> 5 mins
15:53:47 <richard> go for it henry-x
15:53:50 <PieroV> I'm done
15:54:03 <richard> (we can chat after jeremy if you like)
15:54:16 <Jeremy_Rand_36C3[m]> richard: yep, no worries
15:54:56 <henry-x> I was looking at the weblate/translate code for fluent support to see if it was obvious how to fix it to support fluent attributes (our main blocker to using fluent)
15:56:27 <henry-x> I was considering whether it would be worth adding the support for them. I don't think they are going to get many other projects that use fluent since most existing fluet projects are using pontoon instead. So I think we would be the only project using it
15:56:48 <PieroV> henry-x: they've replied a few hours ago
15:56:57 <PieroV> They're not interested in keeping strings grouped :(
15:57:13 <PieroV> (not sure you received a notification, I had to enable GitHub's email notifications)
15:58:13 <henry-x> no, but we could try and make it work with their infrastructure by splitting the attributes into separate strings, like they want for weblates UI, but keep them grouped using the ids
15:58:38 <PieroV> I was thinking the same, anyway
15:58:44 <PieroV> But we should go now
15:58:48 <PieroV> There's another meeting here
15:59:00 <henry-x> ok
15:59:06 <Jeremy_Rand_36C3[m]> Thanks!  Good meeting.
15:59:21 <PieroV> Thanks! o/
15:59:23 <richard> thanks everyon!
15:59:25 <richard> #endmeeting