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