18:59:40 <sysrqb> #startmeeting TorBrowser meeting 30 November 2020
18:59:40 <MeetBot> Meeting started Mon Nov 30 18:59:40 2020 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:40 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:42 <Jeremy_Rand_Talos> hello!
18:59:59 <sysrqb> Pad: https://pad.riseup.net/p/tor-tbb-2020-keep
19:00:53 <acat> o/
19:00:55 <GeKo> o/
19:04:09 <dunqan> hi all :)
19:04:11 <antonela> o/
19:07:03 <sysrqb> I see updates on the pad from most people
19:08:18 <sysrqb> let's start with the Boards
19:08:22 <sysrqb> https://gitlab.torproject.org/groups/tpo/applications/-/boards
19:10:37 <sysrqb> Okay, maybe going through each board is not worthwhile
19:11:08 <sysrqb> but does anyone want to talk about anything on their board, or how they should prioritise their tickets?
19:12:12 <sysrqb> Maybe this is simly best as a reminder that everyone should keep their boards updated
19:14:48 <sysrqb> okay, the boards and issue/MR assignments look okay
19:15:39 <sysrqb> the only announcement/reminder I have is that we have the first android alpha version based on FF84 scheduled for this friday
19:15:48 <sysrqb> and we are still on track for that
19:16:45 <sysrqb> the only discussion item I have is regarding our plan for setting https: as the default (and warning before loading a http: website)
19:17:23 <antonela> what is your estimated timeline for it?
19:17:29 <sysrqb> the most recent pan we discussed was enabling this in an alpha version ASAP and then begin testing in as many regions as posisble
19:17:37 <sysrqb> antonela: yep :)
19:17:42 <sysrqb> but
19:18:36 <sysrqb> after I began looking at the work needed for backporting the version Mozilla released in Firefox 83 for Tor Borwser (based on Firfox 78esr)
19:18:48 <sysrqb> we found that is a large amount of changes needed
19:19:10 <sysrqb> and we can use the HTTPS Everywhere EASE mode and modify that UI
19:19:16 <sysrqb> but that is non-trivial work, too
19:19:40 <sysrqb> and then last week GeKo tried a more reasonable approach
19:19:53 <sysrqb> and suggest that instead of backporting Firefox patches or modifying EASE
19:20:06 * antonela anxious about the 3rd position
19:20:17 <Jeremy_Rand_Talos> Any reason to not just use EASE until newer Firefox is used everywhere?  Enabling EASE is just a pref or something similar, isn't it?
19:20:34 <Jeremy_Rand_Talos> (Are there UI issues in EASE?  I use it all the time and never noticed problems.)
19:20:51 <sysrqb> we  concentrate on moving all platforms on the rapid release and pick up the Firefox https-only mode automatically
19:20:58 <antonela> love it
19:20:59 <sysrqb> after the rapid release tranistion is stablized
19:21:07 <antonela> yes, they are Jeremy_Rand_Talos
19:21:37 <sysrqb> but, that means we likely don't release this as stable until the middle or end of next year
19:22:05 <antonela> 9.5 is a good target?
19:22:07 <sysrqb> becase we won't finish the transition for TB 10.5
19:22:13 <GeKo> antonela: is that "anxious" in a positive way? that word has in my english often just a defensive/negative meaning
19:22:13 <antonela> ay 10.5
19:22:18 <sysrqb> nah, i think that is too ambitious
19:22:20 <antonela> yes yes, positive
19:22:24 <antonela> was eating my nails
19:22:26 <GeKo> cool
19:22:28 <GeKo> haha
19:22:32 <sysrqb> haha
19:22:36 <antonela> hahaha
19:22:41 <sysrqb> so, we would target TB 11
19:22:57 <sysrqb> whenever we decide on a release date for that
19:23:07 <GeKo> well, i guess we could even postpone that decision
19:23:21 <GeKo> looking how experiment goes
19:23:28 <antonela> sounds good for me, do you think the alpha can be ready earlier?
19:23:30 <sysrqb> and I agree with GeKo that this is probablyu the most reasonable plan, given everything else we are doing
19:23:37 <antonela> just to run experiments before it
19:23:38 <GeKo> how fast we can remove to rapdid release for the other plaforms
19:24:00 <GeKo> or whether we would be cool with shipping a feature not on all platforms from the start
19:24:01 <sysrqb> antonela: yes, i hope we will start having alphas around spring time
19:24:15 <antonela> after or before 10.5?
19:24:19 <GeKo> s/remove/move/
19:24:43 <GeKo> antonela: we could start with mobile this week :)
19:24:44 <sysrqb> antonela: i'm not sure right now
19:24:56 <sysrqb> heh, sure
19:24:59 <antonela> GeKo: that'd be awesome actually
19:25:01 <antonela> hahaha
19:25:02 <antonela> oki
19:25:04 <antonela> good to know
19:25:14 <GeKo> well, it's just a pref flip away
19:25:16 <sysrqb> android doesn't have a good UI, but we can try it
19:25:19 <sysrqb> yeah
19:25:29 <antonela> nah has this one open https://gitlab.torproject.org/tpo/ux/research/-/issues/19
19:25:39 <antonela> if tba happens, please let her know so we can call for testing
19:25:59 <sysrqb> antonela: yeah, i that was one reason I wanted to discuss this topic today
19:26:02 <dunqan> maybe we should wait there too
19:26:19 <sysrqb> -i
19:26:53 <sysrqb> i'll think about enabling it on android this year
19:27:06 <sysrqb> i don't think this week is the best idea :)
19:27:14 <sysrqb> (android alpha)
19:27:22 <GeKo> no :)
19:27:52 <GeKo> but doing that in two weeks for the alpha does not seem to be unreasonable to me
19:27:59 <sysrqb> yeah
19:28:16 <antonela> that is cool
19:28:18 <GeKo> and then whenever we have linux ready etc.
19:28:36 <sysrqb> and then eaach platform inherits that pref flip when we move it onto the new branch
19:28:57 <sysrqb> sounds good
19:30:00 <sysrqb> does anyone else have comments or concerns about this plan?
19:30:11 <antonela> lets say we launch TBA tomorrow with https-only enabled in 2 security levels, how we prefer user to report feedback? should we think in a prompt? should we include a link in the error page to trigger an email to frontdesk?
19:30:17 * antonela poor frontdesk
19:30:38 <antonela> you dont need to answer me now but some ideas in the ticket would be appreciated
19:31:04 <dunqan> so it's just going to be on safer/safest by default?
19:31:30 <GeKo> antonela: the usual avenues? blog, bug tracker, irc?
19:31:41 <GeKo> mailing lists...
19:31:55 <antonela> yes.. but i was wondering if having something in the app will help
19:32:27 <sysrqb> is the goal learning which websites don't support https?
19:32:52 <GeKo> dunqan: for a start, yes
19:33:30 <antonela> sysrqb: mmm no, but you might like numbers
19:33:50 <dunqan> GeKo: gotcha
19:35:01 <sysrqb> yeah, hrm
19:35:16 <antonela> lets think about it, i dont need an answer now now
19:35:31 <dunqan> has the error flow been discussed already?
19:35:32 <sysrqb> i'll think about what information will be most helpful
19:35:35 <dunqan> (for http only pages)
19:35:50 <sysrqb> dunqan: no, not outside of using the error page in Firefox
19:35:50 <antonela> regular call for testing in tor-qa + a contact to global south partners is a good start
19:36:00 <sysrqb> yeah
19:36:19 <sysrqb> dunqan: there is an important edge case where the exit node in the current cuircut is malicious
19:36:31 <sysrqb> and it stripped the redirect to the https page
19:36:55 <sysrqb> so we may want to encourage the user to reload the page with a new circuit
19:37:00 <sysrqb> (new circuit for this site)
19:37:23 <sysrqb> but we can't easily distinguish between this attack and a website that doesn't support https
19:37:47 <dunqan> right, I see
19:37:54 <Jeremy_Rand_Talos> sysrqb, any reason not to automatically try a new circuit a couple times?  Would it put too much load on the relays?
19:38:09 <sysrqb> so we should think about how we include this as a suggestion, but not scare users away from every http site
19:38:26 <sysrqb> Jeremy_Rand_Talos: only engineering time
19:38:35 <Jeremy_Rand_Talos> ah ok
19:39:56 <GeKo> sysrqb: might be less invasive, though, all in all given all the ux engineering to decide between attack or not
19:40:29 * Jeremy_Rand_Talos ponders maybe filing a ticket about automatically trying a new circuit if any kind of TLS error happens, including but not limited to "only non-TLS HTTP available"
19:40:55 <GeKo> s/invasive/engineering-time-costing/
19:41:03 * Jeremy_Rand_Talos sees TLS handshake errors fairly often, which go away with a new circuit
19:41:41 <sysrqb> we could implement it relatively easily in a web extension (or using the webextension API)
19:42:05 <sysrqb> but i'm not sure where we should put something like this on the roadmap for the entire feature
19:42:36 <sysrqb> i don't think this needs to be part of the "MVP"
19:43:03 <antonela> maybe for the stable release? we can start with the alphas as it is...
19:43:30 <sysrqb> but if dunqan (and/or antonela) think they can mock useful UIs with this feature, then we can think about how to implement it
19:43:59 <antonela> good stuff, we will need a ticket tho or take over the current one
19:44:06 <dunqan> yup, feel free to throw a ticket my way!
19:44:09 <sysrqb> or, maybe this feature means we don't need to change the UI as much
19:44:25 <sysrqb> because any malicious exit node will be autoamtically routed around
19:44:36 <sysrqb> okay, we'll think more about this
19:45:06 <antonela> we somehow discussed this flow here https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40209
19:45:49 <sysrqb> yep, it is a similar problem
19:46:58 <sysrqb> and the https-only mode should mostly replace the cryptocurrency feature
19:48:11 <sysrqb> and we can consider keeping the warning message on http sites afterward
19:48:51 <antonela> my take away there is: we should encourage users to raise their security level (that might raise other problems but per-site sec settings could help)
19:49:00 <antonela> anyways, good problems to think about :)
19:49:24 <Jeremy_Rand_Talos> sysrqb, as an aside, seems like the cryptocurrency feature might make more sense as a crypto feature.  I.e. it seems like PGP and Signify keys should be considered untrustworthy in the same way as Bitcoin addresses
19:50:15 <sysrqb> Jeremy_Rand_Talos: that's an interesting idea
19:50:40 <Jeremy_Rand_Talos> But if TLS is soon going to become mandatory, then yeah, it becomes less of an issue anyway
19:50:48 <sysrqb> Jeremy_Rand_Talos: can you add a comment on the ticket?
19:51:05 <Jeremy_Rand_Talos> sysrqb, yeah sure, I'll add a comment later today
19:51:10 <sysrqb> thanks
19:52:09 <sysrqb> any final thoughts on this?
19:53:23 <sysrqb> alright
19:53:35 <sysrqb> thanks everyone, have a good week
19:53:45 <sysrqb> #endmeeting