19:00:16 <GeKo> #startmeeting network health
19:00:16 <MeetBot> Meeting started Mon Mar  9 19:00:16 2020 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:22 <GeKo> okay, hello everyone
19:00:28 <GeKo> it's network health meeting time
19:01:13 <GeKo> so, let's see what we have on our agenda
19:01:16 <dgoulet> o/
19:01:28 <GeKo> the pad is over at https://pad.riseup.net/p/tor-networkhealth-2020.1-keep
19:01:30 <GeKo> as usual
19:01:41 <dennis_jackson> o/
19:01:43 <gaba> o/
19:01:52 <GeKo> if anyone worked on stuff in network health land, please update the pad so we are all up-to-date
19:01:58 <GeKo> and mark items to discuss in bold
19:02:06 * gaba is half here
19:02:17 <juga> o/
19:03:25 <GeKo> okay. it seems we don't have much on our plate
19:03:28 <GeKo> good :)
19:03:43 <GeKo> i have one of my items in bold
19:04:01 <GeKo> just in case folks have an opinion and want to add things
19:04:24 <GeKo> ggus and i are coordinating the tor legal faq update with the eff
19:04:29 <GeKo> or we plan to do so at least
19:04:47 <GeKo> the current text and questions are on https://pad.riseup.net/redirect#https%3A//community.torproject.org/relay/community-resources/eff-tor-legal-faq/
19:04:52 <GeKo> arg
19:05:02 <GeKo> https://community.torproject.org/relay/community-resources/eff-tor-legal-faq
19:05:27 <GeKo> and the community team looked into newer questions and issues
19:05:32 <GeKo> that could be worth getting added
19:05:47 <GeKo> the results are documented at https://pad.riseup.net/p/tor-legal-questions-keep
19:06:25 <GeKo> so i sat down last week and drafted a mail to the eff people to talk with them together about
19:06:30 <GeKo> new additions and possible changes
19:06:59 <GeKo> if any of you have changes to that mail draft, which is on https://pad.riseup.net/p/A1CmR28t3V8XAhT-qIaf, please add them to the pad
19:07:23 <GeKo> my plan is to clean this up tomorrow/maybe on wed and then get the conversation going
19:07:32 <GeKo> (with eff lawyers)
19:07:43 <GeKo> okay
19:08:02 <GeKo> in case there are no questions about that
19:08:27 <GeKo> are there any other status related things we should discuss here?
19:09:15 <GeKo> let's move on to discussion then
19:09:51 <GeKo> #32672 is the first one
19:10:26 <GeKo> last week i looked at the result of our email campaign for contacting relay operators
19:10:44 <GeKo> to the ticket; i think it went not bad
19:10:59 <GeKo> so, now the question is how to move forward
19:11:23 <dennis_jackson> Do you have a rough estimate of the response rate?
19:11:36 <GeKo> it seems phw is picking up contacting the bridge operators, so that's good
19:11:42 <dennis_jackson> I feel like I saw a fair few explicit ACKs which was nice, did others also update without replying?
19:11:56 <GeKo> yes
19:12:06 <GeKo> i have not looked at the details yet
19:12:27 <GeKo> but there were definitely a bunch of people that updated without responding
19:12:59 <dennis_jackson> Great! Quantifying that would be really useful for any decision about whether to enforce contact info being set (I think arma was musing about it)
19:13:08 <GeKo> i mean that all affects only relay operators that have some form of valid contactinfo, but, hey, that's cool
19:13:23 <GeKo> yes
19:13:26 <GeKo> maybe
19:13:39 <arma2> i don't currently think that enforcing contactinfo to be set, while letting it be set to anything at all, is a good choice
19:16:06 <dennis_jackson> I guess there's a huge space of possible design decisions - e.g. whether to check the email is valid - whether a email should be pubic or viewable to Tor only. I don't have an opinion, just noting the value of the data if it is something that is being considered.
19:16:27 <arma2> yep
19:16:31 <GeKo> yeah
19:17:12 <arma2> i even talked at one point about having a web registration thing, where they put a nonce in their contactinfo and then they have a secret contact address registered with us. so many choices! none of which are great!
19:17:29 <GeKo> so for setting a final deadline, i.e. for when asking the network team to merge
19:17:41 <GeKo> i'd wait for phw doing his things this week
19:18:01 <GeKo> and think we could decide next week when this should ideally get merged
19:18:18 <GeKo> and what steps we want to do when this is done/has some date attached to it
19:18:31 <GeKo> e.g. ggus said doing some twitter thing could be useful
19:18:43 <GeKo> but there are a bunch of folks out there that only operate with deadlines
19:18:57 <GeKo> that is for some reason they need that pressure to act
19:19:14 <GeKo> i am fine with that :)
19:19:25 <GeKo> but we could include that into our consideration for next steps
19:19:27 <arma2> this is the "bump out old versions" code? even if it gets merged today, it won't get run by a majority of dir auths for...some months
19:19:34 <GeKo> yep
19:19:36 <GeKo> and yep
19:19:46 <GeKo> but there are possible backports and such
19:19:53 <GeKo> so we might get it earlier
19:19:58 <arma2> true
19:20:18 <dennis_jackson> Oh, that's interesting to know! (about the delay between different dir auths)
19:20:39 <GeKo> well, and that :=
19:20:45 <GeKo> :)
19:20:58 <GeKo> some might even just patch their tor, who knows
19:21:19 <GeKo> but communicating a deadline seems important
19:21:31 <dennis_jackson> +1
19:21:31 <GeKo> so we should think next week about it, hopefully ggus can attend then
19:21:37 <GeKo> sounds reasonable?
19:22:31 <GeKo> no objections, great
19:22:42 <GeKo> so the other item on the list
19:22:56 <GeKo> i heard daylight saving time is a thing
19:23:12 <GeKo> so, we should think about adapting our meeting time i guess
19:23:32 <GeKo> now, that's probably a good topic for a proper bikeshed
19:23:53 <GeKo> so let me start by suggesting a model that worked for a lot of teams in the past:
19:24:19 <GeKo> we keep the current utc time until the europreans switch, too
19:24:28 <GeKo> which is in rougly three weeks
19:24:51 <GeKo> and *then* we move the meeting to 1800utc to get back to our used local time
19:24:57 <GeKo> does that make sense?
19:25:37 <GeKo> any other suggestions?
19:25:56 <gaba> yes, that works for me
19:26:06 <dennis_jackson> It makes no difference to me in terms of actual time, but I would vote for whatever minimises conflicts with other meetings
19:26:54 <GeKo> :)
19:27:16 <GeKo> alright, let's stick to the plan i outlined above
19:27:26 <GeKo> if there are no objections
19:27:52 <GeKo> we can revisit that if there are suddenly unexpected conflicts popping up and change our mind
19:28:20 <GeKo> anything else we should discuss today? anything anyone needs help with?
19:28:58 <dennis_jackson> I have a minor question
19:29:10 <GeKo> go for it
19:29:12 <dennis_jackson> I think I see you post weekly in IRC about a dir auth update with some names?
19:29:27 <GeKo> yep
19:29:30 <dennis_jackson> Can I ask what exactly that is or what it involves or why it is coordinated through IRC?
19:29:38 <GeKo> sure
19:29:52 <GeKo> we are actively trying to find bad relays on the network
19:30:03 <GeKo> there are different scanners for that
19:30:07 <GeKo> sometimes they find stuff
19:30:20 <GeKo> and then the bad relays team is looking at the results
19:30:31 <GeKo> and is removing relays from the network
19:30:49 <GeKo> there is a private repo containing the rejected fingerprints
19:30:52 <GeKo> and ip addresses
19:31:02 <GeKo> that gets updated with new entries in those cases
19:31:20 <GeKo> now, in order for that to take effect the dir auths need to update there config
19:31:28 <GeKo> to take those new entries into account
19:31:40 <dennis_jackson> Okay, I see, so this tells the operators to do a git pull / deploy or whatever?
19:31:52 <GeKo> there are some dirauth operators that prefer a ping, say, on irc when new entries show up
19:31:55 <GeKo> yes
19:32:16 <dennis_jackson> Okay, thanks for explaining! That's super interesting. Just to confirm: Bad means malicious in this case?
19:32:21 <GeKo> i mean should see see this already as our internal channel gets a ping when the repo gets updated
19:32:29 <dennis_jackson> Rather than broken / mis configured
19:32:35 <GeKo> and they should get a mail to the dir-auth mailing list
19:32:43 <GeKo> but some still like to get a ping
19:32:56 <GeKo> it could be both
19:33:21 <GeKo> e.g. i'll probably start  kicking out exits soon that don't fix their dns
19:33:25 <GeKo> see #32864
19:33:34 <dennis_jackson> Yep :)
19:33:50 <dennis_jackson> Do the relays get told why they are now rejected? Or does it appear as a silent drop?
19:34:02 <dennis_jackson> Is there some public policy or eventual listing?
19:34:16 <dennis_jackson> I can understand why some exit scanning tools would obviously be better private ofc
19:34:29 <GeKo> they see an entry in their tor logs explaining they should contact the bad-relays list for further info
19:34:53 <GeKo> and we usually talk to them there about the reasons, potential false positives, fixing their stuff etc.
19:35:24 <GeKo> what do you mean with "public policy or eventual listing"?
19:36:10 <GeKo> we don't have a good policy written yet for when we reject relays
19:36:12 <dennis_jackson> Is the decision making process for who is a bad relay public? Private? Not codified?
19:36:19 <dennis_jackson> Ah okay, the last then.
19:36:24 <GeKo> that's one of the todo items
19:36:39 <GeKo> it's private
19:36:43 <dennis_jackson> And then - with the private github repo list of rejections. Do they eventually get published somewhere?
19:36:50 <GeKo> we have a private mailing list, bad-relays
19:36:53 <arma2> dennis_jackson: for rationale (or justification if you prefer) of keeping them sekrit, see these two links:
19:36:55 <arma2> https://gitweb.torproject.org/community/policies.git/tree/social_contract.txt#n54
19:36:58 * arma2 goes to hunt for the other link
19:37:29 <GeKo> it's not really codified either even though folks have thought quite a bit about it and keep doing so
19:37:36 <dennis_jackson> Yeah I totally see the argument for keeping it private! I just wanted to check
19:37:49 <GeKo> they are not getting published yet
19:37:58 <dennis_jackson> ahf was looking at relay churn a few weekends back
19:38:13 <dennis_jackson> And it looked surprisingly high to me, so I wonder if bad relays could be the reason
19:38:29 <dennis_jackson> I did not actually know this process existed so I am glad I asked about the dir auth update thing now
19:38:43 <GeKo> i doubt that bad relays would account for that
19:38:55 <GeKo> it's maybe a handful over a week
19:39:06 <dennis_jackson> ah okay, probably not then
19:39:09 <arma2> https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html is my other link
19:39:29 <GeKo> dennis_jackson: yeah, glad you asked, keep doing that ;)
19:39:56 <GeKo> (in particular as the meeting is public and "recorded", so folks can at least read about where we are now with those sekrit things)
19:40:08 <arma2> geko: we had a thought, long ago, of publishing everything with a 12 month lag
19:40:12 <dennis_jackson> Thanks arma, just skimmed it and yeah it makes sense to me as a policy :)
19:40:23 <arma2> since that seems like a good balance between transparent and effective
19:40:32 <dennis_jackson> Thanks Geko - super helpful to me  :)
19:40:38 <dgoulet> arma2: in theory I did that for couple years ... but failed to do so
19:40:42 <dgoulet> last years*
19:40:43 <GeKo> arma2: i am a fan
19:41:11 <GeKo> or did there speak anything against it that i am not aware of?
19:41:15 <dgoulet> all previous bad relays are public up until 2018-ish I believe
19:41:30 <dgoulet> GeKo: not sure I can parse your sentence
19:41:45 <arma2> dgoulet: "are there any reasons not to"
19:41:53 <GeKo> yep, thanks :)
19:42:07 <GeKo> dgoulet: where can one find those bad relays?
19:42:14 <dgoulet> not to publish... I don't see any... maybe some _ongoing_ thing we ought to prevent relays caught ... but
19:42:31 <dgoulet> the discussion ended up that everyone was happy that we would publish all bad relays with a 3 months lag
19:42:39 <dgoulet> GeKo: this is why the Expiry date in the bad.conf is always 90 days :P
19:42:54 <GeKo> yeah, that's what i figured ;)
19:42:54 <dgoulet> GeKo: it is in the DocTor git history
19:43:03 <dgoulet> not the most obvious way to find it
19:43:14 <GeKo> aha, yes, i remember stumbling about that
19:43:17 <dgoulet> https://gitweb.torproject.org/doctor.git/commit/?id=c29bba1efb92927b975cd863bb4f437792947a67
19:43:20 <dgoulet> example ^
19:43:36 <GeKo> any reason this process did not continue?
19:43:53 <dgoulet> GeKo: I had no time or forgot or didn,t take time to do it regurlarly
19:43:59 <dgoulet> GeKo: there is no counter pressure to do it
19:44:03 <dgoulet> GeKo: the dirauth kabal was on board
19:44:13 * dennis_jackson chants automation automation automation
19:44:16 <dgoulet> and for a time it was what I was doing every ~6 months
19:44:29 <GeKo> okay, great, let's revive that then
19:44:41 <dgoulet> that is primarly why I've standardized the comments in the bad.conf
19:44:47 <dgoulet> so a script could expire the entries!
19:44:59 <dgoulet> but never got to writing it :(
19:45:16 <GeKo> that's solvable ;)
19:45:44 <GeKo> ooookay, do we have anything else to discuss today?
19:46:04 <dennis_jackson> Nothing from me, thank you all for the knowledge sharing :)
19:46:08 <GeKo> maybe dennis_jackson has another small question ;)
19:46:16 <dennis_jackson> How many hours do we have left? :P
19:46:38 <GeKo> :)
19:47:00 <GeKo> okay, nothing anymore. thanks everyone! have a nice week and happy hacking
19:47:04 <GeKo> #endmeeting