[tor-relays] improving the badexit flag process
atagar at torproject.org
Tue Jul 15 00:02:14 UTC 2014
Hi Nusenu. For the past few days we've been having an internal
discussion about how to revamp our process for flagging bad relays.
Its been dysfunctional for years and it's high time we fixed it.
These discussions are where the wiki you mentioned came from...
I was planning to make an announcement after we got our other
overhauls in place but you make some good points so might as well
discuss this now.
> If you are implying that the current process starts with
> 'let the relay operator handle it', I'd suggest to set the badexit for
> confirmed bad "properties" *first* (no matter whether they are caused by
> the relay operator itself or its upstream/ISP) and give the relay
> operator the chance to request a badexit flag removal upon repair (not
> the other way around).
Ideally I agree. Trouble is that BadExiting requires manual
intervention by the directory authority operators, so adding then
removing flags would each create churn for them.
>> It can range from one hour to several days. It's clearly not good
>> enough at this point and we are trying to get better at it.
> Are there specific trac entries for this?
Nope. Trouble is the manual intervention, and actually in the past bad
relay reports have often never been acted upon. A particularly bad
instance of this is what's prompting us to finally fix it.
> The page states several times "let us know" (even in bold)
> but there is no information on how you are supposed to contact "them".
Those are email links. Is there something we can do to make that more
evident? The text previously cited the address but that felt
> What do you think about creating one where every scanner sends its
> alerts to?
> (something similar to the consensus-health ML)
We plan on making a closed list for bad relay reports. That might be a
good spot for ExitMap's output too.
[ most of the rest of the questions Philipp will best be able to answer ]
More information about the tor-relays