[members-discuss] is the RIPE NCC GDPR compliant ?

Hi Felipe,

thank you for your swift answer. Please see some comments and more 
questions inline.

(to everyone reading my e-mail, apologies for this lengthy e-mail and 
for repeating myself trying to make a point)

On 2/21/19 08:53, Felipe Victolla Silveira wrote:
> Dear Elvis,
>
> Thanks for your email. We haven't forgotten the issues that were 
> raised at RIPE 77 and are working on them (some since before that 
> meeting).
>
> In short, these are not trivial issues. They will take some time to 
> resolve technically and some will depend on community input. But to 
> address your points directly:
>
> 1. Ticketing
> Email is not the only way to open a ticket with the RIPE NCC. You can 
> also use the RIPE NCC Contact Form or one of the request forms in the 
> LIR Portal. This allows for the secure and confidential upload of 
> documentation and avoids the issue you mention regarding links to 
> documents appearing in email responses from the RIPE NCC. When people 
> email us, we actively direct them to upload documents via the LIR Portal.
>
> We are working to address this, although there are limitations to what 
> is possible with our ticketing system. A simple option would indeed be 
> to no longer accept attachments via email, although we would need to 
> balance this against the ability of people to interact effectively 
> with the RIPE NCC.

There are lots of options here. The main concern is that these documents 
are held on the servers operated by a third party and links to these 
personal documents are provided when a ticket is created. I have not 
seen any progress reported in the past 4 months, please provide some 
details about what you have already done in the past 4 months to tackle 
this issue. Are you or zendesk GDPR compliant when providing public 
access to this data without the agreement of the owner of that personal 
data?

So, even if we all agree that the ticketing system has limitations and 
it is wise not to restrict the ability of people to interact effectively 
with the RIPE NCC, the fact that the documents are uploaded to a third 
party's servers (zendesk) and made available for free to anyone that 
knows (or tries to guess) the link is - to me - extremely concerning. 
Why on earth have you changed a very old ticketing system with one that 
is already flawed and limited, I do not understand.

How much money has the RIPE NCC spent for the change from xrtt to 
zendesk? How much is the RIPE NCC paying zendesk yearly?

This issue has been raised by other members as well, even before the 
RIPE 77 meeting. There has been no visible progress, so - as you say you 
are working on this - please provide us with some clarification on what 
you have done already, what needs to be done further and how long this 
work will take. I am asking these details because I believe you have 
been ignoring our requests in the past few months and I am trying to 
assess whether the NCC is even listening to its members these days.


I can come up with a few suggestions, but it is up to the RIPE NCC to 
decide on the implementation.

- One of the suggestions would be to stop processing requests for 
changes that come via e-mail. That is not desirable and I think this 
approach should only be taken if the ticketing system can be fully 
incorporated in the LIR Portal. This is the most extreme solution I can 
suggest - migrate the ticketing system in the LIR Portal and request 
members to use only the portal to communicate with the RIPE NCC.

- another suggestion would be to have zendesk not return any links to 
the attachments. So, once someone sends an e-mail that includes an 
attachment, strip the link to the attachment from the reply zendesk 
sends back.

- another suggestion would be to keep the links in the reply received 
from zendesk but make them available only if the LIR logins with their SSO.

- another suggestion would be to restrict access to 
https://ripencc.zendesk.com/attachments/* from outside the RIPE NCC 
internal network, thus restricting access to those links to anyone else 
but the RIPE NCC.

There are probably many other fixes available. The only thing that 
matters here is that the RIPE NCC does everything possible to restrict 
access to personal documents by zendesk and anyone that has the link 
generated by zendesk - and quickly. It has been 4-6 months since this 
(to me, trivial) issue was reported and there is ZERO visible progress.

>
> In the meantime, as we investigate different options, our staff are 
> removing attachments from the ticketing system manually in order to 
> mitigate these issues.
Manual removal of the attachments from the ticketing system is prone to 
operator failure and as we are all human (and humans make mistakes) I 
believe this is the worse implementation. I hope you can make a better 
effort to have this automated before the next RIPE Meeting and report to 
us before or at RIPE 78. You were doing this manual removal even before 
RIPE 77, so what have you worked on in the past 4 months?
>
> 2. RIPE Database object creation
> We create PERSON objects for new LIRs to make things easier for them. 
> Before they get started with the membership application form, we tell 
> them how we intend to use the information they provide. We also make 
> it clear that they should make sure they have permission to submit the 
> personal data of third parties.

Why do you create person objects and not role objects? Is it not clear 
to the RIPE NCC that generating and publishing private data in the RIPE 
Database may not be not GDPR compliant? What will it take to convince 
you that this is not GDPR compliant?

Shouldn't you have updated your procedure when GDPR got adopted? Was 
there any analysis done by the RIPE NCC CS department on the compliance 
to the GDPR of their internal procedures?

You have been hiding this problem under the carpet by taking the stance 
that you are a data processor and not the data controller. YOU create 
the data and you should be LIABLE for it, I believe.

Has the RIPE NCC discussed with the Dutch DPA 
(https://autoriteitpersoonsgegevens.nl/en/contact-dutch-dpa/contact-us) 
to make sure it is compliant with GDPR? If yes, can you please share the 
results of that analysis?

I am not an expert on GDPR but I believe the RIPE NCC is not doing a 
good enough job to clearly inform members of the type of data it uses 
and for which purpose. Also, I don't think the LIRs are offered at this 
moment a method to provide a proper consent for the processing of the 
personal data. The RIPE NCC needs to receive the consent of the LIR 
before it publishes personal information in the RIPE DB on its behalf 
and this consent must be informed and unambiguous - this is currently 
not the case, I believe.

>
> Since before GDPR became an issue, our systems have created 
> person-maintainer object pairs - we are looking at the implications of 
> changing this to require role-maintainer pairs. Most of our work 
> regarding the database over the past several months has focused on 
> implementation of NWI-5 (out-of-region objects) and abuse-c 
> validation, which was requested by the community. In 2019, we hope to 
> be able to dedicate more resources to furthering work on the areas you 
> identify. However, we also have to consider the wishes of the community.

You make it sound like you have always done things this way and 
therefore there's nothing that needs to be changed. I do not remember 
when the NCC started creating person objects in the RIPE Database once a 
new member signs up but this procedure should have been evaluated 
closely when you made your legal analysis you mention below. You are 
GENERATING personal data and publishing it to the RIPE Database to then 
tell the LIR - you are maintaining it so you may not be GDPR compliant, 
not us. How long do you plan to continue doing things this way before 
you seriously evaluate your procedures?

As a side note, has the RIPE NCC attempted to contact the 
LIRs/maintainers that publish/maintain the rest of the personal data in 
the RIPE Database to tell them they may not be GDPR compliant? Or is the 
RIPE NCC just waiting for one of the LIRs to be sued for possible 
non-GDPR compliance before they react?

>
> Our legal analysis of the RIPE Database and GDPR was based on input 
> from RIPE community members. It essentially said that personal data is 
> entered into the database for a specific purpose – to support 
> coordination between network operators, which can be vital in the 
> event of an outage or security incident.

While I agree that contact details for a company are needed and very 
useful, I also believe that a role object instead of a person object 
should have been used since the 25th of May 2018. Most members will have 
a department handling technical or abuse issues and not a specific 
person. Actually, even before I started working for the RIPE NCC, while 
attending an LIR Training more than 15 years ago, the RIPE NCC had 
identified issues with linking person objects to resources and was 
recommending LIRs to use role objects to identify the technical contacts 
(admin-c/tech-c) of a company.

In today's world it is very rare that a person will be stuck doing the 
same job for many years or decades. People leave companies, advance to 
other positions, etc. Data entered in the RIPE Database is usually 
entered once and forgotten. Stale data is, I believe, the norm and not 
the exception. Even the RIPE NCC had identified this issue 15-20 years 
ago and a solution should have been found by now. Moreover, if YOU 
create data in the RIPE DB, YOU should maintain it and be LIABLE if this 
data is not compliant with GDPR.

If someone (LEAs and the likes) wants to know the person behind the 
resource, they can request this data from the country registrar of that 
company (the LIR). They can also get a subpoena and request the RIPE NCC 
to provide the name of the person that has signed the contract on behalf 
of that LIR. If a network operator needs to know who is behind a 
resource and they are not happy with just the company details, they can 
either use the contact details from the role object to ask for these 
details or query the company registrar in the country that company was 
registered. If the company registrar does not provide that data, why 
should the RIPE NCC?

>
> At RIPE 77, the question was raised in the Database Working Group 
> whether PERSON objects are really required. If this is the case, then 
> it affects our legal analysis. However, we can't decide this ourselves 
> - we will need the community to make this determination. As we 
> understand it, the community will be looking at this issue closer in 
> 2019 - and we will be watching and supporting this process.

Even the RIPE Chair was surprised that all these person objects (over 1M 
objects) have slipped through the GDPR legal analysis. Now I realize 
that SOME of these objects are actually created by the RIPE NCC and 
liability is immediately transferred to the LIR because the RIPE NCC 
uses the LIR's maintainer and will then say that they do not maintain 
the data. The general agreement during the RIPE 77 DB-WG session was 
that all this data is probably not GDPR compliant. How long is the RIPE 
NCC going to ignore this issue (as creators of some of this data)? Dear 
Hans, can you step in or is this the Board's responsibility and liability?

Is there fine print in the SSA that states that data registered in the 
RIPE DB by the RIPE NCC in the name of the LIR becomes the LIR's 
responsibility? Is the LIR through the SSA agreeing that the NCC can 
create data that may not GDPR compliant and take liability for this 
data? If such a statement exists in the SSA, can you please point to the 
link/article?

Can a single LIR sue the RIPE NCC for registering GDPR non-compliant 
data in the RIPE DB on their behalf? I believe one of the board members 
(Remco) told me at some point that thousands of LIRs need to agree 
before the RIPE NCC can be sued in front of a Dutch court. If that is 
true, the RIPE NCC can do whatever they want and still not risk any 
liability because I doubt someone can get thousands of LIRs to agree to 
a trial. Maybe someone from the Board can join this conversation. Remco, 
care to share your (or the Board's) opinion?

ICANN has already been going through a legal struggle to keep this data 
public and in the whois. Their "Temporary Specifications" have stripped 
all the personal data meanwhile. When is the RIPE NCC going to do the 
same and attempt to be GDPR compliant?

https://www.icann.org/news/announcement-2018-05-25-en

>
> Regarding your final point, our systems were never intended to cater 
> to multiple LIRs and so the duplication you mention is a natural 
> consequence of this. When thinking about changes to fix the issue, we 
> need to consider the wisdom of spending resources to cater to this 
> sub-set of members instead of improvements that would benefit the 
> wider community and membership.

So, please explain to me who is liable for this data that you register 
in the RIPE DB. The LIR does not register the personal data in the RIPE 
Database, it is the RIPE NCC registering this data in the RIPE Database. 
Why on Earth are you using the LIR's maintainer to create data in the 
RIPE Database? If YOU create this data, YOU should maintain it. Why are 
you using MY maintainer to create data in the RIPE Database that may not 
be GDPR compliant?

What other data do you create in the RIPE Database by *overriding* a 
company's (LIR) maintainer? I do not want the RIPE NCC to use my 
maintainer to create data in the RIPE Database and I doubt I ever gave 
the NCC this permission but this may be mentioned in the fine print 
which I missed, and if so, please let me know the article in the SSA 
that allows the NCC to do exactly that.

Lastly, I think you are making too much of a big fuss about the multiple 
LIR issue. You have known about the possibility that people/companies 
can create multiple LIRs even before the runout in 2012. WHY is the RIPE 
NCC creating duplicate data when they could easily reuse for LIR[2-n] 
the data they have already registered for LIR1. How hard is it to 
include in the CS procedures another step where if a company registeres 
a 2nd or a nth LIR, CS will re-use the same data from LIR1?

To clarify, are you saying that you prefer to create duplicate data 
instead of changing a simple procedure and adding one extra step, just 
because you think this will spend resources of the NCC? I am baffled by 
your response to this issue and I hope you will evaluate all of the 
internal procedures and fix them.

Kind regards,

Elvis

-- 
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: elvis at v4escrow.net
Mobile: +1 (702) 970 0921

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20190221/99e49975/attachment.html>