Hi Nick, The lack of authentication / checks for creating person objects could indeed be a problem, but I wouldn't choose to remove the requirement for having addresses and phone numbers associated with globally unique numbers because of this. I can think of the following situations: 1) the object is created by a LIR because the person is a customer => the LIR is responsible for maintaining the accuracy of this data according to [1] 2) the object is created by the person => if the object is associated with any resource, a LIR is again responsible for the accuracy 3) the object is created by a third party, not the person, neither the LIR => if the object is associated with any resource it is the LIR's responsibility, as it is their customer If the person object is not associated with a resource I see no problem with the accuracy of the information. I used the LEAs as an example because RIPENCC constantly refers them to the public information available in the database, if such even potentially wrong information did not exist how would the RIPE NCC reply to their requests? [2] I did not suggest in any way that accurate registration details for number resources are legally required in the NL, they are required by the RIPE NCC contracts that comply with both GDPR and NL laws. The RIPE NCC Privacy Statement [3] informs that the database shows registration details and contact information such as names, phones, postal addresses. This is a legal basis to publish these details since you have to agree with it in order to register resources, as a person or organization. GDPR does not apply to company details, and both companies and natural persons agree with this information being published when requesting resources. So there is both consent and a legitimate interest in having this data and publishing it. [4] I understand that some might not want this type of information related to them in a public database, but registering globally unique resources is not mandatory so it is a choice they have to make. There is nobody forcing people to become *-c contacts for resources, it is either their job, so the details except the name are company details, or their choice. Only because the RIPE NCC validated part of the details at some point in time is not a guarantee that ALLOCATED PA is accurate either. Companies and persons (that are LIRs and have ALLOCATED PA) sometimes change addresses or phones and updating the RIPE DB might not be among the things on their to-do lists. So, for the particular case of the RIPE DB, I disagree with this principle, I think that having some potentially wrong data is much better than having an anonymous registry. There is a clear way to trace who is responsible for keeping the data accurate, and procedures to "persuade" them to fix it. It does not really matter if the contact details are found in a person or role object, but I think it is important to continue to have them. Best, Radu [1] https://www.ripe.net/publications/docs/ripe-791/ [2] https://www.ripe.net/publications/docs/ripe-819/ [3] https://www.ripe.net/about-us/legal/ripe-ncc-privacy-statement/ [4] https://commission.europa.eu/law/law-topic/data-protection/reform/rules-busi... On Thu, Jul 11, 2024 at 8:22 PM Nick Hilliard <nick@foobar.org> wrote:
Radu,
there are a lot of things to unpick in regard to personal information in the RIPEDB.
Person objects are not authenticated or checked, except inside the scope of RIPE ARC checks. Second and third parties can create person: objects for people without verification either for the email or phone number. So there are serious questions about the accuracy of the existing data in the database. This alone needs a good deal of attention and where necessary, remediation.
As a general principle, no data is better than incorrect data.
In regard to who uses the data, and what they use it for, LEAs are one of many classifications of RIPE DB data consumers. The data might be of use to them if it's verified (e.g. ARC checks / LIR verification / PI contractual obligations / etc), but for other stuff like unverified person objects, or ASSIGNED-PA objects, there is no guarantee of any form about whether the data is accurate in any way.
In regard to your question, accurate registration details for this data are not a legal requirement in NL, and LEAs do not have statutory access to the data. That said, there's an obligation on the RIPE NCC to ensure that the policies and practices for accessing this data are legal and fit for purpose. That will includes providing access to LEAs within the scope of GDPR in the normal course of events, or e.g. providing access to internal data following a court order.
When the DBTF noted that accurate registration of data and removal of unnecessary data (= data minimisation) from the RIPE DB should be followed up in a way that the DBWG thought was appropriate, they did this because these are legal requirements. In this context, it would be unwise to drop this from the DBWG's list of outstanding tasks.
Nick
Radu Anghel wrote on 08/07/2024 18:36:
I also support dropping NWI-17.
Removing contact information (address/phones) from the database just because "it looks like PII" would get more confused LEAs contacting RIPE and just defeat the purpose of the DB - a way to find contact information for _who_registered_this_resource_.
For GDPR there is the "legitimate interest" when dealing with persons, while company addresses are not PII at all.
Some persons found ways to keep the DB "accurate" regarding phone numbers, among other things, just check out a few examples nic-hdl: haz nic-hdl: fsci
Radu
On Sat, Jul 6, 2024 at 4:33 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Denis,
denis walker via db-wg wrote on 03/07/2024 17:33:
The Task Force (TF) made the recommendation in NWI-17, but did not give any justification for it.
the justification is included in the final DB-TF report which was published as ripe-767. The recommendations in the various NWIs should be read in the context of this report.
The high cost and low (if any) benefit of splitting this data is completely pointless. [...]
My recommendation is that we drop NWI-17.
The DB-TF considerations behind NWI-17 related to GDPR, so this wasn't a recommendation that came out of nowhere. It would be a better idea to do something about the recommendation rather than unilaterally dropping it.
Since 2021, ML has become a thing. It would be interesting to see if any of the LLMs would return anything useful in response to a query along the lines of "provide a list of all database objects containing information which looks like it's PII".
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg