Skip to main content

Europe's GDPR Meets WHOIS Privacy: Which Way Forward?

DEEPLINKS BLOG
January 26, 2018

Europe's GDPR Meets WHOIS Privacy: Which Way Forward?

Europe's General Data Protection Regulation (GDPR) will come into effect in May 2018, and with it, a new set of tough penalties for companies that fail to adequately protect the personal data of European users. Amongst those affected are domain name registries and registrars, who are required by ICANN, the global domain name authority, to list the personal information of domain name registrants in publicly-accessible WHOIS directories. ICANN and European registrars have clashed over this long-standing contractual requirement, which does not comply [PDF] with European data protection law.

This was one of the highest profile topics at ICANN's 60th meeting in Abu Dhabi which EFF attended last year, with registries and registrars laying the blame on ICANN, either for their liability under the GDPR if they complied with their WHOIS obligations, or for their contractual liability to ICANN if they didn't. ICANN has recognized this and has progressively, if belatedly, being taking steps to remediate the clash between its own rules, and the data protection principles that European law upholds.

A Brief History of Domain Privacy at ICANN

ICANN's first step in improving domain privacy, which dates from 2008 and underwent minor revisions in 2015, was to create a very narrow and cumbersome process for a party bound by privacy laws that conflicted with its contractual requirements to seek an exemption from those requirements from ICANN. Next in 2015, ICANN commenced a Policy Development Process (PDP) for the development of a Next-Generation gTLD Registration Directory Services (RDS) to Replace WHOIS, whose work remains ongoing, with the intention that this new RDS would be more compatible with the privacy laws, probably by providing layered access to registrant data to various classes of authorized users.

Meanwhile, ICANN considered whether to limit registrants' access to a privacy workaround that allowed registrants to register their domain via a proxy, thereby keeping their real personal details private. Although it eventually concluded that access to privacy proxy registration services shouldn't be limited [PDF], these don't amount to a substitute for the new RDS that will incorporate privacy by design, because not all registrars provide this option, or they only do so as an opt-in service, or via a third party who charges money for it.

Meanwhile, effective July 2017, ICANN amended its contract with registries to require them to obtain the consent of registrants for their information to be listed online. But again, this is no substitute for the new RDS, because consent that is required as a condition of registering a domain wouldn't qualify as "freely given" under European law. ICANN followed up in November 2017 with a statement that it would abstain from taking enforcement action against registries or registrars who provided it with a "compliance model" that sought to reconcile their contractual obligations with the requirements of data protection law.

Three Interim Options

Finally, with the GDPR deadline hard approaching and with the work of the Next-Generation RDS group nowhere near completion, ICANN has issued a set of three possible stop-gap measures for public comment. These three models, based upon legal advice belatedly obtained by ICANN last year [PDF], are intended to protect registries and registrars from liability under the GDPR during the interim period between May 2018 and the final implementation of the recommendations of the Next-Generation RDS PDP. In simple terms the three options are:

  1. Allowing anyone who self-certifies that they have a legitimate interest in accessing personal data of an individual registrant to do so. 
  2. Setting up a formal accreditation/certification program under which only a defined set of third-party requestors would be authorized to gain access to individual registrants' personal data.
  3. Access to personal data of registrants would only be available under a subpoena or other order from a court or other judicial tribunal of competent jurisdiction. 

None of these are perfect solutions for retroactively enforcing new privacy on ICANN's old procedures. In EFF's comments on ICANN's proposals, we ended up supporting the third option; or actually, a variation of it. Whereas in ICANN's option 3 proposal a case by case evaluation of each field in each registration would be required to determine whether it contains personal data, this seems impractical. Instead, as with option 2, it should be assumed that the name, phone number, and address fields contain personal data, and these should be withheld from public display.1

ICANN's first option, which would allow anyone to claim that they have a legitimate interest in obtaining registrants' personal data, is unlikely to hold water against the GDPR —they could simply lie, or may be mistaken about what amounts to a legitimate interest. The second option is likely to be unworkable in practice, especially for implementation in such a short space of time. By requiring ICANN to make a legal evaluation of the legitimate interests of third parties in gaining access to personal information of registrants, ICANN's legal advisers acknowledge that this option would:

require the registrars to perform an assessment of interests in accordance with Article 6.1(f) GDPR on an individual case-by-case basis each time a request for access is made. This would put a significant organizational and administrative pressure on the registrars and also require them to obtain and maintain the competence required to make such assessments in order to deliver the requested data in a reasonably timely manner.

Moreover, the case most commonly made for third party access to registration data is for law enforcement authorities and intellectual property rights holders to be able to obtain this data. We already have a system for the formal evaluation of the claims of these parties to gain access to personal data; it's the legal system, through which they can obtain a warrant or a subpoena, either directly if they are in the same country as the registry or registrar, or via a treaty such as a Mutual Legal Assistance Treaty (MLAT) if they are not. This is exactly what ICANN's Model 3 allows, and it's the appropriate standard for ICANN to adopt.

Is the Sky Falling?

Many ICANN stakeholders are concerned that access to the public WHOIS database could change. Amongst the most vocal opponents of new privacy protections for registrants include some security researchers and anti-abuse experts, for whom it would be impractical to go to a court for a subpoena for that information, even if the court would grant one. Creating, as Model 2 would do, a separate class of Internet "super-users" who could use their good work as a reason to examine the personal information databases of the registrars seems a tempting solution. But we would have serious concerns about seeing ICANN installed as the gatekeeper of who is permitted to engage in security research or abuse mitigation, and thereby to obtain privileged access to registrant data.

Requiring a warrant or subpoena for access to personal data of registrants isn't as radical as its opponents make out. There are already a number of registries, including the country-code registries of most European countries (which are not subject to ICANN's WHOIS rules) that already operate in this way. Everyone who is involved in WHOIS research — be they criminals using domains for fraud, WHOIS scraping spammers, or anti-abuse researchers — is already well aware of these more privacy-protective services.  It's better for us all to create and support methods of investigation that accept this model of private domain registration, than open up ICANN or its contracted parties to the responsibility of deciding what they should do if, for example, the cyber-security wing of an oppressive government begins to search for the registration data of dissidents.

There are other cases in which it makes sense to allow members of the public to contact the owner of a domain, without having to obtain a court order. But this could be achieved very simply if ICANN were simply to provide something like a CAPTCHA-protected contact form, which would deliver email to the appropriate contact point with no need to reveal the registrant’s actual email address. There's no reason why this couldn't be required in conjunction with ICANN's Model 3, to address the legitimate concerns of those who need to contact domain owners for operational or business reasons, and who for whatever reason can't obtain contact details in any other way.

Comments on ICANN's proposals are being received until January 29, and may be sent to gdpr@icann.org. You can read our comment here.

  • 1. There are actually two versions of Model 2 presented; one that would only apply if the registrant, registry, or registrar is in Europe (which is also the suggested scope of Model 1), and the other that would apply globally. Similarly, options are given for Model 2 to apply either just to individual registrants, or to all registrants. Given that there are over 100 countries that have omnibus data protection laws (and this number is growing), many of which are based on the European model, there seems to be little sense for any of the proposals to be limited to Europe. Neither does it make sense to limit the proposals to individual registrants, because even if it were possible to draw a clear line between individual and organizational registrations (it often isn't), organizational registrations may contain personally identifiable information about corporate officers or contact persons.

Related Issues

JavaScript license information