Hi, I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions. However, this information can be used to obtain information about individuals and entities in order to carry out unwanted actions (network recognition, phishing, etc.). To prevent network information and contact information from being obtained, objects with anonymized information are stored in the database, role objects are used instead of person objects, non-real information is used, or inetnum objects are not created. Some mailing threads related to these issues have been seen on the mailing list [2][3]. My proposal is that the database offers privacy regarding the information it contains, allowing real information to be stored while protecting LIRs and end users by providing filtered information. To this end, I propose using a system similar to "domain privacy" in DNS registries to hide desired information: - Use the option to hide sensitive information in mandatory fields. - Provide an option to maintain contact with the person responsible for the object. Example: person: Privacy protected address: Privacy protected address: Privacy protected e-mail: Privacy protected (contact link) phone: Privacy protected (contact link) remarks: For mail filtering or abuse problems contact with the abuse mailbox nic-hdl: ABCD1-RIPE mnt-by: Privacy protected (contact link) created: 2008-11-13T15:53:02Z last-modified: 2024-09-23T13:25:48Z source: RIPE 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." 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 information could be included by default at the user or LIR level using the LIR portal. For email or telephone communication, the platform could act as a mail intermediary or by providing anonymized email addresses, facilitating coordination between network operators/users. IMO, first, we must reach a consensus on whether this option is useful for database management, and then we can discuss implementation details. Regards, Rodolfo García (kix) PS. Thanks Jordi, Miguel for your help. [1] https://docs.db.ripe.net/What-is-the-RIPE-Database/Purpose-and-Content-of-th... [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... [3] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/MEOS4MD7ZYLVOAW... The content of this email reflects personal opinions and does not represent the views of any organization.
I am not a fan of this proposal. Part of the value the RIPE database offers is some kind of reasonable way to get into contact with operators, and this would basically turn a lot of the end records into unactionable records (other than for LEA use cases, something that I am reasonably sure that LEAs are not that familiar with at the moment anyway) I've seen the value in the previous ones for removing the requirement for phone numbers and/or addresses, but removing/hiding the entire object is a step too far I guess what I am not understanding is what you are trying to prevent here by hiding the person object? On Fri, 23 May 2025 at 19:49, Rodolfo García Peñas (kix) <kix@kix.es> wrote:
Hi,
I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions. However, this information can be used to obtain information about individuals and entities in order to carry out unwanted actions (network recognition, phishing, etc.). To prevent network information and contact information from being obtained, objects with anonymized information are stored in the database, role objects are used instead of person objects, non-real information is used, or inetnum objects are not created. Some mailing threads related to these issues have been seen on the mailing list [2][3].
My proposal is that the database offers privacy regarding the information it contains, allowing real information to be stored while protecting LIRs and end users by providing filtered information. To this end, I propose using a system similar to "domain privacy" in DNS registries to hide desired information:
- Use the option to hide sensitive information in mandatory fields. - Provide an option to maintain contact with the person responsible for the object.
Example:
person: Privacy protected address: Privacy protected address: Privacy protected e-mail: Privacy protected (contact link) phone: Privacy protected (contact link) remarks: For mail filtering or abuse problems contact with the abuse mailbox nic-hdl: ABCD1-RIPE mnt-by: Privacy protected (contact link) created: 2008-11-13T15:53:02Z last-modified: 2024-09-23T13:25:48Z source: RIPE
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." 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 information could be included by default at the user or LIR level using the LIR portal. For email or telephone communication, the platform could act as a mail intermediary or by providing anonymized email addresses, facilitating coordination between network operators/users.
IMO, first, we must reach a consensus on whether this option is useful for database management, and then we can discuss implementation details.
Regards,
Rodolfo García (kix)
PS. Thanks Jordi, Miguel for your help.
[1] https://docs.db.ripe.net/What-is-the-RIPE-Database/Purpose-and-Content-of-th...
[2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013...
[3] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/MEOS4MD7ZYLVOAW...
The content of this email reflects personal opinions and does not represent the views of any organization.
----- 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/
participants (2)
-
Ben Cartwright-Cox -
Rodolfo García Peñas (kix)