Hi Lutz, On Tuesday, May 27th, 2025 at 09:02, Lutz Donnerhacke <[email protected]> wrote:
> * Rodolfo García Peñas (kix) wrote: > > > El 26/05/2025 a las 11:24, Lutz Donnerhacke escribió: > > > > > That's the point. In the case of real trouble, you want to be able to > > > reach out for somebody competent > > > at the other end of the problem. That's why this information is > > > collected, stored and made accessible. > > > > In my opinion, the proposal does not change the fact that the information > > must be collected > > in the database and made it accessible. The information is simply there, > > but if the owner > > does not wish to display it, the database should hide it. Contact could > > still be made, > > but instead of sending an email to mailto:[email protected], the email for > > the user would > > be mailto:[email protected]. > > > So you want to introduce a level of indirection, which does not tackle the > problem of spam and phishing > at all, but make it worse. You can be still reached by the "privacy-address", > but you lose the > information, which system was originating the mail. You can't anymore block > well known spammer hosters, > as well as combine suspicious mail body coming from dynamic address ranges. > Instead, everything is > coming from the well trusted RIPE servers, you never will block. It is not a question of resolving spam from the contact system, but rather of avoiding unnecessary exposure of personal data. The source data will be included in the message; what is being hidden is the recipient's information. In fact, the source information is necessary to provide a response. Email filtering can be done at the destination, as before; nothing changes in this regard. In fact, anti-spam tools could even be added to proxies if this is the goal. > Bad actors will use the privacy proxy addresses in the same way as they are > using the current ones. > Unless you require RIPE NCC to operate spam and phishing prevention at their > servers at a very high > level, those services will make the problem worse. Malicious actors already use current addresses without difficulty. Nothing will change in this regard. What is different is that by hiding the destination information, the malicious actor will not know who they are sending spam to or who they are trying to contact. > And for what? The human eye can't recognise the mail address anymore? So the > bad actors does not > longer know. Who is this person, which they are sending mail to? Seriously? So that the source does not know the address assignment information or the contact person's details. This improves the security of the entities and individuals registered in the database. We are not just talking about contact addresses; the aim is to protect the information so that not everyone has access to it. > Okay, you might add an real proxy-privacy service at this point, like ICANN > is doing. > This would require a human intervention step, where the content of the > message is checked for > legitimate use cases. Processing time between 24 and 72 hours. Very cool > solution for an > (emergency) contact during a network disruption. Not! In most cases, no human intervention will be necessary, and I do not believe that delays will be any longer than they are currently. In any case, an emergency contact channel could coexist, validated by strong authentication, operational agreements between LIRs, or, as proposed, different levels of access to database information. It is not all or nothing. > You are right, that several people do not want to give away their contact > information. If this is > acceptable behaviour: Fine, drop the information from the database = "Remove > Whois". I am not suggesting that the information should be removed from the database. On the contrary, the aim is to retain the registration information while allowing the owner to choose whether or not to make it publicly visible. In fact, the proposal may encourage many LIRs to enter the information into the database. > Otherwise if the information is necessary to operate in the Internet > yourself, then you have to > publish this information: Standing in public requires to be seen by others. > If you do not want > to stand in public, use an Internet Service Provider, which is standing there > instead of you. > You can't have both. I disagree with this. Given the changes in the current legal and social context, the database should be adapted. Including information in the database does not mean that it has to be displayed publicly. According to RIPE document 804, section 6.2, 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' Even if an entity does not wish to register information in the database, if it is an 'End user', this information should still be included. This paragraph was omitted from the document. Is the intention to exclude the user's contact information? Would it not be better to include the information but not make it visible? > > > > One proposal is to use a Boolean model for each field (or for all > > > > fields in the object) > > > > to indicate whether the information should be "protected" or "public." > > > > > > This option would simply say either: > > > - "I don't care about others, go die yourself" or > > > - "I'm responsible for problems, I cause" > > > > > > > Another example option would be to include levels such as "public" > > > > (publicly accessible), > > > > "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated > > > > LIRs), > > > > and "private" (fully private). > > > > > > This option would translate to > > > - "I'm responsible for problems, I cause" > > > - "I don't care about others, but RIPE NCC should not be sued for" > > > - "If everything is fine, others at my league may contact me. If things > > > are broken, I don't care" > > > - "I don't care about others, go die yourself" > > > > I don't think this proposal will change behavior. Are the phone numbers > > published > > in the database currently answered? Are emails responded to? If someone > > does not > > respond to emails, RIPE NCC is notified and they try to facilitate contact. > > I think it could be the same in this case. > > > Data accuracy and responsiveness are different problems. If we conclude, that > the information > can*t be validated, and nobody is willing to take action on inaccurate or > unresponsive entries, > then this information MUST NOT be collected in the first place: "Remove > Whois". These are indeed different problems. However, this does not justify removing the information from the database. On the contrary, with information privacy mechanisms in place, it is possible to retain the data and, by not exposing it publicly, the quality of the data may even improve. > Besides that, I stand for my interpretation of your proposals. > > > > Ultra thin whois > > > > This model is interesting and very similar to the one used in RPKI. The LIR > > can > > choose between managing the information on the LIR portal or on its own > > servers. > > > Valid extension: Let the LIR choose to use the RIPE DB instead of running > their own. I agree, but this would be a proposal to be dealt with separately. > > However, my proposal relates to the information contained in the database > > and > > how it is displayed, not how the database is implemented (single or > > distributed). > > In both cases, the information should be the same. > > > You miss the point of this proposal: The only information stored in a DB is > the information, > is the information of the active contract, which is always known and > validated. > Requiring a third party (LIR) to update a subset of their contract > information in a DB, > which is located in a different, possibly distinct legal region, will always > let to > inaccuracies over time. What I propose is a conscious design. The information included in the database is that of active contracts. But what happens if a company does not want to publicly disclose the address ranges it is using to prevent them from being attacked? What happens when a person's personal data is displayed publicly, including their name, surname, telephone number, company name, email address, and that person does not want the information to be publicly accessible? What does the database offer for these situations? > > > Remove whois > > > > Not storing information is different from not displaying it. To fulfill its > > purposes, > > the information must be in the database, and the records and contacts may > > be different > > for an LIR and the customers of that LIR. Therefore, in my opinion, there > > is a need > > to identify inetnum/inetnum6 objects and contacts (admin, tech, zone, > > abuse). > > Contact methods will not display the information (if the user so chooses > > it), > > but the recipients will be different. > > > The whole purpose of this database is to have access to the most accurate > contact > information, in order to resolve network issues quickly. Storing information > and > preventing access, violates this purpose. Hence, the information MUST NOT > collected > in the first place. Plain and simple. I understand your point, but I think we need to distinguish between indiscriminate access to information and functional access for cases where it is necessary. Just because information is not publicly visible does not mean that it is not accessible in a controlled manner. There are multiple possible mechanisms (I have proposed some examples) that allow for quick contact in real situations, without this implying total exposure of personal data and entities at all times. Protecting information does not mean that it is not stored in the database; on the contrary, I believe it is a tool for including more information, with greater detail and quality. What is proposed is to decouple public visibility and operational availability. > Lutz Regards, kix -- Rodolfo García Peñas (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
