Court denies ICANN’s GDPR injunction against Tucows
A German court has refused ICANN’s request for a GDPR-related injunction against Tucows’ local subsidiary EPAG, throwing a key prong of ICANN’s new Whois policy into chaos.
EPAG now appears to be free to stop collecting contact information for each domain’s administrative and technical contacts — the standard Admin-C and Tech-C fields.
The ruling may even leave the door open for registrars to delete this data from their existing Whois databases, a huge blow to ICANN’s Whois compliance strategy.
According to an ICANN-provided English translation of the ruling (pdf), the Bonn judges (whose names are redacted — another win for GDPR?) decided that the Admin-C and Tech-C records are unnecessary, because they can be (and usually are) the same person as the registrant.
The judges said that if the additional contact names were needed, it would have historically been a condition of registration that three separate people’s data was required.
They wrote that this “is proof that any data beyond the domain holder — different from him — was not previously necessary”.
“Against the background of the principle of data minimization, the Chamber is unable to see why further data sets are needed in addition to the main person responsible,” they wrote.
Data minimization is a core principle of GDPR, the General Data Protection Regulation, which came into force in the EU less than a week ago. Tucows and ICANN have different interpretations on how it should be implemented.
The judges said that the registrant’s contact information should be sufficient for any criminal or security-related investigations, which had been one of ICANN’s key claims.
They also said that ICANN’s attempt to compare Whois to public trademark databases was irrelevant, as no international treaties govern Whois.
If the ruling stands, it means registries and registrar in at least Germany could no longer have to collect Admin-C and Tech-C contacts.
Tucows had also planned to delete this data for its existing EPAG registrations, but had put its plan on hold ahead of the judge’s ruling.
The ruling also gives added weight to the part of ICANN’s registry and registrar agreements that require contracted parties to abide by local laws.
That’s at the expense of the new Temporary Policy governing Whois introduced two weeks ago, which still requires Admin-C and Tech-C data collection.
There was no word in ICANN’s statement on the ruling last night as to the possibility of appealing.
But the org seized on the fact that the ruling does not directly state that EPAG would be breaching GDPR rules by collecting the data. General counsel John Jeffrey is quoted as saying:
While ICANN appreciates the prompt attention the Court paid to this matter, the Court’s ruling today did not provide the clarity that ICANN was seeking when it initiated the injunction proceedings. ICANN is continuing to pursue the ongoing discussions with the European Commission, and WP29 [the Article 29 Working Party], to gain further clarification of the GDPR as it relates to the integrity of WHOIS services.
Tucows has yet to issue a statement on the decision.
It may not be the last time ICANN resorts to the courts in order to seek clarity on matters related to GDPR and its new Temporary Policy.
If you find this post or this blog useful or interestjng, please support Domain Incite, the independent source of news, analysis and opinion for the domain name industry and ICANN community.
Am still a bit confused by this discussion. I see admin-c and tech-c (as well as billing-c and abuse-c) as an option for the registrant to name someone else as his primary contact for specific topics where he has no knowledge of himself. Of course, the registrant needs to have the option to fulfil all these roles himself (I would say the default option) but I can’t understand why GDPR would forbid anyone to give the registrant an option to name others in specific roles.
(and yes, it is debatable under the GDPR how much of this information should be published publicly or shared with whom, but that is an entirely different question)
Hi Maarten,
The court doesn’t say that GDPR forbids to give registrants the option to name others in specific roles.
Regardless, providing such an option would come with significant legal risks and/or administrative costs for the registrar, the registry, and (if we buy into ICANN’s assertion that they are a/the data controller) even ICANN. That is because they would need to make sure that consent by the named person has been given and they would need to deal with later withdrawal of such consent. Also, they would be legally responsible if something went wrong in this instance.
Best,
St.
Hi Stephan,
Sorry to disagree here.
By naming someone else, the registrant becomes a data controller himself and yes the basis would most probably be consent.
All of course provided that the named one is a natural person which is not necessary at for example .nl, where it can also be for example a department of the registrar, reseller or hosting provider.
For the registrar and registry the basis for processing the data is not consent but execution of a contractual obligation towards the registrant. If the named natural person withdraws its consent it is therefore upon the the registrant to change the records at the registrar or registry.
Does of course not mean that you can still receive request from natural persons inquiring if their data is in your systems, etc. but it is in principle not your obligation to prove the existence of the consent.
Agree that it may still give some hassle but does not mean that it is not legally allowed. It is a policy choice.
Best,
Maarten
Hi again,
We seem to disagree indeed.
Albeit it is usually the obligation of the registrant to name an admin-c I assume you can make it a contractual obligation of the registry to register a person named by the registrant as the registrant’s admin-c. However, the fulfillment of this obligation does not justify the processing of the admin-c’s data under Article 6 Section 1 lit. f) GDPR as this clause only applies if the data subject whose data is being processed is a party to the contract in question – and the admin-c is not a party to the registration contract. Consequently, the registry needs some other grounds for processing the admin-c’s data, and this can only be consent.
The only other alternative I can think of is to regard the registrant as controller and the registry as the registrant’s processor – but I am pretty sure we at least agree that this would be nonsense.
Best,
Stephan
Policy shouldn’t be imposing clear legal risks. If a registrar wants to trust a registrant to assure their compliance regarding 3rd party information, it’s their choice to make…