14:58:32 #startmeeting Tor Browser Weekly Meeting 2023-01-30 14:58:32 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:58:39 meeting pad: https://pad.riseup.net/p/tor-tbb-keep 14:59:09 o/ 14:59:15 o/ 14:59:19 o/ 14:59:26 good morning afternoon and evening 15:01:30 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 i'm currently building/will be signing what will be our first privacy browser build for s131 15:02:25 \o/ 15:02:44 coool! 15:02:51 and I'm a bit excited to see msim's patchset in (hopefully) the next alpha 15:03:00 assuming we can iron out the rough edges before then 15:03:17 many, many, rough edges :p 15:03:31 we should get tags around February 9th so should be plenty of buffer time 15:04:33 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 So, if I understand what happens, you cannot install addons on Android, unless they're listed in the file we ship 15:05:40 But we ship only a few addons 15:05:57 Installation of the other ones fails with a very generic error message 15:06:14 I don't know if we really want TBA to be that walled 15:06:41 Firefox too shortlists their installable add-ons to a set of recommended ones, because Fenix compatibility is not trivial. 15:07:05 Yes, but that's another kind of error 15:07:21 I'm speaking of addons that work on Firefox for Android, but not on TBA 15:07:34 If an addon doesn't work you get an error on AMO 15:07:51 (like "your Firefox version/platform isn't compatible" or something similar) 15:08:06 But some addons that pass this step on Firefox, then have the generic error on TBA 15:09:36 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 (I guess it's generic because you're not supposed to get there in Firefox's UX provisions) 15:11:24 well if we do want to be that walled the UX should be fixed regardless 15:12:20 iirc it currently shows a list of recommended addons on the addon page 15:13:09 Yes, and those should be the only ones that can be installed at the moment, too 15:13:36 But it's a file we grab from Moz, so it isn't even that meaningful for us 15:13:50 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 And as a result we're being walled for nothing 15:14:50 The bad UX is already there 15:14:56 Even if we keep the curated list from Moz only 15:15:04 (is the curated list 11 addons only?) 15:15:49 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 (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 I mean that we don't double check that list 15:17:21 We should at least remove any visible recommended flag, since we're not recommending anything 15:17:35 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 PieroV, that's true. It should just be "available add-ons" 15:17:44 ^yeah that 15:18:24 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 of the generic error 15:19:03 Actually I don't even think you can install from AMO in fenix. 15:19:06 (I don't know that particular addon, just one that appears as recommended but isn't listed on our cache either) 15:19:38 Installing uBlock from AMO seems to work 15:20:00 Mmm, it turns out you can, actually (just checked). It used not to be the case iirc. 15:20:56 Anyway, I think that 1000 years of cache validity isn't a great value 15:21:04 :D 15:21:36 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 oh no, it seems rather convuluted and involving lists, anyway :( 15:22:13 We could add a warning about extensions 15:22:33 After you accept the permissions 15:26:31 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 Uhm, no, my plan we simpler: 15:27:06 (and of course removing any "recommended" label, but that should be done anyway)? 15:27:20 - remove our patches and switch to Firefox's behavior 15:27:32 - remove the recommended label, and change it with something like "available" 15:27:54 - maybe add a warning about installing extensions 15:28:16 i'm not sure I agree here 15:28:27 esp if torvpn is going to be a thing 15:28:49 Agree with what? 15:29:05 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 i'm saying maybe we should just disable extensions altogether in TBA 15:29:58 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 We have an issue for hiding recommended, we could update it: tor-browser#40502. 15:30:59 but letting users install extensions does seem like a potential privacy/security risk for people in say Iran etc 15:33:28 is the risk much different for desktop? still can have addons with phone home on clearnet 15:34:29 unsure tbh 15:34:48 well i don't have a solution, but we should perhaps think before blanket enabling all extensions 15:34:55 just becaue we *can* 15:35:26 Well, for sure we could immediately relabel "Recommended" to "Available" and be in a much better place. 15:35:37 yeah agreed on that point^ 15:36:19 (maybe the warning foreword abount potential dangers of extensions could be directly under the "Available" header) 15:37:04 so we 1) warn the user; 2) push the list further down as a further UI deterrence. 15:38:58 sounds like a good plan 15:39:29 I think we should also elaborate on what Dan says, in the future 15:39:47 I.e., check differences between desktop and Android 15:39:55 yes 15:40:01 +1 15:40:10 Users are never happy with us gating things 15:40:24 At least we should be ready to explain 15:40:48 ux for wording? 15:40:56 +1 15:41:16 ^ donuts ? 15:44:27 well we can worry about it on the ticket 15:44:40 assuming there is/will be one :D 15:45:42 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 is there anyhing else to discuss today? 15:46:03 otherwise i'm happy to call it 15:46:09 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 I think we need to cherry-pick a bug from Moz 15:46:16 (as with all unsponsored tickets atm) 15:46:17 i have a quick question 15:46:24 msim: gogogo 15:46:30 "quick" as in i haven't been trying to solve it for a few days ;D 15:46:32 so 15:46:46 current status is getting mingw builds working on a windows host (and has been for far too long now) 15:47:12 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 at first i thought path issue 15:47:41 but then when i copy and paste the command that mach executes into a shell, it works fine 15:47:57 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 https://share.riseup.net/#a7EPbKwNkGfkymbf552HNg 15:48:21 first command is what mach executes 15:48:38 midl.py then actually invokes widl 15:48:50 and i'm completely at a loss here 15:49:42 does anyone have any ideas as to why this happens? maybe python virtual envs have some weird footguns? 15:50:00 hm 15:50:57 I'd check the args list better 15:51:06 Maybe it isn't parsed as you'd expect 15:51:31 https://share.riseup.net/#KSrKI5AbHj9H3nKPBLdcfw 15:51:31 my best guess would be different environet vars 15:51:33 ^full mach run 15:51:36 (like print the args list passed to subprocess, in addition to "Executing: C:/...." 15:51:55 ah good idea 15:52:05 also, should clarify, the "missing" files are in `/c/Users/msim/Downloads/gecko-toolchain/msys2/mingw64/include/` 15:52:32 PieroV: ty :) 15:52:40 And then also check the env vars, maybe replace the exe with a small launcher that dumps the vars too 15:52:53 In case you defined some in your machine to use Mingw 15:52:55 ^ that's a good plan as well 15:53:04 Just in case mach does a cleanup 15:53:05 PieroV: wdym replace the exe? 15:53:31 like just drop an exe in place of widl that dumps environment? 15:53:32 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 replace widl,exe that first prints out env vars and then invokes widle.real.exe for exampe 15:53:36 ah right 15:53:40 yea good idea 15:53:41 What richard says 15:54:00 (before stopping the bot I have another quick topic) 15:54:05 mk 15:54:44 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 But there's already a fix that is landing 102.8, but we'll need to cherry-pick first 15:55:11 ooh nice 15:55:39 seems like a relatively small patch 15:55:42 https://hg.mozilla.org/releases/mozilla-esr102/rev/1345ee1bfd75 15:55:49 (just be aware, in case someone else gets the same error with Python 3.11) 15:56:50 i can backport that just to avoid weirdness for anyone on debian 15:57:25 alright lets end it here then 15:57:26 o/ 15:57:29 o/ 15:57:31 have a good week everyone 15:57:32 o/ 15:57:37 #endmeeting