14:58:32 <richard> #startmeeting Tor Browser Weekly Meeting 2023-01-30
14:58:32 <MeetBot> Meeting started Mon Jan 30 14:58:32 2023 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:58:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:58:39 <richard> meeting pad: https://pad.riseup.net/p/tor-tbb-keep
14:59:09 <ma1> o/
14:59:15 <msim> o/
14:59:19 <PieroV> o/
14:59:26 <richard> good morning afternoon and evening
15:01:30 <richard> i'm still catching up on everything that happened last week, but from waht I can tell there doesn't seem to be anything urgently in need of my attention
15:01:55 <richard> i'm currently building/will be signing what will be our first privacy browser build for s131
15:02:25 <msim> \o/
15:02:44 <dan_b> coool!
15:02:51 <richard> and I'm a bit excited to see msim's patchset in (hopefully) the next alpha
15:03:00 <richard> assuming we can iron out the rough edges before then
15:03:17 <msim> many, many, rough edges :p
15:03:31 <richard> we should get tags around February 9th so should be plenty of buffer time
15:04:33 <richard> i don't have any further discussion points, PieroV did you watn to cover the point that didn't get covered last week re Android addons?
15:05:34 <PieroV> So, if I understand what happens, you cannot install addons on Android, unless they're listed in the file we ship
15:05:40 <PieroV> But we ship only a few addons
15:05:57 <PieroV> Installation of the other ones fails with a very generic error message
15:06:14 <PieroV> I don't know if we really want TBA to be that walled
15:06:41 <ma1> Firefox too shortlists their installable add-ons to a set of recommended ones, because Fenix compatibility is not trivial.
15:07:05 <PieroV> Yes, but that's another kind of error
15:07:21 <PieroV> I'm speaking of addons that work on Firefox for Android, but not on TBA
15:07:34 <PieroV> If an addon doesn't work you get an error on AMO
15:07:51 <PieroV> (like "your Firefox version/platform isn't compatible" or something similar)
15:08:06 <PieroV> But some addons that pass this step on Firefox, then have the generic error on TBA
15:09:36 <ma1> Right, the first one is from AMO's server-side compatibility data, the second one is client-side from the list of installable add-ons.
15:10:08 <ma1> (I guess it's generic because you're not supposed to get there in Firefox's UX provisions)
15:11:24 <richard> well if we do want to be that walled the UX should be fixed regardless
15:12:20 <richard> iirc it currently shows a list of recommended addons on the addon page
15:13:09 <PieroV> Yes, and those should be the only ones that can be installed at the moment, too
15:13:36 <PieroV> But it's a file we grab from Moz, so it isn't even that meaningful for us
15:13:50 <ma1> So here we're deciding whether allow users to shoot themselves in the foot with broken add-ons (and possibly handling unexpected errors with a better UX) or keep the curated list from Mozilla, correct?
15:13:53 <PieroV> And as a result we're being walled for nothing
15:14:50 <PieroV> The bad UX is already there
15:14:56 <PieroV> Even if we keep the curated list from Moz only
15:15:04 <PieroV> (is the curated list 11 addons only?)
15:15:49 <ma1> Yes, very short. Why is the list not meaningful for us? That's the list of Add-ons which have been verified compatible with Android by AMO's staff.
15:16:21 <ma1> (I mean there are add-ons which aren't good for the TB, as a subset, if that's what you mean)
15:16:58 <PieroV> I mean that we don't double check that list
15:17:21 <PieroV> We should at least remove any visible recommended flag, since we're not recommending anything
15:17:35 <richard> yeah honestly there seems very little in that list (that shows up in my recomendeds anyway) that we would want to people install
15:17:37 <ma1> PieroV, that's true. It should just be "available add-ons"
15:17:44 <richard> ^yeah that
15:18:24 <PieroV> Anyway, if you go to amo, you see for example "Ghostery" as recommended, but it won't install because of the error
15:18:28 <PieroV> of the generic error
15:19:03 <ma1> Actually I don't even think you can install from AMO in fenix.
15:19:06 <PieroV> (I don't know that particular addon, just one that appears as recommended but isn't listed on our cache either)
15:19:38 <PieroV> Installing uBlock from AMO seems to work
15:20:00 <ma1> Mmm, it turns out you can, actually (just checked). It used not to be the case iirc.
15:20:56 <PieroV> Anyway, I think that 1000 years of cache validity isn't a great value
15:21:04 <richard> :D
15:21:36 <ma1> and fenix nightly has a mean to install any addons, so we could go with the shotgun and remove the recommended stuff all together :) https://blog.mozilla.org/addons/2020/09/29/expanded-extension-support-in-firefox-for-android-nightly/
15:22:12 <ma1> oh no, it seems rather convuluted and involving lists, anyway :(
15:22:13 <PieroV> We could add a warning about extensions
15:22:33 <PieroV> After you accept the permissions
15:26:31 <ma1> So the plan would be 1) patching the addons manager to skip any restriction except the extension being signed by AMO; 2) Adding a footgun waring on installation of any extension?
15:27:02 <PieroV> Uhm, no, my plan we simpler:
15:27:06 <ma1> (and of course removing any "recommended" label, but that should be done anyway)?
15:27:20 <PieroV> - remove our patches and switch to Firefox's behavior
15:27:32 <PieroV> - remove the recommended label, and change it with something like "available"
15:27:54 <PieroV> - maybe add a warning about installing extensions
15:28:16 <richard> i'm not sure I agree here
15:28:27 <richard> esp if torvpn is going to be a thing
15:28:49 <PieroV> Agree with what?
15:29:05 <richard> users that want to use tor for say censorship circumvention and don't care as much about the privacy/security implications could use vanilla firefox or w/e  with extensions as they see fit
15:29:33 <richard> i'm saying maybe we should just disable extensions altogether in TBA
15:29:58 <richard> well in the short term we should update the UX so at least it's not lying to users (re recommended vs available)
15:30:40 <PieroV> We have an issue for hiding recommended, we could update it: tor-browser#40502.
15:30:59 <richard> but letting users install extensions does seem like a potential privacy/security risk for people in say Iran etc
15:33:28 <dan_b> is the risk much different for desktop? still can have addons with phone home on clearnet
15:34:29 <richard> unsure tbh
15:34:48 <richard> well i don't have a solution, but we should perhaps think before blanket enabling all extensions
15:34:55 <richard> just becaue we *can*
15:35:26 <ma1> Well, for sure we could immediately relabel "Recommended" to "Available" and be in a much better place.
15:35:37 <richard> yeah agreed on that point^
15:36:19 <ma1> (maybe the warning foreword abount potential dangers of extensions could be directly under the "Available" header)
15:37:04 <ma1> so we 1) warn the user; 2) push the list further down as a further UI deterrence.
15:38:58 <richard> sounds like a good plan
15:39:29 <PieroV> I think we should also elaborate on what Dan says, in the future
15:39:47 <PieroV> I.e., check differences between desktop and Android
15:39:55 <richard> yes
15:40:01 <ma1> +1
15:40:10 <PieroV> Users are never happy with us gating things
15:40:24 <PieroV> At least we should be ready to explain
15:40:48 <dan_b> ux for wording?
15:40:56 <richard> +1
15:41:16 <ma1> ^ donuts ?
15:44:27 <richard> well we can worry about it on the ticket
15:44:40 <richard> assuming there is/will be one :D
15:45:42 <donuts> If you think UX is needed rather than just turning the recommendations off, feel free to assign the ticket over to me
15:46:00 <richard> is there anyhing else to discuss today?
15:46:03 <richard> otherwise i'm happy to call it
15:46:09 <donuts> however I've got to prioritize S30 fixes atm (and nicob's busy with S131), so it'll be bottom of the pile
15:46:14 <PieroV> I think we need to cherry-pick a bug from Moz
15:46:16 <donuts> (as with all unsponsored tickets atm)
15:46:17 <msim> i have a quick question
15:46:24 <richard> msim: gogogo
15:46:30 <msim> "quick" as in i haven't been trying to solve it for a few days ;D
15:46:32 <msim> so
15:46:46 <msim> current status is getting mingw builds working on a windows host (and has been for far too long now)
15:47:12 <msim> the current reason builds are failing is widl fails to find dlls/tlbs that *exist in the search paths given as arguments*
15:47:29 <msim> at first i thought path issue
15:47:41 <msim> but then when i copy and paste the command that mach executes into a shell, it works fine
15:47:57 <msim> as in, widl finds the library fine when it's executed from a command line, but fails to find it when executed from mach
15:47:59 <msim> https://share.riseup.net/#a7EPbKwNkGfkymbf552HNg
15:48:21 <msim> first command is what mach executes
15:48:38 <msim> midl.py then actually invokes widl
15:48:50 <msim> and i'm completely at a loss here
15:49:42 <msim> does anyone have any ideas as to why this happens? maybe python virtual envs have some weird footguns?
15:50:00 <richard> hm
15:50:57 <PieroV> I'd check the args list better
15:51:06 <PieroV> Maybe it isn't parsed as you'd expect
15:51:31 <msim> https://share.riseup.net/#KSrKI5AbHj9H3nKPBLdcfw
15:51:31 <richard> my best guess would be different environet vars
15:51:33 <msim> ^full mach run
15:51:36 <PieroV> (like print the args list passed to subprocess, in addition to "Executing: C:/...."
15:51:55 <msim> ah good idea
15:52:05 <msim> also, should clarify, the "missing" files are in `/c/Users/msim/Downloads/gecko-toolchain/msys2/mingw64/include/`
15:52:32 <msim> PieroV: ty :)
15:52:40 <PieroV> And then also check the env vars, maybe replace the exe with a small launcher that dumps the vars too
15:52:53 <PieroV> In case you defined some in your machine to use Mingw
15:52:55 <richard> ^ that's a good plan as well
15:53:04 <PieroV> Just in case mach does a cleanup
15:53:05 <msim> PieroV: wdym replace the exe?
15:53:31 <msim> like just drop an exe in place of widl that dumps environment?
15:53:32 <PieroV> Replace C:/Users/msim/Downloads/gecko-toolchain/msys2/mingw64/bin/widl.exe with a console app that print all the environment variables first
15:53:34 <richard> replace widl,exe that first prints out env vars and then invokes widle.real.exe for exampe
15:53:36 <msim> ah right
15:53:40 <msim> yea good idea
15:53:41 <PieroV> What richard says
15:54:00 <PieroV> (before stopping the bot I have another quick topic)
15:54:05 <richard> mk
15:54:44 <PieroV> I've updated to Python 3.11 (well Debian has) and the build is broken https://bugzilla.mozilla.org/show_bug.cgi?id=1769631
15:55:07 <PieroV> But there's already a fix that is landing 102.8, but we'll need to cherry-pick first
15:55:11 <richard> ooh nice
15:55:39 <richard> seems like a relatively small patch
15:55:42 <richard> https://hg.mozilla.org/releases/mozilla-esr102/rev/1345ee1bfd75
15:55:49 <PieroV> (just be aware, in case someone else gets the same error with Python 3.11)
15:56:50 <richard> i can backport that just to avoid weirdness for anyone on debian
15:57:25 <richard> alright lets end it here then
15:57:26 <richard> o/
15:57:29 <msim> o/
15:57:31 <richard> have a good week everyone
15:57:32 <ma1> o/
15:57:37 <richard> #endmeeting