15:00:10 <pili> #startmeeting S27 01/21
15:00:10 <MeetBot> Meeting started Tue Jan 21 15:00:10 2020 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:10 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:14 <antonela> hello o/
15:00:17 <dgoulet> o/
15:00:18 <mcs> hi
15:00:20 <asn> o/
15:00:33 * sysrqb is here, mostly
15:00:49 <pili> here's the pad as usual: https://pad.riseup.net/p/s27-meeting-keep
15:00:54 <acat> hi
15:01:00 <pili> please add your updates :)
15:01:08 <pili> and discussion topics
15:01:41 <pili> feel free to place your discussion topics above my own, otherwise we may never get to them...
15:01:48 <antonela> welcome back asn
15:01:58 <asn> antonela: o/
15:02:06 <antonela> good stuff in #28005 acat
15:02:45 <asn> yes #28005 progress is nice!
15:03:41 <acat> i hope i can have something tangible soon :)
15:03:48 <asn> dgoulet: i need to review your #32542
15:04:00 <asn> dgoulet: but i got lots of backlog and stuff going on with the intro2 thing
15:04:06 <asn> dgoulet: but i will get to it!
15:04:09 <dgoulet> np
15:06:07 <pili> will give until 10 past for pad updates and then jump into discussion
15:09:26 <pili> ok, let's get started
15:09:49 <asn> o/
15:10:08 <pili> antonela: I think the last discussion point is yours? let's start there
15:11:02 <antonela> yes it is
15:11:07 <mcs> my opinion is we can try to do the graphic and see how it goes
15:11:13 <mcs> try to do it now
15:11:22 <antonela> nice, i should update the assets
15:11:29 <antonela> you can use a placeholder for now mcs :)
15:11:37 <antonela> glad we can do it !
15:11:53 <brade> antonela: could you try to do a top-down graphic?
15:12:18 <antonela> what do you mean? first the graphic then the text?
15:12:24 <brade> antonela: does a left-right graphic work in right-to-left languages?
15:12:40 <antonela> or an entire [] - [] - [] graph and then you place the [X]
15:12:57 <antonela> good point brade
15:13:08 <pili> I would also like to test this iteration as part of S9
15:13:26 <antonela> let me mockup how it will look, i can have it ready for today end of day
15:13:28 <antonela> could that work?
15:14:00 <antonela> if we have like a list (ul) then we can organize the items based the locale
15:14:58 <brade> antonela: whenever you can do it would be great
15:15:15 <antonela> nice, let me try some markup and i'll share today
15:15:18 <antonela> thanks a lot brade!
15:16:00 <mcs> if we reuse the about:neterror layout, the graphic would fit nicely on the side :)
15:16:13 <brade> (in place of the graphic Mozilla has)
15:16:40 <mcs> we will be looking at implementation details this week, so some iteration is OK
15:16:41 <antonela> i know
15:16:52 <mcs> thx
15:17:05 <antonela> thanks both
15:17:12 <pili> ok
15:17:15 <pili> is everyone good on this? :)
15:17:20 <antonela> is groot
15:17:31 <pili> ok
15:18:04 <pili> asn: acat  did you want to discuss O2A5/HTTPSE ?
15:18:12 <pili> I think I saw something on a ticket... :)
15:18:17 <asn> i skimmed over acat's post
15:18:25 <asn> i think many questiosn there are UX questions in principle
15:18:54 <asn> and there is (at least) one central engineering question namely "Should we use HTTPS-E or just do it ad-hoc DIY on our own?"
15:18:59 <pili> this is the perfect forum for it then :)
15:19:02 <asn> i'm not sure how to answer that engineering question
15:19:20 <pili> asn: right, I'm interested in this last point also
15:19:42 <asn> i'm not a browser dev so im not sure what are the positives and negatives of HTTPS-E or ad-hoc
15:20:08 <pili> for me it's a matter of whether it will be simpler/easier to maintain/quicker to implement than using HTTPS-E
15:20:09 <asn> if acat prefers doing it ad-hoc, and we think this is a reasonable way to maintain this in the future, I would be okay with this
15:20:10 <pili> anyone have any idea? :)
15:20:17 <asn> but i get questions like "How do we do update channels then?"
15:20:31 <antonela> how we are going to maintain it? orgs will give us a list? a pr?
15:20:50 <asn> i think, we start with securedrop and then we play it by ear
15:20:50 <antonela> will we have an open repo and we will accept PRs?
15:20:57 <asn> i dont think so
15:21:18 <acat> yeah, update channels feature is one that we would have to implement if we want it
15:21:18 <asn> i think we should start with a safe close-to-home list of securedrop isntances, and then see how people use the feature before we decide how to move further
15:21:38 <acat> but are there any 3rd party update channels currently?
15:21:45 <sysrqb> is this something we want to maintain long-term?
15:21:56 <sysrqb> i guess i don't see this scaling
15:21:58 <asn> acat: for https-e? i think securedrop has their own
15:22:04 <mcs> we can view it as an experiment and decide later how/whether to maintain
15:22:17 <asn> i think this should be maintainable
15:22:24 <hellais> anarcat: yes slacktopus is registed. It worked fine until January 7th, but now doesn't work anymore
15:22:30 <sysrqb> and i worry about designing and building something now, in like...3 weeks, that is only a proof-of-concept
15:22:41 <hellais> Tunde has been trying to join this meeting for the last 2 weeks, but cannot because the bridge is down :(
15:23:08 <antonela> what do you see doable sysrqb?
15:23:53 <sysrqb> i think we can get a list for securedrop and implmenet the UI/UX for that list
15:24:33 <sysrqb> and if we like how it works and we think this is a good idea at the end, then we can think about how we make it maintainable
15:24:41 <antonela> good
15:24:50 <asn> that seems plausible
15:25:01 <sysrqb> but the idea of custom rule sets and users adding their own custom thing is difficult to reason about
15:25:10 <antonela> we are not going to do that
15:25:15 <asn> that was not in the plan for s27
15:25:30 <anarcat> hellais: it would be great to have more information about what actually happens when it tries to join, because with the info i have now, i can't help you
15:25:35 <asn> a problem i could see with the approach we are discussing now
15:25:37 <antonela> we can ship tor browser with the channels updated ; in fact we dont want to allow users to update rule sets
15:25:57 <asn> is that redshiftzero wanted to even change the FPF website to mention the shorthand names of the securedrop instances
15:26:16 <asn> and i worry that if what we provide is too hacky, perhaps they won't want to play along
15:26:35 <anarcat> hellais: all i can see in my logs is this: 2019-12-26 21:05:11 -!- mode/#tor-meeting [+R] by arma2
15:26:40 <asn> in the sense that if we make an unmaintainable thing that we will strip out in the future, FPF will not want to experiment with the future
15:26:41 <sysrqb> ah. i thought there was some idea of users being able to add custom rulesets from websites
15:26:44 <anarcat> so that might be the cause
15:27:05 <asn> sysrqb: yes there was, but as part of our stockholm meeting we decided to go with a minimal version of the concept to start with
15:27:11 <asn> and see how that plays out, before we expand to custom rulesets
15:27:26 <sysrqb> ah, gotcha. okay
15:29:03 <sysrqb> i also worry about https-e becoming unmaintained
15:29:19 <antonela> afaik is already unmaintained
15:29:22 <sysrqb> and if we build this functionality into https-e, then we are doomed to maintain https-e long-term
15:29:24 <GeKo> i don't think that happens anytime soon
15:29:39 <GeKo> antonela: eff still maintains it
15:29:42 <antonela> GeKo: what exactly?
15:29:43 <sysrqb> okay
15:29:49 <antonela> oh, okey
15:29:52 <sysrqb> that's...good :)
15:29:57 <mcs> maybe this new feature will be another reason to keep maintaining it?
15:30:08 <mcs> (if EFF likes what we do)
15:30:16 <GeKo> the eff folks told us they would not stop maintaining it anytime soon
15:30:37 <GeKo> like they would not drop it if they found no one who stepped up
15:30:53 <antonela> oki, that is good
15:31:10 <acat> but as i said in the ticket, i can see some difficulties to having these kind of rules in https-everywhere vs. in Tor Browser as simple .tor.onion -> .onion pairs (if that's good enough for what we want)
15:31:53 <acat> mostly they have to do when you have to implement some kind of rules view/editing UI, as the https-everywhere rules can be complex
15:32:37 <asn> given the lack of time, i don't want to oppose the approach of doing it in TBB
15:32:49 <asn> but i'm afraid that securedrop might need update channels to make this work effectively
15:32:57 <asn> which is one of the things we lose if we do it in TBB
15:33:14 <asn> so perhaps we could ask them?
15:33:23 <acat> ok, if update channels is a must then it's a good reason
15:33:25 <asn> since securedrop is gonna be our first and only customer for now
15:33:50 <asn> acat: im not sure if they are a must
15:33:55 <asn> but i think they use them currently
15:34:29 <asn> https://github.com/freedomofpress/securedrop/issues/3668
15:34:32 <asn> or maye they dont
15:35:05 <asn> or maye they dont currently, but that issue seems to imply they would want to use them if we do onions
15:35:18 <sysrqb> hrm. if we use update channels, and securedrop can update their rules at any time
15:35:34 <sysrqb> then i'd want some transparency and auditability of those rules
15:35:41 <asn> sysrqb: there is a filter
15:35:46 <asn> sysrqb: in https-e
15:35:53 <asn> where it only allows certain types of updates
15:36:03 <asn> like u cant update wikipedia.org to go wherever you want
15:36:16 <asn> u can only update securedrop.*tor.onion to go wherever you want
15:36:20 <asn> or something
15:36:27 <asn> bill was telling us about that with excitement
15:36:38 <acat> yes, you can do that when you add an update channel
15:36:40 * antonela bill we miss you
15:36:41 <pili> :)
15:37:01 <antonela> who we can ping if we need help on this
15:37:07 <sysrqb> asn: okay, cool
15:37:14 <pili> we should move forward with this soon
15:37:22 <pili> with one solution or another :)
15:37:34 <pili> and, again, it's only a PoC :)
15:37:40 <asn> i think it could be okay to do it in TB, but perhaps we should get in touch with redshiftzero first
15:37:48 <asn> to tell her about the lack of update channels
15:38:05 <pili> although it would be nice if we can keep the solution on
15:38:08 <asn> antonela: bill and alexis
15:38:20 <antonela> si
15:38:23 <asn> bill seemed on top of it two months ago
15:38:29 <asn> so i dont think he just disappeared
15:38:34 <antonela> good to hear
15:39:05 <asn> acat: suggestion:
15:39:08 <sysrqb> okay, we can make decisions on this outside of this meeting
15:39:19 <asn> wanna do an estimation of work if you do it in https-e, and an estimation of work if u do it in TBB?
15:39:34 <asn> and perhaps a pros cons list for each approach (like features we lose if we go TBB)
15:39:41 <asn> and then we can take an informed decision based on that?
15:39:50 <acat> makes sense
15:40:03 <asn> (hope that didnt sound like too much work)
15:40:26 <acat> no, it should be fine
15:40:30 <antonela> basically, can we do channel updates without https-e? or do we have a better way to do it?
15:40:33 <brade> acat: a proposal with pros/cons is a good idea :-)
15:40:44 <asn> antonela: we could, but we would have to reinvent the crypto wheel
15:40:46 <mcs> scope is also important, e.g., update channels or not, rule editor or not
15:41:00 <antonela> asn: exactly
15:43:13 <asn> antonela: and perhaps u can take a look at acat's UX questions at parallel time?
15:43:32 <antonela> yep, will do that
15:43:35 <asn> because i feel like (1) (2) and (3) are all UX qs
15:44:08 <pili> ok
15:44:39 <pili> are we good here? :)
15:45:14 <asn> i think so?
15:45:31 <acat> brade: just to clarify, you mean to do this as a tor-browser proposal?
15:45:58 <brade> acat: yes, but not necessarily a full-blown proposal
15:46:32 <acat> ok, sounds good
15:48:04 <pili> ok, let's move on
15:48:05 <pili> similar to what we did last week I wanted to review the O2A4 -must tickets
15:48:20 <pili> to see where we are with these
15:48:25 <pili> and whether they still make sense
15:48:38 <antonela> O2A4 is errors?
15:48:47 <pili> https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&parent=%2330025&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&col=component&col=changetime&col=sponsor&desc=1&order=sponsor
15:49:00 <pili> yup, and it has the url bar indicators also
15:49:20 <pili> I'm more interested in the url bar indicator issues actually
15:49:28 <pili> since I think we're pretty clear on the errors
15:49:43 <antonela> we are discussing some of those stuff in #32645
15:49:52 <asn> btw O2A4 also has #13410. is this still in the game?
15:50:00 <asn> we get many requests for that over time
15:50:06 <pili> e.g #13410
15:50:13 <asn> but we havent mentioned it lately
15:50:16 <pili> yup, I saw your update today antonela ! :)
15:50:44 <pili> so, is #32645 ready for implementation now?
15:50:51 <pili> or does it need further dev review?
15:51:10 <antonela> well, we have all those child tickets open :)
15:52:02 <antonela> maybe #32645 should perform as a parent?
15:52:02 <antonela> not sure
15:52:29 <brade> Is Richard working on these bugs?
15:52:40 <antonela> we have been discussing them, yes
15:52:47 <pili> will implementing #32645 close the children? e.g #13410
15:53:03 <antonela> ideally...
15:53:07 <pili> #27636
15:53:21 <pili> #30937
15:54:06 <pili> ok, that's what I was hoping :)
15:54:07 <pili> I'm good with parenting those then
15:54:30 <pili> ok
15:54:31 <sysrqb> oh. i don't think they are all related
15:54:36 <pili> no?
15:56:24 <sysrqb> ah, i was thinking about #27636
15:57:01 <sysrqb> hrm. it hink that one is about the warning page, and not the url bar indicator
15:57:04 <sysrqb> *think
15:57:25 <pili> hmm, possibly, let me re-read
15:57:30 <sysrqb> but i think #30937 can be a child of #32645
15:58:04 <pili> I think #27636 is a mixture of the page + indicator
15:58:05 <sysrqb> idk. this is all a bit confusing.
15:58:10 <antonela> lol
15:58:13 <sysrqb> okay. that could be.
15:58:32 <pili> it's about how we treat all of the different scenarios for onions
15:58:35 <sysrqb> oh, yeha. "My expectation would be to not see the untrusted issuer warning and get the green onion *without* padlock indicator."
15:59:05 <hellais> anarcat: yes I guess some more debugging into this is needed from our end. It's already useful to know that the +R is something fairly recent and may in fact be what is causing the problem
15:59:09 <pili> I think what we might be missing here is what the error page should say? or maybe there shouldn't be an error page for some sorts of certs?
15:59:18 <anarcat> hellais: i suspect so as well
15:59:25 <pili> anyway, we're at the hour now and I have another meeting :)
15:59:27 <sysrqb> pili: yeah
15:59:46 <antonela> should i review all those child tickets?
15:59:55 <antonela> who is going to work with them? pospeselr or?
16:00:05 <pili> I think for now let's continue working on the implementation of the url bar onion indicators
16:00:07 <pili> antonela: please, if you can :)
16:00:20 <sysrqb> antonela: we have our team meeting today, i'll let you know after that
16:00:31 <antonela> sysrqb: super, thank you
16:00:34 <pili> ok
16:00:39 <pili> I'm going to call it... :)
16:00:44 <pili> thanks everyone
16:00:46 <asn> thanks all!
16:00:47 <pili> #endmeeting