On Tuesday, June 23, 2015 9:07pm, saitosean@ymail.com said:

Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?

A quality that can't be measured: resistence to intrusion.

On second thought, that can be evaluated from outside to a certain extent. What ports on the server are open in addition to the OrPort/DirPort? Can the OS be fingerprinted to reveal an unsupported (and therefore unpatched) version?

I worry about those relays with a heroic uptime. How is it that they haven't needed to reboot in, say, nine months? No security updates to the kernel or glibc in all that time? Really?

In these days when governments, with their expertise and multi-billion-dollar budgets, get infiltrated I wonder how easy it would be get some monitoring malware onto machines that run Tor relays. That seems a lot more likely to me than the scare stories about the NSA/GCHQ running a lot of nodes themselves.

https://atlas.torproject.org/#details/7489E8EDD0B8B68C8A2CB31D2B56B6572091DA...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I’m currently working with Dr. Virgil Griffith on Roster, a tor project that aims to reward relay operators with good relays.

Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?

What are you generally aiming for: 1) a current rating (snapshot) or 2) a rating that accumulates over time (like in distributed computing/BOINC projects)? or 1 + 2?

For the rest of this email I'm assuming you go for (2).

Start with what matters most: - - Reward people for their total pushed traffic.

You could use it as the base value that gets multiplied by other diversity/configuration factors.

- - Reward people running relays for a longer time.

(use a relay's age)

- - bandwidth According to Roger one fast relay is more useful than many small relays.

Use bandwidth history (not advertised bandwidth).

- - Does the exit policy allow rare destination ports? more=better (excluding *:25)

- - Does the relay's declared family match the effective family?

bigger diff = less good

Once [1] is implemented this will be really easy to check for.

[1] https://trac.torproject.org/projects/tor/ticket/16276

- - IPv6 connectivity

IPv6 enabled = better

- - Does the torproject want to reward non-announced 'exit_addresses'? (as defined by onionoo)

- - Has the relay a contactinfo set?

non-empty is better

Certain people will scream "don't force people to disclose their email addresses or link them to their relays". I agree, but I'd say it is easy enough to create a new email address for this purpose and people can also specify arbitrary strings there (still more valuable than empty contacts if used consistently or created by following a certain scheme).

- - Reward people running more than one relay.

You could simply use len(effective family) for that.

more relays = better

(until they reach some upper bound sum(CW) value?) We don't want families to become to big in terms of CW fraction. In practices you might ignore "the upper bound limit" since it is unlikely that many ops will hit it anyway. And if more than one strives for it the competition solves the problem itself.

Patch Level / Tor version / Supported Tor Handshake Types

- - Is the relay running a tor version - 'recommended' as per consensus and - free from known vulnerabilities (that is unfortunately not a perfect overlap with 'recommended' as per dir auths) and - the latest version of one of the stable/supported version - using the latest

Does the torproject want to reward ops for running current alphas? You probably want some but not all of the relays running alphas so this is probably not suitable for automatic metrics.

Diversity

Judging by the latest paper on that topic it is good to start many guards near your users (in terms of how many ASes need to be traversed) and many exits near popular destinations, but I'm still judging by another very simple approach that actually runs counter to that: starting relays where there are none or few (by CW) is rated as better than starting a new guard in the country where most users are.

So things to weight in for a quality measurement could be:

- - /16 netblock (by CW fraction, relay count)

- - country/region/city (by CW fraction, relay count (less important than CW) and flags) - - AS (by CW fraction, relay count (less important than CW) and flags)

Lower CW fr./ relay count in CC/AS is better. goal: spread relays across the world

Examples: - X added/runs a relay in a country and/or AS that had none or very few before. - X added/runs an exit relay in a country and/or AS that had none or very few before (no matter how many non-exits there are)

Then you could "give out" rewards like "X started the first relay in country/AS Y".

- - OS (by CW and relay count)

rare OS = better (until people start to spoof their reported OS ;)

The calculation could look like this:

a new exit started, after 24 hours it did 700MB in a very common AS/country/netblock, on Linux, with no contactinfo, with a great open exit policy, running an unsupported tor version, declared+effective family=0 ....

factors (purely invented):

exit relay factor: 2.7 common AS factor: 0.7 common cc factor: 0.8 common netblock factor: 0.6 common OS: 0.9 unsupported tor version: 0.1 family len 0: 1 ...

700 * 2.7 * 0.7 * 0.8 * 0.6 * 0.9 * 0.1 * 1 * ... = X points

after 24 hours the relay is relocated to a rare AS/country/netblock, changed its OS to OpenBSD and runs the latest tor version, effective family changed to 2 and did 900MB more.

exit relay factor: 2.7 AS factor: 1.4 cc factor: 1.5 netblock factor: 1.7 OS factor: 2.5 recommended tor version: 1 family len 2: 1.05 ..

points from day 1 +

900 * 2.7 * 1.4 * 1.5 * 1.7 * 2.5 * 1 * 1.05 ...

multipliers will have to be dynamically calculated as the tor network changes.

I would love to see something like this implemented.

I'm really looking forward to your results.