15:00:39 <pili> #startmeeting S27 03/17
15:00:39 <MeetBot> Meeting started Tue Mar 17 15:00:39 2020 UTC.  The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:39 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:41 <pili> better
15:00:50 <mcs> hi
15:00:58 <antonela> o/
15:01:12 <syverson_> o/
15:01:29 <pili> welcome the ☘️ (St Patrick's) edition of this meeting
15:01:35 <pili> please add your updates in the pad: https://pad.riseup.net/p/s27-meeting-keep
15:04:52 <pili> I think we'll be missing asn and dgoulet today as they're preparing for a marathon online session themselves :)
15:06:13 <pili> ok, let's get started
15:06:23 <pili> I hope everyone is doing well and looking after themselves :)
15:06:42 <pili> I wanted to do our usual progress review
15:07:29 <pili> we can start from the end with O2A5 and HTTPSEverywhere for long onion names
15:07:30 <pili> acat: is #28005 ready for a second review?
15:08:20 <acat> i think can still revise it to include the change so that the bookmarks are done with .tor.onion instead of .onion
15:08:23 <acat> *should
15:08:51 <mcs> do we need to talk about that issue? I think storing .tor.onion in a bookmark makes sense
15:08:52 <acat> and the other suggested change related to the circuit display
15:09:20 <antonela> mcs: +1
15:09:29 <pili> mcs: sure, we can discuss this now
15:09:39 <acat> yes, i think it does, i guess there are little downsides
15:09:45 <pili> unless everyone is already in agreement ;)
15:09:59 <acat> only that it might be difficult for a user to store the real .onion, in case they wanted
15:10:21 <acat> but i'm not sure i see why they would want to do that, since the .tor.onion is probably more stable than the .onion
15:10:22 <antonela> acat: right
15:11:40 <syverson_> Don't know that I think that would be a good thing (relative stability) but perhaps a topic for another time.
15:11:43 <acat> the other change, if i understand it correctly, is to show the full .onion address on hover in the circuit display, right?
15:12:36 <antonela> i'd go with saving the memorable option, if advanced users want to save the origin onion address we can think about to add a field in bookmarks
15:12:54 <pili> actually, this has probably been discussed already and I missed it, but what happens when the .onion addressed by a .tor.onion has to change? how are updates pushed to .tor.onion?
15:12:57 <antonela> i like what mcs and brade suggested, a regular hover makes sense
15:13:19 <sysrqb> if someone wants to save a bookmark using the .onion adres, then they can go to the website using the .onion address and create a bookmark
15:13:24 <sysrqb> *address
15:13:40 <acat> sysrqb: for now yes, but i think the plan is to also rewrite those to .tor.onion in the future, right?
15:14:17 <sysrqb> acat: i think that is an option, but I would want a way of disabling that
15:14:31 <sysrqb> maybe in about:preferences
15:14:33 <acat> ok, makes sense
15:14:48 <acat> pili: the updates would be pushed via the securedrop update channel
15:14:56 <pili> ok
15:15:31 <pili> cool
15:15:47 <pili> acat: are you good with how to proceed?
15:15:59 <syverson_> This is fine short-term, but it changes thinking of the onion address as the primary identity.
15:16:01 <acat> yes
15:16:34 <syverson_> versus the familiar address as just a nickname.
15:16:45 <antonela> yep
15:18:08 <sysrqb> right, there is a trade-off here
15:18:33 <sysrqb> and i think it is helpful creating a proof-of-concept implementation that maps recognizable names to .onion address
15:18:37 <sysrqb> in the short term
15:18:59 <sysrqb> and hides the complexity of using a 50+ character address
15:19:15 <syverson_> sysrqb: definitely, I was responding to why anyone would want to bookmark the .onion address
15:19:32 <sysrqb> ah, i see
15:20:35 <sysrqb> we could think about adding another field into the bookmark entry
15:20:58 <syverson_> bookmark alt names? ;>)
15:21:01 <sysrqb> but then we need to think about what we do with that .onion address
15:21:23 <sysrqb> do we use it instead of the https-e rule (if it exists)?
15:21:30 <sysrqb> how do we resolve conflicts?
15:22:18 <sysrqb> maybe local rulesets (as bookmarks) have higher priority over https-e rulesets?
15:22:37 <syverson_> In general, which applies first? bookmarks or H-E extension?
15:22:42 <sysrqb> this seems like a good discussion we should have as this idea evolves
15:23:01 <syverson_> sysrqb: talk to you about it tomorrow.
15:23:09 <sysrqb> i don't think the current implementation takes bookmarks into account
15:23:32 <pili> also, should it? :)
15:23:34 <sysrqb> acat: correct? the .tor.onion -> .onion mapping doesn't look at bookmarks
15:23:42 <acat> sysrqb: correct
15:23:54 <sysrqb> i think it should not right now
15:24:06 * antonela adds this item to her local pad for making onion names in stable
15:24:08 <sysrqb> due to our current constrains
15:24:17 <sysrqb> *constraints
15:25:19 <sysrqb> i worry this will result in some problems with existing petname schemes
15:25:29 <sysrqb> because names may not be globally unique
15:25:54 <sysrqb> but we can think about this more when we have more funding for it
15:26:03 <sysrqb> or if we decide to prioritize this without a new funder
15:26:14 <mcs> does “i think it should not right now” mean bookmarks should contain the real .onion address?
15:26:17 <syverson_> Are there current important or wide uses of petnames that need to be taken into account?
15:26:56 <sysrqb> mcs: sorry, i mean that as a reply to pili about whether the mapping should take bookmarks into account
15:27:06 <sysrqb> mcs: and my thought being that it shouldn't right now
15:27:29 <pili> yup
15:27:33 <sysrqb> syverson_: not that i know of
15:28:00 <syverson_> I don't think it should. Put differently, bookmark preferences should not be "overwritten" by H-E rules, at least till we understand better.
15:28:06 <sysrqb> by "existing" i meant "proposed"
15:28:43 <syverson_> Good to maintain flexibility if cost is not high.
15:28:47 <pili> I think we just need to create a minimum viable product for now, this discussion is really good to explore next steps
15:28:58 <sysrqb> yep
15:28:58 <syverson_> D'accord.
15:29:07 <antonela> yes
15:29:29 <pili> I just want to make sure that acat knows what he needs to do next to provide this :)
15:29:34 <pili> loving all the discussions on this sponsor work <3
15:29:43 <acat> pili: i think i do
15:30:01 <pili> great, will you give us a summary so we're all on the same page? :D
15:31:51 <acat> revise the patch so that the .tor.onion URL is bookmarked instead of .onion, and show the full .onion URL in circuit display on hover
15:32:39 <pili> got it
15:33:29 <pili> shall we move on to O2A4: Errors - #30025
15:34:09 <pili> #19251 - are we still waiting on reviews for this>
15:34:11 <pili> ?
15:34:30 <pili> or are we at final revisions? :)
15:34:32 <mcs> we need one more review
15:34:46 <mcs> and some small revisions so far
15:35:02 <mcs> hopefully pospeselr can review soon
15:35:30 <pospeselr> i'll prioritie that for today
15:35:35 <mcs> there is also a question about whether we need to support markup (HTML) within the long description
15:35:47 <mcs> We are not using it so we could drop support for it
15:36:14 <pili> hmm
15:36:18 <mcs> context: https://trac.torproject.org/projects/tor/ticket/19251#comment:40
15:36:22 <mcs> and comment:41
15:36:23 <pili> you mean the long description of the error?
15:36:29 * pili goes to read
15:36:44 <brade> It's nice to have the possibility of html markup in there
15:37:14 <mcs> yes, the long description is the string that is displayed in the bottom part of the error page. we have Details: 0xF0 … there now
15:38:06 <pili> hmm, I don't really have an opinion, I always like to keep things flexible but maybe less is more in this case...
15:38:06 <sysrqb> i don't have a strong opinion on this
15:38:11 <pili> antonela: any ideas?
15:38:23 <antonela> how hard is rely on html there? i feel html is where all the secured pages layout are going
15:38:43 <sysrqb> we could keep it simple for now, and use acat's suggestion
15:38:57 <sysrqb> and then update the code if we ever need to inject html in the future
15:39:02 <antonela> yep, that too
15:39:20 <sysrqb> but, maybe following mozilla is a safer plan, too
15:39:41 <brade> I feel more comfortable being compatible with what Mozilla is doing (html)
15:40:00 <antonela> brade: +1
15:40:14 <brade> (the line of code in question was copy-pasted from Mozilla code)
15:40:18 <sysrqb> and we don't need to worry about mixing html strings with text and different implmenetation deetails
15:40:24 <sysrqb> *details
15:40:38 <sysrqb> okay, that's fine with me
15:40:56 <pili> so let's go ahead with html then
15:42:02 <mcs> I will add a comment to the ticket
15:42:08 <pili> thanks mcs, anything else on #19251?
15:43:25 <mcs> I don’t think so
15:43:29 <pili> #13410 we discussed last week
15:43:30 * pili goes to double check what we decided
15:44:13 <pospeselr> i've reached out to alec about what we can do to get the SOOC proposal finished, but haven' theard back
15:44:32 <pospeselr> in the meantime i've been focused on the firefox release notes/patch reviews
15:44:35 <pili> cool, ( I just reached that conclusion myself)
15:44:43 <pili> pospeselr: sounds reasonable :)
15:46:07 <pili> and #33298 is dependent on the outcome of #13410  ?
15:46:47 <pospeselr> hmm no not dependent, was just lower priority
15:46:59 <pili> ok :)
15:47:29 <pili> maybe it was #27636 that was dependent... :/
15:47:30 <pili> I get lost with these slightly similar yet different tickets
15:48:39 <pospeselr> ah yeah #27236 will just work once #13410/SOOC is properly implemented
15:48:59 <sysrqb> not that one :)
15:49:07 <pospeselr> #27636
15:49:15 <pospeselr> so hard to type numbers w/o a numpad :p
15:49:20 <antonela> lol
15:49:29 <pili> cool :)
15:49:31 <pili> ok, anything else on O2A4? :) shall we move on?
15:49:49 <antonela> should we remove childs from that ticket?
15:50:06 <pili> #33298 is definitely lower priority since we created it once the project started iirc
15:50:22 <pili> antonela: hmm, maybe the S27-can ones
15:50:31 <antonela> rephrasing: what do we expect to close when we call O2A4 done?
15:50:36 <pili> it would be good to do some clean up though
15:51:31 <pili> I don't think we will close #13410 and I would like to include that in O2A4... :/
15:51:37 <pili> #19251 for sure
15:51:56 <pili> #32542
15:52:07 <pili> need to ping dgoulet on this one ^
15:52:17 <pili> #32645 which is done
15:52:39 <antonela> i have a special interest in #27657 - with this one we consolidate the circuit display and url bar UI
15:52:45 <pili> and the documentation: #33517 and #33518
15:53:29 <pili> #27657 would be really nice to have :)
15:53:46 <pili> we should estimate it and see if we can squeeze it in
15:54:03 <antonela> super
15:55:29 <pili> anyone got any ideas on how many days/points that would be?
15:56:31 <sysrqb> i assume it'll take at least 6 days
15:56:31 <pili> before we run out of time... :)
15:56:44 <pili> wow, no chance of squeezing that in then :)
15:56:51 <sysrqb> acat or pospeselr can probably implement it relatively quickly
15:57:11 <sysrqb> but maybe there are weird edge cases
15:57:21 * pospeselr reads ticket
15:57:27 <brade> I'm not sure we should rush it in if it will need localization
15:57:30 <pili> sure
15:58:01 <sysrqb> brade: yes, i agree with that
15:58:44 <antonela> what exactly needs l10n?
15:58:57 <antonela> "Tor connection"
15:59:47 <sysrqb> that is a simple change, and we can change that this week
15:59:53 <sysrqb> if we decide that is important
16:00:01 <pospeselr> yeah the icon swap would be easy
16:00:09 <pili> can we start with that for now?
16:00:24 <pospeselr> the contextual strings a bit of effort but easy
16:00:26 <sysrqb> antonela: like, i don't see a big problem with changing "Tor Circuit" with "Tor Connection" now
16:00:55 <antonela> i feel is more human friendly? but im happy to discuss it in the ticket
16:01:23 <sysrqb> that's fine with me
16:01:32 <antonela> nice
16:01:41 <pili> ok, let's move discussion to the ticket and wrap this up
16:01:47 <pili> great work everyone :)
16:01:52 <pili> and thank you for your time
16:01:55 <pili> #endmeeting