14:58:11 #startmeeting Tor Browser Weekly Meeting 2023-10-02 14:58:11 Meeting started Mon Oct 2 14:58:11 2023 UTC. The chair is PieroV. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:58:11 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:58:36 Hi everyone! Since richard is afk I'm going to facilitate this meeting :) 14:58:46 Our pad as usual: https://pad.riseup.net/p/tor-tbb-keep 14:58:48 o/ PieroV & thank you! 14:58:58 Hi! 14:59:05 o/ 14:59:31 o/ 15:00:00 hmm, Riseup pad onion seems unresponsive for me 15:00:08 Might be a local issue here, my Internet has been spotty today 15:00:25 * Jeremy_Rand_36C3[m] doesn't really have anything particularly important to add to the pad anyway 15:02:11 Jeremy_Rand_36C3[m]: Riseup onion seems to work for me! 15:02:56 o/ 15:03:56 jagtalon: thanks for triangulating. Yeah gonna guess it's just awful Internet here. 15:04:14 I think we can start 15:05:10 Last weekend we released 13.0a6, it contained a lot of the blockers for 13.0 15:05:49 Its 1 of two Oct holiday Mondays for me, so I'm off today, just dropping by to update the pad and make sure there's nothing urgent? Otherwise I'm on YEC for Android tomorrow :) 15:06:03 So, should we release a 13.0a7 or are we ready for 13.0? I think their email forgot an important one because it went on future 15:06:19 And it's the Android API level 15:06:44 dan_b: maybe clairehurst can answer for that in case you want to go :) 15:06:47 what's the situation with that? 15:07:03 Ah, have we bumped that in the dependency it was lower in? 15:07:08 We asked for an extension, and the new deadline is November 1 15:07:13 do we have a ticket for the android api level? 15:07:18 Yes, we have it 15:07:35 tor-browser#42028 15:07:38 thanks 15:07:54 My opinion is that we should try to launch 13.0 with it already fixed 15:07:54 And this is a blocker for 13.0? 15:08:32 If we don't fix it for 13.0, we'll need to have it fixed in 13.0.1 15:08:57 right 15:09:01 PieroV: I think we need the updated icons, which should be done soon. Let me make sure there isn't anything else 15:09:11 The team is going to have an in-person meeting in the week of October 23 15:09:15 clairehurst: I think there is a tool to run on an .apk to tell you which dep of it is causing API level to be lowered? 15:09:39 Pretty sure I remember doing that once 15:09:50 I have two other potential blockers for 13.0 as well 15:09:54 Oh neat! That's going to be super helpful dan_b 15:10:22 Ah was hoping you knew off hand. Ok Im pretty sure I have it installed so I'll try and dig it up 15:10:33 Since we're having the in-person meeting, the deadline of November 1 isn't great 15:10:49 Yeah I haven't encountered that particular issue before 15:11:03 And it'd be better to try to fix sooner rather than later 15:11:24 I can jump on that right after updating the icons 15:11:33 Awesome, thank you very much! 15:11:54 Apart from that and the icons, there aren't too many blockers from richard's email 15:12:22 A review of my pref review as anticipated last week (tor-browser#41496) 15:12:58 And a check for unwanted connections in Mullvad Browser, but Mullvad QA might check on that, we'll have to coordinate on that 15:13:04 ah i was using `apkanalyzer manifest permissions` to find what dep was adding a permission 15:13:38 donuts: what are your blockers? 15:14:00 sorry you've caught me in the middle of switching computers 15:14:06 1 sec while i bring the pad back up 15:15:00 tor-browser#41581 seems to have been closed without a fix for TB 15:15:18 so as of 13.0a6, noscript is still visible in the extensions toolbar menu 15:15:26 I also want to get https://gitlab.torproject.org/tpo/applications/firefox-android/-/merge_requests/23 merged for tor-browser#42121, which I should be able to have ready by EOD 15:16:01 and secondly, richard was also going to chat to the network team last week about whether or not conflux is going to cause strange behavior for the circuit display on release 15:16:15 although I don't know what the outcome of that discussion was – maybe someone here knows? 15:16:24 I saw some messages in #tor-dev 15:16:38 Basically the behavior should be compatible with what we do 15:16:45 But we won't display anything special for conflux 15:16:59 So will users see the first leg of the circuit, for example? 15:17:14 One of the two circuits should always be bound to the SOCKS username+password from what I understood of those messages 15:17:20 So, we're going to display that circuit 15:17:23 ah right okay 15:17:49 how do we feel about that? good enough for release? 15:18:46 If we want special UI treatment for conflux, I guess it's a lot of work - realistically for 13.5 or beyond anyway, right? 15:18:56 I don't know if Tor is signaling the other conflux circuit in some way 15:19:13 (and coordination with the network team indeed) 15:19:19 right 15:19:34 I'm guessing the Conflux signaling will change anyway with the Arti transition? 15:19:52 Well, all the signaling will :) 15:19:52 So maybe not worth writing a bunch of control port code for this before the transition? 15:19:58 right 15:20:02 we will probably need to ask for it, I don't think this detail level it's a priority for the Arti team 15:20:13 I hope the refactor of the control port will make it easy to do it in case 15:20:31 hence my inclination to only do it once rather than twice :) 15:20:31 okay sounds like we're "good enough" for 13.0 15:20:39 +1 15:20:58 back to my first blocker, richard didn't like my initial suggestion for tor-browser#41581 15:20:59 clairehurst: is the change you'd like to do risky? 15:21:07 Oh, sorry donuts, go ahead 15:21:16 does anyone have any alternative suggestions? 15:21:50 the risk is that users will try to configure noscript directly since it's relatively easy to access via the toolbar, instead of going through the security level toolbar button 15:22:08 we could disable the unified extensions toolbar menu completely, I suppose 15:22:24 I wonder if richard's point was wrong, actually 15:22:48 PieroV: for tor-browser#42121? No I don't think its risky 15:23:06 Should just be removing a few UI elements 15:23:50 pierov: I've reopened the issue, can I assign it to you to look into? 15:24:00 donuts: "accessing the NoScript extension impossible without adding some other extension." - I'm not sure about what this means 15:24:09 You can access it from about:addons 15:24:21 yep, exactly 15:24:53 Pierov: so I just looked. in code we have compileSdkVersion and targetSdkVersion at 33 and I dont see a big red error on the android alpha in the play console? or is that cus we asked for an extension? 15:25:27 clairehurst: I think we should maybe run a tor-browser-build build to test it anyway, just to test it in some way 15:25:40 AFAIK, Android nightly builds are still broken :/ 15:26:03 donuts: yes, I can have a look, maybe I'll also ask ma1 what he thinks 15:26:06 in projects/tor-onion-proxy-library/gradle.patch I see a `targetSdkVersion 29` 15:26:09 dan_b: I still see the error 15:26:12 Sounds good. Also want tor-browser#42133, which is also basically done (just need to make it into a fixup commit) 15:26:14 pierov: ack, thank you 15:26:17 pierov: looking further at the play console for hte alpha, it confirms our app is tarket sdk 33 15:26:18 where? 15:26:27 boklm: I agree that this might be the problem 15:26:35 i see if on tor browser 15:26:48 Oh, I might have checked tor browser 15:26:49 but if you back out to "all apps" and pick "tor browser alpha" i dont see it 15:26:51 Let me check again 15:27:52 I see it fixed now, you're right \o/ 15:28:03 I'm not sure what we did, but it's great! 15:28:23 yep, so we can close that blocker 🙂 15:28:33 regarding tor nightly, let me know what i can do like sending detailed adb logs 15:28:36 I wonder if the warning was generated on an old 12.5aX 15:29:32 The first 13.0 Android alpha was 13.0a2, released on August 12 (at least on the blog) 15:29:56 donuts, two things though: 1) NoScript is still hidden in the toolbar, even if one click on the puzzle icon away instead of right-click -> "Customize" (not very ergonomical anyway, unless user decide to actually pin it, which requires another two clicks) 2) any change made from that menu is temporary as long as we're in private mode (always) 15:29:59 i just think we skipped 13.0a1 for android 15:30:32 but yeah maybe someone accidently put a 12.5 up? dunno. or just left the old 12.5 alpha up and then it got flagged wit the error 15:31:03 Yes, we did. I see the warning generated on August 18, so a few days after 13.0a2, but the old screenshot says date sent August 11, so the day before 13.0a2 15:31:30 weird 15:31:48 ma1: not sure whether that extra click will be enough of a deterrent, however I really can't say until we start getting user feedback 15:31:51 well, its gone now so 🤷‍♀️ and woo 15:31:59 I'm sure curious users will notice the new icon in the toolbar relatively quickly 15:32:37 So, perhaps to be safe, we should hide it from the toolbar menu entirely 15:32:42 donuts: what exactly is the concern about users configuring NoScript manually? 15:32:56 donuts: I suspect there may be cases where doing so is safe 15:33:23 Jeremy_Rand_36C3[m]: we would prefer users to interact with the predefined security level options instead 15:33:48 donuts: I'm not certain that's always the right approach. Qubes DispVM's where only a single website is accessed seem like a possibly safe place to deliberately enable only the bare minimum to get a site to work. 15:34:27 Not saying that's definitely the case, but it seems plausible 15:35:02 Jeremy_Rand_36C3[m]: it's plausible, however power users can continue to interact with noscript via about:addons without the risk of general users getting in a tangle 15:35:07 (I don't want to derail the discussion, just wanted to make sure this is considered) 15:35:24 donuts: going to about:addons in a DispVM seems like a lot of extra click work 15:36:46 I get what donuts is saying 15:36:51 this seems niche to me 15:37:05 a general user who breaks their security level is going to be confused 15:37:11 Its not like we used to show it, and now it would annoy people to no longer have it 15:37:25 also, many general users won't even know noscript is installed at all 15:38:10 donuts: as someone who uses DispVM's routinely, I'm not convinced it's a niche use case. That said, handling the UX for this in a robust way is probably more effort than either no change or disabling the UI, so short term I'm fine with deferring this, until we can evaluate something better 15:39:10 If we hide the icon, can power users show it again? 15:39:18 So, they can interact without the extra clicks 15:39:21 Yeah, that's one risk to this approach 15:39:48 ideally power users should still be able to add noscript to the toolbar itself 15:40:28 PieroV: there are issues with changing settings in a DispVM template, but probably those issues are Whonix's problem, not ours 15:41:13 PieroV: I could work on this since I've tinkered in the area before and I'm only working on minor things this week 15:41:23 (well, I mean, maybe we should coordinate with Whonix on finding a way to solve that better -- but it's not something we can deal with on our own) 15:41:34 henry-x: ack, feel free to take the issue then :) 15:41:36 Thanks 15:42:01 Jeremy_Rand_36C3[m]: I think Tails achieves custom config via user.js 15:42:01 thanks henry-x! 15:43:10 PieroV: yeah, IIRC they can do that because they package Tor Browser themselves as a deb; Whonix fetches the official Tor Browser binaries, and the specific way they do that makes the approach you describe nontrivial. But yes, we should encourage them to improve that. 15:43:49 * Jeremy_Rand_36C3[m] has been meaning to talk to the Whonix guys about exactly that issue for quite a while, but ENOTIME 15:44:03 ack 15:44:21 So, with what we said at this meeting, should we do these final changes without another alpha? 15:45:08 We still have 3 or 4 items we want to fix, so Wed as a date for 13.0 might not work anymore 15:45:36 I'm very nervous about deploying changes like this without another alpha, but maybe OK to make it a shorter-lived alpha than usual? (Or maybe I'm just being overly cautious and it's fine to release) 15:46:28 Yeah Wed feels very tight 15:46:44 if we release another alpha, what would the new date for 13.0 stable be? 15:46:45 I think we can use nightly to test, or ad-hoc builds for Android 15:47:36 donuts: it depends on how much time we want to take to test or to wait for last minute feedback 15:47:54 did richard's fix last week changing the nightly channel fix the nightly builds for andoird or are they *still* crashing? 15:48:07 pierov: how much testing will android require after the API change? 15:48:17 donuts: it seems the error disappeared 15:48:28 I got confused and checked the stable dashboard 15:48:35 yeah 13.0 has been 33 the whole time, we inherited that from moz 15:48:44 + some timings problems from Google 15:48:55 They generated the warning on Aug 11, but notified us on Aug 18 15:49:05 playconsole... sluggish 15:49:10 In the meantime, we published the first 13.0 alpha for Android (on Aug 12) 15:49:18 which is what you want when it gives you tight deadlines... 15:49:25 dan_b: oh there's a fix for nightly on android? i haven't tested! 15:49:50 jagtalon: dan_b: I think richard's fix was for single-arch (currently only testbuilds) alpha builds 15:50:15 https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/820/diffs 15:50:56 jagtalon: you can give it a quick try, i'm unsure. it built for me locally 15:51:08 I don't think it fixes nightlies, it changes only alphas 15:51:25 aah yes it's just into main for tbb 15:51:34 ah alrighty 15:51:47 but once we promote 13.0 😄 should be good 15:52:44 So, I think we can push 13.0 to the beginning of the next week 15:52:55 sounds fine to me 🙂 15:52:59 I can prepare it later this week and we can build it over the weekend 15:53:05 should we still do an alpha this week? 15:53:21 If nothing is on fire on Monday, we can start releasing 15:53:44 okay, sounds sensible to me 15:53:54 boklm: that is the remaining question. donuts, what do you think? 15:54:28 or is testing the changes in nightly enough? 15:54:29 I don't think we'd get any alpha tester feedback in such a short window anyway 15:54:35 so testing nightly may be sufficient 15:54:40 wfm 15:54:45 dan_b: So we don't need to upgrade to 33 then, since we're already there? 15:54:50 yep! 15:54:51 however I'm not sure about android 15:55:02 as I don't really understand the potential impact of the API issue 15:55:04 Cool! Can we close the story then? 15:55:19 clairehurst: i'll look at your MRs first thing tomorrow morning 15:55:21 donuts: the API issue should not really be an issue anymore 15:55:26 pierov: ack okay 15:55:32 no alpha necessary then 15:55:33 But only delay from the play console 15:55:47 Okay! Does anyone has anything else? 15:55:54 (but we're close to the hour) 15:55:57 nothing from me 15:55:57 are we doing a qa day this week? sorry i might have missed that 15:56:26 jagtalon: that might be a very good idea 15:56:36 Maybe we wait for the last changes and then do it 15:56:44 👍 15:56:45 I have 2 things that I was going to bring up, but they can wait till next week 15:57:02 great yeah please ping when ready to test! 15:57:11 They're not urgent 15:57:16 Okay Jeremy 15:57:16 yeah jagtalon and I need to leave for our next meeting :) 15:57:27 Closing the meeting then! 15:57:29 #endmeeting