> 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 -- https://mastodon.social/@nusenu
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays