19:00:30 #startmeeting network health 19:00:30 Meeting started Mon Mar 2 19:00:30 2020 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:39 hi! 19:00:42 hi 19:00:44 okay, let's get started with the weekly party 19:00:52 so 19:00:58 hello 19:01:09 the meeting pad is over at https://pad.riseup.net/p/tor-networkhealth-2020.1-keep 19:01:21 please add your items either in the status section 19:01:23 * ggus will need to leave 19:30 UTC 19:01:26 if you have something to report 19:01:38 or in the discussion one if that fits more in that area 19:01:44 o/ 19:01:56 additionally, please look over the entries already written 19:02:06 and mark the items bold you want to talk about 19:02:15 or have questions about 19:02:18 o/ 19:02:38 juga: nice to see you here :) 19:02:59 :) (gaba suggested me :) 19:03:09 good suggestion ;) 19:04:31 changed the order of the agenda so the guildelines can be discussed with ggus 19:04:37 yeah, thanks 19:04:49 i don't see any bold items 19:05:02 (hello world, i am nearby, but also in another meeting. let me know with some latency if there's a thing i should help with. :) 19:05:09 so let's go with the first one in the discussion section 19:05:12 o/ 19:05:20 gaba: you brought that up, right? 19:05:47 do you want to go with it? 19:05:48 right but because irl wants some feedback there 19:05:59 to see if everybody is ok with those changes he is proposing 19:06:28 "remove the features that filter by exit policy" https://lists.torproject.org/pipermail/tor-relays/2020-February/018189.html 19:06:46 heh, you changed 19:06:51 the order of the items 19:07:04 oops 19:07:06 sorry! 19:07:06 and i thought we want to start with the code-of-conduct one first 19:07:09 OMG 19:07:10 haha 19:07:14 i am fine either way ;) 19:07:15 yes yes 19:07:15 sorry 19:07:32 the guidelines 19:07:49 this is something that came up in the tor-relays mailing list 19:08:15 to extend the code of conduct with something related to guidelines that relay operators could follow 19:08:30 and I added the second link as it was related to something that those guideliens could have 19:08:47 a limit on amount of exit relays run by one person for example 19:09:52 ggus: was there some discussion about that at fosdem? 19:09:59 GeKo: nope 19:10:28 and the only reference about that is this phrase in the mailing list 19:10:36 >we (Frënn vun der Ënn) are working on a "Tor Organization Code of Conduct" . 19:11:01 ahf had discussion with some people at fosdem about it 19:11:11 not sure if we should do anything or just let it be 19:11:16 but it is something to be aware of 19:11:33 Something to feed into a possible Guidelines: Some exit relays are behind VPNs. This dramatically increases latency and hurts Tor Browser users. 19:11:36 i can contact Christophe and ask how things are going. 19:12:04 ok 19:12:30 Are technical issues like that suitable for inclusion? 19:12:44 if that, things like 'i promise not to look at the traffic' too 19:14:02 yeah 19:14:19 paul even wrote one of these, for relay operators, back when we were first thinking about a code of conduct for tor 19:14:27 i am not sure what actually should be in there if anything 19:14:28 might be useful to go find his paragraph. or ask him for it. 19:14:40 and whether we should try to drive that or not 19:15:10 ggus: maybe that is a good next step, yes 19:17:01 ok, i can do that today 19:17:03 dennis_jackson: that is interesting 19:17:11 do you have data about that? 19:17:20 Actually - it came from Arthur's dataset 19:17:32 It was something I looked it whilst I was at Mozilla 19:17:33 i think i'd be happy to contact relay operators 19:17:36 aha 19:17:53 counter point, exits are scarce and removing the ones behind vpns might actually make things worse for everyone 19:18:15 That's true and I'm not suggesting removal 19:18:18 yeah, which is why i'd like to talk to those folks (first) 19:18:33 Just in guidelines, asking people not to would be a good step. They won't be aware of the impact it has 19:18:39 this might also be a western world viewpoint, and actually the increased latency doesn't matter much compared to access network latency in a lot of the world 19:19:22 well, "not mattering much" does not seem to be a good criteria for not fixing things, though 19:19:28 I have data on this - it is significant 19:19:29 if we think they should be fixed 19:20:23 i mean if we can talk to those folks and get things corrected on their end that seems like a good way of spending a bit of time 19:20:56 i doubt those exits are using vpns by mistake 19:21:16 but certainly worth talking to the operators 19:21:16 yeah, maybe. i guess we'll see 19:22:22 okay, anything else for this point? 19:22:58 So to check: Are these guidelines ethical / social? Or is it general best practice? 19:22:59 i'm good 19:23:31 If the former, easy to put these issues in separate tickets, just want to check where to file them 19:23:57 dennis_jackson: i think it's not just best practices 19:23:57 i believe the first option 19:24:12 at least from what i understand when reading the mail conversation 19:24:16 yes, what ggus said 19:24:52 okay, thanks :) 19:24:58 okay, irl, you are up 19:25:07 or gaba :) 19:25:12 irl :) 19:25:36 tordnsel has a dnsbl that is used by irc networks and other things to determine if connections come from an exit relay 19:26:01 it's written in haskell, no one knows haskell, the thing runs on debian oldoldstable and is the last thing on a server we want to turn off 19:26:06 so we're not keeping it 19:26:11 we have a replacement thing 19:26:17 but it's different 19:26:55 instead of allowing fine grained knowledge of exit policies to determine if both a connection comes from an exit relay *and* it would be allowed in the exit policy, we now only tell you it came from an exit relay 19:27:15 i've spoken with one irc network and a staff member tells me this makes zero difference to them 19:27:47 the only people that are going to notice are people that run irc bouncers on their exit relays and deliberately excluded an irc network from their exit policy to not get treated as a tor client 19:27:55 i can't think of any other examples that would actually happen 19:28:08 but, maybe someone else can, so here is the question 19:28:31 is there any reason we should try to do the exit policy handling that tordnsel did before, or is it fine to just have the dnsbl for all exit relays? 19:29:17 Has there been any analysis of the exit policies on the network to upper bound how many people this could impact? 19:29:23 no 19:29:43 but i really don't recommend running your irc bouncer on your exit relay host 19:30:08 i posted to tor-relays@ on the 27th, no responses 19:30:37 from my pov i am fine with the plan 19:30:43 Okay - I will add this to my never ending list of things to look at sometime. (How many non-default exit policies there are) 19:30:54 GeKo: that's excellent news because i already implemented it 19:30:56 It impacts walking onions as well. 19:31:01 irl: :) 19:31:12 ok i will write up the service retirement announcement 19:31:21 this is going to happen in weeks, not months 19:31:21 dennis_jackson: in what way? 19:32:10 To clarify: The uniformity of exit policies impacts Walking Onions, not this decision on dnsel 19:32:21 aha, yes 19:32:35 that's true 19:32:43 Sorry - I am not great at IRC - too spoiled by slack and threading etc 19:33:05 nah, it's cool :) 19:33:28 okay, anything else for this topic? 19:33:35 or do we have other discussion points? 19:34:04 juga: i wonder whether we should talk a bit about sbws? 19:34:12 i wonder if ahf would be around for that 19:35:06 GeKo: as you prefer 19:35:22 not sure what to comment from my side 19:36:09 juga: i was just wondering if ahf and i could/should more help than doing code reviews or so 19:36:30 like do you feel there is too much work for you so we should step up here 19:36:35 and help with that? 19:36:55 GeKo: code reviews are really needed, so that's great help for now 19:37:05 there are 3 tickets for review: https://trac.torproject.org/projects/tor/query?status=needs_review&status=needs_revision&keywords=~sbws-roadmap&order=priority 19:37:07 okay. 19:37:29 actually, only 2 19:37:33 (oh, 1 shouldn't be in revewi) 19:37:35 #33076 is for mikeperry 19:37:35 yes 19:37:59 1 only :) 19:38:13 (will create more this week) 19:38:16 which one? 19:38:24 #30196 19:38:31 #30196 seems to be in need for revision 19:38:32 ahf was on that 19:38:36 according to teor 19:39:04 (which is why i did not look closer at it yet) 19:40:01 or maybe i misread their comment? 19:40:25 all fine ahf was going to make some comments on that 19:40:35 okay 19:41:04 juga: so, i am fine with poking more at sbws and doing reviews 19:41:05 yes. #30726 is for review. Maybe you can do that one? Also there are 2 tickets that are blockers for sbws #30735 and #30735 that needs to be done. 19:41:19 gaba: i already did that one today :) 19:41:28 nice :) 19:41:29 or did you mean working on it? 19:41:53 i just changed #30726 to needs revision 19:42:06 since GeKo answered a question 19:42:20 juga: and if there are things i can help with beyond doing code review, let me know 19:42:24 re. tor#30735, i already started working on it, but ist not for review 19:42:36 GeKo: ok, cool 19:42:37 nice 19:42:52 juga: what about #3009? is that something geko can start on? 19:42:57 oops 19:43:00 #33009 19:43:15 juga: i am fine, too, getting a personal introduction to sbws :) 19:43:30 i can ping you for that 19:43:31 :) 19:43:35 GeKo: yes, we can do that this week 19:43:47 i am not sure when this week is a good time for me 19:43:58 gaba: re. #33009, yes, if GeKo feels like 19:44:08 GeKo: just ping me and we see 19:44:15 or next week if needed 19:44:20 thanks 19:44:57 idem :) 19:45:11 alright, i might take a look at #33009 this week, we'll see. 19:45:38 okay, anything else for today? 19:46:15 not from me 19:46:23 neither me 19:46:30 let's close this meeting then. thanks everyone! and have a nice week 19:46:37 #endmeeting