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.

GDPR and domain name resellers, 20 million reasons to read this.

Companies will face very harsh punishments for infringements under the GDPR. Art. 83 Paragraph 5 of the GDPR offers the supervising authorities the possibility of imposing fines of up to 20 million Euro or, for corporations, up to 4% of the worldwide turnover of the preceding financial year.

 

Tick tock, tick tock, goes the clock
The EU GDPR will go into effect May 25th, 2018. It looks like there is still a lot of time, but actually, there is not much time left to prep your organization for the GDPR!

Most of your company’s operations will be affected by the GDPR, from your human resources to your marketing department. Policies and processes need to be reviewed, altered and communicated. Privacy by design will be key.

From a wholesale registrar perspective, the impact of the GDPR in combination with domain names is relatively low.
However, the impact for you as a reseller is a massive one.
In respect to registering domain names, your company, as the data collector, sends a lot of Personally Identifiable Information (PII) all over the globe. Be it a ccTLD registration or a gTLD registration.
The GDPR will affect all of our resellers who deal with European citizens as customers even if you, as a reseller are not located in the EU.

We at Realtime Register will, however, assist you in the upcoming struggle.

Privacy protect
As you may have read in one of our previous blog posts, we will offer our privacy protect services for free for our resellers.
This will make sure that you can comply with the EU GDPR and ICANN regulations without too much hassle. We strongly suggest to evaluate your customers and see who will require this service. The easiest and safest way is to use Privacy protect by default for your customers.
For Dutch resellers, who have so-called ZZPers as customers, by law they are exempt from the demanded privacy. However, the GDPR did not take into account how these self-employed business owners should be treated, as the lines between being a professional and a natural person often cross each other.
If you make mistakes here and you forget to enable privacy protect and your customers PII is unprotected, you will be risking the high fines as mentioned earlier. Forgetting about (overlooking) a customer or customers could result in a data breach.

Currently, we are working with a leading juristically advice agency to set up a deal for several services including the new agreements and privacy statement you will need; more details will follow soon.

Some aspects of exporting PII data outside the EU and ccTLD registries (and several others) are still not clear. We will inform you about this as soon as there is more clarity on this subject.

The bottom line, when it comes concerning the GDPR to the GDPR, think twice about how you deal with PII. Be prepared the GDPR will be affecting your business in more ways than you expect.

Other geographical areas
China already introduced severe privacy laws, and companies need to comply early 2018. Overall there are over 100 countries with data protection laws, and 46 countries are currently drafting data protection laws similar to the GDPR.

It is a shame that ICANN and a lot of Registries do not support the privacy by design principle, at the moment, this would have made our lives a lot easier. Perhaps ICANN and Registries should consider the following.

On December 10, 1948 the General Assembly of the United Nations adopted and proclaimed the Universal Declaration of Human Rights.

Article 12:

No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.

So let us be sensible about privacy.

 

 

 

 

EU GDPR, is consent the Silver Bullet for Domain Name Registrations?

Update:28-11-2017

According to the Dutch DPA, consent is not the silver bullet. 

https://autoriteitpersoonsgegevens.nl/en/news/dutch-dpa-unlimited-publication-whois-data-violates-privacy-law

This will make ccTLD registrations outside of the EU for natural persons very problematic and perhaps such registrations should be avoided, though this is not legal advice in any shape or form. 

Consent is often cited as the Silver Bullet to transfer data outside of the EU.The requirements, however, can be rather complex given the fact how registries/ICANN process and control the data.

The rules according to Art.6.1(b).

Data subjects are provided with a clear explanation of the processing to which they are consenting; The consent mechanism is genuinely of a voluntary and “opt-in” nature;
Data subjects are permitted to withdraw their consent easily;
The organization does not rely on silence or inactivity to collect consent (e.g., pre‑ticked boxes do not constitute valid consent);

  • Be specific and granular. Vague or blanket consent is not enough
  • Name any third parties who will rely on the consent
  • Make it easy for people to withdraw consent and tell them how
  • Consent must specifically cover the controller’s name, the purposes of the processing and the types of processing activity

Purpose
Consent will be needed for different processing operations wherever appropriate – so you need to give granular options to consent separately to separate purposes unless this would be unduly disruptive or confusing. As a minimum, consent must specifically cover all purposes.

Consent shouldn’t be.
Recital 32 also makes clear that electronic consent requests must not be unnecessarily disruptive to users. You will need to give some thought to how best to tailor your consent requests and methods to ensure clear and comprehensive information without confusing people or disrupting the user experience – for example, by developing user-friendly layered information and just-in-time consents.

Principles of data protection
In data protection, there is the fundamental principle which is unchanged even in the age of Big Data.

The data subject has to be in control of her/his data, which means for consent that you need consent for every each of the data processing activities (even for minor changes in the processing)

Scope

Considering that Registrars and Domain Name Resellers do business with more than 1000’s of TLDs located in more than 200 countries the complexity of getting consent “right” seems to be very difficult and complex and not recommended for domain name registrations.

The Right to be forgotten.
Individuals have a right to have personal data erased and to prevent processing in specific circumstances:

  • Where the personal data is no longer necessarily about the purpose for which it was originally collected/processed
  • When the individual withdraws consent
  • When the individual objects to the processing and there is no overriding legitimate interest for continuing the processing
  • The personal data was unlawfully processed (ie otherwise in breach of the GDPR)
  • The personal data has to be erased in order to comply with a legal obligation

The above adds another layer of complexity. Some Registries will delete the data of the data subject; some don’t. Currently, it is unknown which policies the registries have in place. In short, consent adds a whole layer of organizational challenges. It is assumed that the withdrawal of consent does not automatically imply that the service can be terminated as consent was not ““freely given”, a requirement of the GDPR.

Given the fact how the public WHOIS system works it is unknown how the right to be forgotten should work in practice within the DNS.

More information about consent can be read here.