Thanks for getting back to me. See my comments inline.
Hi Frank
First of all I would like to thank you for joining this discussion.
With any policy discussion it is important to get as wide a range of
views as possible. We also like to hear from people who use the RIPE
Database to get a better understanding of who uses it and for what
purpose.
There has been a lot of misunderstanding over what this policy
proposal is about...and what it isn't about. Let's split it into
privacy and verification. On the privacy side there is no suggestion
at all that we leave resources without valid contacts.
I’m happy to hear that it is not you intention to remove contacts from te database. But I am worried that an incorrectly worded policy may have that result. If RIPE NCC adopts a policy in which it states that in order for PII to live in the DB it needs permission from the subjects, then subjects may hold RIPE NCC to this policy forcing RIPE NCC into a position where it has to make a choice.
If there is a
contact listed in the database you can use it to make reports. It is
not your responsibility to determine if it is a personal or business
contact.
Understood.
One of the main aims of this policy is to slowly change the
mindset of resource holders away from entering the personal details of
their staff as contacts and to switch to using business contact
details. When the RIPE Database was first established, privacy on the
internet was not a concern. By default, users would just enter
personal details for contacts. We currently have the personal details
of around 2 million people in the database. It is still growing by
several thousands per month. In almost all of these cases, 'personal'
details are not needed. There has to be a way to contact resource
holders and network operators, but not using your home address or
private phone/email.
This is a great aim, but right now the proposed policy doesn’t state this. It clearly states that RIPE NCC is going to move to a permission model.
A large proportion of resource holders and end users are corporate
bodies. Where they have entered corporate contact details, nothing
will change.
Again this is not what your policy states. You policy states that you should not enter PII and even somebodies corporate email address is PII. Also an abuse@ address of a company with a single owner/employee is PII. And if you say you will only process PII if you have permission, that is what you have to do.
Where they have entered personal details of staff, they
will need to change this to business information. Names of contacts
are the only bit of personal information that a public registry must
have. People argue that personal information is OK if people consent
to it. But is it really informed consent? This is an open, public
database, accessible by anyone connected to the internet. It has
personal details of 2m (technical) people. It can be easily (and
probably is) data mined on a daily basis. Once you put your details
into this database you have irreversibly broadcast them to the world.
Again this is a very good thing to do. One of the key principles in GDPR is data minimisation and you are going to practise this.
It is funny that you mention consent, because consent is only consent if it is not conditional.
If somebody approaches RIPE NCC stating they did not give permission their details have to be removed from the DB. RIPE NCC cannot stop their registration because that would mean that consent was not free consent.
The policy is not based on GDPR specifically. In fact GDPR is not even
mentioned in the policy text. Privacy rules existed before GDPR. The
driving force behind this policy is the unease of a number of
individuals that are concerned about having their personal data in the
database.
But one has to consider the consequences of switching to a consent model under GDPR. And with GDPR in effect this is an ill advised move.
During this discussion some people have suggested those who
are concerned about privacy could enter misleading information like PO
boxes as addresses. Even maybe totally false details. We know there is
a lot of false data in the database. But how can you build a public
registry and advocate entering false data to overcome privacy
concerns? Some investigators have said that even false data is useful
if it has been used consistently. They can still do pattern matching
on the false data. When the conversation goes down that path it is
clear something is wrong.
Agree, this needs to be addressed.
The RIPE community has no legal definition, no legal authority, no
membership. It is made up of anyone who wants to be a part of it
today, perhaps gone tomorrow. This includes the good, the bad and the
ugly. All those operators who take internet safety seriously are a
part of this community. But so are those who provide services to the
abusers, even those involved in criminal activities. They all have an
equal say in policy discussions. This makes policy development very
difficult.
Then we come on to the verification. You sent an email to this mailing
list, exposing your email address. You referenced your web url. On
that site you have a phone number and postal address. Anyone can now
create a contact object (PERSON or ROLE) in the RIPE Database
containing your name, address, phone and email details. That object
can be referenced from any address space object, suggesting that you
and your organisation are the legitimate contact for that address
space. Maybe those addresses are involved in the worst kind of
activity possible on the internet....and you are the contact. Unless
you regularly search the database for your details to make sure no one
has done this, the first you will know about it is when some
investigators turn up at your office to question you. This is because
anyone can enter these details into this database without the need for
any verification. This policy says you can only enter a phone number
if you are holding the phone in your hand. Only enter an email address
if you have control over it. The policy also suggests we don't need
addresses for contacts. So it prevents the worst of these types of
abuses of your details. There has been so much public debate in recent
years about big tech companies abusing personal information.
Verification has become a part of daily life...except in the RIPE
Database.
Verification is a good thing, no objections (you honor ;) )
But RIP NCC is setting itself up for a lot of trouble by going to “permission” as the GDPR ground for processing instead of “legitimate interests pursued by the controller”
The policy isn't based on GDPR, but if it was I would suggest'legitimate public interest' rather than the controller's interest.
The policies base doesn’t matter to the effect such a policy has under GDPR. And yes, legitimate interest of the public is even better. We also use it for DIVD.
Especially this line in the proposal can be explained as such:
“All organisations holding resources allocated or assigned by the RIPE NCC, or documented in the RIPE Database, must sign a declaration that they have read and understood this policy and that either all the data for their organisation and resources contained in the RIPE Database is fully compliant with this policy or they are working towards full compliance.”
Considering we have around 15k to 20k RIPE NCC Members who are allcontractually bound to follow policy, and yet only about 50 peopleever comment on policy discussions, I would suggest that ALL Membersshould be required to affirm that they acknowledge any new or changedpolicy annually when they are invoiced for membership.
What is the consequence of not signing this policy. If it is nothing I wish RIPE NCC good luck. If it has consequences it doesn’t count as ‘consent’. And if enough people do sign it, it creates a president that allows those with bad intentions to have their details removed.
With this statement in the policy it is quite possible that RIPE NCC at some point will have to choose between two evils:
a) Either revoking all resources of those parties that did not sign a declaration
b) Removing all PII of those parties from the database.
Action does not need to be taken, just get the reaffirmation annuallythat they state they are up to date with policy. Then if any policyviolation is exposed later they cannot argue they were not aware ofthe new policy.
But RIPE NCC may be forced to take action at some point either by an activist, a person in the database with bad intentions or a regulating body.
What would the impact be?
I analyzed 7476 IP addresses that popped up in a certain case using ripeSTAT and whois (see attachment)
458 Afrinic
1052 APNIC
1277 ARIN
190 LACNIC
4090 RIPE
409 no RIR in ripeSTAT abuse finder API
I marked all email addresses that were not clearly a “function”/group/department mailbox as personal.
If we could not report to email addresses that were personal we would not be able to report abuse to 929 out of 7476 ip addresses. (~12%)
201 of these IP addresses belong to the rir RIPE. (of the 4090 marked as belonging to RIPE, about 5%)
180 of these come from the ripeSTAT API, so they come from a CONTACT record, not a PERSON record.
In only 21 cases I had to resort to whois to get a PERSON record.
You can send your reports to any contact you see in the database. Thispolicy does not affect you in this way.
Until those objects disappear from the database for one reason or the other.
Conclusion:
A small but significant portion of “abuse” addresses are “personal”
Most of these are in CONTACT records not PERSON records.
Besides these email addresses, RIPE NCC will have to do the work to be GDPR compliant for other PII anyway. IP addresses are considered PII in The Netherlands, a work/group phone number/email can still be PII, e.g. in the case where the company is a single person company or the company name can be traced back to a natural person, so going this route creates a lot of work and doesn’t actually reduce the compliance load on RIPE NCC.
As I said, this policy is not about GDPR compliance. It is aboutrespecting basic privacy. Also arranging data that people arecomfortable with so there is more chance they will enter correct data.A reliable database with valid data is in everyone's interest.
Agree. I’m worried that this policy will have a negative impact in the long run.
cheers
denis
policy author