Hi list,
First of all, why is email verification not used as an additional method for making family settings? (Additional meaning that operators could choose to either verify their mail address or write all their relays fingerprints in the config.) Wouldn't it be more convenient to verify the address once and then automatically adding every relay with the same contact to that family. And maybe notify the operators so that they can claim the new relays to be "not theirs" in case somebody else pretended to be that operator.
Secondly, how about adding something to the configuration of relays with the purpose of showing inheritance from other configurations in order to make bad relay detection easier?
Imagine the guide for running secure relays changed regularly in a way that makes the 'version' of torrc distinguishable by looking at the settings. This could be easily achieved by adding a varying additional field in the settings. The value of the field is not important, but the name of the field should change in an unpredictable way. Somebody would keep the chronology of old suggested configurations. This way it can be used like non coding DNA for m/paternity testing.
The desired effect: If a good operator sets up a new relay for the very first time, the person reads the guide and copies this extra line which adds very little extra effort. If the good operator sets up many relays he can automate that and always use the same settings because the good operator doesn't need to hide she is running multiple relays. (This does not replace family settings.) If a bad operator sets up many relays over a long period of time, the bad operator cannot automate this process as the relays would stand out by using outdated recommendations that a new operator would not have found online and that can be related to the other relays of the same operator.
The extra information should not de-anonymize relay operators because the time when they setup their relay is usually available through the first seen field and family settings are public available too.
The obvious difficulty is, for it to work, the tor relay guide containing the altering information should be so well-written that the majority of new relay operators always choose to follow this rather than other guides that don't change. And it maybe requires different error handling.
Anyway this example should only illustrate the basic concept. I don't know if that option has been discussed so far.