Hi Denis,

Please find here our response to the request you are referencing: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/43T2BW26I46NOJJ7FYDXW6HDZVK5MRFF/

For your convenience, here is our RIPE Labs article explaining the legal basis for processing personal data in the RIPE Database when it refers to an individual resource holder or their contact persons: 

https://labs.ripe.net/author/athina/how-were-implementing-the-gdpr-legal-grounds-for-lawful-personal-data-processing-and-the-ripe-database/

Kind regards, 

Maria Stafyla 

Senior Legal Counsel 

RIPE NCC

> On 12 Jul 2024, at 12:23, denis walker <ripedenis@gmail.com> wrote:
>
> Hi Nick
>
> You seemed to have mixed up many issues here including privacy, data
> verification, 2023-04, legal basis within GDPR, lawful access, etc. I
> actually agree with many of the points you make. In fact I have made
> many of these points myself over a number of years and generally they
> were all ignored by the community.
>
> You may remember I put forward a policy proposal on privacy and data
> verification a couple of years ago. The verification part was totally
> rejected by the community as it would involve some extra work by LIRs.
> The privacy part was rejected as I suggested using consent as the
> basis of processing personal data in the RIPE Database. Arguments were
> made that it is not processed on the basis of consent, which at that
> time was supported by the legal impact analysis. Then we jump forward
> to 2023-04 where the legal analysis said ALL personal data processed
> by the RIPE Database is on the basis of consent. When I asked the
> legal team to clarify that, they remained silent. So right now we have
> no clear idea on what basis any or all personal data in the RIPE
> Database is processed according to the GDPR. I did suggest the legal
> team writes a very clear statement defining the basis (or bases) on
> which personal data is processed. There was no response to that. I
> still think we need this clearly defined in a way that does not keep
> changing, depending on what policy proposal is being reviewed.
>
> BUT...none of this has anything to do with historical queries. Ed was
> very clear that PERSON and ROLE objects are NOT subject to historical
> queries and never will be. No one will be allowed to sign an NDA and
> get access to this personal data. So although I agree that all of what
> you have said does need to be addressed, it is not relevant to NWI-17.
> Nothing you have said justifies the complexity required to create a
> split level access to historical operational data.
>
> btw it looks like you have taken over my role of writing long,
> detailed emails...that few people, if any, read.
>
> cheers
> denis
>
> ========================================================
> DISCLAIMER
> Everything I said above is my personal, professional opinion. It is
> what I believe to be honest and true to the best of my knowledge. No
> one in this industry pays me anything. I have nothing to gain or lose
> by any decision. I push for what I believe is for the good of the
> Internet, in some small way. Nothing I say is ever intended to be
> offensive or a personal attack. Even if I strongly disagree with you
> or question your motives. Politicians question each other's motives
> all the time. RIPE discussion is often as much about politics and self
> interest as it is technical. I have a style of writing that some may
> not be familiar with, others sometimes use it against me. I also have
> OCD. It makes me see the world slightly differently to others. It
> drives my mind's obsessive need for detail. I can not change the way I
> express my detailed opinions. People may choose how to interpret them.
> ========================================================
>
> On Fri, 12 Jul 2024 at 01:26, Nick Hilliard <nick@foobar.org> wrote:
>>
>> Radu,
>>
>> Radu Anghel wrote on 11/07/2024 20:57:
>>> 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
>>
>> In all these cases, the RIPE NCC is co-processor of the data, and has a
>> responsibility for GDPR compliance.
>>
>>> If the person object is not associated with a resource I see no
>>> problem with the accuracy of the information.
>>
>> I understand where you're coming from on this, but the legal situation
>> is that this doesn't matter: personal data is personal data, regardless
>> of what sort of object it's associated with or whether it's associated
>> with any object at all.
>>
>> Unassociated person: objects are deleted after a period of time. This
>> isn't incidental.
>>
>>> 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]
>>
>> It's totally worth pointing LEAs to data relating to ALLOCATED-PA and
>> ASSIGNED-PI because that will tell them where to serve the summons. But
>> its often pointless for ASSIGNED-PA which makes up the majority of the
>> objects (and consequently the person: objects) in the ripedb.
>>
>> It would help to clarify in the RIPE DB what data is authoritative, i.e.
>> subject to checks, and what sort of checks.
>>
>>> 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.
>>
>> For ASSIGNED-PI and ALLOCATED-PA, the resource holder needs to provide
>> their details, for sure. That would constitute performance of a
>> contract. But that's not the same as publishing it to the world,
>> regardless of what it says in the T&Cs. You can't make the leap from
>> stating that just because the RIPE NCC Privacy Statement says the
>> information will be published, that this implies that "legal basis" is
>> satisfied as a basis for data processing. This is not how GDPR works.
>>
>> The difficulty here is that there is a mixture of PII and non-PII in the
>> database. There's no difficulty with non-PII. The problem is that it's
>> all mixed up together.
>>
>>> 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]
>>
>> You're correct, partly, on company details. For example, role email
>> addresses or telephone main lines are not subject to GDPR. However,
>> individual contact details within a company can be. E.g.
>> Joe.Schmoe@example.com could be considered personally identifiable
>> information, but accounts@example.com definitely not.
>>
>> Consent is complicated in GDPR. Legally it must be possible to withdraw
>> consent without detriment. So if the GDPR basis for processing data is
>> "consent", and the resource holder withdraws that consent, you gotta
>> respect that and nothing can change contractually. This is something
>> that the european data protection board has started taking action on in
>> the last couple of years, and there is now case law to support this
>> position.
>>
>> The rationale behind this is that if there is pressure or coercion
>> involved, then it's not consent: it's pressure or coercion.
>>
>> Consent in GDPR gives the right for a data processor to hold information
>> about a data subject if the subject agrees. But it does _not_ give the
>> data processor the right to withdraw service if that consent is withdrawn.
>>
>> There are arguable points in Legitimate Interest. If this is the basis
>> for publishing the data, then this is why the RIPE Community needs to
>> ensure that the policies and data management practices are assessed,
>> i.e. to ensure that if this information is published on the basis of
>> legitimate interest, then there is careful consideration of this within
>> GDPR, that the policies are compliant with GDPR and that the practice is
>> compliant with the policies.
>>
>> In other words, if the RIPE NCC / RIPE Community makes a claim that a
>> specific legal basis is used for processing data, then the justification
>> for that basis must be analysed carefully and clearly described.
>>
>>> 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.
>>
>> See above on consent and whether personally identifiable information in
>> the context of corporate operation constitutes PII.
>>
>>> 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.
>>
>> You're correct that it doesn't guarantee accuracy, but the ARC is a
>> process which satisfies due diligence, i.e. it's a visible and tangible
>> demonstration that the RIPE NCC is proactive about maintaining data
>> accuracy.
>>
>>> 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.
>>
>> This is one of the issues which the DBTF has recommended to get some
>> attention. The one thing we can all agree on is that it's a difficult area.
>>
>> Nick
>>
>>
>>> 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-business-and-organisations/legal-grounds-processing-data/grounds-processing/what-does-grounds-legitimate-interest-mean_en
>>>
>>> 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
>>> _______________________________________________
>>> db-wg mailing list -- db-wg@ripe.net
>>> To unsubscribe send an email to db-wg-leave@ripe.net
>>>
>> _______________________________________________
>> db-wg mailing list -- db-wg@ripe.net
>> To unsubscribe send an email to db-wg-leave@ripe.net
> _______________________________________________
> db-wg mailing list -- db-wg@ripe.net
> To unsubscribe send an email to db-wg-leave@ripe.net