[db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database

Hi Athina

Thanks for the review. But to use an English colloquialism, I beg to 
differ :)

As you know I was part of the Data Protection Task Force and I have 
quite a good understanding of data protection and the RIPE Database. You 
seem to have missed the conversation between Piotr and myself which goes 
against some of your points. Also you contradict yourself.

On 20/04/2016 12:33, Athina Fragkouli wrote:
> Dear Denis, all,
>
> The RIPE NCC is by default the "data controller" of the personal data
> in the Database (i.e. it has liability by law) but in practice it has
> no control over all these personal data.

That is not entirely true. For example the DPTF agreed that unreferenced 
PERSON and ROLE objects and PERSON/ROLE paired with a MNTNER and nothing 
else should be deleted after 90 days. This auto delete functionality was 
disabled a few years ago. Has it been re-enabled now?

  The Data Protection Task
> Force, representing the RIPE community, decided that this
> responsibility should be contractually (via the RIPE Database Terms
> and Conditions) transferred to those that have actual control over
> the personal data.
>
> In the RIPE Database, these persons are identified by the maintainer
> object (referenced by the “mnt-by:” attribute in any data object).
> The Data Protection Task Force decided that this attribute should be
> made mandatory for all objects. This attribute would be used to
> indicate who is really responsible for specific personal data in the
> RIPE Database. Additionally, the Data Protection Task Force decided
> that the RIPE NCC should remove all unreferenced personal data from
> the RIPE Database.
>
> Although the RIPE NCC allowed some time for the community members to
> add a mandatory "mnt-by:" to their so-far unmaintained personal data,
> there were still unmaintained personal data in the RIPE Database. The
> RIPE NCC was alerted by third parties that this data could be
> hijacked in order to facilitate illegal activities.

This point was discussed with Piotr and he said the risk of hijacking 
has been known about for many years and has nothing to do with personal 
data being maintained or not. He said it is very easy to 'get' id to 
match any maintained personal data in the database.

>
> It was the RIPE NCC's responsibility to inform the RIPE community of
> this security risk and initiate a community discussion on possible
> ways to handle it.

Although the community has been aware of this risk for many years.

At the same time, the RIPE NCC could anticipate
> that if we were merely exposed the security risk without taking any
> measures to prevent it, we would alert malicious people and the
> hijacking attempts would increase.

But the community was already aware of this risk and 'being maintained' 
makes no difference to the risk.

>
> Therefore, we considered that locking the objects, until the
> community could discuss a proper way forward, would be an adequate
> measure to prevent possible hijacking cases in the meantime, without
> creating a disproportionate burden for legitimate holders. This
> action was in line with the RIPE NCC's obligations by law.

As Piotr stated, being maintained, or locked, makes no difference to the 
risk of hijacks.

But now consider the situation you have created by locking almost a 
million personal data objects. As you pointed out in your reference to 
the database Terms & Conditions, much of which I wrote, Article 6.2 
states, "The Maintainer is responsible for keeping all data maintained 
by him accurate and up-to-date". Who is the maintainer now of these 
million objects? The RIPE NCC, as it is their MNTNER that now protects 
them. So in effect the RIPE NCC has bypassed the legal protection it 
tried to give itself with contracting out the maintenance, by adding 
it's own MNTNER to these objects.

So also according to Article 6.2 the RIPE NCC is now responsible for the 
accuracy of this data and it is the responsibility of the RIPE NCC to 
ensure that these data subjects are aware that their personal data is 
held in this database by the RIPE NCC.

If it was a handful of objects I don't think anyone would be concerned 
while measures were taken to sort out the situation. But this is almost 
a million personal data sets. The RIPE NCC has no idea how accurate any 
of that data was at the point when you locked it as it has been 
unmaintained for many years. It may personally identify legal persons 
and show the wrong information that the data subjects do not want to be 
public now. This is now your responsibility.

>
> If people would like to have their locked personal data removed from
> the RIPE Database, they can submit a request to the RIPE NCC.

It was made clear in Trudy's original announcement that the RIPE NCC 
will not unlock any of these objects as it is not possible to identify 
the data subjects. So by what criteria are you going to accept deletion 
requests?

I think you need to consider my suggestion in an earlier email:

1/ Immediately unlock these objects and revert the responsibility for 
them back to the resource holders who reference them, as they have no 
direct maintainer.
2/ Immediately remove any references to unmaintained objects where 
references to other, maintained, objects fulfil syntax and business rules.
3/ Ensure the auto deletion of unreferenced personal data objects after 
90 days is currently enabled.
2/ Aggressively pursue the resource holders who reference the remaining 
unmaintained objects to maintain them.

cheers
denis

>
> Kind regards,
>
> Athina Fragkouli Head of Legal RIPE NCC
>
>
> References: RIPE Database Terms and Conditions
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms
>
>  DPTF report
> https://www.ripe.net/participate/ripe/tf/dp/report-of-the-ripe-data-protection-task-force
>
>  Data Protection report
> https://www.ripe.net/about-us/legal/ripe-ncc-data-protection-report
>
> Procedure for the Removal of Personal Contact Details from the RIPE
> Database
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/removal-of-personal-data
>