> > Hi Denis, > > Please find here our response to the request you are referencing: > https://mailman.ripe.net/archives/list/[email protected]/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 <[email protected]> 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 <[email protected]> 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. > >> [email protected] could be considered personally identifiable > >> information, but [email protected] 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 <[email protected]> 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 < > [email protected]> 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 -- [email protected] > >>> To unsubscribe send an email to [email protected] > >>> > >> _______________________________________________ > >> db-wg mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > _______________________________________________ > > db-wg mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
----- 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/
