Does anyone have a script for periodically updating strick exit nodes lists after running an inspection as per https://tc.gtisc.gatech.edu/bss/2014/r/spoiled-onions-slides.pdf or similar? Looking to help protect against crypto transaction sender redirect attacks.
Trying to maintain a list like this on your own is counterproductive and potentially dangerous:
(A) If you have a private set of relays that you try to avoid, then the resulting difference in path selection can act as a tracking cookie. The more different you are from normal clients, the easier it is to recognize you.
Another answer might be in more parts...
- Choosing whatever sets of nodes you wish to comprise your trusted set based upon whatever metrics you find valid and choose to apply... well that's up to you. Or as has been mentioned, might be done by various groups of users and analysts among them freely banding together to develop and subscribe to such things.
There are many meta things that could go into such trust metrics. So far, no one's really explored them as an active project.
- The NSA and other entities can see significant fraction of all internet traffic, Tor doesn't defend against that. For which worrying about non degenerate path differences among a large sea of remaining path choices could be moot. In particular when, being random, weighted, and so forth, it's statistically possible you could end up not pathing through your excluded node sets anyways.
Yes users developing degenerate cases is a risk to themselves, and even to the network for network wide / affecting options. Thus it is said by default to all users "just don't". But there is often no technical evidence of any proposed degeneracy from them to qualify that default as applicable to each such user that comes.
(B) If you discover relays that are modifying traffic, then you should tell the bad-relays list, so they can kick them out of the network to keep everybody safer: https://blog.torproject.org/how-report-bad-relays https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays
There are various good people discovering, reporting, and nuking bad relays. But it's not to be relied upon as any sort of safety assurance.
Here's another "don't"...
Don't be doing sensitive data over clearnet, nor based on instructions and data you've seen over clearnet. At least throw in some TLS with fingerprint pinning and verification.
The same applies to sending cleartext coin transactions, over clearnet, to cleartext ledgers. There are evolutions of coins that are beginning to address those significant privacy problems, here's two of them...