18:29:41 <sysrqb> #startmeeting Tor Browser Team Meeting, 18 November 2019
18:29:41 <MeetBot> Meeting started Mon Nov 18 18:29:41 2019 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:29:41 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:29:54 <sysrqb> Hello, hello
18:30:25 <boklm> hi
18:30:42 <acat> hi
18:30:48 <mcs> happy Monday!
18:30:51 <brade> hi
18:31:05 <sysrqb> happy happy
18:31:29 <pili> Hi!
18:31:57 <sisbell> hi
18:32:47 <Jeremy_Rand_Talos> Hello!
18:35:39 <sysrqb> okay
18:36:08 <sysrqb> i bolded acat's item for #21952
18:37:00 <sysrqb> i wonder if we should think about this some more
18:37:25 <sysrqb> i'm excited to see how this looks, and the patch acat posted looks good so far
18:37:28 <mcs> Was Antonela going to provide feedback in that ticket?
18:37:29 <sysrqb> (i only skimmed it)
18:37:47 <sysrqb> but i wonder if this is really something we want
18:38:02 <pili> Makes sense that she would
18:38:11 <pili> She’ll be back on Wednesday
18:38:24 <acat> i didn't mean finishing the work, just leaving the prototype code in a decent shape :)
18:38:34 <sysrqb> ah, okay
18:38:35 <mcs> acat: ah, makes sense
18:38:52 <sysrqb> i got an out-of-office from anto, too :)
18:39:02 <sysrqb> but, in particular, i think the idea is interesting
18:39:05 <acat> what i posted did not implement automatic redirects, so just wanted to push a new version with that, and the pref exposed in about:preferences
18:39:45 <sysrqb> yeah, that's good
18:40:00 <GeKo> sysrqb: what is "this"?
18:40:15 <GeKo> in the what we really want sentence?
18:40:20 <GeKo> the particular patch?
18:40:29 <sysrqb> i had a conversation with alec, and i read over the the ticket and proposal, and i am wondering if this is actually a good idea
18:40:33 <GeKo> or whether we want to give the user an educational moment
18:40:55 <GeKo> where we want to give the user the option to visit a .onion instead?
18:40:56 <sysrqb> in particular, will anyone use this header if we implement it in tor browser
18:41:41 <GeKo> well, alec will probably working pretty hard against the adoption
18:41:52 <Jeremy_Rand_Talos> So, I can say that Namecoin definitely would like to use this kind of functionality to redirect users from DNS domain names to Namecoin domain names when the website has a .bit domain available
18:41:59 <sysrqb> i like the idea of telling people they are using an onion service
18:42:12 <sysrqb> so the UI is a nice addition
18:42:31 <sysrqb> but maybe there is a better way we can accomplish this
18:42:48 <sysrqb> maybe finishing #21952 is a good first step
18:42:49 <Jeremy_Rand_Talos> And I think generally speaking there's a major benefit to having a machine-readable method of telling users "there's a .onion version of the site you're on"
18:42:56 <sysrqb> and we should continue down that path
18:43:07 <sysrqb> pospeselr: wlecome
18:43:12 <sysrqb> welcome...
18:43:53 <sysrqb> but, i think this is dicsussion that is better had on a mailing list
18:44:06 <sysrqb> so i'm thinking about starting another thread
18:44:17 <GeKo> what would the topic be?
18:44:21 <pospeselr> o/
18:44:21 <Jeremy_Rand_Talos> I haven't read all the way though the ticket yet, but I think one decent way to avoid confusing/panicking users would be to make the browser display a notification that says "This website has automatically redirected you to its onion service" or something to that effect
18:45:01 <sysrqb> GeKo: "Is an Onion-Location header a good idea?"
18:45:10 <GeKo> for what?
18:46:03 <sysrqb> for solving the problem of redirecting users from dns-domains to .onion addresses
18:46:52 <sysrqb> it seems like we thikn this is a good idea, so we're doing it
18:47:00 <sysrqb> but i don't know if we know this is a good idea
18:47:22 <GeKo> well, there has been plenty of discussion about that on the tor-dev
18:47:24 <GeKo> mailing list
18:47:30 <GeKo> and the result is #21952
18:47:45 <GeKo> and the otf proposal which gives us the money to implement that
18:47:58 <sysrqb> right. but the world has changed a bit since that discussion. i'm fine trying this as an experiment
18:48:05 <sisbell> If those headers are forged, it can send someone to unrelated onion adress
18:48:15 <sysrqb> so we can continue with the implementation
18:48:30 <Jeremy_Rand_Talos> Speaking as the "new guy", is there a summary of why it might not be a good idea that I can read up on?
18:48:38 <GeKo> yeah, i am fine with whatever we decide here
18:48:50 <sysrqb> but i think maybe we should think more about this
18:49:08 <GeKo> i just wanted point out that like 1 or 2 years ago we had plenty of dicussions
18:49:10 <sysrqb> Jeremy_Rand_Talos: the ticket has some of that info
18:49:20 <sysrqb> GeKo: yeah
18:49:28 <GeKo> and were confident that #21952 is an option forward worth exploring
18:49:47 <sysrqb> but i think the new world with alt-srv and other new pieces of the puzzle make this a more weird solution long-term
18:49:51 <pili> I would just like to say that, with my PM hat on, we should probably at least try to fulfil the spirit of the proposal :)
18:49:58 <GeKo> sysrqb: i think an important point in your mail opening that new thread would be to explain why we now think #21952 might not be a good idea anymore
18:50:08 <GeKo> like what has changed from now to then
18:50:26 <GeKo> *then to now
18:50:29 <sysrqb> GeKo: yeah, i'll make sure i include that
18:50:43 <sysrqb> pili: yeah, i'm not saying we should stop the work now
18:51:17 <GeKo> from my pov the important part is that we have a mechanism where the user can decide whether they want to opt into an onion
18:51:25 <sysrqb> i'm just raising my concern thta this isn't really a solution that will see wide deployment, even if we implment it, and maybe we should think about it again
18:51:26 <GeKo> to give them a educational experience
18:51:48 <GeKo> whether that's achieved via a new header
18:51:51 <GeKo> or Location
18:51:54 <GeKo> or...
18:52:03 <sysrqb> yeah
18:52:04 <GeKo> is probably not that important
18:52:07 <GeKo> e.g.
18:52:14 <sysrqb> i agree
18:52:23 <GeKo> i could easily see us in #21952 Location instead
18:52:27 <GeKo> *using
18:53:20 <sysrqb> yeah
18:53:55 <sysrqb> okay, good
18:54:04 <sysrqb> okay sisbell: you're up. what is MR?
18:54:46 <sisbell> This would be to the TOPL project
18:54:59 <sysrqb> but what is "MR"?
18:55:14 <sisbell> Once we review these issues, I'd like to submit a merge request to topl
18:55:23 <sysrqb> ah, "merge"
18:55:23 <sysrqb> thanks
18:56:05 <GeKo> sisbell: works in principle for me
18:56:15 <sisbell> ok, cool
18:56:24 <GeKo> we should however making sure to sort the things out with the guardian project folks
18:56:39 <GeKo> so we are sure there is a place for TOPL in the future or not
18:56:54 <GeKo> because if not then we should not spend timie on TOPL work (anymore)
18:57:04 <GeKo> *time
18:57:12 <sysrqb> i'll prioritize the code review today/tomorrow
18:57:18 <sisbell> GeKo: Yes, i'll follow up more this week. These changes are first step in getting the config stuff cleaned up and moved to their own module
18:57:23 <GeKo> and the same holds for other parts that might go away
18:57:24 <sysrqb> but yes, we should follow up on that discussion
18:57:33 <GeKo> sysrqb: thanks, appreaciated
18:57:36 <sisbell> So it can be used independently of other TOPL code
18:57:52 <GeKo> sisbell: yes, but the point is whether we end up using that in the future
18:57:55 <GeKo> or not
18:58:19 <GeKo> and the time we spend on things should be related to that question in the first place
18:58:46 <GeKo> sisbell: could you put #31992 on your plate, too?
18:58:49 <sisbell> TOPL can be broken into parts we can resuse and those which conflict (potentially) with using tor as an embedded service
18:59:07 <sisbell> so getting those defined is important
18:59:16 <GeKo> yes, i tend to agree
18:59:24 <GeKo> hence the discussion with hans and nathan
18:59:32 <sisbell> Sure, I'll put the apktool workaround into this week's tasks
18:59:59 <GeKo> sisbell: when you pick up that discussion it would be worthwhile to fold in the discussion that happened on #32032 as well
19:00:02 <GeKo> err
19:00:19 <GeKo> #32303
19:00:27 <GeKo> there are good points in it
19:00:34 <sisbell> ok, I'll look
19:00:40 <GeKo> thanks
19:01:42 <sysrqb> great, thanks sisbell
19:03:31 <sysrqb> okay, tomorrow GeKo, pili, mcs, brade, and I are going through the current set of tickets
19:03:52 <sysrqb> and assigning people who we think will be able to work on them within the next two months
19:04:32 <sysrqb> in particular, we're hoping we can choose target releases for some tickets
19:04:49 <sysrqb> in particular, the sponsored work, like s27
19:05:22 <sysrqb> so, some of you already have some tickets assigned, and tomororw we'll hopefully assign most of the remaining tickets
19:05:42 <sysrqb> don't treat these assignments as set-in-stone
19:06:17 <sysrqb> we're simply trying to understand our capacity and make a guess about when certain bugs and features will be completed
19:06:46 <sysrqb> so, if you have any questions or concerns, please ask
19:07:09 <sysrqb> we're meeting tomorrow at 1600 UTC, if you want to join, also
19:07:17 <sysrqb> probably here
19:07:32 <sysrqb> any questions about this?
19:08:58 <sysrqb> okay, great. after we finish this, i may ask some of you to prioritize different tickets than what you current have on your list for this week
19:09:01 <sysrqb> just fyi.
19:09:22 <sysrqb> i have one discussion question for this week
19:09:34 <sysrqb> boklm: this may be for you. or maybe GeKo
19:09:53 <boklm> for the testsuite, it is currently being run on nightlies, but most tests are failing because the version of marionnette needs to be updated for the new ESR
19:09:56 <sysrqb> i was looking at our test suite, and i was tryig to understand who/what/where of it
19:10:11 <sysrqb> are those results published?
19:10:16 <boklm> I just opened #32537 for that. And then after doing that some tests will need to be updated/fixed too.
19:10:44 <sysrqb> i was looking for a report for it, but i didn't find it anywhere
19:10:47 <boklm> the url of the (failing) test reports is: http://xer3kgd5ygqr7n6i.onion/index-browserbundle.html
19:11:04 <sysrqb> ah ha!
19:11:05 <sysrqb> thanks
19:11:18 <GeKo> sysrqb: you could even get notifications by mail if you wanted :)
19:11:19 <sysrqb> that's good to know
19:11:30 <sysrqb> yeah, i saw the tickets for adding email notifications
19:11:39 <GeKo> (the same goes for nightly builds)
19:11:40 <sysrqb> but i was missing that url :)
19:11:51 <sysrqb> i think that is probably a good idea
19:12:02 <GeKo> well, we get them already
19:12:03 <sysrqb> i can open a ticket for adding my email address on the list
19:12:10 <GeKo> yeah
19:12:22 <sysrqb> yeah. i saw it was already closed and implemented, too :)
19:12:30 <GeKo> haha, okay :)
19:12:58 <sysrqb> okay, i think that's all i have for this week
19:13:15 <sysrqb> although my head is full of things today, so maybe there is more
19:13:22 <sysrqb> but i'l llet you know after the meeting :)
19:13:34 <sysrqb> does anyone else have any last comments or questions?
19:14:23 <sysrqb> oh!
19:14:28 <sysrqb> cohosh
19:14:41 <sysrqb> sorry, one last thought/question from me
19:15:02 <sysrqb> should we consider enabling debug logs for PTs in our nightly builds?
19:15:08 <sysrqb> or alpha builds?
19:15:16 <sysrqb> nightlies seem safer
19:15:40 <sysrqb> enabling debug logs on android is almost impossible unless it is the default or we add a UI config for it
19:15:53 <sysrqb> but i don't see us implementing that "soon"
19:16:38 <sysrqb> was this discussed previously?
19:16:45 <GeKo> no
19:17:23 <sysrqb> okay, i can open a ticket for it
19:18:01 <sysrqb> it doesn't seem like anyone here has strong opinions
19:18:08 <boklm> the goal would be to help debug issues for censored users?
19:18:13 <sysrqb> boklm: yeah
19:19:12 <sysrqb> so, smae configuration as the stable but more verbose logging
19:19:17 <mcs> a hard to find/hidden GUI switch would be nice. but if a log is generated, how does one read it?
19:19:20 <sysrqb> but maybe there is a better option
19:19:38 <mcs> or maybe the log is available?
19:19:49 <sysrqb> mcs: on android, the app won't progress past the log screen if it can't bootstrap
19:20:08 <sysrqb> but, if they successfully bootstrap, then they can't get the the logs
19:20:17 <sysrqb> so it's a bad UX
19:20:40 <sysrqb> showing more detailed logs when connecting fails may help, though
19:20:50 <mcs> It sounds like something worth fixing but maybe not something we have time to work on.
19:21:33 <sysrqb> yeah, giving access to the logs is not something we'll fix until after the fenix transition
19:21:48 <mcs> sysrqb: makes sense
19:22:04 <sysrqb> so enabling debugging as the default seems like a cheap hack in the mean time
19:22:17 <sysrqb> on non-standard builds, that is
19:22:30 <sysrqb> s/standard/stable/
19:23:01 <sysrqb> i can open a ticket and we can make a decision from there
19:23:24 <sysrqb> okay, i'll close the meeting
19:23:29 <sysrqb> thanks everyone!
19:23:36 <sysrqb> #endmeeting