> Does this mean that you're planning to expand the SoaT codebase? Write > a revised version? If the project is going to be revived then it would > make sense for it to take advantage of one of our newer controller > libraries...
Yeah the plan is to do a complete rerwrite of SoaT. That guy was a beast and almost did its job too well. I talked a little about this on the tor-dev side but I'm definitely using Stem. I didn't know about the other project though so thank you. There was also some discussion about interfacing with Onionoo but now we're talking too far down the line. > 2. Even when a bad exit *is* reported our process for flagging it is > pretty well broken. To be flagged at least two of the three authority > operators that vote on the BadExit flag need to take manual action. > All three operators are highly busy people so in practice relays don't > get flagged without considerable nagging. Exactly. I think Mike Perry's proposal that Aaron linked to is still spot on in terms of what we want from a solution. In the deployment section it notes three phases where the final one is an automatic communication between the scanning engine and the Tor Network so that it alerts Directory Authorities. This interface in itself requires some thought. It's threat model includes accidentally causing a DoS on all hosts on the network if something goes wrong, or inappropriately flag a good node, or the fact that knowing how to tool works, a malicious node could change it's activities to avoid detection. The other issue that is stuck in my head is that I think exit scanning is always going to be a losing battle and this is a best-effort game. I see it in the same way that Android has tried to keep track of malware on the Play market. It will be days in even the best case scenario before we find out an exit node is malicious and properly report them. It's high effort for little return. In an ideal - not-Tor world - there could be some kind of activation process for exit nodes that validate configurations and performs simple checks before they join the network, and contact information is confirmed (or at least attempted). This assuredly will never happen for a variety of reasons one of which is that it's a deterrent for those volunteer operators that we need lots and lots of. I wonder if this has already been discussed or if it's worth at least documenting the design decision somewhere. It's valid to say "We won't do this because of X Y and Z" but I would like to see how the debate would go against a realistic solution (that has yet to be proposed). ROC _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
