Data Protection/GDPR TLD Guidance Matrix

I think this is the first blog where I start with phrases like;

  • We are not done yet
  • Guidance only
  • We are not done yet
  • By no means legal advise
  • Best effort only
  • We are not done yet

While we are not done, we are trying to get this matrix as complete as possible before May 25; we do expect that we will still be updating the matrix way beyond May 25.

Back in 2016, I was under the impression that our industry would work together and come up with solutions to make things easier when it comes to the GDPR.
However, it is April 2018, ICANN is still in chaos, the EU ccTLD registries move at a glacial pace, and the ccTLD registries outside of the EU still have to figure out what the EU GDPR is.

A few months ago we came up with the idea that we should assist our customers when it comes to the GDPR.Over a thousand registries, located all over the world in many different jurisdictions, processing personal data in ways not known to us. At the time, it was like asking the question, how do you put an elephant in a car?

The answer? Put the GDPR and all the data protection laws of the world into the metadata of our API.
https://dm.realtimeregister.com/docs/api/tlds/metadata#privacy

 

At first glance, this looks very complex and confusing, just like the GDPR itself.
When you send an info request on the metadata for the name, “gdprCategory”, it will give you four values depending on the TLD.

  • EU_BASED: Registrations are under EU jurisdiction
  • ADEQUACY: Registrations are in a jurisdiction that provides an adequate level of data protection according to the EU
  • DATA_EXPORT: Registrations are in a jurisdiction without an adequate level of data protection as outlined by the EU. Fundamental rights like the right to be forgotten or erasure do not apply
  • UNKNOWN: Situation unknown

So how does this work?
As I mentioned before we still need to complete this and things are still in motion with a lot of registries, but we can tell you a few things already based on current info and predictions, as such we came up the following suggestions.

  • Caution advised
  • Use privacy protect
  • EU based, whois exposed
  • Safe, data adequacy or EU based

GDPR Advise
Let’s start with the advice called:”Caution advised.”
And be advised these are the most complex TLD’s to register.
We know that these TLDs are outside of the EU and Article 49 is most likely to be relevant for such TLD’s.
In some cases, we do not know what will happen and how the registry in that country will treat the data of your customer.

Our advice, consult a lawyer when your customer wants to register a domain name in a TLD labeled “Caution advised.”
You do not need to worry about this when this is a company registration. Companies (legal entities) are exempt from the GDPR. Make sure you do not use any personal data for such registrations.

Use privacy protect
Rather straightforward advice. We do not know what ICANN will be doing or not. With our privacy protect service you do not have to worry about the following:

  • Consult a lawyer regarding your legal requirements to register a domain name (money saver).
  • The data will not be exported to a “third country.
  • Do you need privacy shield as a legal basis or not?
  • No need to worry about “third parties” having access to your customer’s data outside of the EU.
  • If the right to be forgotten or erasure applies or not?
  • EU GDPR data minimization requirements
  • Can the GDPR data accuracy requirements be exercised or not?
  • The need to ask consent from your customer for every possible data processing (no disruption of registration flows in your shop)

Our advice, use this service whenever you can, it will save you a lot of time and hassle.

EU based, whois exposed.
These registries are EU GDPR compliant. But some of them do expose personal data in the WHOIS. Personally, I do not like this, but there can be a few legal reasons (on a member state level) that such a practice is permitted under the GDPR.
You might want to give your customers a heads-up of such practices as their perception might be different.

Safe, data adequacy or EU based.
My personal favorite.
These TLDs are GDPR compliant and do not expose personal data through the WHOIS. Hassle free; let’s hope the rest will follow soon.

Terms of Service & Privacy notice.
As an extra service, we have included links to the relevant registration contracts and privacy notices. I am aware it is not complete at the moment, but we hope to have most of it ready, before the 25th of May.
Keep in mind, so far we have seen zero new contracts from gTLD registries. I expect that we as a registrar we will have to sign over a thousand contracts just a few weeks before the 25th of May.

So check the matrix regularly to remain up to date.

More information regarding the Realtime Register Privacy Service can be located here

 

Berlin Group to ICANN, WHOIS is not your only GDPR problem

Just before ICANN 61, ICANN and its community received essential information regarding WHOIS and the GDPR and more.
The latest statement and recommendations are from the Berlin Group (International Working Group on Data Protection in Telecommunications and Media or IWGDPT).

The Berlin Group started out in 1983 on the initiative of some national data protection authorities; nowadays members include government agencies, representatives of international organizations and IT experts from all over the world.

So basically we have the opinion on ICANN and registrant data and WHOIS vetted by all the members of the International Conference of Data Protection and Privacy Commissioners from around the world (see https://icdppc.org/ ).
And let me put this into perspective for you as a reader. There are 122 countries with data protection laws, this opinion, is not just the opinion of a few EU DPA’s, far from it.

A few highlights from the report.

First, the report describes the current procedure for registrars regarding WHOIS and conflicts with data protection law. This procedure created in 2006 is currently not workable for registrars, and the report explains why it is barely used.

Moving on.
The report sets out that the data collection as required by the RAA 2013 (the contract between ICANN and registrars) appear to be excessive, disproportionate and obtained without free consent. My personal opinion, it is not a matter of appearance, it is the reality.

WHOIS
The Berlin group observes that publication of personal data in the WHOIS is a no go, and data gathered by service providers creates barriers for registrants to have their data removed. The examples cited are DomainIQ and Domain Tools. Anyone who knows a little about the DNS knows that it does not stop with those two companies, we are talking hundreds of companies who harvest WHOIS data.

Recommendations extracts.

1 All current WHOIS purposes for several stakeholders are not necessarily legitimate purposes and require remediation.

2 Purpose, purpose, purpose, only process data necessary for the registration of the domain name and not beyond.,

3 LEA’s should get access to a tiered WHOIS system.
Private sector security firms, to have access to such a tiered system seems to be very problematic.

4 Data retention requirements and the RAA 2013 should be re-examined.

5 Reverse WHOIS is not a given and so is bulk data capture in the new WHOIS/RDS

6 Transborder data flow.
This advice relates to the upcoming (but still in limbo) Thick WHOIS migration. The Berlin Group is somewhat skeptical here and recommends to limit data flows when necessary. In my opinion, there is zero reason to replicate data registrant databases and centralize them at registries. It is a data breach waiting to happen, and it will happen.

7 ICANN should take into account that data from small businesses, sole contracts, home businesses, start-ups may contain personal data.

There are several ICANN stakeholders, who push for a distinction between commercial and personal data.
The Berlin Group notes that there is a distinction, but it does not mean that it is up to ICANN or the WHOIS to make such a difference.
In most cases, if not all, regional law or national law requires companies to publish their contact data on their website(s) NOT the WHOIS.

8 There are, as mentioned earlier 122 countries with data protection laws, ICANN should make sure it is compliant with the highest data protection requirements.

Let us hope that ICANN takes the recommendations seriously and goes back to its core function.

The Berlin Group recommendations can be read in full here.

Update on publication of personal data in the WHOIS / RDS

There has been a considerable debate whatever ICANN will enforce the contractual agreement between registrars and registries to display personal data in the WHOIS.

Publication of personal data in the WHOIS is usually in conflict with many data protection laws around the world.

The EU GDPR and its substantial non-compliance fines seem to sway the discussion into a direction where ICANN needs to come up with solutions. And they did: ICANN published several models that propose to limit the publication of personal data in the WHOIS. The next step is that the ICANN community analyzes these models.

The models created by the ICANN Organisation can be viewed through the link below.

interim-models-gdpr-compliance-12jan18-en

All the models published by the ICANN community are posted here.

The end of WHOIS?
The models proposed by the ICANN organization have limited personal info published in the WHOIS the two other models no longer publish personal data in the WHOIS.

The ECO model also has in common that there is no personal data published in the WHOIS.

So ultimately I think we are heading to a solution where registries and registrars no longer will publish person data in the WHOIS.
All models continue their support for data transfer to registries. In my opinion, this does not meet the EU GDPR data minimization principle, which I will explain in a future blog post.

Most beautiful model?
All models are not perfect, and to be used as a solution the following are of key importance.

  • Flexibility
  • Implementation time frame.

In my opinion, the ECO model fits those requirements.
In addition to this, the ECO model has the largest industry support, which is key critical for mass adoption.

The end of privacy protection services?
Should you still use the Realtime Register privacy protect service even when there will be no personal data published in the WHOIS in May 2018?
The short answer is, yes.

All proposed models might tackle the WHOIS issue; it does not address the issue of possible data breaches, increased legal requirements for you as a reseller, and other areas of GDPR noncompliance. Our privacy service does that, though perhaps we should rename our privacy service to Data Protection Compliance Services (DPCS).

Interim solutions.

Keep in mind the solutions proposed are interim solutions, I would urge the ICANN community to band together and start working on real lasting solutions, rather than attacking interim solutions.

Realtime Register is a supporter of the ECO model.

 

GDPR update, legal definitions and possible action items.

Below, a quick update and some information which is crucial to you as a reseller regarding the GDPR.

Privacy notice
We should have the privacy notice ready for you at the end of February.

Processing agreement
We expect to send this to our resellers at the end of February, given the vast amount of different jurisdictions and number of registries this may be delayed by a few weeks.

The processing agreement is required for your contractual agreements between you and our customers.

Legal definitions

  • ICANN, joint data controller
  • gTLD registries, joint data controller
  • ccTLD registries, data controller
  • Realtime Register (registrar), data processor
  • Reseller, data controller

Data processor
I consider Realtime Register a data processor, we process the data on behalf of you as a reseller.

Data collector/reseller
As a reseller, you collect the data from your customer(s).
From a contractual point of view, it is required you have the correct legal basis from your customer(s) to send us the data, data which we, as a registrar will transfer to the registry to register the domain name for your customer(s).

Depending on the TLD and the jurisdiction of the registry operator your legal basis will vary.
In some cases, a notice is required (easy).
In other cases, you will require consent for every piece of processing from your customer (very hard).

More information on how to obtain consent from your customer for domain name registrations can be read here. As getting consent is complex to use as a legal basis, you might want to read the following article by the UK DPA, please visit the following link

The GDPR and its impact on domain names is a very complex topic and our role as data processor is limited. So, if you are unfamiliar with the definitions above, I suggest you put in some research. A Data Protection Impact Assessment (DPIA) is a good idea to get a better understanding of which legal requirements apply to you under the EU GDPR.

More information regarding a DPIA can be found here.

When does the GDPR affect you as a reseller?
The GDPR would apply only to personal data included in the registration data of a natural person where:

  • The reseller/registrar and/or registry are established in the European Economic Area (EEA) and process personal data included in registration data;
  • The registrar/reseller and/or registry are established outside the EEA and provide services involving the processing of personal data from registrants located in the EEA; or
  • The registrar/reseller and/or registry are located outside the EEA and process non-EEA personal data included in registrations, where registry and/or registrar engage a processor located within the EEA to process such personal data.

Due to its complex nature, I will provide more info about the legal ins and out of publishing personal data in the WHOIS in another blog post.

 

Why Registrars require an EU based Escrow provider

Domain names, registrant data and data protection, they all have a long history in the ICANN universe. Let’s do some time traveling and let me take you back in time, starting a decade ago…

March 2007
ICANN de-accredits RegistryFly, this disaster demonstrates clearly that Registrars should escrow registrant data to an escrow provider in case a registrar goes “down.”

To counter the RegistryFly disaster, ICANN introduced escrow requirements, ICANN picks up the bill, but of course, indirectly the registrars are paying for it, how much is unknown though, as we do not know how much ICANN is paying Iron Mountain USA.

October 2015
The escrow of data to the USA went on for years without problems, until October 2015, when the CJEU invalidated Safe Harbor. Most companies, registrars included relied on Safe Harbor to transfer data to the USA. But all of the sudden this was no longer an option.

This raised awareness among registrars. Our contractual ICANN obligation to escrow data was no longer an option as it was deemed illegal by the CJEU.

ICANN had appointed more escrow providers during the years including the EU. The problem, these escrow providers are not funded directly by ICANN. The prices are high, up to 2500 Euros a month.

This means that registrars using another provider would pay twice, first the provider of their choice and second Iron mountain through the ICANN fees. Effectively this means you’re sponsoring the competition, which is insane.

Further developments………

November 2015
The invalidation of Safe Harbor demonstrated another issue; legal agreements could be here today and gone tomorrow.
Realtime Register entered into a contract with Iron Mountain using a so-called SCC aka Model Contract. This solution provided us an option to continue our escrow obligations.

July 12, 2016
The European Commission deemed the EU-U.S. Privacy Shield Framework adequate to enable data transfers under EU law.

Realtime Register continued to use the SCC as it provided more safeguards for registrants compared to Privacy Shield, which was deemed invalid by legal experts the moment it was released.

August 2017
Denic the German ccTLD Registry for .DE informs ICANN registrars their far developed plans to become an ICANN designated escrow agent. ICANN acknowledged that EU Escrow providers would get the same treatment funding wise like Iron Mountain USA. Next year this treatment will be available to other escrow providers like for example China, China has very strict privacy laws.

Most recent developments……………

October 3, 2017
The Irish High Court rules on Facebook surveillance case:
Irish DPC has “well-founded concerns” over US surveillance of Facebook.
EU-US data transfer complaint referred to European Court of Justice for the second time.
The court found that the DPC has “well-founded concerns” that the SCC Decision by the European Commission (2010/87/EU) may be invalid.

11 October 2017
Realtime Register submits a letter of intent supporting Denic and urges ICANN to make haste.letter of intent

Looking ahead…………

Future
Most likely the CJEU will rule that SCC’s can no longer be used in the future. Privacy Shield will most likely be invalidated (again), causing massive operational and legal problems for registrars. ICANN should push forward with the Denic proposal as soon as possible.