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-the-RIPE-Database/
[2]
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013860.html
[3]
https://mailman.ripe.net/archives/list/[email protected]/thread/MEOS4MD7ZYLVOAW4OESVMGWLSSV2CYLA/
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/
