We should write a proposal to make sure ContactInfo is really just an email address. We could add a second step where we want to enforce it actually. Tor's man page says:
ContactInfo email_address Administrative contact information for this relay or bridge. This line can be used to contact you if your relay or bridge is misconfigured or something else goes wrong. Note that we archive and publish all descriptors containing these lines and that Google indexes them, so spammers might also collect them. You may want to obscure the fact that it’s an email address and/or generate a new address for this purpose. ContactInfo must be set to a working address if you run more than one relay or bridge. (Really, everybody running a relay or bridge should set it.)
which is already pretty close to what I plan to propose. This is related to tpo/core/arti#870.
@gus is not done with the meta proposal yet, so I wait for that. Additionally, I am not sure yet how to split this up properly for some potentially needed tor-spec proposal.
Edited
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
I agree with @nickm that adding a new EmailAddress torrc option would be better than to change the semantics of ContactInfo to prevent introducing a backward incompatible breaking change.
I agree with @nickm that adding a new EmailAddress torrc option would be better than to change the semantics of ContactInfo to prevent introducing a backward incompatible breaking change.
As @ahf said I think you got this wrong. As I pointed out Tor's man page says:
ContactInfo email_address
for what is currently expected for that field (even though no one actually enforced it so far).
I think we can make that happen in a backwards compatible way by parsing the currently available ContactInfo fields to extract emails automatically, e.g. from CIISS entries.
I didn't know that proposals are implementation specific. So this proposal applies to future arti tor but not to C tor?
Since this discussion is taking place in two gitlab issues I'm not sure where there right place is to answer, but I also answered there:
tpo/core/arti#870 (comment 2906265)
I didn't know that proposals are implementation specific. So this proposal applies to future arti tor but not to C tor?
Proposals are not implementation-specific. However, we likely want to use the advent of arti relays to make that change. But if folks want to have that change even earlier it's probably doable to squeeze it into some C Tor release. Note: there is not even a proposal written yet, which is the task for this ticket, and it will have to address the arti/C tor situation.
Since this discussion is taking place in two gitlab issues I'm not sure where there right place is to answer, but I also answered there: tpo/core/arti#870 (comment 2906265)
Here is a good place. The arti ticket is for implementing the code later on.
So the Tor Project is knowingly going to break AROIs, without providing a migration path first?
Not only AROI and OrNetStats also the considerations and attempts to build a WOT for improving the health of the Tor relay operator community and the Tor network.
By the way, average joe don't use man torrc but reads sample torrc.
torrc.sample.in
8<#ContactInfo Random Person <nobody AT example dot com>## You might also include your PGP or GPG fingerprint if you have one:#ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com>>8
So the Tor Project is knowingly going to break AROIs,
Three things:
This is a ticket to write a proposal. That means that at least one person thinks it is a good idea to write a document to explain how and why to do this. It does not mean that that there is a project consensus. People (including you) are discussing the idea.
"No freeform field" doesn't mean "no structured info". Even if contactinfo were email-only (or if contactinfo were deprecated and replaced with an email field), that's no reason there can't be a number of other fields to hold other information as needed.
The descriptor metaformat allows adding new fields; I don't think that you'd be able to make a "recognized fields only" rule and still have Tor work without a lot more engineering than anybody here has proposed.
"No freeform field" doesn't mean "no structured info". Even if contactinfo were email-only (or if contactinfo were deprecated and replaced with an email field), that's no reason there can't be a number of other fields to hold other information as needed.
Adding a bunch of fields to cover (a subset of) the CIIS spec seems kind of messy, but I'm sure @nusenu has better thoughts on this. Some people might want to publish other legit information not covered by CIIS, though. Bummer that the Tor Project apparently managed to attract so many cryptoscammers recently.
Could an alternative be a freeform field that is part of the relay descriptor, but not shown anywhere on Tor Project websites? That way i.e. nusenu's tools could still work, but scammers wouldn't get their stuff published. (Unless that's not the issue.)
A freeform field isn't really needed in my opinion. Email-only and a new descriptor for CIIS-info-only shold be enough.
If useful CIIS things are missing, people can ask/fill issue if they can be added. Nusenu asked 2 years ago in the relay list whether there is something to improve or add on CIIS.
In CIIS is URL. So people can put everything else on their website and don't have to put all freeform crap in a relay descriptor.
I wonder what exactly the cryptoscammers are doing with the contact info field? I'll put this question on the pad at the next relay meeting.
So the Tor Project is knowingly going to break AROIs, without providing a migration path first?
I think @nickm covered some good points but let me add to that a bit.
This proposal idea does not mean that whatever some folks put into their ContactInfo nowadays (be it PGP ID, cryptocurrency address, AROI, whatever) will be rejected by the Tor Project in the future. It just means ContactInfo is not the right place for that (anymore). Oh, and that's nothing new. It's been a point Iain has been bringing up years ago (2017) on the tor-relays@ mailing list. The status quo has been biting us over and over again in our daily bad-relay and network-health work, so it's not just some scammers coming along that are forcing our hand (they were only the tipping point).
To be extra super clear: I think it would be a very useful exercise to go over real-world examples of what folks use the ContactInfo field for nowadays and think about whether and how to support those things in the future while we are at it. Maybe there are things that are not worth supporting anymore while we want to keep other stuff.
Since @alxndr mentioned me, I feel like I need to add my 2 cents now instead of just waiting for the proposal:
This change is aiming to address one (or several?) problems.
We know a bit of how geko would like to address the problem
but at least I know very little what problem(s) this change
is aiming to solve.
We have recently seen scammers that abuse that field
to get a clearer picture a few example relay fingerprints
that exploited the problem and a description of the impact would probably
be useful.
Proposals usually have a motivation/introduction section, so I guess
this will become clear once the first version of the actual proposal hits
tor-dev/tor-relays.
It is also clear that geko's needs with regards to that field do not match
the operators needs, but I'll wait for that proposal text including the problem description/motivation or any further information about the problem it tries to solve before discussing possible solutions.
It is also clear that geko's needs with regards to that field do not match the operators needs
I don't think that's true as it stands, quite to the contrary. We have hundreds of operators and my experience in contacting them during EOL work and bad relay work suggests that a vast majority (and thus the Tor network as a whole) would benefit from well-structured ContactInfo information. So, there is no need to start thinking along the lines of GeKo (and the Tor project) vs. operators.
Note to self: there are oldthreads which propose a verified email address in the ContactInfo field (or which would benefit from having that available), which would very nicely fit here and should be included in the proposal.