MENU
  • Enom.com
  • Resellers

Enom Blog

December, 2017
Archive

  • Consent and the GDPR

    December 21, 2017

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 8877

    As we get closer to May 25, 2018, I see more attention paid to the GDPR and to how service providers will need to change to accommodate these new data privacy regulations. At the same time, we’re hearing questions from our resellers about whether this will affect them. I want to take a moment to emphasize that the GDPR is a Really Big Deal and that anyone who sells services online should be looking into what changes they need to make to be compliant by that May deadline.

    Why is the GDPR different?

    This isn’t the first data privacy regulation to hit the Internet, but it is the first one to carry such significant fines and such a broad scope. If a data controller is found to have infringed upon the basic data processing principles in the GDPR, such as the requirement to obtain appropriate consent from the data subject, the fine can be up to 20 million Euros, or 4% of annual turnover, whichever is higher — that’s huge! And I’m not sure about you, but I tend to think of laws as applying only to the country or union where the law is in effect. But the GDPR’s scope is much wider — it applies not only to businesses based in the EU, but also to businesses in the rest of the world that sell services to EU-locals.

    If you’re a reseller with clients in the EU, it’s likely that some element of your data processing falls under the scope of the GDPR, whether that means setting up accounts for EU-locals in your system, taking their payment for a domain name, or providing them with services on an ongoing basis. Due to the scope and the significant penalties involved, non-compliance with the GDPR is a big risk not only for registrars but for every reseller.

    With that context about the GDPR’s scope and penalties in mind, I think it’s clear that the GDPR affects almost everyone doing business on the Internet. Remember, nothing I’m saying here is legal advice — this is my domain-industry perspective, I’m not a lawyer, and you should be talking to one.

    Why is data privacy so important?

    I’ve done most of my holiday shopping already, and as much as I try to shop locally and support small businesses, some gifts are just better purchased online. But one thing I kept in mind this year, probably because the GDPR has me thinking so much about data privacy, is how much information is generated by my online shopping.

    I remember a story in the news a few years ago about how Target, a major North-American retailer, used data analytics for marketing, which ended up revealing a young woman’s pregnancy to her family. Would my online shopping be revealed to my partner, via well-placed browser ads and coupons sent to our shared email address? Could I stop that from happening? I used a private browser window, but that doesn’t stop the retailers from tracking my purchases, creating a profile based on data they collect from me and bought from third-parties, and serving up targeted advertising that might give away some holiday surprises. If only they had to get my permission before processing my personal data! And on a more serious note, concerns around data privacy shouldn’t be limited to annoying marketing emails and spoiled surprises — data privacy is a necessary element of modern democracy.

    When does the GDPR allow processing of personal data?

    Processing of personal data is only permitted under the GDPR if it is done “lawfully, fairly and in a transparent manner” (GDPR Article 5). The details of what is considered “lawful” are found in Article 6, where six different legal bases for data processing are given; the first two of these clearly apply to the relationship between a registrar and registrant:

    • The data subject consented to the processing of their personal data
    • Data processing is necessary as part of fulfilling a contract with the data subject

    Other ways that data processing can be legal are when it’s done in order to protect the vital interests of the data subject or when processing is necessary for the public interest; those don’t usually apply to domain names. Finally, there’s a legal basis of “legitimate interests,” which is defined in recital 47 of the GDPR. This definition says “processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller” — this one could relate to domains since most companies offering paid services use personal data in some manner to protect against fraud and to process payment data.

    But let’s venture back to consent for a moment. Consent is a difficult legal basis to rely on since there are many conditions laid out in the GDPR which determine what consent means, how consent can be requested, and what kinds of data use can be consented to. If these conditions are not met then the processing is not lawful. However, in some situations, consent is the most appropriate legal basis for the processing of personal data. To get a better sense of when consent does suffice, we took a close look at what constitutes consent under the GDPR.

    How does the GDPR define consent?

    In Article 4 of the GDPR, consent is defined as follows:

    “…any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;”

    There’s a lot going on in that first sentence, and we talked about this a bit in our first GDPR post. But let’s break it down. Consent must be:

    • freely given – there can’t be negative consequences for not consenting to more data use than is required to fulfill the contract;
    • specific – consent needs to be requested for each data use individually, they can’t be bundled together;
    • informed – the way the data will be used must be clear in the consent request; and
    • unambiguous – consent has to be a clear, active choice on the part of the data subject rather than a passive allowance.

    The requirement that consent be provided “by a statement or by a clear affirmative action” goes hand-in-hand with the “unambiguous” indication of consent. We’ll be revamping our existing processes under the assumption that it’s not enough to display a pre-checked box that the domain owner simply scrolls past; instead, the domain owner must actively grant consent. This may still be done by checking a box, but whatever process we choose, we will ensure the option to grant consent isn’t pre-selected.

    Article 7 of the GDPR delves more into the conditions for consent. It requires that the data controller (the party who determines “the purposes and means of the processing of personal data”) can demonstrate that the data subject (the person to whom the data pertains) did consent. It also talks about how the consent request may be presented and requires that consent can be withdrawn at any time, by a method no more difficult than that used to give consent. In other words, withdrawing consent has to be a straightforward process. That’s a lot of requirements to meet for consent to be valid.

    Consent vs. Contract: what’s the difference?

    Consent is one possible legal basis for data use and, as mentioned earlier, fulfillment of a contract is another legal basis that often applies to the domain registration world. It may seem that signing a contract is the same thing as providing consent, but legally these are two different things. Contract and consent may achieve the same purpose (to allow data processing) but the underlying legal basis is different. Any data processing required in order to provide the service must be included in the contract; for collecting data that’s “nice to have” while not essential to that service, consent is required.

    There are requirements around contractual data use as well, including data minimisation (which we talked about in the Whois changes blog post), and the requirement to provide an explanation of which data elements are collected on the basis of contractual need and how those elements are processed.

    We do need some personal data in order to fulfill our domain registration contract with the domain owner. Because those specific data elements are processed on the basis of fulfillment of a contract, rather than consent, there’s no option to withdraw consent from the use of that data. This is important because it’s what ensures that our compliance with the GDPR won’t result in situations where we must suspend domains. If consent is requested but never provided, we won’t use personal data in any way other than what’s covered in the contract  —  this means we can still provide the domain registration, we just can’t use more data than the bare minimum, and we can’t share the data in ways that are not required to fulfil the contract.

    How does this apply to the domain industry?

    We’re all accustomed to accepting lengthy and incomprehensible Terms and Conditions; it’s so common that it’s become a joke in popular culture. But this setup fails to fulfill a basic requirement under the GDPR: informed consent. So after May 25, 2018, that just won’t fly.

    Once the GDPR is in effect, we’ll be using a detailed consent request, sent to each domain owner after the registration request has been processed. This will disclose all the uses of personal data that are required by contract in order for us to provide the requested domain service, and will request consent from the data subject for those uses where our legal basis is their consent. Once the initial consent is granted, each domain owner will also have the ability to review and modify their consent choices on an ongoing basis. Finally, as required, we’ll ensure that there’s a way to withdraw consent as needed.

    Bringing contract and consent together

    To put this into real-life terms, when a domain is registered, we need to collect some data in order to enter into a domain registration contract with the registrant. This includes the registrant’s name, organization name (if one is provided, otherwise we assume the domain owner is an individual rather than a business), email address, and country code. Other pieces of data, such as the postal address and telephone number, are not required by contract. However, the domain owner might want to consent to us using this data, for a number of reasons. For example, it could provide a backup authentication method in case the registrant ever loses access to their email address.

    It’s not only about the contract the registrant enters into with us, however — there’s also a contract between us and the registry and, if that contract is GDPR-compliant, it will outline exactly which data elements the registry requires and their legal basis for collecting each piece of data. In turn, those data elements become required by us in order to be able to provide that domain registration service to the registrant — so that base set of data that I listed above will change, depending on the requirements of the specific TLD.

    That said, in some cases, we won’t be able to get a GDPR-compliant contract in place with the registry before May. In order to process registrations in these TLDs, we’ll need the domain owner to consent to the sharing of their data with the registry. Our other option would be to stop selling those TLDs entirely, but we don’t want to make that decision for the domain owner; we’d rather offer the choice, and let the registrant decide if they want the data shared (and the domain name registered) or not.

    What impact will this have on domain resellers?

    What does this mean for you as a domain reseller? The biggest changes that you’ll see resulting from to the GDPR’s consent requirements are around how we inform the domain owner about the ways their data is used and our need to obtain consent for any data use that is not required by contract. All these changes will put the domain owner in charge of how their data is used, which can only be a good thing.

    As we mentioned earlier, consent is needed if the domain owner wants to allow more data use than is required by contract, or if we don’t have a GDPR-compliant contract in place with our registry-provider but still want to offer the TLD. Keep in mind, though, domains are only one piece of the puzzle, one part of a reseller’s service offering. Anyone who takes orders, provides services, collects data, etc., needs to do their own work around disclosing data use, updating contracts, and gathering consent from customers. With the help of a lawyer, you can apply the same logic I described above to your business — be it web hosting, online presence building, or something else entirely. Work with your legal team to determine what data is truly needed to provide the service, make sure that’s included in the relevant service contracts, and gather consent for the rest. This way, your risk is greatly reduced and your clients can rest assured that they’re with a trusted provider, committed to the principles of transparency and consent.

    If you found this post helpful, check out our  GDPR page. We also encourage you to sign up for our GDPR newsletter so you don’t miss a thing!


    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

    • GDPR-Related Contract Changes (Published on Mar. 5, 2018)
    • The GDPR’s Right to Be Forgotten (Published on Jan. 18, 2018)
    • How will the GDPR impact Whois? (Published on Nov. 9, 2017)
    • The GDPR Overview (Published on Oct. 30, 2017)

    GDPR Resources – View third-party resources on a specific GDPR topic

    • Right-to-be-forgotten-related resources (Published on Feb. 1, 2018)
    • Consent-related resources (Published on Jan. 4, 2018)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • GDPR Resources: Changes to Whois

    December 7, 2017

    Featured, GDPR, Industry Insight

     Like

    Views: 5630

    Business woman considers the GDPR in front of parliament building in Brussels

    Following last week’s discussion of the significant Whois changes that compliance with the GDPR will require, here are some resources that I hope will help put things into a broader context.

    A letter to ICANN from Article 29 Working Party December 6 2017 (PDF)

    The Article 29 Working Party (“WP29”) is an advisory body established in 1996 under the EU’s Data Protection Directive (soon to be replaced by the European Data Protection Board under the GDPR). This letter to ICANN directly addresses the public Whois and how that system intersects with data privacy laws. WP29 says “unlimited publication of personal data of individual domain name holders raises serious concerns regarding the lawfulness of such practice under the current European Data Protection directive,” suggesting that this will be the case under the GDPR as well since it is based on the same principles. WP29 also states:

    “Whilst the data protection authorities united in WP29 recognize that, inter alia, enforcement authorities entitled by law should have access to personal data in the WHOIS directories, they also underline that the original purposes of the WHOIS directories can be achieved via layered access. In this respect, the unlimited publication of WHOIS-data does not appear to meet the criteria of article 6.1 (c) of directive 95/46/EC (personal data must be adequate, relevant and not excessive in relation to the purposes of the WHOIS directories).”

    This is the same conclusion that we arrived at — the public Whois system as it exists today is incompatible with the principles of data privacy that the GDPR affirms. It is gratifying to see this strong statement coming out of the EU, especially since it aligns with our own understanding of the changes to our domain registration infrastructure that the GDPR will require. Hopefully, this prompts ICANN to review and update their policies, allowing Registrars and Registries to comply with applicable laws with no concerns about breaching the affected sections of their ICANN contracts.

    “ICANN under pressure over GDPR preparations, as future of WHOIS is mired in uncertainty”

    Originally posted on World Trademark Review, this blog post was written for the benefit of trademark holders but contains useful insights for anyone with a connection to the world of domain names. If you’re looking for an overview of recent events related to how ICANN’s Whois plans—and those of its larger community—are progressing, this article outlines many of the challenges the GDPR presents to those operating within the domain industry, and highlights some conflicting opinions put forth by various stakeholders.

    ICANN’s GDPR legal analysis

    ICANN is working with an EU-based law firm, Hamilton Advokatbyrå, to gather legal advice related to the GDPR’s impacts on the domain name system; this page on the ICANN site will hold analysis from Hamilton as well as related documents. The first part of this analysis was posted on October 16, 2017 and responds to a series of questions that ICANN had laid out. In this response, Hamilton suggested that ICANN should evaluate the purposes for which personal data is being processed (displayed in the Whois). They also confirmed that these purposes could likely be achieved while remaining in compliance with the GDPR by using a gated Whois model, as we discussed in our previous post. We don’t yet know how ICANN will act on this information. Part 2 of the Hamilton analysis, which will look at the GDPR’s broader impact beyond the Whois system, is said to be “coming soon.”

    Dutch DPA: unlimited publication of Whois-data violates privacy law

    The .AMSTERDAM and .FRL registries are at odds with ICANN over the publication of personal data in the public Whois for these two TLDs. You can read the letters back and forth between ICANN and Jetse Sprey, who represents the .FRL registry, on ICANN’s data protection page and there’s a good recap of the situation at Domain Incite. The Dutch Data Protection Authority stepped in with this statement indicating that publication of personal data in the public Whois does, in fact, violate current Dutch law, and will also violate the GDPR. This gave .AMSTERDAM and .FRL a basis to argue to ICANN that they’re not in breach of their Registry Agreement. The statement also acknowledges that there may be technical or legal reasons why personal data should be accessed, but argues that default publication of registrants’ full contact details in the public Whois should not be permitted.

    Letter from CENTR answering ICANN questions (PDF)

    ICANN contacted various registries with a series of questions requesting information about how data protection laws are currently addressed. You can read the initial request here (PDF). CENTR, the Council of European National Top-Level Domain Registries, was unable to share some of its confidential discussions but provided general information that came out of a June 2017 survey. One notable statistic from this survey is that over 40% of these registries plan to hide some fields from the public Whois. I’m looking forward to the results from the next survey, which should hopefully be available before the end of 2017, and will tell us more about the ‘state of mind’ of these European ccTLD registries.

    Looking ahead

    While the future of Whois may be unclear at this point, it is clear that change is coming. We are moving ahead on our work towards a gated Whois, a solution which resulted from extensive legal and regulatory investigation and which we believe balances our legal obligations with our contractual requirements to ICANN. While a consistent, industry-wide approach to Whois, led by ICANN, would be ideal, it seems right now to be a far-off prospect.


    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

    • GDPR-Related Contract Changes (Published on Mar. 5, 2018)
    • The GDPR’s Right to Be Forgotten (Published on Jan. 18, 2018)
    • Consent and the GDPR (Published on Dec. 21, 2017)
    • How will the GDPR impact Whois? (Published on Nov. 9, 2017)
    • The GDPR Overview (Published on Oct. 30, 2017)

    GDPR Resources – View third-party resources on a specific GDPR topic

    • Right-to-be-forgotten-related resources (Published on Feb. 1, 2018)
    • Consent-related resources (Published on Jan. 4, 2018)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

FEATURED POSTS

  • Colleagues review ICANN's temporary specification requirements.

    What Domain Resellers Should Know About ICANN’s Temporary Specification

    September 18, 2018

  • keys on surface.

    Enom’s Tiered Access Directory (gated Whois)

    June 19, 2018

  • What you should know about ICANN’s May 25th Legal Action

    May 29, 2018

  • A Guide to Choosing the Right SSL Certificate

    May 24, 2018

CATEGORIES

  • Advice
  • Announcement
  • Developers
  • DNS
  • Featured
  • Fun
  • GDPR
  • Industry Insight
  • New TLDs
  • News
  • Premium Domains
  • Promotion
  • Resellers
  • Roadmap
  • SSL
  • Uncategorized
  • WTB

ARCHIVES

  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • September 2018
  • August 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • January 2016
  • December 2015
  • November 2013
Support

Report Abuse
Help Center
Contact Us

Resources

WHOIS Lookup
Maintenance Alerts
Developers
Products & Services

Domain Name Search
Premium Domains
Web Hosting
SSL Certificates
Website Builder
Basic Email
Bulk Tools

© 2019 Enom Blog |