In our previous articles on how we are implementing the GDPR and the RIPE Database, we looked into:

• Whether the processing of personal data published in the RIPE Database is justified by the purpose of the RIPE Database; and
• The legal basis for processing personal data in the RIPE Database.

We have concluded that the processing of personal data is in line with the GDPR and no changes are necessary in this regard.

In this article, we’re taking a closer look at the queries the RIPE Database allows; we will conclude that some amendments are necessary to ensure GDPR compliance.

Historical Queries in the RIPE Database

The Data Protection Task Force (DPTF) reviewed the option of publishing in the database historical information about resources that were previously distributed to resource holders, along with the relevant contact persons for these networks.

The purpose of publishing contact details is to make sure network operators can communicate on issues that occur in the present (see our previous article), so this does not justify the publication of outdated contact details. The DPTF concluded that the RIPE NCC had to remove non-current contact persons from the RIPE Database.

Although the RIPE NCC has complied with this, we now realise that outdated contact persons were not the only personal data returned when querying historical information (historical queries).

NIC Handles

Historical queries still return references to NIC handles of historical role and person objects.

Every person and role object is identified by a NIC handle. Historically, NIC handles were available to be reused as soon as an object was deleted. Many NIC handles have been used and reused by several different people. In 2009, a new rule was introduced to the RIPE Database which meant that if a person object was deleted, it was not possible to create another person object with the same NIC handle.

With regards to historical queries, if a historical person and/or role object exists in the RIPE Database, a user will be able to identify the relevant individual that was previously the contact person responsible for the administration or technical maintenance of specific Internet number resources and networks. Since it was possible to reuse NIC handles up until 2009, it is also not certain that the NIC handle refers to the person or contact that was using that NIC handle in the historical reference.

This is not in line with the data protection legislation, nor is it justified by the purposes for making personal data publicly available in the RIPE Database that were previously identified (i.e. “facilitating coordination between network operators (for network problem resolution, outage notification etc.”))

Contact Details of Resource Holders/Natural Persons

Holders of Internet number resources may be either natural or legal persons. Currently, the RIPE Database returns all contact details of resource holders, including historical resource holders.

As in the above examples, returning the historical contact details of resource holders that are natural persons cannot be considered as in line with the purpose of the RIPE Database and therefore, not in line with the data protection restrictions.

While aiming to strike a balance between the interests of the RIPE community in having access to historical information about resource holders (e.g. to help investigate how past network outages were resolved, spamming, DDoS attacks, etc.) and the legal obligation to comply with the data protection regime, we believe it is necessary to filter out the contact details of historical resource holders.

Following internal discussions as to how this could be implemented efficiently from an operational perspective, we believe that the results to historical queries can be brought into alignment with the rules applied when the RIPE Database is provided via FTP files. By this, attributes that may contain personal data will be filtered out, such as “address”, “notify”, “e-mail”.

We believe that this solution will serve to adequately provide historical information of Internet number resource registrations, while taking into account the restrictions placed on us with regards to personal data processing.

Queries for Individuals

At the moment, any user may search the RIPE Database based on any search term, including an individual’s first and/or last name. The results will return all objects containing at least one of the search criteria. Searches on individuals performed on the web interface (screen page) will return by default the complete object details.

The RIPE Database Acceptable Use Policy sets limits for the use of RIPE Database services and the number of personal data sets returned in queries from an IP address. However, from a data protection point of view, this search functionality could be considered excessive, as there are not enough restrictions against unauthorised access to personal data contained in the RIPE Database.

To tackle this issue, it is recommended that results to queries for individuals be restricted. As a first step, it is recommended that the default search settings in the RIPE Database are changed (both screen search and full text). Specifically, the default would be changed to “Do not retrieve related objects” and “Do not show full object details”.

In this way, related objects will not be returned by default for such a search, while the user will still be able to identify the relevant contact person when this is necessary for an operational purpose.

Getting the Consent of a Contact Person when the RIPE NCC Creates a RIPE Database Object

According to the GDPR, when personal data is processed based on an individual’s consent, it is the legal obligation of the controller to obtain this consent and be able to demonstrate that the data subject has consented to this processing.

According to the RIPE Database Terms and Conditions, Article 6.3, “The Maintainer who enters personal data into the RIPE Database has a responsibility to inform the individual to whom the data pertains and to obtain his/her explicit consent for the entry in the public RIPE Database if required by law.”

During the membership application process, an applicant is requested to provide, amongst other information, the contact details of those persons that will be appointed as the tech-c and admin-c for this organisation in the RIPE Database.

Given that it is the RIPE NCC that creates these initial RIPE Database objects for organisations that apply for membership, we are currently investigating how we (the RIPE NCC) could modify our process to include a verification mechanism. This would allow us to demonstrate that the relevant individual has consented to this processing before a person object is created for them.

Conclusion

We will keep the RIPE community informed and up-to-date about these changes, and about their operational implementation.

If you wish to discuss this in more detail, or if you have any feedback/input on these changes, feel free to join us at the Database WG session at RIPE 76 on Wednesday, 16 May. You can also send your input to the Database WG mailing list, or leave a comment below.