[db-wg] Privacy proposal, concerns

Dennis,

Thanks for getting back to me. See my comments inline.

> On 26 Oct 2022, at 19:37, denis walker <ripedenis at gmail.com> wrote:
> 
> 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 all
> contractually bound to follow policy, and yet only about 50 people
> ever comment on policy discussions, I would suggest that ALL Members
> should be required to affirm that they acknowledge any new or changed
> policy 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 annually
> that they state they are up to date with policy. Then if any policy
> violation is exposed later they cannot argue they were not aware of
> the 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. This
> policy 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 about
> respecting basic privacy. Also arranging data that people are
> comfortable 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20221026/a6439f43/attachment-0001.html>