18:01:03 #startmeeting Tor Browser meeting 21 September 2020 18:01:03 Meeting started Mon Sep 21 18:01:03 2020 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:38 This is the time and place 18:01:45 here is the pad: https://pad.riseup.net/p/tor-tbb-2020-keep 18:02:09 you are the participants, wllcome all 18:02:14 *welcome all 18:02:25 hello! 18:03:15 hello! 18:03:29 hello 18:05:07 so far we only have 1 discussion item 18:06:26 sorry, now we have two 18:07:29 ahf: "Mobile API usage survey"? 18:07:50 is that sitll a work in progress or are you already sending it to people? 18:07:54 *still 18:08:23 we have tested it with benjamin 18:08:43 about what they need for ios 18:09:06 but the pad needs some revisions i think. i dont know what next step is here, but i think gaba might know? 18:09:41 okay. cool 18:10:22 please don't forget to include us (browser/application people) in it :) 18:10:25 network team need to figure out what we need to do for people who are integrating tor because right now it is a bit of a pain 18:10:27 no no no 18:10:31 you are coming in for the android stuff 18:10:35 XD 18:10:45 sounds good 18:12:21 alrighty. we have Tor Browser 10.0 and 10.5a1 releases this week 18:12:59 we'll see later in this week if we can release the first android alpha based on fenix 18:13:25 wrt to api survey, the next step will be for me to start organizing meeting with people. 18:13:28 we still have some implementation peices remaining, and some build reproducibility 18:13:31 sysrqb: i will include browser 18:13:47 gaba: thanks 18:14:47 sysrqb: one more thing. the issue for the survey is https://gitlab.torproject.org/tpo/core/team/-/issues/14 18:15:41 great, thanks 18:16:08 i hope i can follow along, but i'll probably forget and then participate in the survey when it's ready :) 18:16:31 ok 18:17:34 mikeperry: did you already start on the audit script? 18:18:00 and you don't have another natural disaster headed your way this week, right? 18:18:18 no 18:18:19 * sysrqb is losing track of all the natural disasters 18:18:50 okay 18:19:00 I am still thinking about how to do it and if I should include desktop stuff too 18:19:05 I am guessing android is most important? 18:19:26 most important, yes, but if you can get desktop for free (or alomost free) then please try to include it 18:19:45 we'll need desktop before we move onto the release train for that piece 18:20:02 but that isn't in the pipeline for another couple months (probably, maybe) 18:20:10 and there is mobile code that uses general network proxy settings in geckoview 18:20:16 making sloppy script is easy. making it nice and easy to add things and give context and such may be trickier 18:20:26 see fenix#40045 18:20:49 so, i am not sure whether there is a clear line we can draw here 18:21:11 * antonela needs to step out - door, brb 18:21:19 k 18:23:05 yah 18:23:24 that client could also get set to a basic http client, which I think uses system proxy settings 18:23:36 or to the system webkit 18:23:46 yeah, and application-services#1 reminded me of https://bugzilla.mozilla.org/show_bug.cgi?id=1620045, too 18:25:02 the positive answer is that it seems mozilla is generlly respecting the network proxy settings 18:25:44 the unfortunate part is that the APIs are very flexible, and changing from (for example) gecko to webkit is very easy 18:25:54 when I looked at the client usage, it looked ok 18:25:55 yah 18:26:13 so we need to make sure these parts don't change in the future (accidently) 18:26:29 i wonder if sth like https://developer.android.com/studio/command-line/apkanalyzer can help here 18:27:12 acat: that looks nice 18:27:25 getting a diff between apks 18:27:48 we should catch these issues during code review when we rebase, too 18:28:07 but i'd feel better if we had some tooling to help here, too 18:29:43 acat: can you open an issue for something like "investigate tools for identifying changes between fenix versions"? 18:29:55 the wording could be better 18:29:56 sure 18:30:02 but something so we're reminded that we want this 18:30:18 and you can add the apkanalyzer as a possible option 18:30:34 thanks 18:30:44 antonela: are you back? 18:31:53 ahf: are you looking at the fenix migration stuff this week, as well? 18:33:00 right, we need to test one at least once for alpha users 18:33:20 so, probably at least one additional alpha after the first one 18:33:31 sysrqb: i think i will be done tomorrow morning with it, then probably try to grab something else from you 18:33:49 ahf: great, thanks 18:34:56 GeKo: is your comment for the migration or diff tooling? 18:35:16 migration 18:37:09 i'm not sure i follow why we need at least two alphas for testing the migration 18:37:28 is it from alpha to alpha or what do you mean by that? 18:37:31 i think we want two for general testing, so i'm not opposed to this 18:37:35 yes 18:37:53 ok 18:37:58 we should test whether the fennec alpha -> fenix alpha migration works 18:38:16 so we have an idea whether the fennec stable -> fenix stable migration works 18:38:17 ah, right. i thought you meant one fenix alpha to another fenix alpha. makes sense 18:39:02 hrm 18:39:21 what happens to fennec alpha users once we release the first fenix alpha? 18:39:56 maybe i have the logic wrong here 18:40:03 if they are using a recent-enough android version, then they become fenix users 18:40:13 and if not? 18:40:14 we're migrating in-place 18:40:24 then they never upgrade 18:40:25 no, it sounds right. if we continue those two channels they will be upgraded so that needs to be tested too 18:40:32 same as fennec 18:40:40 aha, okay you get that for free then 18:40:49 yes 18:40:57 why do we need to test the upgrade logic then 18:40:59 ? 18:41:11 because that seems to be like a normal update then, no? 18:41:15 "normal" 18:41:23 mostly just a sanity check 18:41:34 ah, okay. then scratch my comment 18:41:36 ah, and because fenix stores information different 18:41:38 to make sure that bookmarks and other state isn't dropped. i took it as a make sure nothing breaks 18:41:41 which is why there is custom migration logic 18:41:48 and there is some logic to upgrade from one to another 18:42:00 i don't know if i use the term upgrade there correctly. sounds like it should be called migrated here 18:42:00 from one fenix to another one? 18:42:09 no 18:42:27 from current TB to Fenix based TB 18:42:32 k 18:42:49 so, yes, then there is no need for two alphas for that, cool 18:43:00 sysrqb: now back, sorry 18:43:10 we get the fallout from upgrading to the first fenix alpha, nice 18:43:11 good, i'm glad you're on the same page now :) 18:43:23 yeah 18:43:23 buenos 18:43:48 antonela: cool. as usual, i am late in asking this, but is there a comms plan for Tor Browser 10.0 release? 18:44:08 are we just releasing the normal blog post? 18:44:34 normal blogpost, some social media, i'm copypasting your changelog from tor-qa 18:44:51 we can discuss the details of the highlights right after this meeting 18:45:04 okay 18:45:06 what we will do with tba? 18:45:21 that is the next question/discussion item 18:45:26 great 18:46:37 i reached out to mozilla, and they will help us (some amount) for discovered/disclosed security issues over the next couple weeks 18:47:18 i dislike the idea of discouraging people using the current Tor Browser app during this time 18:47:51 because that sends mixed signals and will likely scare people away from tor browser on win the longer-term 18:48:43 +1 nice 18:48:56 i agree, do we have a list of potential threats? something we want to advice people specificly on? 18:49:28 i'd like to say something like "Android Tor Browser is under active development, and we are supporting the current Android Tor Browser until the new version is ready. We expect the new Android Tor Browser will be released in the beginning of October." 18:49:58 sounds good to me 18:50:08 i don't think we should commit a specific releae day 18:50:22 but I hope "Early october" is vague enough that we have some flexibility 18:50:41 we can use the same comms pattern we did during 9.06 about disabling JS https://www.torproject.org/download/ 18:50:49 sysrqb: we should mention that mozilla is helping us keeping an eye on potential security issues in the mean time 18:50:52 banner in /download and a mention in the release blogpost 18:51:16 because users would start wondering what the security story is here 18:51:17 GeKo: i'll confirm Mozilla is okay with saying this publically 18:51:23 yeah 18:51:34 we are walking a fine line here 18:51:42 yeah 18:51:58 i am totally fine seeing some hand-wavy thing on our blog 18:52:15 being non-committing etc. 18:52:32 and making sure the blame falls on us if we mess up 18:53:07 yeah 18:54:09 okay, good 18:55:16 i was hoping we could assign people for remaining unassigned tickets 18:55:19 https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%20Browser%3A%2010.0&assignee_id=None 18:55:32 for the Tor Browser 10.0 milestone 18:55:41 but with 3 minutes remaining, i don't think we have time 18:56:35 GeKo: did you add the FF82 tickets into the milestone in preparation for 10.0.1 (or 10.0.2) whichever comes at the end of October? 18:56:59 as in, this milestone now has tickets for future 10.0 releases? 18:57:19 the milestone is meant to be for the whole life of 10.0 18:57:39 yeah 18:57:40 if things should land in 10.5 first they should go into the 10.5 milestone 18:57:46 and then get backported 18:57:49 imo 18:57:57 but with the fenix things this is tricky 18:58:05 because we still target 10.0 for them 18:58:14 yeah, i agree, i wonder how we should tag issues that should go into specific 10.0 releases 18:58:18 hence the milestone for the ff82 tickets 18:58:34 so 18:59:09 the original idea was to use the 10.0 milestone for all minor releases, too 18:59:27 because there would not be so much changes between bugfix only releases 18:59:53 however, the mobile world is following a different model now 18:59:56 ah ha 19:00:02 with the regular release train 19:00:03 right, okay, that makes sense 19:00:52 so, i think we need to figure out whether we still want to adhere to the .0 and .5 releases as major releases 19:01:01 or whether mobile changes that part 19:01:21 and then we can figure out whether the .0 milestone is enough to track everything 19:01:32 yes, but that can be in a different meeting 19:01:37 or whether we need to have something more finegrained 19:01:40 yep 19:01:40 but we should discuss it 19:01:59 yeah. 19:02:14 right now things that land on 10.0.x first have 10.0 as milestone 19:02:33 and those with 10.5(a)x 10.5 19:02:34 wfm 19:02:39 at least that's the idea 19:03:05 yep 19:03:21 okay, i think antonela answered the final discussion point on the ticket 19:03:52 so, with that i'll close this meeting 19:03:56 thanks everyone 19:04:08 sorry we ran a little over time 19:04:11 #endmeeting