|
||
|
||
As I noted over the weekend, ICANN has instigated legal action against EPAG, an ICANN accredited registrar based in Germany that is part of the Tucows group.
ICANN claims that the case is to “preserve WHOIS data”, but Tucows asserts in their statement that the ICANN approach is flawed. It’s not a frivolous statement, but one they’ve backed with fairly detailed rationale—and this is just their public statement and not a formal legal filing.
Tucows explains that they rebuilt their systems and processes based on GDPR and its principles:
“In order to have a domain registration system reflective of ‘data protection by design and default’, we started with the GDPR itself and crafted our procedures and policies around it. We built a new registration system with consent management processes, and a data flow that aligns with the GDPR’s principles. Throughout the registration life-cycle, we considered things like transparency, accountability, storage limitation, and data minimization.”
ICANN’s temporary specification, which was only finalised about a week before the May 25th GDPR deadline, requires registrars to collect and process all existing domain name registration contacts, which Tucows had issues with for a number of reasons:
”...it also required us to collect and share people’s information where we may not have a legal basis to do so. What’s more, it required us to process personal information belonging to people with whom we may not even have a direct relationship, namely the Admin and Tech contacts.”
From exchanges I’ve had with several large registrars it’s apparent that in many, if not the majority, of cases the contacts are identical, which is something that Tucows note:
“However, in the vast majority of gTLD registrations, the Registrant (Owner), Admin, and Tech contacts are the same. As such, collection of Admin and Tech contacts is meaningless, as the data belongs to the Registrant.”
So the case in Germany will, in Tucows’ view, come down to whether ICANN’s rationale for collecting and processing all of these contacts is really viable in relation to GDPR. Kevin provided an overview of how the various ccTLDs across Europe are handling whois in light of GDPR, and while there is divergence, many of them have reduced collection and display. In many cases the only data that is being processed relates to the registrant.
You can read the full statement on the Tucows site here.
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byRadix
A World-Renowned Source for Internet Developments. Serving Since 2002.
It seems to me that ICANN has a simple, solid basis for collecting this information about domains: problem-free operation of the Internet depends in part on being able to contact the owner/operator of a domain about problems or issues with or caused by the domain. That need isn’t limited just to the domain’s registrar, anyone may need to contact the domain owner or operator. From a legal standpoint, think trademark issues. From an operational standpoint, think a malfunctioning email server or invalid DNS entries that’re impacting someone else’s systems. If a domain’s got an MX record that’s accidentally sending all their mail to my mailserver (which has to process and reject it) I definitely want to be able to contact the domain’s operator to get the problem fixed because it’s eating up my data allocation, overloading my server and possibly preventing my own mail from getting to me. Name, address, phone number and email address are pretty much the basic contact info for any such situation. I don’t see why it’d be controversial for registrars to collect that nor for registrars nor registries to make it available for that purpose.
I can see how some people legitimately want to not have that info available, just as they want unlisted phone numbers or to not have their name and address in the phone book. This situation though isn’t similar, there’s the matter of impact on others that isn’t present with an individual not wanting their home address published. It’s not like there aren’t options readily available, either, like post-office boxes or mail drops for the address and dedicated VOIP phone numbers to keep phone calls from interrupting your day. Yes they’re more effort and cost than just having your information unavailable, but then keeping that same information private when you run a business is also more effort and cost and requires the exact same kinds of alternatives and nobody has a problem with that because, like a domain, a business has an impact on more than just the owner and we don’t prioritize the owner’s privacy over everyone else’s need to resolve problems caused by the business.
This has nothing to do with the domain owner/operator. These are additional, superfluous contacts who are, by definition NOT the domain owner.
Those additional contacts, the administrative and technical contacts, are the ones you'll usually need to go to if there's a problem with or caused by the domain. The technical contact would be the one to go to for things like DNS and mail-server issues. The administrative contact would be my first choice for most non-technical issues as they'd be the one responsible for the day-to-day operation of the domain above the purely technical level. The registrant would normally be my last choice of contact (unless they're also the technical and administrative contact) unless possibly it's a legal issue like a trademark dispute. The only contact I can see that shouldn't be public is the billing contact because that's entirely between the registrant and the registrar and nobody else is affected by billing problems or disputes.
over 90% of the time they are the same as the owner and when they are not, they are most often the reseller, whose info is already displayed. this is simply "we have it. so we want it." these contacts are anachronisms of the old, netsol fax process. nothing more. they made sense when there was no automated registration. and in any event you need to focus on how they are legal under the GDPR and how consent can be obtained from individuals that are not parties.
>these contacts are anachronisms of the old Totally agree. GDPR forces review where there has been no obvious need for such review. They can all be tossed. Now that said, my fear here is there being a single email address associated with domain management. From experience its nice to have other emails in case access is lost to one, such as when registrars treat registrant and admin fields as equal. This is obviously not going to happen, but having additional registrant email fields available would be nice with the removal of the other fields. Or change the admin field to Registrant field "2", again I know this will never happen but there is a lot of benefits to doing this (a little added fault tolerance). I myself recently got "locked out" of a domain almost 20 years old as I deleted the email's domain long ago. I never had a reason to care, until I went to transfer it ..... DOH! What a mess that made.
The contacts are a holdover, but not an anachronism. How automated the registration system is doesn't come into play when it comes to people other than the registrant having problems originating from another domain (eg. that domain's MX records are inadvertently pointing it's mail to my mail servers) need to contact the domain operators. You can't assume email works because the problem may be with email so phone numbers and/or mailing addresses are needed (phone numbers more so than addresses for technical issues, while mailing addresses are mandatory for legal issues). Consent should be trivial. The registrant is the one registering the domain and supplying the contact information. Registrants shouldn't be filling in information for people who don't know they're being drafted into the operation of the domain, but a contractual requirement for the registrant to have consent from all parties they're supplying as contact points can't hurt and should be utterly trivial. The registrar has a contractual relationship with the registrant, that's the obvious place to put that consent requirement. A company like Tucows that supplies services to registrars has a contractual relationship with those registrars where it can require them to require registrants to have consent for contact info. All ICANN should need to do is supply the justification for contact points and require that all registrars require registrants to have consent before supplying contact info for a party.
If one requires a data subject to supply data that is not needed to perform the service, such consent is not freely given, and violates GDPR. The "my contract made me do it" excuse doesn't work anymore.
>data that is not needed Clear as mud. From the registrant there is *ZERO* "need" of anything more than a credit card number or bank details and a text string to technically manifest a domain name on the internet. Simple proof of that is Verisign only recently supporting contact objects, they don't need them. Nobody does technically ..... You pay for the domain and then the registrar tells you to kiss off and go away, retaining no record of your existence. That you have needs after that is your problem nobody else's. It is an extreme view, but its accurate, everything else is convenience for management not need. And we have DENIC: https://www.spamhaus.org/news/article/724/ongoing-abuse-problems-at-nic.at-and-denic The people dealing with spam seem to be expressing a need. But GDPR in this case is asymmetrical warfare. A pretty piece of paper with pretty writing on it says the spammer NEEDS privacy more than the people stopping spam NEED the spammers contact information. The never ending game of true chaos, who defines truth? Who defines need? NOBODY and EVERYBODY, so there is no definable truth or needs at all. And yet the statement you quote is based on the idea that we can know for sure, that there is clarity such that all parties agree. But it gets better as the customer, seeking professional services do to their own ignorance, gets a seat (threat of GDPR lawsuit) on the service providers board of directors telling them how to run their business (what we are seeing this very second) ..... The customer defines "needs" not the experienced professional, who was retained for their experience which is unwittingly rejected. Tucows versus ICANN is a great example, ICANN has zero experience managing domains (but they know how to tax them), and when its representatives where asked how many domains they personally had they dodged the question. Looking at history this lawsuit makes so much sense. The people in the trenches trying to get things done versus the bureaucrats telling them what they are supposed to be doing. I personally think there is ample evidence that there is need for a public whois server system that displays registrant contact information. And for those that choose not to participate privacy whois was available. Both "needs" could be simultaneously met versus playing the collectivist game suggesting everybody's needs are the same and nobody gets a choice on the matter. Time to return to my favorite 1985 Brazil quote, which just happens to be about needs and is very appropriate for GDPR: Sam Lowry: Excuse me, Dawson, can you put me through to Mr. Helpmann's office? Dawson: I'm afraid I can't sir. You have to go through the proper channels. Sam Lowry: And you can't tell me what the proper channels are, because that's classified information? Dawson: I'm glad to see the Ministry's continuing its tradition of recruiting the brightest and best, sir. Sam Lowry: Thank you, Dawson.
What's the service, though? In the case of a domain name the service isn't the registration of the domain name, it's the operation of the global DNS to resolve hostnames and other records in that domain properly. Contact information is needed to perform that service for the same reason that contact information is needed to run an apartment complex or to operate a business: people other than you and your registrar/registry need to be able to contact you about problems so they can be resolved.
To the Registrant dealing with a reseller (regardless of registrar) who is the Data Controller and who is the Data Processor? Let say Tucows does not own EPAG, to EPAG, for a "registrant" located in the US using a Tucows reseller, who is the Data Controller and who is the Data Processor? The reseller? To the EU who is the Data Controller and who is the Data Processor to a Registrant, using a Tucows reseller (having NO IDEA this is happening) and Tucows uses EPAG for the registration. It seems to me the Data Controller and Data Processor keeps changing as you look at it from different points along the food chain. That inconsistency strikes me as very problematic. Its one thing if I am interacting with a company for something it directly provides, versus my personal information having to pass through multiple layers to the the service provider from an otherwise unrelated party. This seems to me to come out in just that fact that ICANN is pushing for collection of the other 3 contact records. Its also worth noting that the Billing record disappeared from public whois long ago, for the obvious potential problems it causes. But does it really stop there, does it also apply to the registrant record? Many consultants use their own info as the registrant info for their client registrations. That is a lie, but its useful to help clients manage their domain. The potential EU client "owns" the domain name but has no way to control it as their contact information is not in the contact field. So does a US consultant open themselves up to a GDPR lawsuit for placing their info in the reg fields to help manage the domain? I am saying I think Tucows position might be the tip of the iceberg for other problems that will be rippling through the system, and to me this seems more clear as I consider "resellers" and their behaviors. Lets say if a consultant tries holding a client's domain name hostage (we all know this happens too much), can a registrant now slap the consultant with a GDPR lawsuit for not changing the registrant record to theirs from the consultants? Can they slap the registrar, or even the registry, with such a lawsuit if the consultant does not comply? The above are all rhetorical.
Tucows is a great test case given OpenSRS is just that “open”. Its a resale platform and thus does not generally have a direct relationship with the registrant, the OpenSRS reseller does thus adding another layer of responsibility.
Godaddy has the same issue as well as other registrars with Reseller API’s.
I have a “personal reseller” account at Tucows for the more obscure TLDs I’m not interested in sponsoring. I see one of them I see is in EPAG, and yet my relationship is with Tucows ...
Also note that KeySystems/Domain Discount 24 (Germany) is the sponsor for ABC.US, for which “thick” whois details are provided. Nothing excludes, say, a dual national (US and Italian) from satisfying the .US nexus requirement and registering a .US domain ....
GDPR is clear as mud for such a diffusion of responsibility across many organizations working together to serve registrant needs.