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.

 

FAQ Privacy Protect support

1. What does privacy protect do?
2. Why should you offer privacy protect to your customers?
3. What are the benefits of privacy protecting?
4. How can I set all domains of a registrant contact to privacy protect?
5. Do I need to have consent of the registrant for privacy protect?
6. Do ALL TLDs allow privacy protecting?
7. How can someone get in touch with the registrant of a privacy protected domain?
8. Why should I set my customers domains on client transfer prohibited TRUE?
9. How about exposing registrant information through the other contacts?

1. What does privacy protect do?

Realtime Register privacy protect removes the exposed registrant information and replaces it by a default data set and email address related to the domain name.

Example whois output non-privacy protected domain

Registrant Name: John Johnson
Registrant Organization:
Registrant Street: 404 street name
Registrant City: Amsterdam
Registrant State/Province:
Registrant Postal Code: 1000 AA
Registrant Country: NL
Registrant Phone: +31.106660666
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: john@whatever.whatever

Example whois output privacy protected domain

Registrant Name: Privacy Protect
Registrant Organization: My Domain Provider
Registrant Street: Ceintuurbaan 32A
Registrant City: Zwolle
Registrant State/Province: 
Registrant Postal Code: 8024 AA
Registrant Country: NL
Registrant Phone: +31.382305013
Registrant Phone Ext:
Registrant Fax: 
Registrant Fax Ext:
Registrant Email: domainname.extension@mydomainprovider.com


Where “domainname.extension” is replaced by the domain name of the whois output. If the  phone number is called a recorded message is played to contact the registrant through email.

To Top Of Page

2. Why should you offer privacy protect to your customers?

By exposing the registrant information, you might be in breach with the GDPR. Especially if you don’t have explicit consent to have the registrant information published in a public whois. And in addition, it’s a human right. As article 12 of the United Nations Universal Declaration of Human Rights states:

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

To Top Of Page

3. What are the benefits of privacy protecting?

  • It protects your customer’s privacy even more effectively
  • It prevents spam by email, phone calls or text messages to your customers
  • It is compliant with over 100 data protection laws worldwide.


To Top Of Page

4. How can I set all domains of a registrant contact to privacy protect?

For starters, make sure you have your customers consent for setting domains to privacy protect. You can do this by either explicit consent or through your terms of service. If you use the Realtime Register Domain Manager, we have a Privacy Protect step-by-step plan available for you. If you use the Realtime Register API, you can use the API commands set to privacy protect. However, even then you want to have a look at the Privacy Protect step-by-step plan.

To Top Of Page

5. Do I need to have consent of the registrant for privacy protect?

Yes, you need to have some form of consent, please have a look at item 4 of this FAQ.  The privacy protect feature also sets the domain to transfer prohibited. This also requirers the consent of the registrant.

To Top Of Page

6. Do ALL TLDs allow privacy protecting?

Nope, I am sorry, however, privacy protect is allowed for practically all generic TLDs. Most ccTLDs don’t allow it. However, the ccTLDs that don’t allow privacy protect in general show very few information, so effectively it’s privacy protected.
For example; the Dutch .nl extension does not display the registrant name if there is no organization name added to the registrant information. As do other ccTLD registries like DNS BE, Eurid and Afnic.


To Top Of Page

7. How can someone get in touch with the registrant of a privacy protected domain?

Basically, in two ways by using a captcha-protected form at my domainprovider.com and sending an email to the domainname.extension@mydomainprovider.com email address.

  1. If the form at mydomainprovider.com is used, the email with optional attachment is directly send to the registrant’s email address in the registrant contact handle. Of course, the sender does not get to see the real address.
  2. If the mail is send directly to the email address in the whois, the behaviour depends on the status of the client transfer prohibited setting.
    1. If client transfer prohibited is TRUE, the sender gets an email to go to the mydomainprovider.com form. Effectively blocking spam bots from reaching the registrant.
    2. If the setting client transfer prohibited is FALSE, the registrant gets a standard email with a link to view the message. Attachments from the sender are discarded. This route ensures limited protection from spam though allows for transfer out FOA’s to reach the registrant.


To Top Of Page

8. Why should I set my customers domains on client transfer prohibited TRUE?

  1. It helps to prevent domain theft and unwanted transfers.
    • Even if someone of your staff has been socially engineered to provide an authorization code to an unauthorized person, it adds an additional threshold for transferring the domain away.
  2. It reduces spam reaching the registrant even better.
    • If the domain is privacy protected automated spam is unable to get in your customers mailbox.


To Top Of Page

9. How about exposing registrant information through the other contacts?

That is a tricky one, if you use different contacts with the registrant’s information you will end up exposing unwillingly contact information of the registrant. In general, there are two approaches:

  1. Change all admin, billing and tech contacts to a contact that has your brand information. As a nice side effect, your brand gets more exposure in the whois information.
  2. Change all contacts to the contact handle of the registrant. This way, these whois contacts will also display the privacy protect information.

It’s up to you, make your pick!

ICANN, Thick WHOIS Migration Delay & Pray

The migration of the Verisign Thick WHOIS has been delayed until 29th November.
This is a welcome change from the original migration data wich was set at 1-August-2017.

We at Realtime Register were not planning to migrate on this data anyways, as we are still reviewing the EU GDPR and its impact.

Currently, ICANN is collecting community input regarding the EU GDPR till September this year. In November ICANN will present the results wich will provide more clarity regarding the fact if ICANN is the data controller or not according to the EU GDPR. Furthermore, Registrars expect more clarity at this date regarding the output of personally identifiable data through the public WHOIS.

The EU GDPR will go into effect on 25-May-2018 and will severely impact your business.
A blog post regarding the EU GDPR and how it will affect you as a reseller will follow soon.

ICANN blogged about this migration delay here.

Registrar Negotiating Team Statement On The 2013 RAA

Last night ICANN published an updated version of the registrar accreditation agreement 2013 with additional documents. Though the Registrar negotiation team has been working on this for 18 months in conjuction with ICANN staff they feel that the publishing of the documents was to premature.

ICANN Logo

The official Registrar Negotiating Team Statement:

After nearly 18 months of negotiations with ICANN over a new Registrar Accreditation Agreement (RAA), formal negotiations have concluded. The posting of a “proposed” 2013 RAA by ICANN for public comment signals that ICANN staff believes that negotiations have concluded and the remaining issues will not be resolved.

The Registrars’ NT disagrees. To be clear, this is NOT the outcome that registrars wanted, and they remain ready and willing to continue negotiations.

Prior to the Toronto ICANN meeting (October 2012), all parties acknowledged that they were very close to agreement on all remaining issues. The process appeared to be reaching a favorable conclusion and when ICANN CEO Fadi Chehadé communicated his desire to have RAA negotiations wrapped up by the end of 2012, registrars felt it was an ambitious timeframe, but one worth pursuing for the benefit of all parties.

When negotiations finally resumed in February 2013 much to the surprise of registrars, the few remaining issues were not the only items under discussion. ICANN staff presented a list of 10 brand new items for inclusion in the agreement, under the pretext of enhancing the “public interest.” Furthermore, these new items came along with an arbitrary deadline and decision to link the 2013 RAA to the new gTLD timeline.

Among these new demands was a Registrant Rights and Responsibilities document (R3), a temporary privacy accreditation program and a requirement that registrars accept and implement recommendations of the WHOIS Expert Working Group, which had yet to be formed and whose work is just beginning.

Although registrars were surprised by these new demands, registrars worked in good faith with ICANN to accommodate its intentions. For example, registrars consulted with their members to fine-tune the R3 document to make it easier to understand and readily translatable in other languages.

Some of the other new items for inclusion transcend the RAA and could affect the entirety of the multi-stakeholder model. For example, ICANN insisted on including a proposed Revocation (or “blow up”) Clause that would have given them the ability to unilaterally terminate all registrar accreditations. After major pushback, ICANN staff relented and in its place proposed giving the ICANN Board the ability to unilaterally amend the RAA. This is identical to what ICANN inserted into the proposed new gTLD registry agreement – a clause met with strong opposition not only from the Registry Stakeholder Group but from the broader ICANN community.

The effect of such a clause in the primary agreements between ICANN and its commercial stakeholders would be devastating to the bottom-up, multi-stakeholder model. First, it will effectively mean the end of the GNSO’s PDP, as the Board will become the central arena for all controversial issues, not the community. Second, it creates an imbalance of authority in the ICANN model, with no limits on the scope or frequency of unilateral amendments, and no protections for registrars and more important registrants.

In addition to the new items for inclusion there was a surprise announcement that all new gTLD registries must only use registrars that have signed the 2013 RAA, a transparent effort by ICANN to arbitrarily link the new gTLD program to the outcome of RAA negotiations. This requirement would create separate “classes” or “levels” of registrars, which is unprecedented in the DNS industry. There can and must be only one meaning of “ICANN-Accredited.”

All of the items that have been agreed to over the past 18 months would, by themselves, produce an RAA that is vastly improved over the current 2009 version. If adopted, that RAA would significantly raise performance requirements for every ICANN accredited registrar and bring dramatic improvements to the domain name ecosystem. Nearly all of the Law Enforcement requests that were endorsed by the GAC have been included, as well as the major items that were requested by the GNSO are included in that RAA. That RAA would bring registrant verification. That RAA would bring enhanced compliance tools.

Registrars must emphasize that the key differences between that RAA and the one currently proposed by ICANN are not issues raised by Law Enforcement, GAC or the GNSO but by ICANN staff.

It now moves to the greater ICANN community to review these competing draft RAAs, and registrars look forward to those public discussions. We welcome engagement with all stakeholders on the new 2013 RAA, and what it means for registrars, registrants, and the management of the DNS as a whole.

ICANN 44 a week in review

ICANN 44 Prague was a busy event and produced a lot of news and new information.

Friday June 22 : ICANN announces it’s new CEO and President Fadi Chehadé.

Saturday June 23 : The biggest news this day must have been the fact that ICANN

ICANN Logo

suspended the Digital Archery system and later in the week abandoned it completely.
Sunday June 24 : A number of registrars participated in a briefing with the Governmental Advisory Committee (GAC) regarding the Domain Name Marketplace and the role of registrars in the ecosystem.
Points being discussed with the GAC.

  • Registrar business models
  • the role resellers play
  • the diverse nature of the RrSG (Registrars Stakeholder Group) members

Monday June 25 : The RrSG met directly with representatives from the Law Enforcement community on Monday to provide them an update and to update them on the status of the 12 requests they had previously indicated were important. The RrSG has accepted 10 of the 12 proposals.
Outstanding issues are WHOIS verification and Data Retention.
In the evening ICANN CEO Rod Beckstrom had it’s farewell party which was largely attended.

Tuesday June 26 : Tuesday was a busy day for the Registrars.
RAA (Registrar Accreditation Agreement) discussions
gTLD discussions about the implications for Registrars and it’s Resellers/Customers.
The Executive Committee of the RrSG met with the ICANN Board Tuesday afternoon. Main topics were the new RAA and gTLDs.
A healthy interaction with the ICANN compliance team.
ICANN renews the .com contract with Verisign.

Wednesday June 27: WHOIS replacement workshop. A few observations from this workgroup.

  • No uniform data model that exists for domain name registration data.
  • The WHOIS protocol itself has no standard capacity for handling non-ASCII text.
  • Directory services do not satisfy legitimate needs for access to different granularities of data.

Replacing the current WHOIS system as we know it, is one of the top priorities of ICANN’s priority list.

Participation as a panel member regarding the IRTP Part C Update. This workgroup is gathering information to recommend a control function for domain name owner changes.

No further news on the URS. ICANN has not selected an URS provider yet.

Thursday June 28 : Participation as a panel member regarding the locking of a domain name during an UDRP (Uniform Domain-Name Dispute-Resolution)
Most noteable was the public forum. This session lasts around 5 hours and includes a variety of topics. This is a session where anyone and everyone can ask their questions or make comments to the ICANN board.