I've written up what I think would be a useful building block: https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
thanks, I'll reply here since I (and probably others) can not reply there.
Three highlights from that ticket that tie into this thread:
(A) Limiting each "unverified" relay family to 0.5% doesn't by itself limit the total fraction of the network that's unverified. I see a lot of merit in another option, where the total (global, network-wide) influence from relays we don't "know" is limited to some fraction, like 50% or 25%.
I like it (it is even stricter than what I proposed), you are basically saying the "known" pool should always control a fixed (or minimal?) portion - lets say 75% - of the entire network no matter what capacity the "unknown" pool has but it doesn't address the key question: How do you specifically define "known" and how do you verify entities before you move them to the "known" pool?
(B) I don't know what you have in mind with verifying a physical address (somebody goes there in person? somebody sends a postal letter and waits for a response?)
The process is outlined at the bottom of my first email in this thread (short: a random challenge sent to an address in a letter which is returned via email).
but I think it's trying to be a proxy for verifying that we trust the relay operator,
"trust" is a strong word. I wouldn't call them 'trusted' just because they demonstrated their ability to pay someone to scan letters send to a physical address.
I would describe it more as a proxy for "less likely to be a random opportunistic attacker exploiting tor users with zero risks for themselves".
and I think we should brainstorm more options for achieving this trust. In particular, I think "humans knowing humans" could provide a stronger foundation.
I'm all ears for better options but at some point I'd like to see some actual improvement in practice.
I would dislike to be in the same situation in one year from now because we are still discussing the perfect solution.
More generally, I think we need to very carefully consider the extra steps we require from relay operators (plus the work they imply for ourselves), and what security we get from them.
I agree.
(C) Whichever mechanism(s) we pick for assigning trust to relays, one gap that's been bothering me lately is that we lack the tools for tracking and visualizing which relays we trust, especially over time,
and especially with the amount of network churn that the Tor network sees. It would be great to have an easier tool where each of us could assess the overall network by whichever "trust" mechanisms we pick -- and then armed with that better intuition, we could pick the ones that are most ready for use now and use them to influence network weights.
reminds me of an atlas feature request for family level graphs https://trac.torproject.org/projects/tor/ticket/23509 https://lists.torproject.org/pipermail/tor-relays/2017-September/012942.html
I'm generating some timeseries graphs now to see what exit fraction (stacked) is managed by https://torservers.net/partners.html and those mentioned at the bottom of https://lists.torproject.org/pipermail/tor-relays/2020-January/018022.html + some custom additions for operators I had some contact before over time (past 6 months). spoiler: it used to be >50% until some malicious actor came along and reduced it to <50%
Seeing their usual fraction over time can be used as an input when deciding what fixed fraction should always be managed by them.
At the same time, we need to take other approaches to reduce the impact and incentives for having evil relays in the network. For examples:
(1) We need to finish getting rid of v2 onion services, so we stop the stupid arms race with threat intelligence companies who run relays in order to get the HSDir flag in order to scrape legacy onion addresses.
outlined, planned and announced (great): https://blog.torproject.org/v2-deprecation-timeline
(2) We need to get rid of http and other unauthenticated internet protocols:
This is something browser vendors will tackle for us I hope, but it will not be anytime soon.
kind regards, nusenu