Hi there, That's interesting. Does it mean that services providing contact information for abuse (e.g. https://ipinfo.io/abuse) are legally wrong? are you going to take any action? Regards, Laurent Le lun. 7 oct. 2019 à 12:38, Edward Shryane via db-wg <db-wg@ripe.net> a écrit :

Dear Working Group,

We implemented and deployed the changes below for GDPR compliance as part of Whois 1.95.1, on the 18th September:

https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rele...

Apologies if this was not clear.

Regards Ed Shryane RIPE NCC

On 27 May 2019, at 11:30, Edward Shryane via db-wg <db-wg@ripe.net> wrote:

Dear Working Group,

as mentioned in last week's DB-WG meeting, we will shortly be implementing the following changes:

- Do not include personal data in historical queries (notify, e-mail, address attributes). - Do not include person/role references in historical queries (admin-c, tech-c, ping-hdl, zone-c).

A legal review found we should not return historical contact details, as they may contain personal data, which is not in line with the purpose of the RIPE database or data protection legislation.

For background, Maria Stafyla from RIPE NCC Legal presented on this topic at RIPE 76: https://ripe76.ripe.net/presentations/101-GDPR-Database-WG-RIPE-76.pdf

Regards Ed Shryane RIPE NCC

Hi Laurent, We do not filter out contact information for abuse with this change (i.e. the "abuse-c" attribute is still included in historical queries). Regards Ed

On 7 Oct 2019, at 14:19, Laurent Pellegrino <laurent.pellegrino@ipregistry.co> wrote:

Hi there,

That's interesting. Does it mean that services providing contact information for abuse (e.g. https://ipinfo.io/abuse <http://email.mailgun.ipregistry.co/c/eJwdjbsOgjAAAL-m3SDQWtChA0IIISCbRhfTF9LIyxYQ_l5icrncdpJKwTDCUNM4ym93w_3qEhckXjNWJtUafNKszJz09pAc4OSaL1sxb87Tnt4LQGdHfMHB65hu3dffYuhgQ2uuQsKxJIJzjxB1lL7HUEgwQlgGdQBb2kzTaAGOAEp39Kj7enD1sDfjs1XQUGUbs7Fe7QOjR-X2avoBd-Y3FA>) are legally wrong? are you going to take any action?

Regards, Laurent

Le lun. 7 oct. 2019 à 12:38, Edward Shryane via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> a écrit : Dear Working Group,

We implemented and deployed the changes below for GDPR compliance as part of Whois 1.95.1, on the 18th September: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rele... <http://email.mailgun.ipregistry.co/c/eJw1jkGLgzAQhX9NvEVsoi495NC1iEi7vW3pXpYxM1RZjTZJa_33GwuFx4P3PWZ4qFCDFDLqVLGrzxfbbE5fxSErnhUc96dnfiurY8XL8w82TO6_68dyuC_8123_Hkx8cj2zNBmg6-Pry_U4RK3SmOgPLUhSRjlgCtRkAmVCGnWeJjLqVev95JjcMVEGzfMc226i2JAPcQADV-Ld5DgY5OCMCzQsEKWlnsARN6OnFa5XHMFDs9J3u4m3WWQVudYuYChsfH__B09pTvg>

Apologies if this was not clear.

Regards Ed Shryane RIPE NCC

...

On 27 May 2019, at 11:30, Edward Shryane via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:

Dear Working Group,

as mentioned in last week's DB-WG meeting, we will shortly be implementing the following changes:

- Do not include personal data in historical queries (notify, e-mail, address attributes). - Do not include person/role references in historical queries (admin-c, tech-c, ping-hdl, zone-c).

A legal review found we should not return historical contact details, as they may contain personal data, which is not in line with the purpose of the RIPE database or data protection legislation.

For background, Maria Stafyla from RIPE NCC Legal presented on this topic at RIPE 76: https://ripe76.ripe.net/presentations/101-GDPR-Database-WG-RIPE-76.pdf <http://email.mailgun.ipregistry.co/c/eJw1Ts0OgjAYe5pxG2FsiB44KAho_IsHiV7MNzaEqIjb_OHtnSYmTZs2aVMRiRKoT50misfzYq84Wa_iRRC_c1gm6_fgnubLHKfFQXBEk9382S8ePT7q0fmJ_AkuX4h5V2gu7unH5e3q1HaT0JAwIhknvgiZCDiDqmR8GFQegdC5RLUxnUZ0jPzUQjWdDAfuV9xWGpt0SmrZGjDNrdXWE4_gLNlscQIGOGiJiwxvZ5sptr1OVI6KpK5VD620j_5DH0yQRmQ>

Regards Ed Shryane RIPE NCC

In message <FAF10ECC-9DCE-4CCE-8289-A8BB416152DA@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:

We implemented and deployed the changes below for GDPR compliance as part of Whois 1.95.1, on the 18th September:

https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rele...

Could you please provide some additional and detailed clarity on exactly what will and what won't henceforth be hidden? Neither the page you referenced nor the RIPE 76 presentation slides perovide any real clarity about what has changed, exactly, much less how, or whether the needs of legitimate historical research were taken into account when deciding on the implementation specifics. There is obviously a great desire, in some quarters, at least, to hide everyhing as much as possible. This applies to both governments and to quasi-governmental organizations such as the five RIRs. To the extent that this is motivated by legitimate privacy concerns, as promoted by GDPR, this is reasonable and desirable. To the extent that this is motivated by a desire to mask malfeasance it is not. The devil is in the details. Is access to historical person and role informtaion being totally wiped out entirely, or are the fine details that some would consider private and personal information merely being elided? The latter is justifiable, under GDPR, and based upon a reasoanble concern for the privacy of the individual. The wholesale "disappearing" of history is however not justifiable. If the name of a person, the final four digits of the person's phone number and the <<userID>> part of a person's exact email address are elided, then this is both eminently reasonable and arguably required under GDPR. Anything beyond that becomes reminicent of Winston Smith, cutting and pasting old newspaper stories in order to adjust history in accordance with the preferences of The Party. Regards, rfg

In message <D4BA4569-D818-4218-BC57-E62AB53773EF@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:

The two changes we recently implemented were:

(1) Do not include personal data in historical queries (notify, e-mail, address attributes). ... (2) Do not include person/role references in historical queries (admin-c, tech-c, ping-hdl, zone-c). ... I hope the Labs article clarifies why we made these changes.

Not entirely, but that's rather besides the point. I didn't actually ask -why- you had made the changes you made. I asked what the changes were. And the above quotes from what you wrote do go a long way towards answering that question, so I thank you for that. I would like to reiterate again that, based on the changes as you have now described them, it is my concerted opinion that by these changes, NCC has effectively engaged in massive overkill in this blunderbuss attempt to reasonably comply with GDPR, much to the detriment of legitimate historical research and legitimate historical researchers. Not that this is anything new. The past 15 years or so have been a long slow march towards hiding everything from everyone, most especially in the domain name space, and the records for IP space allocations are, with sad predictability, now being burried in obscurity by lawyers also. I suppose that it is necessary to continue along this gradual downhill slope, even though the ultimate endpoint is utterly predictable. I have never been one for either mincing words or for half measures, and I would actually prefer it if those behind GDPR, and thus, indirectly, behind these changes would at least display the intellectual honesty to admit that the ultimate goal is to kill WHOIS entirely, both for the domain name space and for the IP address spaces. I would also have a bit more respect for those ultimately behind these changes if they would just get it over with, right now, and in one fell swoop. But I suppose that the politics of the situation demand this continued slow grinding down towards the ultimate endpoint, lest there be some popular outcry against a sudden rapid shift towards that obviously intended outcome. Regards, rfg P.S. The act of delving into WHOIS records, either historical or current, on the part of researchers is often motivated by a desire not to locate personal information but rather a desire to locate correlations. It is a reaosnable basis for some suspicion, and perhaps even further exploration, if a given party or entity, regardless of their specific identity, is seen to be claiming to simultaneously operate networks in, for example, Belize and also the Seychelles Islands. The changes that have been made, ostensibly for GDPR compliance, unambiguously and demonstrably destroy many opportunities to make or notice such important correlations. They need not have done so in order to be in full compliance with GDPR. The data that has now been made utterly unavailable could instead have been subjected to a one-way irreversable hash, along with some additional secret string, known only within NCC, and the results of such hashes could have been substituted for the actual data values. This would not by any means have been technically challenging, and it would have preserved the ability of reserchers to note potentially meaningful correlations, even while providing complete GDPR conformance. Instead however, as is routinely the case in the domain name space, those tasked with insuring GDPR conformance elected instead to pursue the most expedient method of achieving this conformance, which they evidently did by throwing the baby out with the bathwater and just willy-nilly making all data utterly unavailable in any form. While this may have lightened the load modestly within NCC, it is not and should not be a cause for celebration elsewhere, except of course in and among the online cybercriminal community.