14:59:20 <pili> #startmeeting S27 03/24 14:59:20 <MeetBot> Meeting started Tue Mar 24 14:59:20 2020 UTC. The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:20 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:21 <pili> hmm 14:59:22 <MeetBot> pili: Error: Can't start another meeting, one is in progress. 14:59:28 <pili> there we go 14:59:29 <pili> ok 14:59:34 <pili> how is everyone doing? :) 14:59:41 <pili> let me get the pad 14:59:48 <pili> https://pad.riseup.net/p/s27-meeting-keep 14:59:54 <pili> please add your updates 14:59:55 <sysrqb> Happy Tuesday, everyone 15:00:00 <acat> hi 15:00:07 <pili> we may only have one more meeting on this sponsor after this one 15:00:12 <pili> let's see how things go anyway :) 15:00:18 <sysrqb> :O 15:00:31 <antonela> hello 15:00:36 <sysrqb> bitter-sweet 15:00:43 <antonela> :) 15:00:47 <asn> pili: we can finally 100% OBv3 deliverable 15:00:56 <asn> now that the blog post has been published 15:00:57 <antonela> sysrqb: like pineapple pizza 15:01:00 <asn> let me close the ticket 15:01:11 <sysrqb> antonela: lol :) 15:01:18 <asn> ah it's already closed :) 15:01:20 <pili> yup! :) 15:01:21 * pili goes to add some updates 15:01:22 <pili> asn: I may have done it already 15:01:23 <pili> yup 15:04:28 <dgoulet> o/ 15:04:38 <sysrqb> hola 15:07:19 <pili> I'll give a few more minutes for updates and then we can start 15:09:08 * antonela is done 15:09:20 <pili> ok, let's start 15:09:21 <pili> first item is about the meeting time 15:09:59 <pili> is everyone ok with 15UTC still? for those of us in Europe it will mean this meeting is one hour later 15:10:13 <antonela> works for me 15:10:19 <asn> ok 15:10:21 <pili> I guess the US has already adapted ;) 15:10:56 <acat> ok for me too 15:11:20 <pili> ok, great 15:11:21 <pili> so we'll keep it at 15UTC 15:11:22 <pili> let's quickly review where we are also :) 15:11:26 <pili> we have about a week left on this sponsor 15:11:27 <asn> hm. what is the human memorable onion address document to define scope? 15:11:42 <pili> asn: I will put together all conversations I've seen on this 15:11:56 <antonela> we should have a doc that defines what we need to ship HTTPS-E in stable 15:11:59 <pili> and try to map out the different alternatives we have 15:12:09 <pili> with antonela and anyone else's help 15:12:26 <asn> what kind of alternatives are we talkin about? 15:12:28 <syverson_> I would like to be in on that (or at least kept informed). 15:12:29 <antonela> i dont think we should aim to map out all the alternatives we have 15:12:40 <antonela> right 15:12:49 <pili> I can be prescriptive also ;) 15:12:54 <asn> wrt https-e? or human memorable in general? 15:13:20 <pili> well, things like, can anyone provide update channels? 15:13:37 <pili> how do entities register names? who with? 15:13:52 <syverson_> asn: it would be good if whatever is done for https-e is compatible with things that follow. 15:13:55 <pili> who are the stakeholders even? 15:14:04 <asn> so we are only talking about https-e right? 15:14:11 <pili> asn: yup 15:14:14 <asn> not all the alternatives of human memorable approaches 15:14:19 <asn> ok that makes sense and sounds more plausible 15:14:22 <pili> nono 15:14:37 <asn> ok sounds good 15:14:41 <asn> im also interested in this 15:15:20 <pili> yup, I might share the first draft with this group, or tor-internal 15:15:21 <pili> and see what feedback we get 15:15:28 <pili> any other questions/comments/suggestions on this? :) 15:15:31 <asn> great 15:15:34 <asn> im good 15:15:44 <pili> syverson_: noted :) 15:15:44 <antonela> maybe this group, then internal 15:15:53 <antonela> *first 15:16:00 <pili> yup 15:16:06 <syverson_> +1 15:16:32 <pili> ok, let's move on to review status then 15:16:41 <pili> I believe we are done with objective 1 \o/ 15:16:45 <asn> yeah! 15:16:49 <antonela> \o/ 15:17:20 <pili> and O2A1: Integrating client-side authorization to onion services v3 15:17:21 <pili> is also done 15:17:30 <pili> how is O2A2 going? :) 15:17:33 <asn> lovely 15:17:42 <asn> should we close #30000 15:17:43 <asn> ? 15:17:55 <pili> good point, let me see 15:18:23 <pili> yes 15:18:39 <mcs> O2A2 is just #23545 now, and that fix is in review as part of #19251 15:18:54 <mcs> so.. soon it will be 100% complete 15:19:03 <mcs> (we need to ship though) 15:19:11 <antonela> mcs: i can wait for the nightly, could you ping me when it reaches the build? 15:19:20 <pili> yay :) 15:19:21 <pili> great 15:19:22 <pili> does soon == by the end of next week? :D 15:19:22 <mcs> antonela: will do 15:19:27 <pili> mcs: it's fine if it's not shipped 15:19:32 <antonela> mcs: awesome, thanks 15:19:36 <pili> that will come soon enough :) 15:20:16 <mcs> If acat has time for a final review of #19251 and if sysrqb merges it, then we are done (plus antonela review) 15:20:23 <mcs> just a few things :) 15:20:30 <acat> mcs: sure, will do 15:20:32 <pili> :) 15:20:33 <mcs> thx 15:21:20 <pili> cool, shall we move on to O2A3: Notify users if a current website they are visiting on Tor Browser has an onion service version ? 15:21:26 <pili> #30024 15:21:44 <pili> I guess the main ticket here is still #21952 15:22:16 <mcs> brade and I will review acat’s latest patch today or tomorrow 15:22:20 <antonela> i ran a review on it, acat wrote documentation 15:22:32 <pili> nice 15:22:39 <antonela> we will need some announcement around this 15:22:50 <antonela> who can do it, why is good, devs docs 15:23:09 <antonela> and reply to alt-svc fans 15:23:16 <antonela> who also are contemplated in all this scheme 15:23:20 <pili> acat: antonela can the documentation be used for tor browser manual or support? 15:23:21 <pili> antonela: great, that's one for the onion services section in community portal 15:23:44 <pili> if someone shares the docs with me I can maybe put something together as part of the docshackathon this week 15:24:10 <antonela> re docs, maybe? i see it as a ref doc, we will need simple wording in user facing docs 15:24:38 <antonela> this one is the latest? https://github.com/acatarineu/torspec/blob/21952/proposals/ideas/onion-location.txt 15:24:42 <acat> pili: not sure if directly, it's a spec, but maybe someone can use to write the docs 15:24:43 <sysrqb> i guess we need two different docs? right? 15:24:43 <pili> yup, we can use that to write the user facing docs 15:24:46 <pili> yup 15:24:59 <sysrqb> one for "what a user should do when they see this" and, what is this, anyway?" 15:25:06 <antonela> yep 15:25:13 <sysrqb> and how a webdeveloper or website operator should use this 15:25:20 <pili> yup 15:25:22 <antonela> pili: i added it in discussion, but this patch needs comms review for the content string 15:25:30 <antonela> pili: could you coordinate that effort? 15:25:46 <pili> yup, I saw your comment on the ticket this morning 15:25:54 <pili> will do 15:25:57 <antonela> super, thanks 15:26:31 <acat> anto: this one is: https://github.com/acatarineu/torspec/blob/21952+1/proposals/ideas/onion-location.txt 15:26:42 <antonela> oops, there you are 15:27:19 <pili> ok 15:27:31 <pili> then we still have #27502 15:27:35 <pili> in needs_info 15:27:49 <pili> I'm tempted to just close it as out of scope/no longer relevant 15:27:52 <pili> sysrqb: what do you think? 15:28:04 <pili> or does anyone else have any insights on this one? 15:28:48 <pili> I already closed #30599 last week as we had no more details from anyone 15:29:09 <sysrqb> pili: yeah, i think we should close #27502 15:30:15 <sysrqb> for two reasons. 1) firefox's current implementation makes a change like this a little tricky 15:30:40 <sysrqb> but, 2) tor browser shouldn't make arbitrary prioritization decisions about alt-svc 15:30:49 <pili> those reasons help, thank you :) 15:31:11 <sysrqb> if a website operators wants their .onion to be preferred, then they can tell the browser that by only including a .onion 15:31:17 <sysrqb> or putting the .onin address first in the list 15:31:20 <pili> do you mind if I copy and past them into the ticket? :) 15:31:21 <pili> I can "anonymize" you also ;) 15:31:22 <pili> yup 15:31:23 <pili> ok 15:31:36 <sysrqb> you can copy/paste :) 15:31:41 <pili> we should also add this to the dev/implementation docs in the communitty portal onion services section 15:31:41 <sysrqb> or i can do this after the meting, too 15:31:44 <antonela> lol "some cypherpunk said" 15:31:55 <sysrqb> (no real reason for you to do it) 15:32:00 <sysrqb> antonela: :) 15:32:08 <pili> :D 15:32:12 <antonela> and "we proceeded" lol 15:32:43 * pili cheks what else we have for O2A3 15:33:04 <antonela> man we are good a week before the 27 world ends 15:34:32 * sysrqb is happy 15:34:33 <pili> antonela: I guess we are also dropping #27590 ? 15:34:57 <antonela> i still have a coin for the witcher pospeselr on that one 15:35:10 <antonela> :) 15:35:21 <pili> since it was related to #30599 which is now closed as wontfix 15:35:22 <pili> ok 15:35:23 <pili> let's leave it 15:35:34 <pili> I don't think it will be done before the end of march, and that's ok :) 15:35:44 <antonela> oh wait, i was confused i thought it was the icon one 15:35:56 * antonela checking 15:36:45 <pili> it's about whether we display that the connection was made via alt-svc in circuit display 15:36:50 <syverson_> Does this mean there is nothing open to let a user know if they are connected to an alt-svc .onion versus over and exit to ordinary domain? 15:37:04 <syverson_> over an exit 15:37:18 <antonela> seems like that is one case syverson_ 15:37:44 <syverson_> one case? 15:38:15 <sysrqb> pili: i think we should implement #27590, and use follow the https-e .tor.onion naming UI 15:38:46 <sysrqb> where the circuit display shows the .onion address while the url bar shows the human memorable/meaningful name 15:38:50 <pili> ok 15:38:54 <antonela> syverson_: yes, i think we got a discussion around what to show in the circuit display if we are rendering a service with multiple calls to onions eg, subresources 15:39:05 <sysrqb> but i don't see this being implemented in the next week 15:39:21 <pili> what would it take for us to do this: who and how long? :) 15:39:22 <pili> no 15:39:26 <antonela> sysrqb: yes, that is the ideal path to take 15:39:38 <pili> the question is also, do we want to work on it now, beyond the end of march or park it until after Fenix 15:39:44 <sysrqb> i would like acat's opinion on this :) 15:39:45 <syverson_> sysrqb: understood. I was just wondering if there were any related tickets that will remain open after this. 15:40:24 <sysrqb> syverson_: understood. and, yes, i think this is an important UX feature 15:40:41 <sysrqb> (and security feature) 15:40:45 <pili> syverson_: well, we will keep #27590 open 15:41:01 <acat> sysrqb: i think it made sense, here we would have to change the circuit display instead of the urlbar, compared to what we did in #28005 15:41:05 <acat> *makes 15:41:20 <pili> and hopefully work on it sooner rather than later :) 15:41:22 <syverson_> pili: thanks for reminder. 15:41:31 <antonela> https://trac.torproject.org/projects/tor/raw-attachment/ticket/30024/prompt-onion-1.gif 15:41:43 <sysrqb> acat: yeah 15:41:54 <pili> and I think that's all that there is to finish up/close off for O2A3 15:42:07 <antonela> so basically, the user types the regular domain, got "transparent" redirected, the onion icon appears in the url bar and the circuit display gets updated 15:42:15 <antonela> am i missing anything? 15:42:36 * antonela yes, sub resourced onions in special services 15:42:37 <pili> any other comments on this activity? shall we move on to O2A4: Errors (#30025) ? 15:43:20 <pili> I'll wait for antonela to get her answer... 15:43:47 <sysrqb> antonela: yes, that is what i was imagining :) 15:43:47 <antonela> we can continue in the ticket, is fine 15:43:52 <antonela> cool 15:44:16 * antonela here is the preview https://trac.torproject.org/projects/tor/attachment/ticket/30024/prompt-onion-1.gif 15:44:33 <pili> ok 15:44:39 <pili> let's move on to O2A4 then 15:45:36 <pili> I'm going to ignored all the certificate issues for now, i think we have already agreed we will work on this outside this sponsor, possibly after Fenix and I'm planning an email about that 15:46:10 <mcs> do you want to close #33035? 15:46:16 <pili> we already mentioned we're almost there with #19251 15:46:20 <pili> mcs: yup, thanks! 15:47:24 <pili> there is still an outstanding question about when to offer a "Try Again" button though 15:48:05 <pili> my opinion is that for 0xF6 it does not make sense to offer one 15:48:17 <pili> (typo) ^ 15:48:20 <mcs> the current implementation is to offer a Try Again button in all cases except 0xF6 15:48:43 <pili> ok 15:48:46 <mcs> which means it is up to the user to decide if retrying will help 15:48:55 <mcs> this seems OK for now 15:49:02 <antonela> an infinite loop is not fun, so seems OK 15:49:02 <antonela> yes 15:49:20 <pili> mcs:+1 15:49:21 <pili> ok 15:49:22 <pili> I will close 15:49:41 * antonela just closed #25025 15:50:48 <pili> antonela: was #27657 the ticket you were thinking about earlier? 15:51:00 <antonela> yes that one 15:51:20 <pili> ok 15:51:58 <pili> #26491 we have a decision on, so I think nothing to do for now 15:54:17 <pili> and I think the others (#13410 #27636 #30937) are certificate related and we will deal with as part of the SOOC work? 15:54:24 <pili> or doe some fall outside this scope? 15:55:11 <sysrqb> i think those fall under SOOC 15:55:54 <pili> ok, I think O2A4 is more or less under control then 15:56:02 <pili> we have 3 minutes for O2A5 :D 15:56:18 <pili> acat: any updates? I guess we're in the last few review/revise iterations? :) 15:57:02 <acat> yes, i was going to ask whether we should contact jenn regarding the www. prefix in securedrop rulesets 15:57:31 <acat> i think we mentioned that in previous meetings, an mcs also reminded me about it in the last review 15:57:55 <acat> so that for some sites, it's www.nytimes.com.securedrop.tor.onion 15:58:19 * antonela tested O2A5, works smoothly 15:58:38 <acat> instead of just nytimes.com.securedrop.tor.onion 15:58:58 <syverson_> acat: other than ruleset size, why can't there just be both rules in a ruleset? 15:59:21 <pili> acat: is this a blocker for getting something out 15:59:46 <syverson_> so whicheverr user types/links-from will work. 16:00:23 <acat> syverson: i think we could have both, one issue is that then for doing reverse lookup we would have more than one option (with www. and without) 16:00:48 <pili> (we're at the hour) :) 16:00:53 <acat> and actually the current implementation assumes it's one to one mapping 16:00:57 <syverson_> acat: can maybe discuss offline so you can answer pili. 16:01:20 <pili> acat: hmm, ok :) 16:01:24 <pili> acat: yes, please contact jenn to see what she thinks in any case 16:01:32 <pili> I will end the meeting here for now 16:01:33 <acat> pili: no, it's not a blocker, more about usability 16:01:41 <sysrqb> we should ask jen, securedrop may have a rationale for why some have www 16:01:48 <pili> and we can move discussion to #tor-dev or the ticket :) 16:01:50 <sysrqb> ^ yep 16:02:16 <asn> i think perhaps we can let them do whatever they want 16:02:21 <asn> if they like www let them have it 16:02:24 <pili> great work everyone, one final push and we'll have some very cool new features very soon! :D 16:02:29 <asn> ye +1 16:02:32 <asn> that's gonna be super exciting 16:02:33 <sysrqb> +1 16:02:40 <asn> and a huge refreshment for onion services 16:03:01 <acat> +1 16:03:07 <mcs> +1 to letting Securedrop decide how to handle their mappings 16:03:22 <pili> ok 16:03:27 <pili> let's end the meeting then 16:03:30 <pili> thanks everyone! :) 16:03:33 <pili> #endmeeting