Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
On Sat, 21 Oct 2023 15:54:37 + Georg Koppen allegedly wrote: > Hello everyone! > > As indicated in our bug tracker a while ago[1] we have some strong > incentives to redo our ContactInfo field. I've collected all the > different use cases and combined them in a single proposal, > discussing some potential concerns and future work we could get built > upon it. [ some deletia ] > We intend to solve that problem by deploying an email verification > service: relays without a verified `ContactInfo` value won't be > allowed on the network. I assume that the verification system will allow for cases where operators use email aliases in the contact info field (i.e. mail addresses of the form "t...@domain.org" rather than the /real/ address "operator.n...@domain.org"). If this is not the case and replies must come from the advertised address then this proposal could be problematic for some. Mick - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net - ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
On 10/31/2023 03:09PM t...@nullvoid.me wrote .. > My only concern with your solution is anyone can pretend to be the owner of a > relay. - What do you have to say to a relay owner that cannot be said publicly? - What do you have to say that needs a reply? In the rare cases where you would have a valid answer for the above questions, the actual email address in the ContactInfo is good enough, and - assuming there are none - you could ask to include a temporary code in the ContactInfo for authentification when someone contacts you on your request. The point is if you have to contact all relay operators, you don't need to look for their email addresses in ContactInfo. All you need is to post the message publicly, easily accessible by each relay owner (a personalized RSS feed comes to mind). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
I've been thinking long and hard about this problem and I'm not sure if an email address - validated or not - is the best way to achieve the initial goals. What are the goals of having this validated email address? 1- Inform the operator; 2- Make sure the operator will read the info; 3- Identify the operator. I'll keep #1 for last as this is the only truly needed goal from my point of view. Identifying the operator ID to make further decisions on how to share the traffic may be kind of useless. There are either _good_ operators and you have no real reason to divert traffic from these relays or there are _bad_ operators and they will try to hide that fact by creating multiple identities. Your validated IDs are still useless to you as identifying _bad_relay operators. About validating an email address to make sure the operator will read the info, it is still not a guarantee that it will happen in the future. If an operator does not want to - or cannot - read his/her emails, you cannot do anything about it. Except maybe revalidating the email address regularly which is, first, annoying and, second, what are going to do if a _good_ relay operator doesn't revalidate his/her email address? Shut down all of his/her relays? You might shoot yourself in the foot going with such an attitude. So there is no real point in validating an email. It will just turn out to be more red tape to go through. About point #1, you want to inform the relay operator. Do you need a two-way communication method for that? * How about putting the message to the operator on the _metrics.torproject.org_ relay page? * Would there be any reason for the messages not to be public? * If, somehow, a response - or an exchange - may be needed, why not put a general contact email address for answers, comments, etc. with, for example, the message ID as the subject? If the message is really personal, the message can be as simple as "Contact us at torproj...@example.org ASAP." * Why not put an RSS feed to be able to fetch those messages automatically and regularly? * That way, you can also contact multiple operators based on their country, platform, etc. with the same message as well. This would be something similar to _weather.torproject.org_ but much simpler and without a need for any kind of registration. Are you sure all operators will follow, read, and act upon your messages? Not less than by sending an email. Much better than NOT having a valid email address at all. A _bad_ operator will be a _bad_ operator no matter what. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
Hi! Xiaoqi Chen (Danny): Hi Georg, First of all, thanks to all of you for the effort writing up the proposal! Sure. Thank you for your input. I saw that email obfuscation was discussed but no solution was proposed. I want to throw in some ideas about obfuscating the email centrally: - Let's not publish cleartext email in any public descriptor, and only publish an obfuscated address, something like operato...@relay-operators.torproject.org or fingerpr...@relay-operators.torproject.org. - Only those already operating a relay, using their ContactInfo as "from" address, can send to these obfuscated addresses and get forwarded to the actual recipient email. Otherwise the email gets rejected or ignored. (Of course TorProject folks can also be added to the list of allowed senders.) This will be very similar to how tor-relays@lists.torproject.org currently operates. This should reduce spamming as the cost for spamming is quite nontrivial (go through the hassle of setting up a new relay), while frictionlessly serving the existing and planned use cases, mainly 1) broadcast from tor project to all operators, 2) community discussion between relay operators, and 3) debugging and reaching individual operators or a small batch of them. Of course, this solution might be unnecessary (and I agree that historically there's not much spam). We can balance the benefit and cost -- the marginal cost for adding forwarding logic as part of the future operator ID / email verification system. This an interesting idea. However, I have my doubts that relay operators would be happy with it. I mean there are some folks that already have concerns that we require an email address to begin with (as this might leak things about themselves) but what you are suggesting is that Tor would centrally save those email addresses and keep a mapping to some public piece visible in the descriptor. Moreover and even worse, we would see whom of the relay operators would be talking to whom and when this would be happening (if I got the idea right), which sounds problematic to me and would probably not be in the interest of the operators. I think the comparison to the tor-relays mailing list is a bit mis-matched as well given that there is no requirement to sign up to that mailing list. So, setting up spam protections and filtering seems to be way less intrusive than what you have in mind. But I am fine thinking more about it if there is interest from the community. Thanks, Georg -- Danny -- Yours sincerely, Xiaoqi Chen On Sat, Oct 21, 2023 at 3:55 PM Georg Koppen wrote: Hello everyone! As indicated in our bug tracker a while ago[1] we have some strong incentives to redo our ContactInfo field. I've collected all the different use cases and combined them in a single proposal, discussing some potential concerns and future work we could get built upon it. The work is tracked on Gitlab as well[2] feel free to provide feedback there or here on the list as a follow-up to this announcement. For your convenience the proposal text is included below (if you like reading the .md file on Gitlab, see my personal repository for the latest draft[3]). """ ``` Filename: 100-contactinfo-mandatory-email-address.md Title: Restricting ContactInfo to Mandatory Email Address Author: Georg Koppen Created: 2023-10-21 Status: Open ``` ## Overview This document proposes to change the ContactInfo field from a free text field to one that is only allowing an email address. Additionally, providing such an email address will be required after this proposal is implemented. This is a normative document. ## Motivation Being able to reach out to and contact relay operators (bridge operators are included in that group) is important for our day-to-day work at Tor. While this has been brought up in the past as helpful in our fight against malicious relays, it goes well beyond that use case and is affecting general network health work, community-building efforts and quickly deploying anti-censorship related security fixes among other things. Tor is providing a `torrc` configuration option, `ContactInfo`, which is supposed to contain an email address (potentially obfuscated) under which the relay operator may be reached. However, in practise this does not work very well for two reasons: 1. `ContactInfo` is a free-form field which allows the operator to include not just email addresses but essentially any kind of text they want. This results in a lot of overhead when trying to contact all operators and failures to do so because not everything added to `ContactInfo` is a way to actually contact operators or undoing `ContactInfo` obfuscation turns out to be too hard. 2. `ContactInfo` can be empty as it is not required for all operators and in cases where it is supposed to be required (e.g. for operators running more than one relay) the requirement is not enforced. Over the years different teams at Tor developed
Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
Hi Georg, First of all, thanks to all of you for the effort writing up the proposal! I saw that email obfuscation was discussed but no solution was proposed. I want to throw in some ideas about obfuscating the email centrally: - Let's not publish cleartext email in any public descriptor, and only publish an obfuscated address, something like operato...@relay-operators.torproject.org or fingerpr...@relay-operators.torproject.org. - Only those already operating a relay, using their ContactInfo as "from" address, can send to these obfuscated addresses and get forwarded to the actual recipient email. Otherwise the email gets rejected or ignored. (Of course TorProject folks can also be added to the list of allowed senders.) This will be very similar to how tor-relays@lists.torproject.org currently operates. This should reduce spamming as the cost for spamming is quite nontrivial (go through the hassle of setting up a new relay), while frictionlessly serving the existing and planned use cases, mainly 1) broadcast from tor project to all operators, 2) community discussion between relay operators, and 3) debugging and reaching individual operators or a small batch of them. Of course, this solution might be unnecessary (and I agree that historically there's not much spam). We can balance the benefit and cost -- the marginal cost for adding forwarding logic as part of the future operator ID / email verification system. -- Danny -- Yours sincerely, Xiaoqi Chen On Sat, Oct 21, 2023 at 3:55 PM Georg Koppen wrote: > Hello everyone! > > As indicated in our bug tracker a while ago[1] we have some strong > incentives to redo our ContactInfo field. I've collected all the > different use cases and combined them in a single proposal, discussing > some potential concerns and future work we could get built upon it. The > work is tracked on Gitlab as well[2] feel free to provide feedback there > or here on the list as a follow-up to this announcement. For your > convenience the proposal text is included below (if you like reading the > .md file on Gitlab, see my personal repository for the latest draft[3]). > > """ > ``` > Filename: 100-contactinfo-mandatory-email-address.md > Title: Restricting ContactInfo to Mandatory Email Address > Author: Georg Koppen > Created: 2023-10-21 > Status: Open > ``` > > ## Overview > > This document proposes to change the ContactInfo field from a free text > field to one that is only allowing an email address. Additionally, > providing such an email address will be required after this proposal is > implemented. This is a normative document. > > ## Motivation > > Being able to reach out to and contact relay operators (bridge operators > are included in that group) is important for our day-to-day work at Tor. > While this has been brought up in the past as helpful in our fight > against malicious relays, it goes well beyond that use case and is > affecting general network health work, community-building efforts and > quickly deploying anti-censorship related security fixes among other > things. > > Tor is providing a `torrc` configuration option, `ContactInfo`, which is > supposed to contain an email address (potentially obfuscated) under > which the relay operator may be reached. However, in practise this does > not work very well for two reasons: > > 1. `ContactInfo` is a free-form field which allows the operator to > include not just email addresses but essentially any kind of text > they want. This results in a lot of overhead when trying to contact > all operators and failures to do so because not everything added to > `ContactInfo` is a way to actually contact operators or undoing > `ContactInfo` obfuscation turns out to be too hard. > 2. `ContactInfo` can be empty as it is not required for all operators > and in cases where it is supposed to be required (e.g. for operators > running more than one relay) the requirement is not enforced. > > Over the years different teams at Tor developed different workarounds to > the issues mentioned above without addressing them directly. The goal of > this proposal is to make those workarounds obsolete. > > ## Fixing ContactInfo > > As briefly mentioned in the [Overview section](#overview) the idea of > this proposal is deceptively simple: `ContactInfo` will be turned into a > field allowing just an email address, under which the operator can be > reached. Moreover, providing such an address will be a requirement for > all operators regardless whether they run one relay or many of them, or > bridges. > > Why will we require an email address and not, say, a domain set up > somewhere or an account on our forum instead? Firstly, a lot of those > other potential options require a valid email address themselves in the > first place and would therefore just raise the costs for relay > operators. Secondly, email still scales way better than other > alternatives allowing us to reach more people in less time. And, > thirdly,
