14:59:22 <pili> #startmeeting S27 03/31
14:59:22 <MeetBot> Meeting started Tue Mar 31 14:59:22 2020 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:25 <asn> o/
14:59:28 <pili> hi everyone
14:59:30 <brade> hi
15:00:00 <pili> I hope you are all well today
15:00:01 <pili> here's the pad: https://pad.riseup.net/p/s27-meeting-keep
15:00:03 <pili> please add your updates
15:00:20 <pili> this might be our last meeting on this project :'( but we'll see... ;)
15:00:30 <sysrqb> o.O
15:00:41 <antonela> o/
15:01:01 <asn> end of an era
15:01:22 <acat> hi
15:01:30 <dgoulet> o/
15:01:38 <mcs> o/
15:02:09 <syverson_> o/
15:03:03 <nicoleiocana__> o/
15:04:06 * pili does some ticket clean up while people add their updates
15:04:27 <pili> I'll give a few more minutes and we can review progress
15:04:33 <pili> and discuss any other topics
15:08:03 <pili> ok, I think we can start :)
15:08:21 <pili> let's work our way backwards this time from O2A5: HTTPSE
15:08:33 * antonela is reading https://tools.ietf.org/html/rfc6648
15:08:44 <pili> we've got a review from brade and mcs
15:08:48 <pili> do we need a second one
15:09:13 <sysrqb> it looks like i'm the second reviewer
15:09:30 <sysrqb> so, i'll do that review this week
15:10:02 <pili> thanks sysrqb :)
15:10:07 <pili> fingers crossed all is good and we can merge! :D
15:10:36 <pili> ok, O2A4: Errors
15:10:44 <sysrqb> i added one discussion question for this meeting related to this, but i hope we can merge this into nightly this week
15:11:01 <pili> thanks sysrqb  that sounds great
15:11:04 <sysrqb> i'll follow up with jen about the status of their hackathon
15:11:16 <sysrqb> and where they are with moving their ruleset into production
15:11:30 <pili> ok, we can discuss this now then before moving on to O2A4
15:11:47 <sysrqb> i'm fine with either order :)
15:11:58 <sysrqb> i didn't mean to interrupt that flow
15:12:08 <pili> nono, it's fine :)
15:12:17 <sysrqb> okay, hopefully it is quick
15:12:18 <pili> so is it a question regarding whether we want to do this?
15:12:26 <pili> Append onion address as a query string after human-memorable address (http://nytimes.securedrop.tor.onion?onion=nyttips4bmquxfzw)
15:12:41 <sysrqb> yes
15:12:50 <sysrqb> i was going to chat with antonela  and acat after the meeting
15:12:54 <pili> right
15:12:57 <asn> hmm. how did this come up?
15:12:57 <sysrqb> but hten i decided i'd just raise it during th emeeting
15:13:09 <sysrqb> this is related to work paul and i are doing
15:13:19 <sysrqb> but, it has some significant UX benefit
15:13:21 <pili> I would do this as an enhancement after we have merged the existing work
15:13:22 <syverson_> Could I be in on that chat, or would it disrupt?
15:13:30 <sysrqb> in that it is explicit which .onion is being used
15:13:58 <asn> it also seems something that potentially could cause significant UX confusion to people
15:13:59 <sysrqb> syverson_: i decide we can have it now
15:14:00 <pili> otherwise I can see this work dragging on forever ;)
15:14:46 <pili> yes, let's discuss now :)
15:14:47 <sysrqb> asn: is there a specific way you think this could be confusing?
15:15:06 <asn> hm
15:15:10 <sysrqb> we could use a different query string key, instead of onion
15:15:20 <sysrqb> http://nytimes.securedrop.tor.onion?id=nyttips4bmquxfzw
15:15:31 <antonela> and how it give us a memorable address?
15:15:33 <asn> i think appending a GET-style query parameter with jibberish in the end of a human memorable thing has the potential for confusion
15:15:36 <GeKo> i doubt the whole onion will fit into the urlbar?
15:15:36 <sysrqb> i think .tor.onion?onion= is a little wier
15:15:37 <mcs> the .onion is available in the circuit display. do we need it in the URL bar?
15:15:38 <sysrqb> d
15:15:47 <asn> IMO we should be moving towards more human memorable and less jibberish
15:16:02 <dgoulet> agree, we should remove entirely the .onion jibberish in the long run...
15:16:12 <acat> perhaps we could display the .onion in the place were the EV info used to be (removed in Firefox 70)
15:16:14 <syverson_> It doesn't have to fit in the URL bar to be useful?
15:16:22 <syverson_> dgoulet: No!!!
15:16:35 <dgoulet> syverson_: Yes!!! :P
15:16:44 <sysrqb> Paul has strong feelings about this :)
15:16:52 <GeKo> syverson_: well, if you only see the first 5 characters how is this useful for the normal user?
15:17:00 <antonela> sorry, are we discussing a maximum change the day this sponsor ends?
15:17:00 <syverson_> Ermm probably too long a debate to have here, but this majorly undermines security.
15:17:04 <sysrqb> but i also agree it is helpful coupling these two pieces of information
15:17:09 <asn> antonela: +1
15:17:20 <sysrqb> antonela: no, it is a very minor change
15:17:49 <antonela> ook
15:18:07 <sysrqb> :)
15:18:26 * antonela suspicious
15:18:47 <antonela> again, what is the main question?
15:18:49 <pili> hmm, I feel like we're going to go down a rabbit hole with this one... :)
15:19:15 <sysrqb> providing the full address in the circuit display is helpful, but including the address in the url bar along with the human-memorable address is very useful
15:19:19 <syverson_> Should separate issue of query strings wrt securedrop.tor.onion and in general.
15:19:37 <GeKo> what speaks against having this as a feature on top of what gets merged now as pili suggested?
15:19:50 <syverson_> The current talk should be only about the former
15:20:12 <acat> sysrqb: the change would be just cosmetic, right? that parameter would never be sent to the server on reload, because the actual URL would be different, i assume
15:20:25 <sysrqb> acat: correct
15:20:38 <sysrqb> i can see us using this in future future
15:20:49 <sysrqb> for "hinting" at the .onion address
15:20:56 <sysrqb> but currently this would only be cosmetic
15:21:31 <pili> just to play devils advocate.. is anyone really going to double check the long .onion string?
15:21:40 <acat> the question is what happens if the URL already has a onion parameter? :)
15:22:07 <sysrqb> GeKo: nothing speaks against adding this as another feature after the current except we may never add it later
15:22:21 <syverson_> acat: you mean already has a query string?
15:22:32 <acat> yes
15:22:34 <GeKo> well, if it's important we'll surely add it, no? :)
15:22:36 <sysrqb> acat: an existing parameter should take priority and not be replaced
15:22:55 <sysrqb> GeKo: yes, we always complete important tickets :)
15:23:03 <sysrqb> </sarcasm>
15:23:05 <mcs> Someone should write up a short doc that explains what the security issue is and how this addresses it. This is completely new to most of us :)
15:23:05 <asn> are we trying to acquire consensus in this last meeting about this topic? it seems unlikely.
15:23:08 <GeKo> well, it might give more time to think about it
15:23:11 <dgoulet> mcs: +9k
15:23:20 <GeKo> given that some folks here seem to be caught by surprise
15:23:28 <pili> yup, I think we definitely need to start with a ticket
15:23:45 <asn> the question is if this ticket/discussion is also gonna delay the feature from being shipped
15:23:49 <syverson_> pili: if it's in a link or entered the change may be noticed (if not off end of window)
15:23:54 <dgoulet> with v3 address, we are moving towards a scheme where URL look like SPAM click-bait "add-junky" addresses tbh... so would love to see the doc. explaining why that makes sense
15:24:00 <pili> there are plenty of follow up S27/Onion services related projects that we should follow up on once this project is over
15:24:17 <pili> I don't think we'll drop them all after this sponsor is over
15:25:09 <sysrqb> firefox already supports handling long, spammy urls
15:25:11 <pili> so, I would say to 1: create a new ticket for this enhancement and move the discussion there
15:25:16 <sysrqb> by prioritizing the base domain
15:25:20 <sysrqb> this isn't a problem.
15:26:00 <pili> estimate implementation cost and then implement as a follow up to this
15:26:06 <pili> I really don't want to add last minute things when we're 99% done with this activity
15:26:28 <syverson_> pili: but more important is allowing these to be provided by a domain owner, not just trusted from HTTPS-E channel.
15:26:53 <brade> I need a spec
15:27:03 <pili> syverson_: I would love to know how this would work which is why a ticket or email explaining it would be great :)
15:27:44 <syverson_> pili: will send you something after meeting, when I can again get to my email.
15:27:47 <sysrqb> that's fine, i'll open a ticket
15:27:53 <syverson_> that too.
15:28:03 <sysrqb> but this is a very minor change to the current patch
15:28:27 <mcs> but it is a major change from the UX perspective :)
15:28:40 <syverson_> mcs: yes an improvement.
15:28:42 <sysrqb> is it?
15:28:54 <sysrqb> a major change, that is
15:28:54 <dgoulet> it is massive change guys come on
15:28:59 <dgoulet> v3 are 52 chars!
15:29:06 <dgoulet> (to UX)
15:29:08 <pili> and a lot of us need to fully understand the benefits :)
15:29:21 <dgoulet> precisely!!
15:29:51 <sysrqb> i'll follow up this converation with more detials
15:29:57 <sysrqb> *meeting
15:30:41 <pili> thanks sysrqb :)
15:31:00 <pili> are we ok to move on to O2A4?
15:31:02 <asn> thanks :)
15:31:14 <antonela> quick question, will this push O2A5 to stable? or that is still on discussion?
15:31:51 <sysrqb> that is part of me following up with jen
15:32:07 <antonela> i want to learn how this move us closer to where we want to be
15:32:09 <antonela> sysrqb: oki
15:32:19 <sysrqb> but, this should be in upcoming alpha (next week)
15:32:36 <sysrqb> if everything is good
15:32:39 <antonela> got it
15:32:42 <asn> love it
15:33:17 <pili> :D
15:33:19 <pili> ok
15:33:24 <pili> I'm moving on :P
15:34:27 <pili> I still need to clean up a bunch of tickets on O2A4:Errors #30025
15:34:54 <pili> dgoulet: I have #32542 in needs_revision
15:35:07 <pili> what's the status with that one? :)
15:35:33 <dgoulet> that one is for 044 so on the radar for that :)
15:36:06 <pili> does that impact the error display in browser?
15:36:50 <dgoulet> I would think little because those 2 missing codes are extremely rare but until we have them, yes TB will not print them
15:36:50 <pili> as in, does it mean we will have some situations where there is no error code returned to the browser and what's going to happen if so?
15:37:07 <dgoulet> pili: will end up in the situation we are now that is no error code to understand what is going on :S
15:37:08 <pili> right, I seem to remember us discussing this in the past :)
15:38:00 <pili> what's the likelihood of it making it into 044 vs moving into an even later release?
15:38:07 <dgoulet> 100% in 044
15:38:21 <dgoulet> not much remains, just need to get it revised but it will be on 044
15:39:24 <mcs> will tor return a generic error today in those situations?
15:39:36 <dgoulet> mcs: yes
15:39:49 <dgoulet> mcs: as in behavior before the extended errors
15:40:13 <mcs> so the user will probably see the standard “unable to connect” error page; just not our new one. seems OK for now
15:40:36 <dgoulet> right
15:40:49 <sysrqb> +1
15:41:45 <sysrqb> can you say when the ticket will be assigned?
15:41:51 <sysrqb> sometime in April?
15:41:59 <pili> ok, #27657 we keep saying pospeselr will take care of it ;) but it's not assigned
15:42:01 <pili> antonela: do you remember which was the related ticket
15:42:03 <dgoulet> sysrqb: asking me?
15:42:08 <sysrqb> sure :)
15:42:12 <pili> sysrqb: I can assign it now, another thing is when to schedule it for ;)
15:42:25 <antonela> pili: im not pospeselr pm :)
15:42:32 <dgoulet> sysrqb: in April yes it will be resolved if this is your question :)
15:42:35 <sysrqb> i mean, the 044 feature freeze is May 15 (currently)
15:42:37 <pili> :)
15:42:41 <sysrqb> so, April or early May :)
15:42:53 <sysrqb> dgoulet: okay, thanks :)
15:42:54 <dgoulet> April it will be for sure
15:43:24 <pili> crossed wires on those tickets...
15:43:51 <sysrqb> oh
15:43:56 <sysrqb> one sec
15:44:00 <pili> it's fine :)
15:44:09 <pili> #19251 is merge_ready \o/
15:44:17 <sysrqb> #33707
15:44:24 <pili> aha
15:44:33 <pili> thanks sysrqb that's what I was looking for
15:44:34 <sysrqb> i think we missed gk's original ticket, so he opened a dup
15:44:39 <pili> that's fine
15:44:56 <pili> I'll close the original (#27657) as a dupe
15:45:44 <sysrqb> okay, i'm fine with using either ticket
15:46:32 <pili> I'll clean up after the meeting...
15:47:03 <pili> the other cert related tickets under O2A4 we will deal with after the transition away from ESR in Tor Browser land...
15:47:14 <pili> any other comments or shall we move on to O2A3?
15:47:15 <sysrqb> yep
15:47:24 <sysrqb> (no comment from me)
15:48:09 <pili> #21952 we need UX review I guess
15:48:37 <antonela> i dont think so, i reviewed stephw's comments and give an OK
15:48:53 <pili> I thought there was another review needed for whether or not to have an icon?
15:49:21 <antonela> acat and i talked about it this morning, we will go without icon
15:49:24 <pili> ok
15:49:55 <acat> pili: yes, so i'll do a revision for the strings and without the icon in the notification
15:50:00 <pili> and then it needs code review from brade mcs and pospeselr ?
15:50:14 <mcs> yes, I think so
15:50:17 <pili> ok great, and then (final) review? :D
15:50:49 <pili> we had also discussed doing #27590 last week
15:51:18 <pili> I added a comment on the ticket for how we would implement this
15:51:51 <acat> pili: oh, i thought this was to be done after s27
15:52:00 <pili> I think we need a points estimate to decide when to schedule this for
15:52:01 <pili> i.e April vs July or beyond
15:52:02 <pili> acat: yes, that's fine :)
15:52:28 <pili> I'll stop trying to sneak things in after blocking others from doing so... ;)
15:52:48 <pili> I think that's it on O2A3
15:53:01 <pili> O2A2 is done in #19251
15:53:07 <pili> and O2A1 is done
15:53:13 <pili> as well as all of Objective 1
15:53:28 <pili> does that seem like an accurate reflection on the state of things to everyone?
15:53:52 <mcs> yes
15:54:03 <asn> yes
15:54:15 <pili> wooo :)
15:54:36 <pili> do we think we will be able to tie up the last remaining pieces by the end of this week?
15:54:53 <pili> where tie up == tickets being reviewed and merge_ready
15:55:02 * antonela finds hard to define the state of things so just imagine the "accurate reflection"
15:55:12 <antonela> im happy to review what is needed this week
15:55:36 <acat> pili: i think so
15:56:37 <asn> im gonna throw this out here, but since this sponsor was one of the biggest cross-team projects we've ever had, should we do a retrospective at some point of how it went?
15:56:54 <pili> asn: that's a great suggestion
15:56:57 <mcs> asn: good idea
15:57:02 <sysrqb> asn: we're planning a tor browser-specific retrospective
15:57:17 <sysrqb> but a cross-team retrospective would is a good idea, too
15:57:33 <pili> I would love to do it towards the end of April when hopefully everything is back to "normal" for me
15:57:33 <asn> yeah we are also doing net-team retros. but this one is cross team (net, tb, ux)
15:57:39 <asn> sounds good to me
15:58:00 <pili> right now I'm low on time slots for extra meetings :(
15:58:05 <sysrqb> so yes, +1 :)
15:58:44 <sysrqb> maybe we can ask everyone involved to write some notes about their experience working on this
15:58:56 <pili> let me take a note to follow up on this
15:59:00 <sysrqb> because memories/feelings may fade a little after a month
15:59:05 <pili> right :)
15:59:36 <mcs> we could have a pad for jotting down some notes now/soon
15:59:52 <sysrqb> that could work
16:00:00 <pili> ok
16:00:04 <pili> ok, I'll set that up
16:00:09 <pili> I need to go now though
16:00:13 <pili> so I will end the meeting
16:00:15 <pili> thanks everyone
16:00:18 <sysrqb> thanks pili o/
16:00:18 <pili> #endmeeting