17:59:02 <sysrqb> #startmeeting Tor BrowserTeam Meeting 16 March 2020
17:59:02 <MeetBot> Meeting started Mon Mar 16 17:59:02 2020 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:02 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:07 <sysrqb> Hello everyone
17:59:20 <brade> hi
17:59:21 <sysrqb> welcome to another edition of the Tor Browser weekly meeting
17:59:38 <antonela> hello!
17:59:40 <boklm> hi
17:59:40 <mcs> hi
18:00:41 <Jeremy_Rand_Talos__> Hi!
18:00:44 <acat> hi
18:02:39 <pili> hi
18:03:57 <khelvn> hi
18:04:38 <sysrqb> alrighty
18:05:17 <sysrqb> I hope everyone is doing well in these crazy times
18:05:35 <pospeselr> hillo
18:06:07 <sysrqb> please don't hesisate to reach out to me or pili (or anyone else you feel comfortablbe talking with) if something happens that any of us should be aware of
18:06:35 <sysrqb> especially related to your work
18:06:52 <pili> yup :)
18:07:01 <sysrqb> i know it may be hard to work at 100% over the next few weeks
18:07:09 <sysrqb> but please try your best, and we'll get done as much as possible
18:07:44 <Jeremy_Rand_Talos__> (I assume we're talking about The Virus (TM)?  Or did something else happen recently as well?)
18:09:02 <sysrqb> no, mostly just the state of the world, the effect covid19 is having
18:09:16 <sysrqb> *and the effect
18:09:40 <mcs> “flattening the curve” is more than a little painful but probably necessary
18:09:56 <sysrqb> indeed
18:09:58 <Jeremy_Rand_Talos__> ok.  Yeah, coronavirus is somewhat disrupting my workflow, but probably a lot less so than other people here
18:10:42 <sysrqb> pospeselr: how far as you gotten with the documentation review?
18:11:03 <pospeselr> I'm midway through FF71
18:11:10 <pospeselr> ticket review
18:11:16 <sysrqb> okay, nice, that's god progress
18:11:17 <pospeselr> already went through all the release notes
18:11:18 <sysrqb> *good
18:11:23 <sysrqb> thanks
18:11:31 <pospeselr> i'm hoping to have a list of tickets that might warrant further investigation by eow
18:11:41 <sysrqb> great
18:11:42 <pospeselr> but so far so good, nothing scary
18:12:27 <sysrqb> that's good news
18:13:20 <sysrqb> okay, acat, i think you should chat with boklm regarding getting the rebased patches working in tor-browser-build
18:13:40 <sysrqb> i don't know if boklm's made progress on that
18:13:52 <acat> yes, i was planning to do so
18:13:56 <sysrqb> and maybe he can use some help
18:13:58 <sysrqb> ah, great
18:14:04 <sysrqb> carry on in that case :)
18:14:05 <boklm> to do what?
18:14:32 <sysrqb> getting the new firefox patches building in tor-browser-build
18:14:51 <sysrqb> (rebased firefox patches)
18:14:53 <acat> i got an "almost working" tor-browser-build branch, but there was some python error
18:15:08 <boklm> ok, I didn't look at that yet, I can look at it this week
18:16:02 <acat> thanks
18:17:01 <sysrqb> sisbell: ping?
18:17:40 <sysrqb> okay, i guess we can move on to the discussion items
18:18:11 <sysrqb> brade: mcs: is that first one yours?
18:18:18 <mcs> it is mine
18:18:27 <sysrqb> i think "yes"
18:18:53 <sysrqb> as in, i've used that process and i think it makes it obvious when the code review is complete
18:18:57 <mcs> I assume the reviewer makes the change to merge_ready?
18:19:03 <sysrqb> yes
18:19:06 <mcs> what if there are two reviews required?
18:19:14 <sysrqb> i'm happy with using that process
18:19:22 <sysrqb> second review sets the flag?
18:19:30 <mcs> I guess the second one, assuming there are no revisions needed.
18:19:33 <sysrqb> unless someone has a better idea?
18:19:39 <sysrqb> right
18:20:04 <boklm> that sounds good to me
18:20:14 <acat> +1
18:20:20 <mcs> I brought it up because we are not all in the habit of using merge_ready but doing so should help people who merge/commit to master repos
18:20:49 <sysrqb> yes, it's good to clarify this process
18:20:54 <sysrqb> thanks for raising it
18:20:55 <mcs> yup. thanks
18:21:34 <sysrqb> i'll move on to the second item (which is mine)
18:22:13 <sysrqb> as some of you are aware, we were told about a bug in our javascript-blocking functionality when the Safest security level was selected
18:22:22 <sisbell> hey
18:22:31 <sisbell> sorry though this was 11:30 today
18:22:37 * antonela just styled https://www.torproject.org/download/
18:23:10 <pospeselr> antonela: the new Disabling Javascript section?
18:23:13 <sisbell> I added my items for week
18:23:45 <antonela> pospeselr: yes, sysrqb pushed it this morning
18:23:56 <sysrqb> this is primarily a bug in firefox, and noscript didn't block some javascript code as a result of this
18:24:20 <sysrqb> a noscript update was released at the end of last week which mitigated this issue
18:24:48 <sysrqb> but, I am still considering completely disabling javascript on Safest beginning in the alpha series
18:24:53 <mcs> why were we not aware of the Firefox bug sooner? fix not backported to ESR?
18:25:08 <sysrqb> mcs: mozilla didn't knowabout it until we told them
18:25:17 <mcs> sysrqb: ah, ok
18:25:24 <tjr> It was fixed inadvertently as part of a refactoring
18:25:27 <sysrqb> it was "fixed" during a large refactoring/code moving process
18:25:48 <mcs> I missed the part about accidental fix… thanks
18:26:14 <sysrqb> currently, we rely on noscript for disabling javascript (per site) on Safest
18:26:20 <boklm> does the noscript update fix the issue completely?
18:26:50 <sysrqb> and this allows a user to enable javascript while still using receiving the "Safest"-level protections
18:26:50 <mcs> if we pref it off, what happens if someone uses NoScript to add an exception for a site?
18:27:04 <sysrqb> boklm: no
18:27:18 <sysrqb> i haven't looked at how noscript is solving the issue
18:27:27 <sysrqb> but i am woried it does not catch all the edge cases
18:27:45 <sysrqb> mcs: my current perspective is that if they are using Safest and they want javascript on "some sites"
18:27:50 <sysrqb> then they can flip the pref and then get this
18:28:17 <mcs> makes sense to me, although people might be confused if there is no UX to support that kind of transition
18:28:19 <sysrqb> but, if they want some exceptional websites then I consider them a power user in that case
18:28:32 <sysrqb> yes, i agree
18:28:58 <sysrqb> originally, before the noscript update, i was going to land this on both stable and alpha
18:29:13 <sysrqb> but now, with the noscript update, i'm thinking about letting it bake on alpha for a bit
18:29:20 <mcs> my guess is a lot of people use that mode (safest with some exceptions) but I do not have any data
18:29:24 <sysrqb> and writing documentation about this
18:29:53 <sysrqb> this is a downside to having zero telemetry from tor browser
18:29:59 <sysrqb> but, such is life.
18:30:04 <boklm> does it look like it will take some time to get the firefox issue fixed?
18:30:18 <sysrqb> there isn't an obvioius, easy fix
18:30:27 <boklm> ok
18:30:33 <sysrqb> so i have no idea if or when we'll get an firefox patch
18:32:08 <sysrqb> and we may migrate to the rapid release before a patch is available, in reality
18:32:16 <boklm> so disabling javascript with the pref sounds like the safest option
18:32:20 <mcs> +1
18:33:26 <acat> +1
18:33:29 <sysrqb> this change will impact the user experience, but i'm more concerned about our users being vulnerable to more edge cases
18:33:44 <sysrqb> than telling some users they should flip the pref if they really want javascript on some sites
18:34:05 <sysrqb> and they can hope javascript is actually disabled on the other sites
18:34:19 <Jeremy_Rand_Talos__> +1
18:34:19 <sysrqb> to be fair, it probably is now
18:34:27 <sysrqb> and the noscript update probably fixed this issue
18:35:22 <sysrqb> but, i prefer not immposing this risk on people who believe "javascript is disabled by default on all sites"
18:35:27 <sysrqb> *imposing
18:35:34 <sysrqb> okay, thanks
18:35:39 <sysrqb> i'm glad we mostly agree on this
18:36:02 <antonela> people also expect no-js in safest mode
18:36:19 <antonela> we are explicit about it in the ui as well
18:36:26 <sysrqb> yeah
18:37:25 <sysrqb> antonela: nice styling :)
18:37:30 <sysrqb> (i just looked)
18:37:48 <antonela> (:
18:38:09 <sysrqb> i think we should add an entry on suppot.tpo about this
18:38:19 <sysrqb> when we change the behavior of Safest
18:38:35 <sysrqb> *support
18:38:37 <pili> ggus: ^ :)
18:38:41 <ggus> oi!
18:38:43 <sysrqb> thanks :)
18:38:48 <sysrqb> wow, so fast
18:39:18 <sysrqb> ggus: we're changing the UX of the Safest security level
18:39:33 <sysrqb> currently, all javascript is disabled on all sites
18:39:47 <sysrqb> but a user can add an except for a specific site and enable javascript there
18:41:24 <ggus> so even if it's safest, you can cherry pick which website you want to trust and allow js
18:41:27 <ggus> very nice!
18:42:07 <sysrqb> with the change, javascript is disabled for the entire browser by default, so the user will need to change a firefox pref which enables javascript "engine"
18:42:17 <sysrqb> (so javascript is available)
18:42:24 <sysrqb> and then they can enable it per-site
18:42:31 <sysrqb> but it is still disabled by default
18:43:08 <sysrqb> so, it is a little confusing, but with screenshots this should be understandable, i hope
18:44:00 <sysrqb> hrm
18:44:08 <sysrqb> maybe the tor browser manual is a better place for this
18:44:22 <sysrqb> we can discuss it outside of the meeting
18:44:38 <ggus> for sure we will need to change tb-manual
18:44:53 <ggus> do you know when we will have these changes?
18:44:55 <sysrqb> okay
18:45:09 <sysrqb> ggus: i'm flexible
18:45:13 <sysrqb> i think "soon"
18:45:24 <sysrqb> i was thinking about enabling this next week
18:45:30 <ggus> like with 9.5 release?
18:45:37 <ggus> oh wow
18:45:40 <sysrqb> oh, right, sorry
18:45:52 <sysrqb> i was thinking of adding it in the alpha release next week
18:46:02 <sysrqb> so, it would come with 9.5 stable
18:46:07 <ggus> ok! it works for me :)
18:46:27 <sysrqb> okay, cool :)
18:47:11 <sysrqb> i think that covers everything for this meeting
18:47:23 <sysrqb> any last thoughts/comments before i end it?
18:47:38 <sysrqb> also, ggus: thanks :)
18:47:46 <pospeselr> how would users enable js for a site?
18:47:52 <antonela> sysrqb: is your plan to deal with per-site with noscript ui?
18:47:59 <antonela> or can we go with our per-site plans?
18:48:03 <sysrqb> pospeselr: flip the pref, then open the noscript ui
18:48:08 <sysrqb> antonela: yeah
18:48:09 <ggus> thanks sysrqb :)
18:48:16 <antonela> oh :/
18:48:19 <pospeselr> oof ok
18:48:30 <sysrqb> GeKo remembered that some users still have the toolbar button
18:48:46 <antonela> yes, some of them
18:48:46 <sysrqb> because they've upgraded since before 9.0
18:48:51 <pospeselr> right, those who have been doing build-to-build upgrades since before we removed it
18:48:53 <sysrqb> or 8.5 or whatever version
18:48:59 <sysrqb> yeah
18:49:01 <antonela> build-to-build ones
18:49:02 <antonela> yes
18:49:20 <sysrqb> so, using the noscript ui is part of their process
18:49:27 <mcs> I think we should test behavior when JS is disabled via pref but people try to use the NoScript UI to enable
18:49:29 <sysrqb> we don't suggest it, but...
18:49:37 <antonela> oki, can we review that flow? can we maybe rely on per-site permissions?
18:49:37 <mcs> at least for documentation purposes
18:49:41 <sysrqb> mcs: that's a good idea
18:49:43 <sysrqb> ye
18:49:44 <sysrqb> s
18:49:48 <antonela> mcs: right
18:50:17 <sysrqb> antonela: yes, ideally, the per-site permissions which pospeselr looked at should replace this
18:50:34 <antonela> groot
18:50:40 <sysrqb> but that is on-hold until after the rapid release migration
18:50:46 <sysrqb> so we need something between now and then
18:51:19 <antonela> gotcha, we will ship the patch to the alpha, and then we can iterate for the major stable release
18:51:32 <sysrqb> yeah
18:51:54 <antonela> sounds like a plan :)
18:51:58 <sysrqb> col
18:52:00 <sysrqb> cool
18:52:12 <sysrqb> okay, good, good
18:53:17 <sysrqb> and with that, i wish you all a good, productive, and safe week
18:53:22 <sysrqb> #endmeeting