14:59:38 <pili> #startmeeting S27 10/15
14:59:38 <MeetBot> Meeting started Tue Oct 15 14:59:38 2019 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:59 <pili> pad: https://storm.torproject.org/shared/o9yu6vOjQ_ovjZE-gDip4Cl6jnJzuTkeDrISGuD-OnA
15:00:04 <antonela> hello!
15:00:05 <pili> please add your notes :)
15:02:01 <sysrqb> o/
15:02:12 * sysrqb finishes email
15:03:21 <pili> I'll give everyone a few minutes to add their notes
15:03:22 <pili> while I finish with the roadmap review
15:05:23 * antonela done
15:06:00 <dgoulet> o/
15:06:51 <pili> hi people :)
15:06:55 <pili> do we have asn today?
15:07:06 <dgoulet> nope
15:07:19 <dgoulet> I'll be the net team only liaison I believe :)
15:08:04 <antonela> we like you too dgoulet
15:09:53 <pili> sorry people, I'm messing around with the notes
15:10:24 <pili> ok, are we ready to start? :)
15:10:32 <pili> dgoulet: any notes from network side?
15:11:02 <dgoulet> I unfortunately can not open the Storm pad... it simply keeps loading on my TB here all the time and once it loads, it will reconnect non stop
15:11:18 <dgoulet> but I do have a discussion point for sure which I bet it is the TB one if any lol ? :)
15:12:09 <pili> ok, no worries :)
15:12:20 <pili> I'll add it in, it wasn't there yet... ;)
15:12:31 <pili> I'm guessing it's the socks stuff?
15:12:48 <dgoulet> well for me it is all about the direction the net team needs to go after our last meeting. And I'm asking because Matt's tor-dev@ email thread might have changed things
15:12:51 <dgoulet> pili: yes
15:12:52 <pili> ok
15:13:21 <pili> I have 2 quick questions before that if that's ok
15:13:22 <pili> because I can see this other point taking up the rest of the meeting
15:13:38 <dgoulet> sure
15:13:41 <pili> unless someone else has any other updates they'd like to share?
15:14:23 <pili> ok, I'll go
15:14:37 <pili> so my first point is about O2.5 and HTTPSEverywhere
15:15:20 <pili> during one of the last meetings we had, I think asn mentioned that network team was going to start working on this in november
15:15:39 <pili> and I wanted to understand what work is required on the network team side
15:15:53 <pili> and any collaboration needed with Browser and/or UX teams
15:16:23 <dgoulet> pili: oh hmmmm... not sure this is net team per-se but rather asn that wanted to come up with a proposal?
15:16:31 <dgoulet> (based on the Stockholm session on that)
15:16:32 <pili> ah ok
15:16:33 <dgoulet> antonela: you know ? ^
15:16:46 <pili> so, related to O2.5, we need to decide who from the browser team can work on it
15:17:21 <pili> since I was hoping we could start on this sooner rather than later, e.g ideally November or December
15:17:37 <pili> so that we have multiple browser team people working on different S27 objectives at the same time
15:17:40 <antonela> i dont think we have a lot for the net team in O2.5, we discussed it and we need someone from TB to work on it
15:17:50 <pili> ok, so likely it was just the proposal
15:18:09 <pili> that asn wanted to work on
15:18:15 <antonela> maybe, yes
15:18:24 <sysrqb> dgoulet: we discussed this with redshiftzero, do you know if there were any other discussions
15:18:28 <sysrqb> ?
15:18:36 <antonela> no, that was the last discussion sysrqb
15:18:36 <sysrqb> like, who else we should include in this?
15:18:52 <sysrqb> antonela: okay
15:19:20 <pili> sysrqb: good point, we should probably start reaching out to people and have a mini kick off for this objective
15:19:25 <antonela> asn updated #28005
15:19:26 <antonela> https://trac.torproject.org/projects/tor/ticket/28005#comment:9
15:19:29 <antonela> with the minutes of that meeting matt
15:19:43 <sysrqb> ah!!
15:19:44 <sysrqb> thanks
15:19:56 <antonela> maybe that was the asn proposal part? not sure, we can ask him when he is around
15:21:36 <sysrqb> yep, looks like it, that's what i remember
15:21:55 <antonela> phew :)
15:22:04 <pili> ok, I'm good with this point
15:22:05 <sysrqb> maybe there will be a more-formal proposal, but i don't know if there are more details
15:22:19 <pili> sysrqb: any ideas on who could work on this from the browser team? :)
15:22:30 <sysrqb> nope, not yet
15:22:41 <sysrqb> ideally, it'll be someone who's already familiar with https-e
15:22:51 <sysrqb> but i don't know if anyone has that knowledge yet
15:23:10 <mcs> Maybe we should discuss at next week’s browser team meeting? Or yesterday’s ;)
15:23:11 <sysrqb> we can discuss this at the next meeting
15:23:21 <sysrqb> yes, yesterday's, good idea :)
15:23:30 <pili> ;)
15:23:51 <sysrqb> we can discuss it next week
15:23:52 <pili> hmm, I'll wait until TB9 is out before bringing this up
15:23:57 <sysrqb> sounds good
15:24:06 <mcs> yeah, waiting might be better
15:24:12 <pili> I'll likely be afk for the meeting next week anyway
15:24:21 <sysrqb> ah, right
15:24:28 <sysrqb> i forgot
15:24:31 <sysrqb> okay
15:25:41 <pili> ok
15:25:52 <pili> my other discussion point was about network team work in 2020 on this sponsor
15:26:11 <pili> I had a good rough timeline up until christmas 2019 but I don't think I have anything after
15:26:33 <pili> but maybe we can discuss this next meeting with asn also (if he's going to be available for it)
15:26:48 <dgoulet> we don't have anything after 2019 roadmapped
15:26:59 <dgoulet> so probably we need to assess soon what will remain and needs to be done?
15:27:20 <pili> dgoulet: cool, it's good to know I'm up to date then :)
15:27:21 <pili> yes definitely
15:27:22 <pili> those were all my discussion points
15:27:39 <pili> does anyone have any others before we jump into the socks errors discussion?
15:29:22 <pili> ok, let's jump in then
15:29:22 <antonela> im good
15:29:23 <pili> who wants to start? :)
15:29:44 <pili> dgoulet, sysrqb brade mcs ? :)
15:30:04 <sysrqb> i sent an email a few minutes ago
15:30:29 <sysrqb> dgoulet: did tjr's email answer most of your questions?
15:30:39 <sysrqb> there's the question about unique id
15:30:41 <dgoulet> I did not see that email yet
15:30:42 <dgoulet> _but_
15:30:53 <sysrqb> but :)
15:30:54 <dgoulet> what I'm wondering there is where the TB team stands about this
15:31:02 <dgoulet> as in "lets go SOCKS error"
15:31:07 <dgoulet> ?
15:31:48 <mcs> It is difficult for me to reason about the ongoing tor-dev email discussion b/c I do not know the onion services protocols and implementation well enough.
15:31:51 <sysrqb> using the socks error if the request fails early?
15:32:12 <sysrqb> (because desc. fetch fails or intro fails?)
15:32:13 <dgoulet> well using the SOCKS reply for the errors
15:32:22 <sysrqb> okay
15:32:23 <dgoulet> as discussed in the thread
15:32:36 <dgoulet> instead of TB relying on control event like discussed at the last meeting
15:32:47 <sysrqb> i think that is the best case for tor browser
15:32:52 <sysrqb> receiving an synchronous error message
15:32:57 <sysrqb> (or error code)
15:33:06 <dgoulet> control event will require us to come up with a solution for the stream ID ... I think asn wanted to spend a bit of time there since we believe control event should be the way to go for TB in the future
15:33:15 <sysrqb> mcs: brade: is that how you feel?
15:33:43 <dgoulet> thing is that having control event along with SOCKS error is more work than just SOCKS error
15:33:54 <dgoulet> so is TB going the control event way for s27 or not at all?
15:33:55 <mcs> sysrqb: yes, I don’t think Firefox’s networking stack is designed with the idea of “out of bad” errors in mind.
15:34:09 <mcs> “out of band"
15:34:16 <sysrqb> yeah
15:34:44 <dgoulet> well with optimistic data... there is sorta that need? Else we hack the SOCKS reply ;)
15:34:53 <sysrqb> right
15:35:01 <dgoulet> I mean, the future is uncertain there if we only rely on synchronous event no? :)
15:35:12 <dgoulet> but anyway, I'm all for SOCKS error if TB team goes that way :)
15:35:12 <sysrqb> the easy solution is we simply don't use optimistic data for .onion addresses
15:35:28 <sysrqb> yes
15:35:28 <dgoulet> but might mean to drop the Stream ID issue with control event for now if TB will not care about those anytime soon
15:36:05 <brade> I think postponing the Stream ID is fine
15:36:08 <sysrqb> yep
15:36:14 <dgoulet> ack!
15:36:16 <dgoulet> all good
15:36:37 <mcs> I am lost now.
15:36:40 <dgoulet> and I understand that this SOCKS error patch in tor, you need it soon-ish?
15:37:21 <mcs> Someone needs to write a specification for this. Or are we doing the easy solution (no optimistic SOCKS for .onions)?
15:37:53 <sysrqb> i guess that is prop#304
15:38:11 <dgoulet> prop304 + SOCKS reply will arrive just a bit later than "right now" for optimistic data in the case of .onion
15:38:24 <dgoulet> basically sysrqb's proposal on tor-dev@ iiuc?
15:38:36 <sysrqb> hrm
15:38:56 <sysrqb> i worry about how we handle rendezvous failure
15:39:09 <mcs> I guess my question is “Does the browser need to do something more than handle SOCKS errors (prop304)?"
15:40:10 <sysrqb> dgoulet: i wonder if we should ignore optimistic data for this
15:40:49 <dgoulet> honestly, at this point, whatever TB team decides, I'll do it ;)
15:41:09 <sysrqb> or, we can modify Tor Browser such that if the socks connection is closed during the initial HTTP request, then we assume it was a rend failure
15:41:22 <sysrqb> but that is more complicated than simply using the socks error code
15:41:59 <sysrqb> okay
15:42:29 <sysrqb> we can start with not doing optimistic data and the SOCKS handshake will block the connection until the connection is established (stream is attached)
15:42:42 <sysrqb> if we finish this early, then we can add the optimistic data part
15:43:02 <sysrqb> but these pieces don't really conflict
15:43:22 <sysrqb> so i don't think we should be re-doing any work
15:43:43 <sysrqb> is that reasonable?
15:43:47 <dgoulet> ok soooooooo this means tor will NOT send the SOCKS reply until the HS dance is done so we can send you back the errors (prop304) until the RP stream is done
15:43:55 <dgoulet> (for .onion ofc)
15:44:02 <sysrqb> correct, that is my thought
15:44:03 <dgoulet> is that correct behavior?
15:44:06 <dgoulet> ok great
15:44:07 <dgoulet> onward!
15:44:18 <sysrqb> mcs: brade: does that sound okay?
15:44:19 <mcs> Is that what was already implemented in tor?
15:44:30 <dgoulet> mcs: yes, I just needed to cleanup for upstream merge I believe
15:44:41 <mcs> That’s what I thought.
15:45:10 <brade> dgoulet: and fix the delay / timing problem?
15:45:21 <dgoulet> yes that one needs to be figured out yes
15:45:55 <mcs> sysrqb: brade and I are fine with this solution, but we need to make the decision stick. That probably means we need a plan for how we will add opt SOCKS for .onions later.
15:46:52 <dgoulet> optmistic data with .onion means somehow TB will have to get async error codes :S
15:47:21 <sysrqb> brade: mcs: okay. i agree, but i don't have a good solution right now
15:47:38 <sysrqb> i can dig into the necko code and see if there's an easy solution
15:47:42 <sysrqb> "easy"
15:47:47 <sysrqb> but i don't know right now
15:48:10 <sysrqb> maybe we can pick this up again at the next meeting (or a later meeting)
15:48:24 <sysrqb> depending on how crazy the next week is
15:48:39 <mcs> Sounds good to me, but I think the network team wants to know how to proceed :)
15:49:39 <sysrqb> in the short term, i think dgoulet can finish the prop304 implementation and get that merged
15:49:56 <mcs> OK, so we have a plan :)
15:50:06 <antonela> \o/
15:50:07 <sysrqb> honestly, using optimistic data is nice-to-have
15:50:08 <sysrqb> and it's eomtrhing we want long-term
15:50:13 <sysrqb> *something
15:50:22 <sysrqb> but i don't know if this is the time
15:51:18 <mcs> the other possible solution is more support on the browser side for optimistic SOCKS (but that requires deeper necko changes that don’t introduce other bugs like the old patch we backed out)
15:51:33 <sysrqb> yep
15:51:47 <mcs> something we would really need Mozilla engineers to do or at least help us implement and maintain
15:52:04 <sysrqb> yeah
15:52:43 <sysrqb> okay, it seems like we have a path forward, for now
15:52:55 <dgoulet> yes all good
15:52:58 <antonela> we can discuss it during all hands with firefox devs
15:53:04 <sysrqb> great
15:53:15 <sysrqb> yeah, that's another conversation we can have
15:53:57 <pili> ok
15:54:22 <pili> anything else on this? :)
15:54:29 <pili> or any other S27 topic?
15:54:44 <pili> does anyone need any help or feedback from anyone else?
15:55:38 <antonela> i've been working with a first approach to error pages ui
15:55:47 <antonela> reviews are appreciated!
15:56:03 <antonela> #19251
15:56:09 <antonela> no hurries, just to point folks to it
15:56:18 * mcs looked at the error page explorations briefly but hasn’t made time to comment yet
15:56:42 <antonela> thanks!
15:57:42 <pili> thanks antonela :)
15:58:14 <antonela> np :)
15:58:57 <sysrqb> antonela: nice!
15:59:20 <pili> ok, we're almost at the hour
15:59:23 <pili> so let's end things here
15:59:24 <pili> #endmeeting