15:00:24 <sysrqb> #startmeeting Tor Browser weekly meeting 28 June 2021
15:00:24 <MeetBot> Meeting started Mon Jun 28 15:00:24 2021 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:29 <sysrqb> hello!
15:00:35 <sysrqb> Pad: https://pad.riseup.net/p/tor-tbb-keep
15:00:40 <boklm> hi!
15:00:42 <sysrqb> Happy Monday, everyone
15:01:03 <donuts> o/
15:01:04 <GeKo> hi
15:01:08 <gaba> hi!
15:01:39 <pospeselr> o/
15:02:21 <antonela> hello!
15:04:41 <thurayya> o/
15:04:42 <sysrqb> Over this past week I thought more about the 10.5 release date
15:04:51 <sysrqb> and I think we should delay it until next Tuesday
15:05:21 <gaba> july 6th?
15:05:38 <sysrqb> yes
15:05:49 <sysrqb> i think releasing in 2 days is too fast
15:06:09 <gaba> ok
15:06:40 <sysrqb> i knew that last week, but I wanted to publish 10.5 so we can move on to the ESR transition
15:07:09 <sysrqb> but i became anxious about all of the cahnges we made within the last couple weeks
15:07:25 <sysrqb> and only a few people have tested them
15:07:41 <donuts> agree, this sounds sensible
15:07:46 <gaba> ok. i just updated the few places we have that info in the notes. It sounds good
15:07:53 <GeKo> +1
15:08:15 <GeKo> i guess it does not matter much for tails
15:08:28 <sysrqb> no, they can wait until 78.12, imo
15:08:33 <GeKo> but i bet intigeri likes "a week" more than "2 days"
15:08:36 <GeKo> yeah
15:08:38 <sysrqb> yeah
15:08:41 <sysrqb> :)
15:08:49 <GeKo> not that it's that much more time, but still
15:08:52 <sysrqb> i'll respond to them after this meeting
15:09:01 <sysrqb> yep
15:10:37 <sysrqb> pospeselr: did you add tor-browser#40477 ?
15:10:51 <sysrqb> or was that gaba?
15:11:04 <pospeselr> that was gaba I believe
15:11:18 <pospeselr> yeah, Craeted 5 days ago by Gaba
15:11:23 <gaba> yes
15:11:29 <gaba> i added. this needs discussion in the team
15:11:37 <gaba> as there is some stuff that needs to be resolved for implementation
15:12:28 <sysrqb> okay
15:12:39 <sysrqb> should pospeselr start that discussion?
15:12:58 <pospeselr> wow that's me
15:13:23 <sysrqb> or is that antonela ?
15:13:23 <pospeselr> so we want to integrate censorship circumvention into about:torconnect and the quickstart feature
15:13:53 <pospeselr> well i guess we can both go, I have some technical shizzle wizzle to discuss, and then we can move over to the design
15:14:24 <pospeselr> anyway, I've been investigating/prototyping Friday and today getting the user location *before* bootstrap
15:14:29 <donuts> sorry, I didn't see that ticket – but I'm subbed now
15:14:42 <sysrqb> you have ~10 minutes, so use it wisely :)
15:15:08 <pospeselr> and assuming that is a thing we want to do, it looks like it is pretty possible, but a bit tricky
15:15:13 * antonela you are doing great pospeselr
15:15:27 <pospeselr> so the boring part, how do we get the user location? easy enough mozilla has a locaiton service with a dead simple API
15:15:33 <pospeselr> it's a GET request and they send back json, great
15:16:12 * antonela amazing
15:16:32 <pospeselr> um, there's some refactoring that will need to happen to about:torconnect to avoid weird racey conditions and have 1 source fo truth for where we are in the bootstrap process
15:16:33 <sysrqb> does it require disabling proxy-bypass-protections?
15:16:35 <gaba> the other option was asking the user instead of getting the user location, right?
15:16:47 <pospeselr> sysrqb: so sort of not really
15:16:50 <antonela> what happen if the user is connected over a vpn and that prevents _somehow_ tor to connect?
15:17:04 <pospeselr> we can temporarily whitelist the mozilla location service, and enable dns
15:17:18 <pospeselr> just long enough to make the get request, then we can go and toggle those prefs back
15:17:24 <antonela> smart
15:17:28 <pospeselr> (but obviously that sounds somewhat scary)
15:17:35 <sysrqb> i have an alternative idea in mind, but we can discuss those details later
15:17:35 <GeKo> no kidding
15:17:42 <gaba> getting user location sounds scary
15:17:43 <donuts> hrmmm
15:18:00 <pospeselr> unfortunately, doing this means we will *also* need to toggle off offline mode
15:18:03 <antonela> the api already have that information
15:18:10 <pospeselr> or else you can't make *any* network requests
15:18:14 <sysrqb> right
15:18:22 <pospeselr> which easy enough to do, but has potential weird side effects
15:18:41 <sysrqb> i see two paths here
15:18:47 <pospeselr> because taht sends out a notificiation, and who knows what will now be all like 'oh hey we have network lets' query things' only to be blocked because they aren't on the whitelist
15:19:08 <pospeselr> so yeah, that's what I have
15:19:19 <sysrqb> 1) ther user just wants their browser to work, and they don't care if we contact a third-paty service to do it (e.g. bridges.tpo for new bridges)
15:19:25 <pospeselr> tldr; automatically getting user location somewhat easy but also tricky
15:19:50 <sysrqb> 2) the user is concerned about their connection, and they don't want to interact with a third-party service, so they can manually choose their current location
15:19:59 <pospeselr> actually wait a sec, we can connect to bridges.tpo before bootstrapping right?
15:20:06 <pospeselr> how on earth are we doing that
15:20:11 <GeKo> no we can't
15:20:14 <sysrqb> for (1), i am imagining a proxied connection like moat, to MLS (or another service)
15:21:08 <sysrqb> GeKo: no?
15:21:14 <antonela> if this causes too much fear, i'd go one step back and ask anticensorship if actually the best way to provide the best bridge is know user's location so we make sure that we are putting our efforts in the best place
15:21:15 <pospeselr> (we can)
15:21:36 <boklm> could we run a separate process for getting the user location?
15:21:58 <sysrqb> boklm: yeah
15:22:02 <pospeselr> boklm: also possible
15:22:03 <GeKo> sysrqb: how do we use tor to reach bridges.tpo without having boostrapped first?
15:22:04 <sysrqb> i think that would be necessary for (1)
15:22:32 <sysrqb> Geki thought it was via meek (but not actually meek, another similar endpoint)
15:22:33 <pospeselr> GeKo: doesn't it use another bridge? asuzre something or other?
15:22:37 <sysrqb> *GeKo
15:23:15 <sysrqb> but i may be confused
15:23:15 <pospeselr> let me verify that *still* works
15:23:23 <GeKo> or i
15:23:45 <GeKo> we can get bridges during bootstrap if that is what is meant
15:24:18 <pospeselr> yeah ok bridgedb is broken now with offline mode
15:24:24 <sysrqb> okay, right, in any case
15:24:25 <pospeselr> soo i guess that's a thing we need to fix anyway
15:24:32 <sysrqb> pospeselr: oh, nice.
15:24:38 <sysrqb> good thing we're not releasing this in two days
15:24:42 <GeKo> i thought you were talking about not doing any bootstrapping but still wanting to reach bridges.tpo
15:24:49 <GeKo> yeah :)
15:24:56 <donuts> well, at least we know now
15:25:01 <pospeselr> GeKo: yeah and we can do that, so long as we are not in offline mode
15:25:18 <pospeselr> (which we are until we bootstrap)
15:25:37 <sysrqb> GeKo: ah, i see, okay. yes, i think we agree
15:25:51 <GeKo> great
15:25:56 <sysrqb> i thought you meant 100% bootstrapped
15:26:02 <GeKo> no :)
15:26:11 <sysrqb> okay, great :)
15:26:51 <donuts> so, in theory at least, this sounds doable?
15:27:02 <pospeselr> yeah
15:27:14 <pospeselr> espcially now that I *have* to solve the main blocker anyway to fix bridgedb
15:27:14 <sysrqb> i think we have some options
15:27:21 <donuts> yep
15:27:29 <antonela> listing them and discussing them in a ticket seems a great next steps
15:27:36 <antonela> a lot of people have opinions about how to do this
15:27:37 <pospeselr> so, we've established that we *can* do it, now the q is *should* we do it
15:27:51 <Jeremy_Rand_Talos> (sorry I'm late, am here now)
15:28:38 <sysrqb> I think asking the user is a clear and easy option
15:28:58 <boklm> +1
15:29:02 <donuts> +1, we should also consider how the userbase will perceive us sniffing their location in the background
15:29:04 <sysrqb> so that may be the best place to start, and then we can add automatic discovery next
15:29:31 <sysrqb> donuts: yeah. I imagining some users will want a "just make this thing work" button
15:29:50 <donuts> yeah, and others can do a custom config
15:29:56 <sysrqb> yes
15:29:58 <donuts> which is what we already offer, effectively
15:30:04 <antonela> btw, this works https://share.riseup.net/#Zyf8yRXb3jGnrROtvaX6Qw
15:30:26 <donuts> yeah, I was pretty sure I tested that? but maybe not?
15:30:42 <sysrqb> huh. pospeselr ^
15:30:52 <donuts> unless it's broken in a specific build?
15:31:02 <antonela> i mean, it makes totally sense
15:31:04 <pospeselr> it worsk when you turn offline mode off ;)
15:31:25 <antonela> right
15:31:28 <pospeselr> (I think we may want to revisit that fix for the various updaters)
15:31:47 <pospeselr> probably add a new event to observe in tandem with 'no longer offline' rather than using offline mode
15:32:02 <pospeselr> and stick it in the relevant places
15:32:15 <donuts> right right
15:32:23 <sysrqb> okay, we can discuss that outside this meeting
15:33:46 <antonela> ye
15:33:47 <sysrqb> Next on the list is our 3-month roadmap: https://gitlab.torproject.org/tpo/applications/team#roadmap-june-2021-september-2021
15:34:41 <sysrqb> gaba: began organizing issues for the 91esr transition
15:36:36 <donuts> is esr roughly planned for end of Q3?
15:36:40 <sysrqb> I'm hoping we can move Linux Nightly onto 91 by the end of July
15:36:46 <sysrqb> donuts: yes
15:36:53 <donuts> gotcha
15:37:03 <sysrqb> Tor Browser 11.0 is scheduled for release at the beginning of October
15:37:16 <sysrqb> but that may slip until beginning of November
15:37:29 <sysrqb> we have a little flexibility
15:37:42 <donuts> sure thing
15:39:22 <sysrqb> as part of the next 3-4 months, I want to try reducing the burden of staying in sync with Mozilla for Fenix
15:39:41 <gaba> there is a lot of stuff in the 10.5. I assume many of those will move into 11.0
15:39:46 <gaba> https://gitlab.torproject.org/groups/tpo/-/milestones/14
15:40:19 <sysrqb> this means staying on Fenix 91 from July until September, and backporting any sec bugs
15:40:45 <sysrqb> but continuing staying synchronized with geckoview
15:41:10 <sysrqb> gaba: yes
15:41:23 * antonela is donuts part of the tb team in gitlab?
15:41:41 <sysrqb> gaba: some of those are related to the ESR transition
15:42:16 <donuts> possibly not? it's not under my "groups" if that's the same thing :)
15:42:42 <sysrqb> i don't see donuts there
15:42:48 <sysrqb> i can add after this meeting
15:42:49 <gaba> he is now
15:42:57 <antonela> thanks
15:43:17 <donuts> ty
15:43:28 <donuts> success
15:44:15 <sysrqb> in any case, the three-month Fenix rebase cycle is an experiment
15:44:25 <sysrqb> and we can adjust it or abort if it is not saving us time
15:44:29 <gaba> sysrqb: how do you want to move forward on looking at thte roadmap? the board seems to be reflecting it. the 10.5 milestone will need to be processed once the release is out.
15:47:04 <sysrqb> i think we don't need to discuss this more in details
15:47:24 <gaba> ok
15:47:26 <sysrqb> unless someone wants to discuss an item on the roadmap (or misssing from the roadmap)
15:47:50 <gaba> https://gitlab.torproject.org/groups/tpo/applications/-/boards the board. please filter by your name to see what you have in your plate
15:48:27 <boklm> I changed some 90esr to 91esr in the roadmap/tickets
15:48:37 <gaba> thanks
15:48:38 <sysrqb> we can move open issues in 10.5 on Friday
15:48:39 <boklm> (as I think there is no 90esr)
15:49:05 <gaba> ok
15:50:02 <sysrqb> boklm: do you think we can get Linux Nightly based on 91 by the end of next month?
15:50:16 <sysrqb> or is that too soon, along with Android work?
15:51:26 <boklm> I think it's plausible, but will depend on how many issues we find while doing it
15:52:02 <sysrqb> yeah
15:52:24 <sysrqb> of course I understand we may hit blockers
15:53:08 <sysrqb> mostly i'm thinking about you having enough time for moving to Moz91 and updating GeKo's branch for Linux
15:53:16 <sysrqb> (from FF87?)
15:53:45 <GeKo> it's not just toolchains, though
15:53:52 <GeKo> those builds are not running anymore
15:53:53 <sysrqb> but, hopefully this is enough time for planning that
15:54:53 <GeKo> mainly due to tor-launcher#40004
15:55:13 <GeKo> but who knows what else changed since that
15:55:36 <sysrqb> right, i have we have some patches needed, and pospeselr and I can work on those
15:56:01 <sysrqb> but I wanted to be know if boklm thought the toolchain work is too much for this timeframe
15:56:15 <sysrqb> s/i have we/i know we/
15:56:21 <GeKo> ah, you only meant toolchain stuff, okay
15:56:33 <sysrqb> yeah
15:57:10 <GeKo> btw. i marked an item bold on the pad which might fit here:
15:57:21 <GeKo> do we still plan with a non-esr desktop at some point?
15:57:33 <GeKo> i ask because we have a bunch of toolchain related tickets to that
15:57:51 <GeKo> and we could just close them to not confuse things with esr91 work
15:58:01 <sysrqb> i suspect no
15:58:06 <GeKo> and add cruft we don't need if we don't have plans to move away from esr
15:58:11 <GeKo> given the maintenance mode
15:58:20 <sysrqb> but i thought some of those would be needed for the esr transition
15:58:26 <GeKo> well, yes
15:58:33 <GeKo> we *could* use them for that
15:58:47 <GeKo> but boklm opened some new ones for the transition in particular
15:59:00 <GeKo> so, i wondered what would be a good way forward here
15:59:21 <sysrqb> ah, okay, then we can close the non-esr ones if that is simpler
15:59:36 <sysrqb> i don't have a strong preference
16:00:13 <GeKo> boklm: i leave that to you :)
16:00:19 <sysrqb> the non-esr issues may have some previous work/history, so that would be beneficial
16:00:35 <boklm> I think we can close the non-esr ones and link them from the esr ones if there is previous work done there
16:00:39 <sysrqb> but yeah, i think whichever issue is best
16:00:51 <GeKo> boklm: yeah, that sounds like a good idea
16:00:59 <sysrqb> sgtm
16:01:10 <boklm> ok, I will do that
16:01:37 <sysrqb> GeKo: are we taking time away from network health meeting?
16:01:45 <GeKo> we do
16:01:49 <antonela> 1 minute
16:01:50 <GeKo> but i think it's okay
16:01:52 <antonela> 2 now
16:01:59 <GeKo> do i hear 3?
16:02:02 <GeKo> :)
16:02:05 <sysrqb> heh.
16:02:06 <antonela> (:
16:02:27 <sysrqb> okay. the last topic is antonela, but we can move that to #tor-dev
16:02:37 <sysrqb> i don't think there is much to discuss
16:02:45 <antonela> right, gaba said she will do it today
16:02:49 <antonela> so its good
16:02:52 <sysrqb> yeah
16:02:56 <sysrqb> thanks gaba
16:03:06 <sysrqb> okay, thanks everyone. have a good week
16:03:08 <antonela> i'll wait for the link to spread the emails
16:03:08 <Jeremy_Rand_Talos> thanks!
16:03:11 <antonela> thanks!
16:03:13 <sysrqb> #endmeeeting
16:03:18 <sysrqb> #end-meeting
16:03:23 <antonela> ay
16:03:26 * sysrqb forgets
16:03:44 <donuts> o/
16:03:45 <antonela> endmeeeting with two ee
16:03:51 <sysrqb> #endmeeting