#tor-meeting2 log

18:31:09 <sysrqb> #startmeeting Tor Browser Team Meeting, 25 November, 2019
18:31:09 <MeetBot> Meeting started Mon Nov 25 18:31:09 2019 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:31:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:31:17 <sysrqb> okay, and we're starting
18:31:24 <mcs> hello to all
18:31:25 <sysrqb> o/ Hello everyone, happy monday
18:31:32 <boklm> hi
18:31:50 <pili> hi everyone :)
18:31:50 <sisbell> hi
18:31:51 <antonela> hola hola
18:32:09 <Jeremy_Rand_Talos> hi everyone
18:33:40 <GeKo> o/
18:33:41 <sysrqb> i hope pospeselr feels better
18:33:46 * mcs is reading the pad at https://pad.riseup.net/p/TorBrowserTeamMeetingNotes-keep
18:34:07 <mcs> flu + travel sounds bad
18:34:17 <acat> hi!
18:35:19 <sysrqb> okay, mcs do you want to talk about the prep?
18:35:34 <brade> pref
18:35:41 <sysrqb> err, yeah, that thing :)
18:35:44 <sysrqb> thanks
18:35:53 <sysrqb> or brade :)
18:36:00 <mcs> so this is related to the discussion in #32418
18:36:30 <mcs> for some users, having a way to disable updates is important. but we no longer provide such a switch
18:36:50 <mcs> Mozilla remove the app.update.enabled pref from Firefox a while ago
18:37:02 <mcs> s/remove/removed/
18:37:39 <mcs> I am not 100% sure, but for Mozilla I think that was a product management decision to avoid any chance people would stay on an old version of Firefox
18:37:58 <mcs> Should we re-implement app.update.enabled? My leaning is “yes"
18:38:07 <GeKo> why?
18:38:36 <GeKo> oh, and do users have still ways to disable auto-updates?
18:38:53 <GeKo> *stil have
18:38:56 <GeKo> *still
18:38:58 <mcs> I lean toward yes because there are some people who are doing their own sandboxing or are doing something else where the update check is a nuisance to them
18:39:21 <mcs> app.update.auto = false will still disable application of an update (I think)
18:40:09 <Jeremy_Rand_Talos> mcs, agreed that disabling updates is a valid use case for various niche cases, and that's exactly the thing that prefs are for
18:40:38 <mcs> Also, Tor Browser is slightly worse than Firefox in this area because we also disable enterprise policies and there is a way to disable updates completely via that mechanism
18:40:56 <mcs> I wanted to bring it up here so we can make a team decision :)
18:41:37 <Jeremy_Rand_Talos> When I was running custom builds of Tor Browser (both for ARM dev and Namecoin dev) I found it useful to disable updates so that nothing unexpected would happen to my customizations if they got overwritten by an update somehow
18:41:52 <Jeremy_Rand_Talos> Sandboxing also sounds like a valid use case
18:41:57 <GeKo> yes
18:42:23 <GeKo> the question is whether there are still means for those use-cases available or not
18:42:36 <GeKo> not applying updates still seems to work
18:43:09 <GeKo> (and if those means are enough or not)
18:43:43 <Jeremy_Rand_Talos> Exactly what steps happen in the "apply" stage (which I guess can still be disabled) compared to the earlier stages?
18:43:44 <GeKo> how does tails do it?
18:43:46 <boklm> however with app.update.auto, the update is still downloaded?
18:43:59 <boklm> it seems tails is doing this: https://redmine.tails.boum.org/code/projects/tails/repository/revisions/e43247dd2558dd391342855796e18c3186a43807
18:45:03 <GeKo> from my point of view that should be enough
18:45:05 <boklm> I think I read that app.update.disabledForTesting is only for QA builds, so it might not work
18:45:33 <GeKo> just point the update url to somewhere else and done
18:45:42 <sysrqb> but clearning...
18:45:46 <sysrqb> ^
18:45:58 <sysrqb> (also *clearing)
18:45:59 <GeKo> ?
18:46:02 <sysrqb> that was my thought
18:46:03 <mcs> I think app.update.url is hard to change now. But brade and I can confirm and add to the ticket
18:46:04 <GeKo> ah
18:46:07 <sysrqb> changing app.update.url
18:46:37 <sysrqb> that seems like an easy solution, if it works
18:47:17 <sysrqb> if it doesn't work, then maybe we should think about re-implementing the pref
18:47:20 <GeKo> i feel we should not start with carrying a patcg with us forever for this usecase if we can avoid it
18:47:29 <GeKo> because we won't get that upstreamed
18:47:51 <GeKo> and disabling updates is a footgun etc. etc.
18:48:14 <sysrqb> yeah.
18:48:15 <mcs> GeKo: That is true. OK, we will see if we can document a different workaround; the Tails info might help (thanks boklm!)
18:48:49 <GeKo> mcs: while you are here:
18:48:58 <GeKo> could you put #32498 onto your review plate?
18:49:06 <mcs> GeKo: sure
18:49:10 <GeKo> thanks
18:50:13 <sysrqb> okay, acat, your bolded item was a question i was going to ask, as well
18:50:30 <sysrqb> do you want to introduce it?
18:51:21 <acat> Sure. It seems https everywhere initialization when `WebAssembly` is enabled is slower than the other one, when JIT is disabled. There's the "unresponsive script" warning, and it also happens on Fennec.
18:52:11 <acat> I assume the JS glue code that is there for wasm but not for the "legacy" one is to blame, as that is still affected by JIT being disabled
18:52:59 <acat> So I'm not sure what should we do about it. Is enabling JIT for webextensions only feasible?
18:53:12 <GeKo> tjr: ^
18:53:29 <acat> Or should we try to improve/investigate/report https everywhere perf. issues when jit is disabled?
18:53:44 <tjr> i can try to take a look
18:53:57 <tjr> probably be a similar situation to the webasm patch
18:54:56 <sysrqb> thanks
18:56:19 <sysrqb> it seems like we can start there
18:56:48 <sysrqb> okay antonela
18:56:52 <sysrqb> welcome back
18:56:59 <antonela> glad to be here :)
18:57:05 <sysrqb> :)
18:57:10 <sysrqb> i see two items from you
18:57:25 <antonela> yes, i unbolded the pospeselr one
18:57:28 <antonela> so we have just two
18:57:37 <antonela> so, re 21952
18:57:42 <antonela> grr #21952
18:58:03 <antonela> we want to offer visual feedback when the onion has been loaded; I made a micro animation that replaces the lock icon for the circular onion one
18:58:18 <antonela> the question is: can we replace the lock for the onion? Do we want to keep the lock for anything like future certificates related stuff?
18:58:25 <antonela> https://trac.torproject.org/projects/tor/attachment/ticket/30024/prompt-onion-2.gif
18:58:34 <antonela> the gif is here ^^
18:59:01 <Jeremy_Rand_Talos> antonela, there do exist people using TLS in combination with onion services for extra security
18:59:08 <antonela> yes, exactly
18:59:12 <Jeremy_Rand_Talos> e.g. for Whonix-style use cases
18:59:42 <Jeremy_Rand_Talos> so yeah, I think ideally we should preserve that info, though the ideal UX for doing so is certainly not something I'm qualified for commenting on :)
18:59:57 <antonela> so, im thinking in something like https://trac.torproject.org/projects/tor/attachment/ticket/30025/O2A4.jpg
19:00:29 <sysrqb> hrm. i'd be scared about replacing the lock with an onion
19:00:30 <sysrqb> ye
19:00:41 <sysrqb> can we not add the onion next to the lock?
19:00:49 <antonela> we can, yes
19:00:55 <antonela> and i think is the right thing to do
19:00:58 <sysrqb> or, you don't thikn it looks as cool?
19:01:00 <acat> antonela: but isn't that already happening right now when we redirect from not onion to .onion? (except the animation)
19:01:03 <sysrqb> ah. okay
19:01:23 <antonela> acat, we dont have the animation yes
19:01:38 <sysrqb> "Do we want to keep the lock for anything like future certificates related stuff?"
19:01:41 <sysrqb> i think, yes
19:01:46 <sysrqb> we should keep it for this
19:02:22 <antonela> so, can we have the animation and keep the lock acat? i can try some mockups to see how it looks before you implement it
19:02:23 <sysrqb> onion and lock show different properties of the connection
19:03:43 <antonela> (note that those mockups have green onions and padlock which is something deprecated already in firefox)
19:04:06 <Jeremy_Rand_Talos> antonela, I feel like the animation you have would be improved by slowing it down a bit.  Right now it's quick enough that if my attention is focused elsewhere on the screen, it might not last long enough for me to notice it
19:04:22 <acat> yes, i also think it's difficult to notice
19:04:31 <Jeremy_Rand_Talos> Maybe some other way to make it more attention-grabby would be useful too, e.g. flashing the background color a bit or something?
19:04:46 <antonela> mmm could be
19:04:53 <sysrqb> let's not get too crazy :)
19:04:58 <antonela> is a good feedback, thank you!
19:05:25 <antonela> ye, that needs to be subtle enough. I like firefox gradient animation on their shield (*__*)
19:06:04 <antonela> another thing related with #21952 is `about:preferences`, are we ok having onion settings in the privacy&security tab?
19:06:11 <acat> but just to clarify, the only think that would be missing is to do the animation, the final icon would be the same as it is currently (.onion or .onion+lock), right?
19:06:20 <acat> or am i missing sth?
19:06:22 <antonela> acat: yes!
19:06:27 <acat> good :)
19:07:28 <sysrqb> `about:preferences#tor` seems like a good place for this
19:07:38 <sysrqb> ah, hrm.
19:07:45 <sysrqb> you said privacy
19:07:49 <antonela> yes, we talked about it. Now #tor has network related settings
19:07:56 <mcs> antonela: if we put them in Privacy & Security, we should rename the “Tor” category to “Tor Network”
19:08:04 <sysrqb> +1
19:08:09 <antonela> you right mcs
19:08:10 <mcs> (I am not sure which is the better solution)
19:08:32 <antonela> what do you think? should we move it under Tor and keep it as Tor?
19:08:43 <antonela> ah ye, me either :) this is why i opened it here
19:09:18 <acat> i'm not sure this has privacy/security benefits, so that's why i was not so sure about that category
19:09:51 <sysrqb> also, i wonder if would go under Privacy or under Security
19:10:26 <sysrqb> i don't tihnk it's likes any of the other options on that page
19:10:41 <sysrqb> of course, it's not like the network settings under Tor, either
19:11:39 <sysrqb> but, maybe now we decide if the Tor preferences page should be tor-related preferences that do not fit on another page
19:11:50 <sysrqb> or only Tor Network preferences
19:12:05 <antonela> if we want to move it under Tor, we can rename Tor Settings as Tor Network Settings and have a new section called something close to Onion sites or Onion preferences or
19:12:35 <antonela> anyways, please feel free to jump into that ticket and leave your throughs !
19:12:40 <sysrqb> i think i like that idea
19:12:47 <sysrqb> okay, thanks anto!
19:13:07 <sysrqb> oh, item #2
19:13:16 <antonela> quick one, when is the next s27 meeting pili?
19:13:49 <pili> hmm, this week
19:13:50 <pili> I forgot to send the reminder
19:13:53 <antonela> tjr: thanks for your review on #32324, i'm thinking what else we can do without opening a pop-up :)
19:13:59 <pili> so tomorrow (Tuesday) at 15UTC
19:14:03 <antonela> pili, my calendar told me that, i just wanted to be sure :)
19:14:04 <antonela> awesome!
19:14:05 <antonela> thanks!
19:14:25 <sysrqb> good.
19:14:28 <pili> let me send the reminder email ;)_
19:15:10 <sysrqb> okay, we have a release coming next week, so here is a reminder to complete patches and reviews as soon as possible
19:15:36 <sysrqb> boklm: can you review #30786? i see emmapeel is looking at it, too
19:15:45 <boklm> sysrqb: ok
19:15:59 <sysrqb> acat: do you think #21952 will be complete by this week?
19:16:05 <sysrqb> or do you need more time?
19:16:11 <sysrqb> (based on what we discussed here)
19:16:20 <sysrqb> and any remaining work
19:16:47 <sysrqb> boklm: thanks
19:17:23 <sysrqb> GeKo: can you review #32475 this week?
19:17:24 <acat> i think so, although i'm not completely sure about the current solution for the redirects, more specifically i'm using a "redirect flag" for the httpchannel which is supposed to be reserved (but not used by anyone i think)
19:17:43 <GeKo> sysrqb: yeah, i planned to do this tomorrow
19:17:48 <sysrqb> thanks
19:17:54 <GeKo> (there were already some rounds)
19:18:10 <sysrqb> yep, just wanted to make sure you saw the last comment
19:18:21 <acat> but from UX point of view and functionality, i think it can be ready, except the animation since i think anto wanted to do some mockups
19:18:36 <sysrqb> acat: okay. i also wonder if we really want/need this in the next alpha
19:18:38 <acat> although i can try to do the animation in the current gif too
19:18:56 <GeKo> sysrqb: i don't think so
19:19:01 <sysrqb> maybe this is one of those features that lands in nightly for a while
19:19:05 <sysrqb> GeKo: okay
19:19:06 <GeKo> we should take the time to review it properly
19:19:16 <sysrqb> yeah. okay, sounds good
19:19:16 <GeKo> and think about the way the feature should go
19:19:27 <GeKo> i mean there is still the question whether to use Onion-location or not
19:19:38 <GeKo> and it think we should settle that first before landing the final version
19:19:43 <GeKo> as the code will change
19:19:44 <sysrqb> right
19:19:56 <GeKo> and we should not introduce half-baked things here
19:20:07 <GeKo> which we will change like a month later
19:20:15 <acat> i think adapting the implementation and use a different header should not be too dificult though
19:20:18 <sysrqb> okay, i'm fine with that
19:20:24 <GeKo> sysrqb: so, i guess a good idea is that you are getting the discussion going
19:20:28 <GeKo> which you wanted to have
19:20:34 <sysrqb> yes
19:20:36 <GeKo> while other folks are fixing things up
19:20:42 <GeKo> and we are reviewing things
19:20:54 <sysrqb> hopefully this week or early next week, depending on time
19:20:55 <GeKo> acat: yeah, the final changes for that should not be that big
19:21:19 <antonela> acat: we can work on the animation later, is not prior
19:21:48 <sysrqb> GeKo: it looks like you're still debugging #32053
19:22:14 <sysrqb> did you pass that back that back to LLVM devs?
19:22:49 <sysrqb> s/that back that back/that back/
19:23:39 <sysrqb> acat: do you think you can review #32531?
19:24:00 <sysrqb> sisbell: do you think you can write a patch for #32405?
19:24:14 <GeKo> sysrqb: yes and yes
19:24:33 <sisbell> yes that's super simple patch
19:25:10 <sysrqb> great
19:25:20 <GeKo> sysrqb: i currently don't have another arrow in my quiver for nailing that bug immediately
19:25:35 <GeKo> so it won't be something for the next releases, alas
19:25:50 <sysrqb> i kinda assumed that, at this point
19:26:55 <sysrqb> okay, wednesday is another release meeting
19:27:37 <sysrqb> i'll go over all the tickets again today/tomorrow, and look for any tickets we should get into 9.5a2 but we are currently missing
19:28:13 <sysrqb> but i don't see any right now that need prioritising
19:28:36 <sysrqb> i don't know if richard will be available for building this week/weekend
19:28:56 <sysrqb> i'll follow up with him after the meeting
19:29:27 <sysrqb> GeKo: wsa there anything else you wanted to discuss here/
19:29:28 <sysrqb> ?
19:29:33 <GeKo> nope
19:29:40 <antonela> do we have tb release meeting this week too, can we bring those tickets by wednesday sysrqb?
19:29:52 <sysrqb> antonela: yes, on Wednesday
19:30:00 <antonela> sysrqb: great, thank you
19:30:27 <sysrqb> okay, on that note, i guess i'll close this meeting
19:30:34 <sysrqb> thanks everyone! have a good week!
19:30:39 <GeKo> wait
19:30:40 <sysrqb> #endmeeting