The EU GDPR, The wrong Equalizer?

We can predict with a large certainty the public WHOIS will be a thing of the past.

This will create issues for two group and a few more, but let’s focus on these two for now:
LEA’s (Law Enforcement Agencies)
Commercial cyber crime fighters, perhaps not the best choice to call them this but as they are very diverse, this seems to cover most of them.

The EU GDPR is somewhat (okay very often) characterized as the boogeyman invented by folks who are so pro-privacy that they lost sense with reality.
This is a misconception. Yes the EU GDPR has been created by an army of lawyers and legal folks that are downright scary in numbers, but they were very much in touch with reality during the process.

The EU GDPR has been forged by the EU directive 95/46/ec and has been challenged in court on a national level and European level by many times. The courts were always trying to strike a balance between privacy and the needs for LEA’s.
Cybercrime is not just something that only happens at the DNS level it is happening on all levels in our society.

Many companies outside of the DNS have been dealing with the EU directives for years and embedded them into their processes when it comes to data collection and data processing. And lets not forget they dealt with Cyber Crime and LEA’s, so far, nothing new.

During the creation of the EU GDPR, many LEA’s were consulted, and this is reflected within the EU GDPR.
For LEA’s there are enough provisions to continue their work.

Commercial cyber crime fighters, what about them?
At first glance and due to one-sided information it looks like these folks are screwed big time. However, this is not the case. The EU GDPR has room, but it requires a legal framework and contractual obligations. I keep this very broad as I am no lawyer, but when you dig through the EU GDPR, you will discover room to operate.

What Commercial cyber crime fighters should not do.
Look at ICANN for help or the EU Data commissioners.
ICANN has a horrible track record when it comes to privacy in general. Not intentional but due to circumstances, but it is what it is. So asking ICANN is not the solution, ICANN requires tons of help regarding the subject of privacy themselves. Like the blind leading the blind here.

EU Data Commissioners
From a high-level perspective, these folks and the Article 29 WG can help. But the problem is that we are dealing with very specific purposes and operational matters, and they cannot zoom into a micro level. And on a macro level, you get the idea that nothing is possible and privacy is blocking everything and anything.

What Commercial Cyber Crime fighters should do.
As a Registrar, we run into practical GDPR issues all the time. The solution? Consult a lawyer that is well versed when it comes to the GDPR and knows the DNS industry well.
Costs money for sure, but hey our business depends on it. And don’t forget many companies outside the DNS already did this in the past, again nothing new here.

The only thing that might be new here is the sudden change in thinking on an ICANN level and a boatload of people who are in desperate need for tailor-made solutions. Again ICANN will not help you out there, neither will the RDS WG at this stage. When it comes to the RDS WG, you will need to bring that knowledge to the table and the solutions. You might get lucky that someone will join us that has deep knowledge about fighting abuse on an operational level and has in-depth knowledge about the EU GDPR and knows exactly what to do.
Personally, I wouldn’t count on that; I would try to get ahead of this.

Personal Experience.

So far my interaction with several lawyers gave me a positive feeling when it comes to the EU GDPR. Just when you are about to smash your head against the wall while yelling:”this cannot be done! or this is going to cost us a fortune!” The lawyers so far always came up with a solution or interpretation of the EU GDPR that turned the issue in a workable solution, ie the EU GDPR is not so black and white as it appears, it actually appears very well balanced, you just need to know the nuances.

If you need a lawyer that knows the EU GDPR and DNS drop me a line, I have worked with several of them over the last few years, not to mention the last few weeks 😉

Theo Geurts ICANN Registrar.

Registrar Stakeholder Group (RrSG) Comment on GAC Beijing Communiqué

The GAC has been making some waves with their latest communiqué and it looks their main purpose is either to delay the gTLD program, or they just did an extremely poor job.

Anyways the Registrar group released this comment. And it is one I support.

In addition to this, you might want to read Philip S Corwin take on this. It’s a very very long read but also a very very good read.

ICANN at the Inflection Point: Implications and Effects Of the GAC Beijing Communique

Anyways here are the comments from the Registrar group.



Registrar Stakeholder Group (RrSG) Comment on GAC Beijing Communiqué
The Registrar Stakeholder Group (RrSG) welcomes the opportunity to comment on the
Governmental Advisory Committee (GAC) CommuniquĂ© from the recently concluded meeting in Beijing. We welcome the ICANN board’s decision to open up the advice to
comment, as the scope and breadth of the advice, merits consideration by the widerICANN Community.
Please note that this comment the views of participating RrSG members, but does not
Necessarily represent the views of any given registrar. Member organizations reserve the
individual right to alternative positions, which may change in the future.
gTLD “Safeguards” and “Categories.”
Section 1(b) and Annex I of the Beijing Communiqué details the GAC advice regarding
new operational requirements (“safeguards”) for all new gTLDs, and more stringent
eligibility restrictions and registry requirements for “Sensitive Strings” and “Regulated
For the reasons enumerated below, the RrSG opposes these measures and urges the ICANN Board to reject the GAC advice proposing “safeguards” and “categories.”

(1) The “safeguards” described in 6,7 and 8 (Annex I, p. 10) represent a fundamental change to the New gTLD program. The program was intended for Generic top-level domains, but the “safeguard” effectively converts the listed applications to Sponsored top-level domains (sTLDs). This is counter to the
original purpose and goals of the New gTLD program.
(2) Many (if not all) of the proposed “safeguards” were considered extensively during the development and implementation of the New gTLD program, as well
as negotiations that resulted in the Draft 2013 Registrar Accreditation Agreement (RAA), and several PDP efforts. These proposals were rejected by the ICANN Community due to questions regarding their effectiveness, and their far-reaching
impact on access and use of domain name registrations. The operational impact of implementing the suggested changes would be far reaching and would fundamentally change the relationship between registries, registrars and registrants. We feel that many of the GAC’s concerns are addressed via the
2013 RAA, which is based in no little part on input from the GAC.
(3) Similarly, the concept of gTLD “categories” and category-specific requirements
was extensively discussed and rejected during the deliberations that led to the
Applicant Guidebook, under the terms of which applicants developed their
business plans and submitted their TLD applications(4) Many of the strings identified in Annex I were not included in the “Early
Warnings” published in late 2012, which would have provided applicants an
opportunity to better understand and perhaps address these concerns.
(5) Many of the strings identified in Annex I represent generic terms. While they
may be considered “sensitive” or “regulated” in a single or few jurisdictions, it
is not appropriate to limit or restrict their use in other jurisdictions. Registries
and Registrars are currently, and will continue to be, obligated to comply
with appropriate local law and regulations.
(6) Many of the strings identified in Annex I represent generic terms that may be
considered a profession in some contexts, but not in others. For example,
.vet could mean “veterinarian”, or “veteran.” There are numerous examples
of these types of multiple meanings, and no compelling reason to justify use
of the narrowest possible interpretation.
(7) Many, if not all, of the proposed “safeguards” are related to the content of
websites (or other services) associated with a domain name registration.
This is outside the scope of ICANN’s remit as the organization charged with
the management of the DNS.
(8) Some applicants have indicated that they will employ specific criteria in how
they run their registry if awarded. This voluntary choice of registry policy is
more appropriate than a top-down decision by ICANN at this late stage in the


Other comments
Additionally, the GAC has noted that it needs more time to consider applications
identified in Section 1(c)(i), and has asked ICANN to place these applications “on hold.”
pending the outcome of Initial Evaluation, until the GAC meets again in Durban (JUL
2013). We would note that this (and any further) delay has the potential for significant
adverse impact on the affected applicants and that the GAC must issue its advice promptly. If the GAC is unable to do so at or before the Durban meeting, we recommend that ICANN allows these applications to proceed.

Governments play an important role in the multi-stakeholder model of Internet
Governance, but the implications of the GAC Beijing Communiqué represents a
fundamental re-write of the New gTLD Program by a single stakeholder at the very end
of a multi-year process.
The mandatory adoption of new “safeguards” and “categories” would have an adverse
impact on the industry, particularly for investors and innovators in the commercial
sector. Non-commercial users would also be affected, as the adoption of “safeguards.” and “categories” could represent prior restraint and significantly impact access and
expression on the Internet. Also, we note that there is nothing particularly novel about
the proposals in Annex I, as they are familiar topics and ideas to veterans of the New
gTLD process. Finally, these changes represent sweeping and fundamental
changes at a this very late phase of the program. We urge the ICANN Board to
reject the GAC advice regarding “safeguards” and “categories.”