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]
