MENU
  • Enom.com
  • Resellers

Enom Blog

  • ICANN 63 Recap: “Unified Access” to Registration Data

    December 19, 2018

    GDPR, Industry Insight

     Like

    Views: 892

    This is the second post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. Before diving in, we recommend taking a look at our recap of the EPDP team’s work leading up to and during the conference. You can watch this space for the final post in the series, which will cover ICANN work unrelated to the GDPR.

    ICANN’s Temporary Specification requires registrars to provide a means for third parties (such as law enforcement agencies) to access a registrant’s personal data when there is a legitimate legal reason to do so. Enom met this requiring by introducing our Tiered Access directory, but we remain hopeful that an industry-wide solution will be developed.  

    Over the last several months, the idea of a unified access model, or “UAM,” has been floating around the ICANN community. With a UAM, the process for accessing registration data would be standardized, with a defined set of eligible users and rules for what data they may obtain. This could be handled at the credentialing level, with registrars and registries required to respect the accreditations provided by a central governing body, or it could go as far as to require that all Whois data is held by and accessed through ICANN itself.

    The advantage to a unified model is that parties with legitimate reasons to access registration data could do so in a streamlined manner, and registrars would (in theory) be able to trust the credentials of any user working within this model.

    This contrasts the current reality: today, in order to access registration data for domains, third parties must each independently obtain credentials from the appropriate registrar or registry.  There is no central authority that we can trust to accredit eligible users, and no single source that a third party can work with to obtain registration data for domains registered with different providers.

    Ongoing discussions

    Two ICANN stakeholder groups, the Intellectual Property Constituency (IPC) and the Business Constituency (BC), have been pushing the EPDP team to develop a UAM, as they are concerned that the current decentralized situation is confusing to users, wastes time, and ultimately hinders their constituents’ ability to protect and assert their legal rights. For example, let’s use the case of a commercial litigator trying to send a cease and desist letter for an instance of trademark violation. The IPC and BC groups claim that the attorney needs to start by using the Whois record to determine who owns the offending domain name, but navigating and managing credentials for various registrar portals is a nuisance.

    The wider ICANN Community acknowledges the benefits of a unified access model, but also raised significant concerns about implementation. Holding all registrant personal data in a central repository creates a single point of failure for data breaches — if someone gains access to that central source, they can access the contact data for every gTLD domain. This may also put ICANN themselves at risk of liability if such a breach were to occur.

    Even if the data itself were decentralized, remaining held by each individual registrar, we’re left with concerns about having a single organization (such as ICANN) control accreditation. Registrars and registries are legally accountable for how and why the data they hold is shared, but in using a UAM, they’d be relying on the credentialing body to require demonstration of legal basis for accessing registration data (hopefully every time data is requested for a given domain, since the legal basis must be specific to each piece of data). And, as illustrated by examples like our own litigation with ICANN over the collection of technical contact data, what is acceptable as a legitimate legal basis can be somewhat subjective. If ICANN’s new contractual requirements require participation in a UAM, registrars and registries may be obligated to provide registration data to third parties in cases where they are not satisfied that a sufficient legal basis has been demonstrated. This is similar to the difficult balancing of more general GDPR requirements against ICANN contractual obligations — the registrar or registry is put in the difficult position of needing to choose between breaching their contract or potentially violating the law.

    What happens next?

    One of the core requirements in the EPDP team charter is to create a system for providing access to registration data. There are “gating questions” laid out in the charter, which will allow the team to “establish a baseline set of data that is collected for each domain name registration,” determine who should hold this data, and how it can be shared and processed. These gating questions must be answered before the EPDP team can consider the question of how third-party access to data will be granted. So until recently, discussions about the “how” had been pushed down the road when they came up during EPDP meetings. But now the EPDP Initial Report is out and, unfortunately, there is no formal consensus on the answers to the gating questions. In light of this, some members of the team have resumed pushing to discuss access as soon as possible, specifically before the Final Report is issued.

    The EPDP team will be meeting in person at the end of January 2019, and we’re eagerly watching to see what happens there, as well as how they respond to the feedback that we and other members of the ICANN community provide in response to their Initial Report. And as this post went to “press,” ICANN announced the assembly of a ten-man “Technical Study Group on Access to Non-Public Registration Data” (Domain Incite has a solid summary of this development). It’s unclear how ICANN selected the members of this team or how their work will fit into or align with the current technical work and in-progress policy development process. Both of these unknowns are extremely worrying. This type of group is unprecedented and their remit and charter are currently opaque. We remain committed to the multi-stakeholder process and will continue to hold ICANN Org accountable to it.

    Read More

  • Comodo CA is now Sectigo

    December 17, 2018

    Uncategorized

     Like

    Views: 782

    For the past two decades, Comodo CA has provided digital identity solutions to both enterprises and small businesses, issuing more than 100 million SSL certificates across 200 countries. Now, Comodo CA has rebranded as Sectigo.

    By rebranding, Sectigo is establishing itself as a separate entity from its predecessor, the Comodo Group, and emphasizing its expansion beyond SSL. The change marks a renewed commitment to innovation, digital transformation, and service.

    Sectigo’s mission is “to be the world’s most trusted, innovative, and customer-centric partner for protecting organizations’ identities, web presence and connected devices – from the biggest brands to the smallest websites – so they can secure today and seize their tomorrow.”

    Watch their journey from Comodo CA to Sectigo:

    If you’re an Enom retail customer who has purchased a Comodo SSL certificate(s) through Enom, there’s nothing you need to do. Your Comodo certificate(s) will remain trusted and valid until they expire.

    If you resell SSL certificates through Enom, you’ll find everything you need to know below.

    Here’s what resellers need to know

    This rebrand will not affect existing products and Comodo Authority roots will remain trusted. You’ll soon start seeing certificates issued by Sectigo instead of Comodo CA, however, the rebrand is happening gradually— you might still see specific certificates issued by Comodo CA during the transition.

    The specs for all certificates will remain the same, however the certificate names will change to reflect the new Sectigo brand instead of Comodo. We’ve created a Product Name Changes Chart to clarify the old and new product names.

    You might also find Sectigo’s FAQ to provide a helpful overview.

    What changes is Enom making?

    We will be making a few minor changes as a result of this rebrand:

    1. We are updating enom.com and our UI to display the new Sectigo brand and product names, removing mention of Comodo.
    2. In early 2019, we will update the API, and other integration platforms and tools to reflect the new certificate names.

    For API users – any future API changes will be backwards compatible. You can continue to use the same “comodo” services parameter values you do today — the Sectigo equivalent will be provisioned.

    Do Enom resellers need to take action?

    As mentioned, this rebrand will not impact how you register and manage Comodo/Sectigo SSL certificates through Enom. However, we recommend making a few front-end  adjustments as you see fit:

    1. Update any references to the Comodo brand on your website to Sectigo.
    2. If you market specific Comodo certificates to your customers, please ensure you update the product names.

    To help you with this, Sectigo has put together a partner resource page with their new logo, brand guidelines, and other marketing assets.

    Have additional questions?

    You can visit sectigo.com to find more information about this rebrand or chat with one of their representatives.

    If you have any questions or concerns about Enom’s’ implementation of this rebrand, please don’t hesitate to reach out to us directly at help@enom.com.

     

    Read More

  • ICANN 63 Recap: EPDP and Temp Spec Updates

    November 20, 2018

    GDPR, Industry Insight

     Like

    Views: 974

    TL;DR: Much of the ICANN 63 conference focused on the GDPR’s effects on our industry. We’ve recapped the EPDP team’s work, focusing on the possible policy outcomes that could most significantly affect our resellers and registrants: should admin and tech contacts continue to be collected and published? Should domain providers be required to differentiate between different registrant types? What happens next in this policy creation process?

    The last full week of October saw a group of Tucows staff attend the ICANN 63 conference in Barcelona. Our team participated in the ICANN policy development process, advocating for industry-wide policies and standards that will benefit our registrants and reseller partners.

    Our summaries of the conference may not bring the sights and sounds — or delicious foods — of Barcelona to you, but they will help ensure you’re up-to-date on important developments in the ICANN community. ICANN has also released their own post-meeting policy report, so be sure to take a few minutes to check that out when you’re done with this post.

    Resolving the conflicts between ICANN policy and the GDPR is a pressing challenge, and, as expected, the Expedited Policy Development Process (EPDP) team captured most of the attention during the week. Their work will also be our topic of focus for this post; our next will focus on the Unified Access Model.

    Background on ICANN’s Temporary Specification and EPDP

    We’ve written previously about ICANN’s Temporary Specification, the modifier to the 2013 Registrar Accreditation Agreement (RAA) which aims to close the gap between the GDPR and the RAA’s contractual requirements. The “Temp Spec” is valid only for one year, expiring in May 2019, at the end of which it must be replaced with a permanent policy. A year may sound like plenty of time to complete the necessary updates to ICANN’s contracts, but the typical turnaround time for a Policy Development Process is more like three to five years; the EPDP team has a very tight timeframe.

    Why does this matter to us, our resellers, and domain owners?

    ICANN has put together an Expedited Policy Development Process (“EPDP”) team, consisting of members from each of ICANN’s stakeholder groups, to work through the Temp Spec and confirm it (or some modified version of it) as a full Consensus Policy. This is crucially important for domain owners, as well as registrars, registries, and other industry participants, because the policy that emerges from the EPDP will define how people’s personal data are used for domain registrations moving forward. Domain owners may have new requirements for what information they need to provide when buying a domain, and how their data is shared or even published could depend on what they provide at the time of registration — more on that later. Registrars and registries will certainly have changes to make, but the full scope of these changes will only become clear as the EPDP team works through their open issues.

    As an ICANN-accredited registrar, we’re in a potentially difficult situation. We have an obligation to adhere to ICANN’s Registrar Accreditation Agreement and Consensus Policies. However, if we don’t believe that the policy resulting from the EPDP work is fully compliant with the GDPR, we’d have to forgo some of our ICANN obligations in order to follow the law — similar to how we currently ignore a few of the Temp Spec’s requirements to ensure we’re compliant with the GDPR.

    EPDP work at ICANN 63

    At ICANN 63, there were several meetings during which the EPDP members went through a series of data elements workbooks to define purposes for each piece of registrant data that ICANN currently requires registrars to collect; this work began in virtual meetings in early October. Under the GDPR, there must be a legal basis (purpose) for each instance of data collection and processing, so the EPDP team needs to come to agreement about ICANN’s legal basis for requiring the data outlined in the Temp Spec. The workbooks help to accomplish this in a structured manner.

    There were also presentations to the broader community, including open meetings where team members presented updates on the project and closed meetings where important groups at ICANN provided input towards the development of a final policy.

    In these open presentations, the EPDP team updated the community at large about their work. They recapped the goal of establishing the list of data elements we work with, and the importance of following each element through its whole life (from collection to deletion) and analyzing the legal basis, or purpose, of everything that happens to it, which must be within ICANN’s defined mission. Each of those purposes was documented in a workbook, which the team then debates until the purpose can be accepted by everyone. As one team member described it, each workbook is like performing a Data Protection Impact Assessment for that specific data use, an exercise required under the GDPR for fully-compliant data processing. The team’s initial report is available on their wiki page in draft format, and when it’s updated to be a final (non-draft) version it will either include a policy recommendation itself or open questions that will then lead to a policy recommendation.

    Debate over technical and administrative contacts

    One of the most-debated topics in EPDP working meetings was the continued collection and publication of technical and administrative contacts for domains, which we have a significant interest in due to the litigation between EPAG (another Tucows-owned registrar) and ICANN.

    Some EPDP members argue that this data should be collected. The domain owner may want to designate an alternate contact point, or a reseller may want to list themselves as the tech contact in order to help the registrant to more easily identify their service provider. And, as we know, ICANN has been pushing hard to maintain the requirement to collect the full pre-GPDR set of Whois data.

    As they worked through the Purpose C Workbook, the admin contact was quickly agreed to be no longer necessary, and the EPDP team focused their debate on a proposal that registrars should be required to allow domain owners to designate a technical contact. The registrant could then decide whether they want to name an alternate contact point; if they do not, their own data would be copied to that other contact set.

    Although this may appear to be a straightforward solution, it brings with it other issues. The purpose of having a tech contact is to provide an alternate point of contact, so we expect that most registrants who opt to do so would be supplying a third party’s info. In these cases, the registrar does not have a valid legal basis on which to process that data, as the alternate contact person would not be party to the registration contract, and the registrar has no clear way to obtain this contact’s specific, informed consent.

    Ultimately, the EPDP team has tentatively agreed on a minimized tech contact data set, which the registrar would be required to allow, but would be optional for the registrant to provide. The specific data elements that would be included are yet to be determined, but will rely on the “legitimate interest” legal basis (Art. 6 1(f) of the GDPR), as they are not needed for performance of the contract, but a third party may have a legitimate interest in the data.

    Beyond the not-so-simple collection of tech contact data, there is also debate about whether this information should be published. Right now, there is no consensus among the EPDP team as to whether the technical contact data must be provided (unredacted) in public Whois results. But if it is to be displayed, registrants will need to be made fully aware of that fact, because either the alternate contact info or their own registrant data would be published. And if an alternate contact’s data is to be published, finding a way to obtain consent from that individual is all the more important. Otherwise, we’d see situations where personal data is published unexpectedly, a huge privacy concern.

    This is a complex situation, where different interests conflict, and there are no easy answers. We don’t see a good legal basis to require that the tech contact be published. If it is required, the registrant’s only choice is between publishing their own info or someone else’s — the “option” to provide a tech contact no longer seems optional.

    Our reading of the legal requirement to provide data upon a showing of legitimate interest is that this legitimate interest must be demonstrated in each case. Anyone who has a legitimate interest to know the tech contact of a particular domain must be given that information, but that person doesn’t automatically get access to all other tech contacts, too. This is why we created a gated Whois: so that personal data can be provided when there is a legal basis but protected in situations where there isn’t.

    Collecting different data in different situations

    Another significant area of discussion among the EPDP members was to which registrants the GDPR protections should be applied. Should registrars differentiate by legal type, providing data protection to natural persons (i.e. actual people) but not to legal persons (i.e. corporations)? Then there’s the question of geographic location — should users local to the EU get GDPR protections while those outside the EU do not? We’ve shared our opinions on the location question already, and we have a similar position regarding the registrant type — we apply our GDPR protections uniformly to all registrants.

    It was gratifying to hear our concerns echoed by other registrars and EPDP members. Differentiation by registrant type creates a lot of risk and uncertainty. How do we know if the registrant is a person or a corporation, should we simply rely on the presence or absence of data in the Registrant Organization field? If so, what happens when a natural person puts their own name in the Organization field, perhaps thinking that it must not be left blank, and their personal data is then published? Would we instead need to add a new “person type” field to the registration requirements, and depend on that to determine if the Whois data should be published or redacted? That sounds like a good solution on the surface, but it would be a significant change for our resellers to implement and would make the registration process more cumbersome and confusing for registrants.

    Differentiating based on location is also more complicated than it might seem. If the address provided is in the EU but the IP geolocation shows North America, where do we consider them to be? Furthermore, this isn’t just about compliance with the GDPR and the rights of EU-locals. What about data handling laws from other jurisdictions, which may have similar requirements to the GDPR? Would we need to identify the various laws in each jurisdiction and apply them to the clients who we think come from those places?

    Minimizing our data collection for all registrant types and keeping things consistent across the board naturally places us more in line with other laws and evolving standards. And, since we use processors in the EU, even if both we and the registrant are located outside the EU the GDPR’s requirements still apply to our data processing practices.

    Even if the largest registrars have the resources to accommodate for all these intricacies in an accurate and automated manner, smaller businesses will likely struggle to implement such complex differentiation practices, and the liability risk for publishing personal data that should be redacted is significant enough to concern registrars of every size.

    So far, the registrar representatives in the EPDP team have held firm and pushed for only optional differentiation, performed only with the consent of the data subject. In this case, we could continuing applying GDPR protections to all registrants by default, unless the registrant specifically requests otherwise. So, if things go as they have been, we think we’ll be able to accept the part of the policy that comes out of the EPDP.

    Next steps for the EPDP

    Like other PDPs, the EPDP will include a public comment period, which is the best time for all members of the ICANN community (including interested resellers and domain owners) to give their feedback on the EPDP team’s recommendations. There were questions around the ‘unified access model’ that ICANN has mentioned, (see our upcoming blog post on the topic), but the EPDP team continues (correctly) to focus on determining the legal basis for processing the data ICANN requires to be collected, which must be established before access to that data can be granted.

    Work on a unified access model, “the definition and framework for reasonable access to registration data,” is part of what the EPDP is chartered to accomplish, but it must follow the completion of the EPDP’s Initial Report (mentioned above) and their eventual Final Report, which is due to be submitted to the GNSO Council by February 1, 2019. In the end, as Stephanie Perrin said in Barcelona, access itself is not a valid purpose under which to process data. Access may be provided, but the data is not collected specifically because someone might later want access to it.

    Moving towards a future policy

    Across the industry, there’s a shared commitment to the timely modification of policies and practices that place all ICANN requirements within the bounds of applicable law. In the first public forum of ICANN 63, our own CEO, Elliot Noss, talked about what he views as an encouraging level of collaboration. He said that at this ICANN meeting he’s seen more cooperation towards trying to resolve issues around Whois than he has seen on this issue in the year and a half that it’s been live, and perhaps on any issue this community has taken on. Elliot added that we have a unique opportunity here to demonstrate what the multistakeholder model can achieve.

    The GDPR’s impact on our industry is not only about Whois data and the rules governing its disclosure. It’s also about ensuring that people maintain control over how their data is used, that when personal data is entrusted to a service provider it remains secure, and that the data subject’s rights are respected at all times throughout a domain name’s lifecycle. As a registrar, we are committed to these principles; as a community, we need to find a way to move forward with them in mind.

    Read More

  • Email API Update: New Email Password Requirement in Effect November 23, 2018

    November 14, 2018

    Developers

     Like

    Views: 905

    padlock sitting on railing

    We’re strengthening our webmail password requirements to give our resellers and email users greater protection and peace of mind.

    If you’re a webmail user, or a reseller who manages your email service through your Enom account, this change does not require you to take any action. A new “Contains check” requirement will simply be applied during all future password resets and account creations.

    If you’re a reseller that manages your email service through our email API, you’ll need to make adjustments to your implementation prior to November 23rd, 2018, when this new requirement takes effect.

    Steps for Email API Users

    As of November 23rd, 2018, when you or your customers create or update mailbox passwords, we’ll only accept them if they meet our new “Contains check” requirement.

    We have added a new error code to our email API to reflect this new requirement:

    • Password rejected – contains username or other account info (48)

    To ensure your own systems, tools, and end-user interfaces remain synced with Enom’s email platform, please update your email API integration, as you see fit, before the new requirement takes effect on November 23rd, 2018.

    If you do not complete this update, your system may not register the appropriate error message when a password reset or registration fails.

    If you have any questions about this change, please don’t hesitate to contact us at help@enom.com.

    Read More

  • What Domain Resellers Should Know About ICANN’s Temporary Specification

    September 18, 2018

    Advice, Featured, GDPR, Industry Insight

     Like

    Views: 2076

    Colleagues review ICANN's temporary specification requirements.

    On May 17, 2018, ICANN issued a  “Temporary Specification for gTLD Registration Data,” the purpose of which is to provide ICANN’s contracted parties (registrars and registries) a path towards compliance with both ICANN contractual requirements and the GDPR. This involved the introduction of numerous registrar requirements, aimed at resolving points of conflict between ICANN’s Registrar Accreditation Agreement (RAA) and the GDPR. Here, we’ll highlight those requirements that are most relevant to our resellers, provide our stance on the Temporary Specification, and discuss some related upcoming features being added to the Enom platform.

    What is a “Temporary Specification”?

    To understand what makes the Temporary Specification unique, it’s important to understand how ICANN policy is typically developed. Normally, any policy that is binding on contracted parties (registrars and registries) is developed by a bottom-up, participatory process, taking input from all stakeholders and interested contributors, along a defined path called a  “policy development process” (or “PDP”).

    The output of a PDP is presented for public comment, refined, and then presented to ICANN’s Generic Names Supporting Organization (GNSO) Council for a vote. After a policy is approved by the GNSO Council, it is presented to the ICANN Board for final review and approval. Only after the ICANN Board approves the policy does it become binding on registrars and registries through a contractual provision in the above RAA.

    The Temporary Specification was issued as an “emergency policy,” meaning it was adopted by a super-majority of the ICANN Board and bypassed the normal policy development process. Emergency policies must be re-approved by the ICANN Board every ninety (90) days and can exist for no more than one year. The idea is that one year provides sufficient time for the ICANN community to develop a permanent policy along the normal, bottom-up development path. The Temporary Specification was adopted on May 17, 2018 and will expire on May 16, 2019.

    What does the Temporary Specification require of registrars?

    The Temporary Specification includes a long list of items that registrars “must” or “shall” implement in order to be in compliance with their Registrar Accreditation Agreement, many of which are pulled directly from, or are heavily based on, the GDPR itself.

    Here are some of the highlights, specifically those most relevant to resellers and registrants, with a note about any related changes we’re making within the Enom platform.

    Registrars “must” or “shall”:

    1. Redact personally identifying information from the public Whois output when (a) the registry or registrar is located in the EU; or (b) the registrant is located in the EU; or (c) the registry or registrar uses a data processor located in the EU for the registrant’s personal data. The redacted fields must say something like “REDACTED FOR PRIVACY.” (Temp. Spec. Appendix A Section 2)

    Enom’s approach: As of May 25, 2018, Whois lookups results for all domains on our platform have returned “Data Protected” in place of any personally identifying information. However, we haven’t just limited this practice to the specific cases listed above; the redaction of personal data in the public Whois is our default for all domains on our platform.

    2. Provide a method for third parties to contact the registrant through an anonymized email or web form. (Temp. Spec. Appendix A Section 2.5)

    Enom’s approach: We plan to launch a Whois Contactability service that will allow the registrant to be contacted through a hosted web form. We’ll provide more details in the next few weeks.

    3. Provide a means for the registrant to consent to have their contact details displayed in the public Whois, instead of the “Data Protected” notice mentioned above. (Temp. Spec. Section 7.2.1)

    Enom’s approach: We’ll soon be launching a Whois Publicity service that allows registrants to opt into the display of their personal data in the public Whois, details of which will be released in the coming next weeks.

    4. Implement Tiered Access to full Whois data, so that third-parties with a legitimate interest in access to a registrant’s personal data (such as law enforcement agencies) can review that data when necessary and appropriate. (Temp. Spec. Appendix A Section 4)

    Enom’s approach: We’ve built a Tiered Access Directory — or “gated Whois” — that accomplishes this.

    5. Provide mandatory disclosures to registrants detailing who has the registrant’s personal data, how it is processed, when and why a data transfer crosses international boundaries (if applicable), and the specific reasons that data is collected and transferred, among other subjects. (Temp. Spec. Section 7.1.)

    Enom’s approach: This information is easily located on our Data Use Information Page

    6. Comply with a new transfer policy, described in Appendix G to the Temporary Specification.

    Enom’s approach: The domain transfer process changes we announced on April 30, 2018, anticipated the new transfer policy outlined in ICANN’s Temporary Specification. No further changes are needed.

    7. Implement and observe Service Level Agreement (SLA) standards for Registration Data Access Protocol (RDAP), otherwise known as the successor to the WHOIS protocol. (Temp. Spec. Section 5.2)

    Enom’s approach: These Service Level Agreement standards are not yet finalized, but Enom has played an active role in the RDAP pilot project. We’re in a position to easily implement any minor changes to our current system that the final agreement may call for, and to help shape the SLA to ensure it’s something that all registrars can meet in order to provide a reliable and fast RDAP service to users.

    How and when are registrars expected to comply with the Temporary Specification?

    ICANN has stated that it is “enforcing the requirements of the Temporary Specification as of 25 May 2018, as it does any other ICANN agreement or policy requirement.” However, aware that the requirements of the Temporary Specification came late, ICANN has provided registrars some leeway. While ICANN has already sent notices of non-compliance to many registrars, they appear to be withholding further action so long as the registrar demonstrates that they are working toward compliance. So we can expect that the various GDPR compliance processes in place now — which vary from registrar to registrar —  may look quite different down the road. Virtually every registrar, including Tucows, is changing its implementation in important ways to comply with the Temporary Specification.

    What changes is Enom implementing?

    We have already implemented the majority of the mandatory requirements. As mentioned above, you can expect two new features in the coming months: Whois Contactability, which provides a means to contact the registrant through public Whois lookup results, and Whois Publicity, which allows registrants to opt into the public display of their contact data.

    What is Enom’s stance on the Temporary Specification?

    We believe industry-standard processes are important — they provide a level of consistency very much needed in this highly-connected registrant/registrar/registry network. Many of the Temporary Specification requirements will help move the industry forward towards a unified approach.

    However, we view other aspects of the Temp. Spec. as problematic. The Temporary Specification aims to provide registries and registrars with a path to comply with both ICANN contractual requirements and the GDPR, but in a way that maintains “the existing Whois system to the greatest extent possible” and requires “robust collection of Registration Data.”

    At Tucows, we believe that “maintaining the existing Whois system” and requiring “robust collection” of data violates the basic principles of GDPR. Put another way, we do not believe that the Temporary Specification is fully compliant with the GDPR. We have an ongoing disagreement with ICANN as to what the GDPR requires in three discrete areas, which is the subject of the ongoing ICANN v. EPAG litigation in Bonn, Germany.

    Right now, we’re focused on implementing those Temporary Specification requirements that do not conflict with the GDPR (which is, of course, the vast majority). The GNSO has initiated an Expedited Policy Development Process (“EPDP”), which we are watching with great interest, as we work within the registrar community to advocate for the best outcome for registrars, resellers, and registrants. We’re advocating for policy which fully complies with the GDPR, keeps domain registration and management simple, and protects the interests of our resellers. As we’ve said before, in any instance where ICANN policy conflicts with the law, our priority is compliance with the latter.

    Read More

  • Why We’re Applying GDPR Protections to Registrants Worldwide

    August 8, 2018

    GDPR, Industry Insight

     Like

    Views: 2299

    Remember, although we have a great legal team working at Enom, none of what we share here can or should be taken as legal advice.

    Among the world’s leading registrars, Tucows, our parent company, is the only one that has redacted all personal data from the public Whois and announced a data use consent management process for registrants worldwide. In making these changes, we’ve disrupted the status quo and encountered resistance from other industry members who would prefer a more conservative solution. But with our nearly two decades’ experience operating as an accredited domain registrar and supporting a large reseller network, we’ve learned that it is imperative to choose proactive solutions and remain focused on how the industry will develop long-term, rather than default to the most simple or convenient option.

    We’ve said many times before that we believe individuals around the world have a right to the privacy and protection of their personal data. We’ve also made the more practical argument that while the GDPR may apply only to EU-local individuals, other governments have also passed data protection laws, and we expect more to follow suit. Today, we want to talk about why we remain confident in our approach and place it within the necessary context of worldwide data privacy regulations.

    Comparing Regional Privacy Laws

    The GDPR has received a lot of attention not because it’s the only law of its kind, but because of its wide scope of applicability and, perhaps first and foremost, the severity of the penalties for non-compliance. There are other, less well-known laws in countries outside of the EU that establish similar data privacy protections. We’ve looked at a few important examples—Canada’s PIPEDA, California’s new Consumer Privacy Act of 2018, and the 2000 Argentina Personal Data Protection Act—to see how they stack up against the GDPR. You can jump to our summary table, which compares their fundamental concepts and relates them back to Enom’s data-processing practices, or continue on below for a high-level overview of each law.

    California

    The California Consumer Privacy Act of 2018 (AB 375) was signed into law by the state’s Governor on June 29, 2018. This new legislation takes effect in 2020, and many of the protections it extends to Californians will sound familiar to anyone who’s read up on the GDPR. At a high level, the CCP Act aims to ensure:

    1. The right of Californians to know what personal information is being collected about them.
    2. The right of Californians to know whether their personal information is sold or disclosed and to whom.
    3. The right of Californians to say no to the sale of personal information.
    4. The right of Californians to access their personal information.
    5. The right of Californians to equal service and price, even if they exercise their privacy rights (s.2.i).

    The CCP Act has an interesting fundamental difference to the GDPR: the GDPR protects the data, while the CCP Act protects the consumer. The GDPR sets out rights and obligations for Data Controllers, Data Processors, and Data Subjects, while the CCP Act focuses on the rights a consumer has in relation to businesses that process their data. Even with this scope of applicability in mind, it’s very clear that we can expect to see a heightened level of transparency and consumer control over data in California.

    These rights under the California Consumer Privacy Act will, of course, be subject to limitations, and the finer details will no doubt shift as government officials and private interest groups work to tighten up data privacy practices in a way that is not detrimental to the Californian businesses that rely on consumer data, including tech giants like Google and Facebook.

    It’s both fitting and encouraging that California, a hub for technological innovation, is leading the U.S. movement to protect individual privacy in our digital age. And while there may not be policy in development at the federal level just yet, other American states are well on their way to passing modernized data privacy legislation—check out this handy, albeit, slightly outdated, map for more details. It seems likely that some of the important provisions in California’s Consumer Privacy Act will serve as a template for other state governments looking to establish stricter data privacy laws.

    Canada

    Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) has been in place since 2000, but an accompanying document, “Guidelines for obtaining meaningful consent,” was just released in its final form on May 24, 2018, shortly before the GDPR came into effect. PIPEDA shares a number of similarities with the GDPR, which these new guidelines serve to highlight.

    PIPEDA may not explicitly mention “data minimization,” but it does state that “an organization may collect, use or disclose personal information only for purposes that a reasonable person would consider are appropriate in the circumstances” (Division 1.3). This idea is echoed and expanded in later sections, including “Principle 5 — Limiting Use, Disclosure, and Retention,” which declares that data “shall not be used or disclosed for purposes other than those for which it was collected, except with the consent of the individual or as required by law.” Much like the GDPR, PIPEDA has a clear aim to curb deceitful or indiscriminate data collection.

    In addition to restricting what data is processed, PIPEDA also calls for a high level of transparency around how and why data is processed. Its “Openness” principle affords individuals the right to request information about an organization’s data processing policies and practices, such as “a description of the type of personal information held by the organization, including a general account of its use” (Sched. 1 4.8.2). PIPEDA also requires organizations to obtain an individual’s consent before processing personal data, and specifies that this consent is “only valid if it is reasonable to expect that an individual to whom the organization’s activities are directed would understand the nature, purpose and consequences of the collection, use or disclosure of the personal information to which they are consenting” (Div.1, 6.1).

    Does this allow for service providers to bury the “nature, purpose and consequences” in the fine print? The word “reasonable” always invites a high degree of subjectivity. But the Office of the Privacy Commissioner of Canada (the “OPC”) released a related document, “Guidelines for obtaining meaningful consent,” which addresses any confusion. It states that “in order for an organization to demonstrate that it has obtained valid consent, pointing to a line buried in a privacy policy will not suffice.” Pretty clear.

    These Guidelines (well-summarized here) also put forth an idea quite reminiscent of the GDPR’s distinction between the legal bases of consent and contract. In Canada, individuals must be offered a clear “yes or no” option to consent to data processing. However, an exception to this rule is the collection or disclosure of personal information that’s required, or to quote directly, “integral to the product or service.” The collection or disclosure of such essential data are referred to as “conditions of service,” and can’t be opted out of without opting not to use the service at all. This is very similar to how contract-based data, those data elements which are required in order to provide the service for which they are collected, do not require explicit consent under the GDPR.

    The OPC also acknowledges that while some individuals may be content with a quick overview of what personal data is being collected, others will want a greater level of detail about their provider’s privacy and data use practices before making a consent choice. Organizations are encouraged to meet the needs of all users by presenting information in a “layered-format”, or some other method that provides the user with control “over how much detail is provided to them.” Our consent management process embodies this idea. We’ve clearly outlined the how, what, and why of our data collection practices, in a manner that avoids bombarding the reader with inaccessible legalese. Those looking to dive deeper can review our Data Use Information page, which we’ve also designed to be accessible to the average reader.

    Argentina

    Argentina’s Personal Data Protection Act is also an older data protection law, in effect since 2000. Argentina was the first Latin American nation designated by the EU as having an “adequate level of data protection” as compared to EU requirements.

    Argentina’s Data Protection Act is easily comparable to the GDPR, particularly in regard to the latter’s data minimization principle and distinctive treatment of consent- and contract-based data. The Argentine law requires that data collected must be “certain, appropriate, pertinent, and not excessive with reference to the scope within and purpose for which such data were secured” (Chapter 2, s.4.1). In addition to restricting what data can be collected, the Act also states that data must only be kept while it is necessary and relevant to the purposes for which it was initially collected—if it ceases to fulfill these requirements, it must be “destroyed” (s.4.4.7).

    These obligations go hand-in-hand with consent requirements: data processing is not permitted without the consent of the individual whose data is being processed, except in certain defined circumstances. The most notable exception to this requirement is the processing of data that arises “from a contractual relationship,” and which is necessary to develop or fulfill that contract. Here again, the consent request cannot be buried in the fine print. It must appear in a “prominent and express manner” (s.5.1).

    Argentina is currently working to create updated data protection regulations, which will be “heavily based upon the GDPR.” Thus far, we’ve only been able to locate a Spanish-language version of the updated draft bill, so we are relying on secondary sources for insight into how it compares to its EU equivalent. In a 2017 IAPP article, GDPR matchup: Argentina’s draft Data Protection Act, Pablo A. Palazzi and Andres Chomczyk provide a solid overview of the changes being made in an effort to bring the Argentine Law in line with the EU Regulation. Their review of the draft bill notes the introduction of “new legal bases” for data processing, including, “legitimate interest,” and the addition of “sections on child consent, data breaches, accountability, privacy by design, the duty to have a data protection officer and mandatory impact studies,” all of which closely resemble the GDPR’s data protection methods.

    It seems we can expect the updated Argentine law to mirror many of the GDPR’s fundamental components and, according to Palazzi and Chomczyk, even its scope of applicability; the draft outlines “new ways to determine whether an entity or certain data processing is subject to Argentine Law, quite similar to the criteria found in the GDPR.”

    We’re eager to view the new law in its final form and learn when it will take effect. The law in place at this time already includes many safeguards to ensure a high level of transparency and individual control around data collection, so in some ways, we don’t expect anything truly surprising from its successor, especially if the new version does indeed follow closely the GDPR. Our GDPR implementation efforts will likely prove sufficient to meet any updated Argentine requirements as well.

    Evolving Global Data Privacy Standards

    The policy revision efforts underway in Argentina speak to the GDPR’s global impact. Not only do the Regulation’s data processing requirements apply to organizations outside the EU that process the data of EU locals, the GDPR also serves as a standard, perhaps particularly for countries who wish to maintain or establish adequacy status with the EU.

    Just before this blog post went to “print,” India took a major step toward data privacy reform with the release of a report, “A Free and Fair Digital Economy Protecting Privacy, Empowering Indians,” that’s to serve as a draft data protection bill. In a recent Data Protection Committee press conference, Ravi Shankar Prasad, Union Minister for Law and Justice & Information Technology, Government of India, noted that India’s Supreme Court “would like Indian’s data protection law to become some kind of model for the…world…” (4m20s).

    For those interested, France’s Commission Nationale de l’Informatique et des Libertés maintains a global map existing privacy law (check it out!), which may look quite different even five years from now.

    A Comparison of Data Privacy Laws and Enom’s GDPR Changes

    To contextualize our recent changes in relation to the GDPR, California’s Consumer Privacy Act, Canada’s PIPEDA, and Argentina’s Personal Data Protection Act, we’ve put together this comparison chart. As you’ll see, many of the core concepts remain the same across borders. This confirms our position that our recent updates demonstrate a proportionate and forward-thinking approach to the rapidly-shifting landscape of global data privacy regulation.

    Reflecting on Our GDPR Changes

    We could have applied our GDPR processes to EU-locals only, allowing resellers who don’t offer services to clients in the EU to proceed with business as usual, unconcerned with the GDPR. But that solution would not only have put our resellers and us at risk of improperly processing the personal data of EU-local individuals, it was also not a viable long-term option. Data privacy standards around the world are evolving and not in a direction that supports the unnecessary collection of personal data or the continued display of unredacted personal data in the public Whois directory without the data subject’s clear and specific consent. If the laws we reviewed today are any indication of where things are headed, Enom and our reseller partners can feel confident that our GDPR implementation work has positioned us all to meet and adapt to changing data privacy requirements.

    Our decision to redact data from the public Whois, even before ICANN confirmed this as an appropriate response to the GDPR, was part of larger move towards a gated Whois solution. In designing our “Tiered Access Directory”, we’ve done our best to balance individual privacy and the rights of registrants with those of law enforcement and other community members. Our consent management process establishes a high level of transparency about what data we collect and why and provides registrants an easy means of revoking consent and submitting data use disclosure requests. These changes may cause some friction in the short term but we are confident they will help us meet the long-term needs of our resellers and ensure we’re protecting their businesses as well as our own.

    On a less practical note, our parent company, Tucows, maintains a long-time commitment to “lobby, agitate, and educate to promote and protect an open Internet around the world.” Part of ensuring that the Internet remains free and open is ensuring that basic individual rights, including control over one’s personal information, continue to be protected as personal data becomes more ubiquitous and easy to share than ever before. The laws we’ve looked at here take varied approaches to addressing this challenge but also share some important similarities and reflect values that are becoming more and more universal: greater transparency on the part of organizations and greater control for individuals.

    Read More

  • Enom’s Tiered Access Directory (gated Whois)

    June 19, 2018

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 2160

    Over the past few months, we’ve talked quite a bit about the concept of our Tiered Access registration directory, also referred to by its informal title, “gated Whois”. This has sparked many questions from our reseller partners and other interested parties who are curious about how the system works, who may have access, and what the accreditation process looks like. Today, we’ll address these topics and discuss why we believe a gated Whois system is the best solution for our platform, our resellers, and our registrants.

    Why are we implementing a gated Whois?

    As we’ve written before, in updating our platform to achieve GDPR compliance, we used data privacy laws as our starting point. We worked from the ground up to design processes that we believe comply with those laws and their underlying principles, and adhere to our contractual requirements with ICANN and other TLD registries to the fullest extent possible. The changes we made, including the decision to remove contact data from the public Whois, are necessary to protect ourselves and our reseller partners from the possible legal repercussions of improperly processing or exposing personal data. Furthermore, we believe this change to the public Whois makes sense — data protection should be extended to all domain owners, and we don’t see any legal basis or justifiable need to publicly display unredacted contact data.

    That said, we acknowledge that, in many cases, third parties may have a real, justifiable need to access a registrant’s personal data, and these legitimate interests are also provided for within the GDPR’s definition of “lawful processing”. By restricting the general public’s access to personal data and introducing our Tiered Access registration data directory, we are complying with the GDPR and extending its protections to all registrants on our platform while ensuring that those with a legitimate legal basis have access to the data they need in order to protect the public and exercise their own rights.

    Who will have access and how will they be accredited?

    Through a rigorous authentication process, Tucows will ensure that only those with a legitimate interest are given access to the gated Whois system and that this access is restricted to only those data elements that the user needs. Parties with a “legitimate interest” may include law enforcement agents, members of the security community, and commercial litigators.

    At present, we are actively responding to requests for accreditation from members of those communities. In the near future, interested parties will be able to click an application link on tieredaccess.com to submit an email with the required application information. This will include the requestor’s first and last name, organization, and email address, which specific domains they want to access, and the requested duration of access. They will also be asked to provide any other pertinent details such as the legal basis for the request.

    What data will be displayed in the Tiered Access Directory?

    There are three factors, that in combination, determine what contact data will be visible to an accredited Tiered Access user by default: the user’s permission access level, the registrant’s data use consent settings, and whether the domain is privacy-protected.

    Permission Access Levels for Accredited Users

    In designing our gated Whois system, we started from the principle of data minimization and determined that a Tiered Access directory was the best way to protect the privacy of our customers while providing parties with legitimate interest access to relevant registrant data. At a high level there are three permission access tiers, and within each we can further restrict permissions by many different factors.

    Through conversations with stakeholders, we determined three major categories of requestors: law enforcement, commercial litigation interests, and security researchers. We then examined the various personal data points we collect and identified those which are most pertinent to the above-mentioned parties. We have done our best to balance individual privacy and the rights of registrants with the rights of law enforcement and the people they protect, the rights of commercial litigators and their clients, and the need for a safe and secure Internet.

    Tier One – Law Enforcement Authorities

    Users within this tier must be a member of a law enforcement authority with jurisdiction over Tucows or one of its companies, and are provided access to the widest range of registrant data available through our Tiered Access system. Our aim is to supply these parties with data elements that may be relevant to a legal investigation while still respecting the registrant’s privacy and consent choices.

    Please Note: For the small subset of ccTLDs whose registries contractually require the admin and tech contact info, a portion of those datasets may be included in tier-one results.

    Tier Two – Commercial Litigators

    Access for users within this tier will be limited to those elements deemed necessary to exercise their clients’ rights to pursue legal action against the owner of a domain registered on our platform.

    Tier Three – Security Community Members

    Users belonging to this tier provide a valuable public service by examining trends in online criminal activity, helping to make the Internet safer for everyone. They may only view a limited set of information because, while they inarguably play an important role in online security, they have no official jurisdiction or legal authority.

    Data Use Consent Settings and Whois Privacy Status

    For domains without Whois Privacy protection, the Tiered Access system (gated Whois) can display the following data:

    • Data that we require by contract: registrant name, country, email, and organization (if applicable)
    • Data that the registry requires by contract
    • Data which we have consent from the registrant to process

    This means that, in instances where the registry does not contractually require any data elements and we do not have consent to process any additional elements, only the minimum data that we require contractually will be shown.

    Tip: Through a quick search on our Data Use Information Page, you can determine which data are processed as per the registry’s contract and which are processed by consent.

    For domains with Whois Privacy protection, the Tiered Access system will only display the Whois Privacy contact data, just as it appears for privacy-protected domains in the public Whois. It’s also important to note that the process to reveal the underlying ownership information has not changed with the introduction of a gated Whois; we would still require the tiered-access-accredited party to provide a court order, subpoena, or similar legal justification before our Compliance team would provide the underlying contact data. In short, all the benefits of Whois Privacy carry over into our gated Whois system.

    Further Customizing User Access

    As we outlined above, the actual data elements visible by default to any accredited user of the Tiered Access system depend not only on the data use consent settings and privacy status of the domain, but also on the accredited user’s permission access level. On top of these controlling factors, we can also place additional custom restrictions on a user’s account.

    Our Tiered Access system uses the Registration Data Access Protocol (RDAP), developed by the Internet Engineering Task Force as an eventual replacement for the current WHOIS protocol. One of the essential benefits of using RDAP is that it allows us to define user access options at a very granular level. We can, for example, restrict the number of domains a user can query per day, the data fields returned by each query, which specific domains can be queried, and which data elements are returned in the response. We can also set the specific duration for which a user’s account remains active.

    This means that some users may have access to the full set of registrant data we hold, restricted only based on the registrant’s data use consent settings and the Whois Privacy status of the domain. For other users, it may be that only the registrant’s email address, only the registrant’s name and country, or, perhaps, only contract-based data, will be shared.

    What’s important to take away is this: our high-level tiers are a starting point; we have the flexibility to customize as needed and make adjustments as we find the best way to balance the rights of multiple parties.

    How will the Tiered Access system be accessed?

    The sign-in portal is available at tieredaccess.com. This page also includes an explanation of the Tiered Access registration directory and some information about who may be accredited. Over the next few phases, we’ll add an option to apply for access, a link to the applicable Terms and Conditions, and a public Whois lookup option, allowing the page to function as a Whois directory for both the public and gated versions of the service.

    Will resellers have access to the Tiered Access system?

    We have no plans to provide our reseller partners access to the gated Whois, but, if you’re one of our resellers, this shouldn’t be cause for concern — the data that appear in Tiered Access for any domains in your account are accessible to you through the Domains tab of the Control Panel or the GetContacts API command. Also, keep in mind that with the new domain transfer process, the gaining registrar no longer has to send the initial Form of Authorization to the registrant email address, which has historically been retrieved from the contact details in the public Whois.

    Finding a Balance

    Much of the debate over the concept of a gated Whois system has focused around finding a balance between protecting individual privacy and ensuring that those using domains to perpetrate malicious activities can be held accountable. A recent Techdirt article described the debate’s central question as, “which is more important for society: protecting millions of people from spammers, scammers and copyright trolls by limiting the publicly-available Whois data, or making it easier for security researchers to track down online criminals by using that same Whois information?” As a registrar, our central concerns are compliance with law and protecting the data we process. However, we also believe that, as far privacy laws permit, those who play an essential role in keeping the Internet safe should have access to the data they require in order to do so. Our Tiered Access system is a solution that accomplishes both objectives.

    Read More

  • Why Choose an EV SSL Certificate?

    June 13, 2018

    Advice, SSL

     Like

    Views: 1892

    Identity theft and browser warnings are growing concerns among consumers. And while you may think enabling SSL on your website will allay these fears, failure to select the right TLS/SSL certificate can erode customer trust. To regain trust, site owners need an easy, reliable way to show customers that transactions are secure and that the site operator is who it says it is. But with the variety of TLS/SSL certs available – DV, OV, or EV – figuring out the best certificate for your business can be confusing. There are major differences in how domains are validated, and the following outline provides some key insights as to which certificate to select for your specific needs.

    Domain Validation (DV) SSL Certificates

    DV certificates prove ownership of the actual domain through a simple email validation process. DV certificates can be issued in minutes, show trust indicators in browsers (like the padlock icon), and enable HTTPS.

    However, DV certificates do not vet the legitimacy of an organization and should not be used for e-commerce sites. Accordingly, DV certificates are best for internal sites, test servers, test domains, and for small to medium-sized businesses seeking cost-effective security.

    Organization Validation (OV) SSL Certificates

    OV certificates provide the same level of protection as DV certificates but go one step further. With an OV certificate, the Certificate Authority (CA) confirms the business is registered and legitimate, checking details such as business name, location, address, and incorporation or registration information, making these certificates more suitable for public-facing websites.

    An OV certificate will also enhance a website’s reputation, providing customers greater assurance in conducting e-commerce transactions.

    Extended Validation (EV) SSL Certificates

    EV SSL certificates provide the highest level of trust, giving customers greater confidence that they are conducting business through trusted websites. EV SSL certificates are the industry standard for e-commerce websites. An EV SSL certificate triggers high-security web browsers to display an organization’s name in a green address bar and show the name of the Certificate Authority that issued it:

    EV SSL certificates confirm site identity and validate the organization according to rigorous industry guidelines established by the CA/Browser Forum, including a strict vetting process using techniques that have been proven reliable in protecting the internet’s most valuable online businesses for more than ten years.

    EV SSL certificates are a good choice for businesses, as these certificates can enhance credibility by showing suspecting consumers that sites are legitimately what they purport to be and that a business is serious about protecting the data of its customers.

    Summed up, for the greatest level of website security, EV SSL certificates are the best choice.

    Find Out More

    This post was sponsored by Comodo CA, one of our trusted SSL providers. For more information about SSL, and a complete list of their products, visit www.ComodoCA.com.

    Read More

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

    May 29, 2018

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 2258

    Update: The German Court has since denied ICANN’s preliminary injunction. If you’re interested in reading the Court Order you can find it, as well as any related documents, here.

    If you’re one of our reseller partners or someone who follows the domain industry closely, you’re likely aware that on Friday, May 25th, ICANN filed a legal action1 against our European sister company, EPAG, a Tucows-owned Registrar based in Bonn, Germany.

    This action was taken because of a disagreement between Tucows and ICANN on how the GDPR should be interpreted, with respect to our contracts. While we look forward to defending our position in court, we also find it important to provide our resellers some context and insight into the dispute. Our position is a registrant-centric one that protects individual rights and the interests of our resellers and registrants.

    The GDPR begins with a statement of its core principle: “The protection of natural persons in relation to the processing of personal data is a fundamental right.” Tucows has long been concerned with privacy and the rights of our customers, and takes the principles enshrined in this law extremely seriously.

    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.

    We realized that the domain name registration process, as outlined in ICANN’s 2013 Registrar Accreditation Agreement, not only required us to collect and share information we didn’t need, 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.

    ICANN’s goal since discussions about the impact of the GDPR on domain registration began has been to preserve as much of the status quo as possible. This has led ICANN to attempt to achieve GDPR-compliant domain registration via ‘process reduction’, as opposed to Tucows’ approach of starting with the GDPR and rebuilding from the ground up. These two approaches have led to significantly different results, and consequently a need to determine whether ICANN’s insistence on the collection of the full thick Whois data and this data’s transfer to gTLD Registries is in compliance with the GDPR. It is this disagreement and need for legal clarity that is at the heart of the lawsuit filed by ICANN.

    On the 17th of May 2018, the ICANN board passed a ‘Temporary Specification2’, meant to temporarily bring gTLD registration services in line with the GDPR. The goal of the Specification is to serve as a stop-gap while the ICANN community works to resolve and balance issues between privacy law and existing ICANN policy.

    With that background in mind, we perceive three core issues with the Temporary Specification that we do not believe are compliant with the GDPR. These issues are the collection, transfer, and public display of the personal information of domain registrants and the other contractually-mandated contacts.

    Personal Data Collection

    Article 5(1)(c) of the GDPR speaks to data minimization: collecting and processing only what personal data is necessary. It is clear to Tucows that we need to continue capturing some information about the domain Registrant—we always want to ensure we have the ability to contact the person legally responsible for the domain. 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.

    That said, in the less common scenario, the Admin or Tech contact does not match the Registrant. In these cases, the mandatory collection of their contact data is problematic because it requires us to store and process personal data belonging to people with whom we have no legal or contractual relationship.

    ICANN will need to prove that the minor, marginally incremental benefit of collecting, processing and transferring Admin and Tech contact data at the request of third parties outweighs the principles of data minimization and lawful processing enshrined in the GDPR. We find the argument that duplicative technical contacts are necessary for the security and stability of the DNS implausible.  We were not convinced this was the case when we first examined the law, and we remain unconvinced following the release ICANN’s Temporary Specification.

    Tucows will continue to ensure that those with legitimate purposes, including law enforcement, intellectual property, and commercial litigation interests will have access to domain registrant information. On a daily basis, we see plenty of important circumstances wherein we find sharing that information to be legally necessary, and this will not change. We collect a contact for the owner of each domain name sold on our platforms, and have the ability to contact the owner. When necessary, we also share that contact with law enforcement and others with a legitimate interest.

    Personal Data Transfer to a Registry

    ICANN’s continuing requirement that registrars transmit all data collected to the relevant registry is counter the GDPR’s principle of use of data only when a legitimate legal basis applies. There are circumstances where this transfer is necessary and reasonable, for example where a TLD has specific registrants requirements such as geographic restrictions.  We are not opposed to these circumstances, but require agreements between ourselves and the registry for the specific collection, processing and transfer of that personal data.

    However, as the registrar, we collect data that we need in order to enter into a contractual relationship with and provide requested services to the registrant. Transfer of that data to a registry is unnecessary—this is proven by the decades-old ‘thin model’ that 140 million .com and .net domains follow.  We don’t feel that the temporary specification offers a robust legal basis for the transfer of data to registries and therefore presents an unacceptable risk under the GDPR.

    Personal Data Display

    ICANN has also required that we continue to publish the organization, state/province, and country fields in the public Whois. We disagree that the organization should be published because, although it is optional, many people do not realize this and put their own first and last names in the organization field. We do not want to expose the personal data of these registrants because of a misunderstanding, and it will take considerable time to educate registrants and cleanse this data from the field.  

    Desire for Clarity

    Fundamentally, ICANN and Tucows disagree on how the GDPR impacts our contract. The facts and the law as we see them do not support ICANN’s broader view of what will impact the security and stability of the internet. Neither do we find the purposes outlined in the temporary specification proportional to the risks and consequences of continuing to collect, process and display unnecessary data. We look forward to, and welcome the clarity that will come from this legal action, which will allow us to move forward in a manner that protects ourselves, our resellers, and registrants.

    If you have any questions, concerns, or comments about our this legal action or Tucows’ position, feel free to reach out to us at gdpr@tucows.com.

    The content of this post was originally published in Tucows Statement on ICANN Legal Action on tucows.com.

    1https://www.icann.org/news/announcement-2018-05-25-en

    2https://www.icann.org/news/announcement-2018-05-17-en

     

    Read More

  • A Guide to Choosing the Right SSL Certificate

    May 24, 2018

    Advice, Featured, SSL

     Like

    Views: 1952

    A parent preparing a toddler for her first beach vacation and a seasoned kayaker preparing for Zambia’s Ghostrider rapid will not reach for the same life jacket. In the world of digital security, the purposes and specs of the various products are also highly relevant to the consumer, although the differences between them may not be so immediately clear. But in both cases, it’s important that the customer find the right fit. Whether you’re a business owner looking for the right SSL certificate for your own website or a domain provider looking to curate a solid SSL offering for your own customers, here’s what you should know about TLS/SSL certificates and what to look for when selecting a certificate provider.

    What are TLS/SSL Certificates?

    SSL is short for “Secure Sockets Layer,” and SSL certificates are used to secure communications between a website, host, or server and the end users that are connecting to it (or between two machines in a client-server relationship). An SSL certificate confirms the identity of the domain name (for example, ComodoCA.com) that is operating the website and enables encryption of all information between the server and the visitor to ensure the integrity of all the transmitted information.

    Why are TLS/SSL Certificates So Important?

    Identity theft and browser warnings are growing concerns among consumers. Failure to select the right TLS/SSL certificate for your website can erode customer trust and lower your rate of completed transactions, negatively impacting your bottom line.

    How SSL Encryption Works

    Encryption makes use of keys to lock and unlock your information, meaning you need the right key to “open,” or decode, the secured information.

    Each SSL certificate comes with two keys:

    • A public key, which is used to encrypt (scramble) the information.
    • A private key, which is used to decrypt (unscramble) the information and restore it to its original format to make it readable.

    Where Are SSL Certificates Used?

    SSL certificates should be used in any instance where information needs to be transmitted securely. This includes:

    • Communications between your website and your customers’ internet browsers.
    • Internal communications on your corporate intranet.
    • Email communications sent to and from your network (or private email address).
    • Information between internal and external servers.
    • Information sent and received from IoT and mobile devices.

    Determining If a Site Has a Valid SSL Certificate

    A website without an SSL certificate displays “http:// ” before the website address in the browser address bar. This moniker stands for “Hypertext Transfer Protocol,” the conventional way to transmit information over the Internet. Most internet users are aware that this indicates a website is not secure and historically have looked for  https:// and a closed padlock symbol in their browser window to confirm that they are on the site of an authenticated organization:

    However, it’s no longer sufficient for business websites to simply enable HTTPS and display the standard padlock symbol to their visitors. Online consumers are demanding assurance that the identity of the website they are visiting has been verified by authentication procedures that are proven to be highly trustworthy. And this assurance is provided in the form of an Extended Validation (EV) SSL certificate. EV certificates display a hard-to-miss green identifier in the URL bar and indicate to the visitor that the website was subjected to extensive scrutiny by the issuing Certificate Authority. The consumer can be confident that they are at a legitimate website, not a phishing website.

    That’s not to say an EV certificate is necessary in every situation. But they can generate a higher level of consumer trust than other options, such Organization Validation (OV) certificates, or Domain Validation (DV) certificates, which undergo far less scrutiny.

    Choosing between EV, OV, and DV Certificates

    Domain Validation (DV) SSL Certificates

    DVs are best for small- to medium-sized businesses seeking cost-effective security with no need to establish site visitor trust. Issuance of a DV certificate simply requires proof of ownership of the associated domain name, which is provided through a simple email validation process. These certificates can be issued in minutes, enable HTTPS, and display a clear indicator, such as the padlock symbol, in internet browsers.

    However, DV certificates do not vet the legitimacy of the organization the website represents and should therefore not be used for e-commerce sites or sites that deal in sensitive information. They are, however, a great option for many internal sites, test servers, and test domains.

    Organization Validation (OV) SSL Certificates

    OV certificates provide the same level of protection as DV certificates but go one step further than simply requiring proof of domain ownership. With an OV certificate, the issuing Certificate Authority confirms the business associated with the domain name is registered and legitimate by checking details such as the business name, location, address, and incorporation or registration information. This makes the OV certificate a more suitable option for public-facing websites that represent companies or organizations.

    Extended Validation (EV) SSL Certificates

    EV certificates provide the highest level of trust by assuring consumers that they are conducting business through a trusted website. For this reason, these certificates have become the industry standard for e-commerce websites. EV SSL certificates trigger high-security web browsers to display a green address bar that includes the name of the company or organization that owns the domain. They also show the name of the issuing Certificate Authority:

    Confirmation of the website’s identity and validation of the organization is carried out according to the rigorous industry guidelines established by the CA/Browser Forum and involves a strict vetting process that is shown to be effective over the course of more than ten years of real-world use.

    EV SSL certificates are essential for large businesses or e-commerce sites as they can enhance credibility by showing discerning consumers that a prospective transaction is with a legitimate recipient and that the site is serious about protecting the data of its customers.

    What to Look for When Choosing a Certificate Authority (CA)

    As the world’s largest commercial Certificate Authority, Comodo CA is proactively monitoring for potential threats and attacks, working hand-in-hand with government agencies, browser providers, and our customers, to ensure it is keeping up with the ever-changing market.

    When evaluating a CA, be sure that it:

    1. Follows CA/B Forum Baseline Requirements.

    This industry group consisting of Certificate Authorities and browser manufacturers developed standards that each CA must meet for its roots to remain trusted in browsers. These include:

    • All information contained within the certificate must be validated to be true through a strict, clearly defined authentication process.
    • Certificates must meet specific minimum levels of cryptographic strength to protect the integrity of the certificate and private key from evolving threats.
    • Certificates must not exceed maximum specified durations.
    • CAs must follow guidelines for CA security, certificate revocation mechanisms, audit requirements, liability, privacy and confidentiality, and delegation of authority.

    2. Conducts Annual Audits – Both WebTrust and SOC 3

    Annual audits are crucial to CA security, yet not every CA makes them a priority. At a minimum, your CA should meet these auditing standards.

    • Maintain membership in the WebTrust program for CAs
      The WebTrust for Certification Authorities program was developed to increase consumer confidence in the Internet as a vehicle for conducting e-commerce and to increase consumer confidence in the application of PKI technology. Comodo CA, for example, undergoes an annual audit from Ernst & Young, which validates that:
    • The Certification Authority (CA) discloses its SSL certificate practices and procedures and its commitment to provide SSL certificates in conformity with the applicable CA/Browser Forum Requirements.
    • Subscriber information was properly collected, authenticated and verified.
    • The integrity of keys and certificates is established and protected throughout their life cycles.
    • Logical and physical access to CA systems and data is restricted to authorized individuals.
    • The continuity of key and certificate management operations is maintained.
    • CA systems development, maintenance and operations are properly authorized and performed to maintain CA systems integrity.
    • The Certification Authority maintains effective controls to provide reasonable assurance that it meets the Network and Certificate System Security Requirements as set forth by the CA/Browser Forum.
    • Submit to publish an annual Service Organization Control 3
      The SOC3 report is published to confirm that the security controls for this cloud service have been examined by an independent accountant. Again, as an example, Comodo CA undergoes an annual audit from Ernst and Young, to validate that Comodo CA has maintained effective controls over its system as it relates to four core principles: security availability, processing integrity and confidentiality.

    To sum it up…

    Trust is everything in the world of online business. Investment in technology to protect customers and earn their trust is a critical success factor for any company that does business online or hosts an e-commerce website.  The effective implementation of TLS/SSL certificates is a proven tool to help establish customer trust. Check out Enom’s lineup of Comodo Certificates, or browse our full inventory of SSL products.

    Looking to learn more?

    This post was sponsored by Comodo CA, one of our trusted SSL providers. For more information about SSL, and a complete list of their products, visit www.ComodoCA.com.

    Read More

  • GDPR Checklist for Enom Resellers

    May 17, 2018

    Advice, Announcement, Featured, GDPR, Uncategorized

     Like

    Views: 3697

    Any time there’s a dramatic shift in our industry, we focus on minimizing the impact on our resellers and providing you as much information and assistance as possible. Admittedly, our GDPR communications work has proven fairly challenging, in part because we’ve simply never seen a shift quite as dramatic as that prompted by the GDPR. While we wanted to equip our resellers with specifics about our implementation plan and a concrete list of action-items right from the get-go, developing long-term solutions that both achieved GDPR compliance and established processes in which registries, registrars, and resellers can play their specific, essential roles required considerable collaborative efforts from players across our industry.

    There’s still much work to be done, but today we’re happy to be able to offer a concrete list of GDPR action-items for Enom Resellers and helpful resources in the form of flowcharts, example landing pages, and FAQs. We’re even happier to say that the to-do list is a short one which will likely require minimal work on your end.

    Having said that, we must remind you that legal counsel is an essential part of any comprehensive GDPR compliance strategy. This checklist is not legal advice, and ensuring its completion by no means guarantees your compliance with the GDPR. Speak with a lawyer who is familiar with your business and equipped to judge whether your internal practices achieve compliance.

    Reseller Action-Items

    Most of these items will necessitate adjustments on your end. You may determine that some do not require action on your part, but all are significant and important for our clients to understand.

    1. Make Sure You’re Familiar with Our Newly Introduced Consent Management Process

    Moving forward, Enom will reach out to end-users to request their consent to process certain pieces of personal information. This “Consent Management” flow involves the sending of a request email which contains a link to the registrant’s unique Data use consent settings page. This Data Use Consent Settings page serves as the registrant’s means to view their settings, manage their settings, and withdraw consent, should they choose to do so. It also contains a link to the Data use information page, which provides more information about how personal data is processed.

    To the registrant, it’s a straightforward experience that makes clear Enom’s relationship with their Registration Service Provider (Reseller). We recommend you take a look at these samples, so you’re aware of what this process will involve for your customers:

    Consent management sample flow – new registration
    Consent management sample flow – consent choice change

    Resellers will be able to view the GDPR consent status for each domain they have under management from the Domain Control Panel, within their Enom reseller account. If you’d like more information on why we require the end-user’s consent to process certain personal data, please check out our Consent blog post.

    2. Understand How to Provide Your Customers Access to Their Data Consent Settings Page

    According to the GDPR, “It shall be as easy to withdraw as to give consent.” With this in mind, we’ve provided our resellers two straightforward options to email a registrant the URL for the registrant’s Data Use Consent Settings page upon request:

    • Option 1: Via the API using the SendConsentEmail command
      Resellers can use this command to integrate into their own end-user portal an option for users to request that the Data Use Consent Settings page URL be sent to the registrant email.
    • Option 2: Via the soon-to-be-available “Send Consent Email” option in your Enom reseller account.
      Resellers can use this new button in the “Domain Control Panel” section of your Enom reseller account to send out the Data Use Consent Settings page URL to the registrant email listed for any domain in their account.

    Please note: both of these options will be available as of Monday, May 28, 2018.

    3. Ensure You’re Prepared for Our Updated Domain Transfer Process

    Once the public Whois “goes dark” in the days leading up to May 25, 2018, Enom will begin using a new process for domain transfers. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

    You can check out our blog for the full details, but here’s a snapshot of the updated process:

    4. Enom Is Moving to a Gated Whois System

    For the full scoop, refer back to our Whois Changes blog post; for today, just keep in mind that after that go-live date, most public whois servers will cease the publication of personal data, and providers will start offering a “gated” or “tiered access” Whois system. Enom resellers don’t need to make any changes — your own clients’ data will continue to appear in your Enom reseller account, and we’ll take care of making sure the public Whois output is fully compliant with privacy regulations, so you’re good to go.

    These changes are also summarized in this quick PDF.

    5. Our Updated Reseller Agreement Now Requires That Resellers Process Data in a GDPR-Compliant Manner

    Hopefully, you’re well on your way to compliance with the GDPR. Enom has updated our Reseller Agreement to include information about the consent management process and the addition of a Data Processing Addendum (DPA), with EU standard contractual clauses to allow data transfer from the EU to non-EU jurisdictions. We encourage you to familiarize yourself with all the recent GDPR-related changes we’ve made to our Reseller Agreement by taking a look the updated version.

    6. We’ve Updated Our Agreement with Registrants

    Our Domain Registration Agreement serves as the service contract between Enom and the domain owner (registrant). We don’t expect the GDPR-related updates to this agreement to be reseller-impacting, these changes primarily relate to the registrant’s consent management flow and the data retention and erasure policy. Keep in mind that all resellers need to display this updated agreement to customers as part of the domain registration process.

    Reseller Resources

    All important Enom resources relating to the GDPR can be found in our central GDPR knowledge base article, but for convenience, we’ve also listed them below. We hope the following resources help our reseller partners assist your clients with GDPR-related changes:

    Overview

    Our GDPR Webinar
    Central GDPR knowledge base article and FAQ

    Specific Platform & Process Changes

    Consent Management

    Consent management sample flow – consent choice change
    Consent management sample flow – new registration
    Consent management FAQ

    End-user consent request emails – The means by which we send the Data Use Consent Settings page URL (see below) to the registrant.
    Data use consent settings pages – The location from which a registrant can set, view, and update their consent preferences or revoke consent.

    Domain Transfers

    Transfer process changes infographic – a before and after GDPR comparison

    Whois Changes

    Whois Changes Overview PDF
    Whois Changes FAQ

    API Changes

    A new SendConsentEmail command has been introduced.

    Contract Changes

    Updated Reseller Agreement
    Updated Domain Registration Agreement
    Data Processing Addendum

    And there you have it. We appreciate that for those resellers affected by the GDPR, achieving compliance has involved a great deal of internal work, in addition to that required to accommodate the changes Enom is making to our platform. And while we’ve made every effort to keep this Reseller Checklist short and easy-to-implement, we know, as members of that same complex registry-registrar-reseller channel in which you operate, that small changes made by one player can have a big impact on others. We view our GDPR implementation work as essential to ensuring that the Enom platform evolves to meet the long-term needs of our resellers and the demands of a highly interconnected internet ecosystem. Greater control over one’s personal data is a good thing, and we’re happy to be able to extend to all users on our platform the rights and protections outlined in the GDPR.

    Read More

  • Important Changes to our Legal Agreements

    May 10, 2018

    Announcement, GDPR

     Like

    Views: 1532

    We appreciate the work that our reseller partners have done, alongside our own, to come into compliance with the GDPR. In support of that work, please review our updated Reseller Agreement and Domain Registration Agreement. These updated contracts will go into effect 25 May, 2018.

    These changes primarily relate to the registrant’s consent management flow and include the addition of a Data Processing Addendum (DPA), with EU standard contractual clauses to allow data transfer from the EU to non-EU jurisdictions.

    We also understand that ICANN will be adopting a standard Data Processing Addendum, which would apply to its role with us (and you), our role (and yours) with gTLD registries, and our role (and yours) with data escrow providers. We were hoping to make this available to you along with our updated agreement, but in the interests of time and the need to achieve compliance on the set schedule, we are using our own data processing addendum instead for the present.

    If, as we anticipate, ICANN develops and issues to registries and registrars a new binding policy under the terms of our Registrar Accreditation Agreement, with a mandatory or recommended DPA, we will likely amend certain terms of our Master Services Agreement and the associated exhibits to conform to industry standards and assure contractual compliance with ICANN.

    We also anticipate that gTLD and ccTLD registries will continue to amend their contracts in the days and weeks ahead, so please ensure that you are always pointing your users to the most current version of the relevant registry terms and conditions, as referenced in our Domain Registration Agreement.

    Should any additional changes be required in this rapidly evolving area, we will inform you via our blog and newsletter.

    Read More

  • Changes to the Domain Transfer Process

    April 30, 2018

    Announcement, GDPR, Industry Insight, Uncategorized

     Like

    Views: 4081

    TL;DR
    The registrar transfer process for gTLDs needs to change once the public Whois “goes dark”. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

    Upcoming Changes to the Domain Transfer Process

    Among the most noticeable and significant changes to result from the domain industry’s implementation of the GDPR are those to the Whois system. As we’ve written in past blog posts, as of May 25, 2018, Enom and many other domain registrars and registries will cease the display of personal data in the public Whois.

    The industry discussion around the effects of the Whois “going dark” has largely focused on the possible lack of access that law enforcement or the security community members may have to Whois data, the potential problems this presents, and how parties with legitimate legal interest in the data may still be able to obtain it. However, the impact of the change goes beyond the simple ability for a person to look up a domain’s contact data. There are automated processes and systems which rely on access to the public Whois contact details in order to function, and we need to make accommodations for these processes as well.

    The most significant impacted process, which we are working hard to ensure is not interrupted by these changes, is the registrar transfer process. Here, we’ll provide details about how we will modify the transfer process to accommodate new, heightened privacy measures for the handling of registrant contact data, and we’ll suggest some changes that our resellers may want to undertake. Ultimately, the updated transfer process will not only provide a work-around for the lack of a publicly displayed contact email, but will result in a simpler, more streamlined experience for the domain owner while continuing to protect against unauthorized transfers and ensure the privacy of personal data.

    The Domain Transfer Process Today

    Let’s start with a review of the registrar transfer process as it stands today. For reference, we’ve provided a flow chart which compares the current and updated transfer processes.

    Step 1

    The domain owner works with their current (losing) registrar to unlock the domain and obtain the transfer authorization code, also called an EPP Code. This step will remain the same even after the transfer process is updated since the current registrar can and should verify that the person unlocking the domain and requesting the authorization code truly has the authority to do so.

    Step 2

    Once the domain has been prepared for transfer, the domain owner works with the new registration service provider to initiate the transfer. Here at Enom, we’ve always required the authorization code to initiate inbound transfer orders. Contact information may also be provided as part of the transfer order; if this information is not included, the Enom system will automatically use the account contact info for the domain transfer.

    Step 3

    In the current transfer process, the gaining registrar sends the initial Form of Authorization (FOA) to the domain transfer contact email, which they acquire from the public Whois. The domain transfer contact email may be either the registrant or the administrative contact; at Enom, our current practice is to send the FOA to both contacts. This FOA must be responded to within five days, and the transfer will only proceed if it is approved at this stage (Step 3a). Once the transfer contact approves the transfer, the gaining registrar submits the transfer order to the registry, who then notifies the current registrar (Step 3b).

    Step 4

    The current (losing) registrar sends a secondary FOA, which is optional for the domain transfer contact to complete. If the domain transfer contact does not respond to it within five days, the transfer will proceed automatically at the end of this five-day period. Alternatively, the domain transfer contact can choose to use this step to cancel the transfer or confirm it again.

    Step 5

    The registry operator completes the transfer process by moving the domain to the gaining registrar’s credential, typically renewing the domain for one year. At this time, the domain is usually locked for 60 days, although standard procedure may differ among registries.

    How Will Transfers Work Post-GDPR?

    At present, the gaining registrar initiates a domain transfer by sending an FOA to the domain contact email, but once the public Whois “goes dark,” registrars may not be able to identify the contact email for a domain that isn’t under their accreditation. The question becomes, how can we securely and efficiently process a domain registrar transfer without a publicly accessible domain contact email? Many registrars have been thinking about this as part of their GDPR compliance work and have taken a collaborative approach to finding an industry-standard solution.

    The TechOps Subcommittee of the Registrar and Registry Stakeholder Groups has proposed modifications to the current transfer process which are intended to resolve this issue; their March 8 letter can be read on the ICANN website. Enom will proceed with the changes to the inbound transfer process as described in that letter, to ensure that the inter-registrar transfer process continues to operate smoothly after contact data is no longer available via the public Whois.

     

    Keeping Domain Transfers Secure

    In the Enom platform, there will be no required changes to how resellers initiate inbound transfers (Step 2), since both the contact data and the transfer authorization code are already required. The only real change is that, in cases where we are the gaining registrar, once the transfer order has been submitted in our system we will move directly to submitting the transfer request to the registry (Step 3b). We are making the required change to deprecate the initial Form of Authorization, with no action needed by our resellers.

    Registrar transfers for many ccTLDs already follow a process very close to this, where the authorization code for an unlocked domain is all that’s required before submitting the transfer to the registry. Making this change across the board allows us to ensure that inbound transfers continue to function for all domains coming into our platform.

    Another security measure that we would encourage registrants to take is to keep the domain locked, using the “ClientTransferProhibited” status, at all times unless specifically intending to transfer to another registrar. As a registration service provider, you can help your customers maintain their domain security in several ways, including requiring strong account passwords, enabling 2-factor authentication, and locking domains by default until otherwise requested by the domain owner.

     

    Additional Changes We’re Making at Enom

    Moving forward, whenever a transfer into Enom is completed, the domain’s contact data will be updated to match that which was used for the transfer order. This is currently optional, but will become mandatory; we will no longer be able to rely on the registry-provided contact data to be correct and not include placeholder information, because other registrars may no longer share registrant contact data with registries. In cases where the owner contact is new to our platform, the registrant verification process will begin as soon as the transfer is complete.

    To better illustrate the streamlined transfer process, we have created this diagram:

    Enom Transfer process before & after

    Is This Really OK?

    Adjusting the inter-registrar transfer process in response to GDPR-related industry changes is a priority for Enom. We believe that domain owners should continue to be able to choose their registrar and move between registrars at their discretion, as long as sufficient security measures to protect against domain theft remain in place. Absent an ICANN-approved transfer policy modification, our best option is to conform with this model proposed by leading registrars, including Enom.

    The modified transfer process meets our requirements around security and anti-theft: only the authorized domain contact has the ability to unlock the domain and obtain the transfer authorization code, and only they may approve the transfer away from the current registrar.  

    We can already point to examples of the transfer process working as it is described here, in use today. Most ccTLDs, .CA and .DE, to name a few, currently follow a process like the one we’ve outlined above, where the authorization code is required to initiate the transfer, but there is no Form of Authorization requirement for the gaining registrar.

    And from the client’s perspective, this is just one less step for them to complete as part of the transfer process, making it easier for them to move to their preferred service provider. This change is something registrants have asked about for years, and it removes one of the barriers to transferring registrars without compromising the domain’s security.

     

    How Does This Relate to the Consent Management Process?

    There is, of course, a connection between this updated transfer process and the newly introduced consent management process — any domain coming into our system must have a consent settings profile that lets us know how to handle all personal data related to that domain. Transferring from one registrar to another, or from one Enom reseller to another reseller, will thus trigger a consent request to the domain owner, just like a new registration would.

    Enom resellers who use the “pushdomain” API command or the “push” option in the Control Panel to move domains between distinct reseller accounts should keep this in mind so that clients are not surprised by consent requests resulting from a domain push.

     

    When is This Happening, and How Should I Prepare?

    We will adopt this new domain transfer process when our other GDPR-related changes go live, on or shortly before May 25, 2018. We appreciate that this will require our resellers to educate their support staff and we hope this post serves as a valuable resource.

    While we cannot speak for other registrars or registry operators, who will no doubt soon be announcing their own plans for handling domain transfers in a post-GDPR world, we’d like to again emphasize the fact that the model we are following was born from the collaborative efforts of leading registrars, ourselves included, and has already proven to be secure and efficient when used for ccTLDs. It is our hope that other registrars will plan to follow this model, and that eventually ICANN and the community-led policy development process will bring us to an industry-wide standard; at such time as ICANN provides a working and mandatory transfer policy, we will certainly comply with it to the fullest extent that we are able. That said, our primary concern is that domain owners on our platform maintain full control over their private information, products and services, and the ability to select the registrar or service provider that they prefer, while we remain compliant with data privacy laws and ensure the appropriate levels of security are in place. These transfer process changes are significant, necessary, and ultimately create a streamlined process that benefits registrants, resellers, and registrars.

    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

    • Tiered Access Directory (gated Whois) (Published on Jun. 19, 2018)
    • GDPR Checklist for Enom Resellers (Published on May. 17, 2018)
    • 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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • GDPR Q&A for Domain Resellers

    March 27, 2018

    Featured, GDPR, Industry Insight

     Like

    Views: 7300

    We had a great turnout for our GDPR webinar, and attendees asked many intelligent and insightful questions about the regulation and our implementation of its requirements. We’ve made available a PDF of the full Q&A session, but if you prefer a shorter read, here are some of the highlights:

    1. What is the allowed time limit for the changes to take place on the side of the reseller?

    First off, if you collect and process the data of EU-locals, or have the potential to, you need to ensure you are doing so in a GDPR-compliant manner by May 25, 2018. Otherwise, you are putting your business at risk. In addition, our agreements with resellers will be updated to require that resellers process data in a GDPR-compliant manner. As for changes that must be made on the reseller’s side which specifically relate to Tucows’ domain registration processes and modifications to our platforms, there are no mandatory changes you need to make, but there are changes on our end that you need to understand and adjust for if you feel it necessary.

    One such change is our new Whois system. Another is the introduction of the consent management page for end users, the details of which we address in the question below. On that note, we are not expecting to have consent for all the millions of domains on our platform from day one (May 25), but by requesting consent at the time of domain registration, renewal, or transfer, we expect that the majority of the registrants in our system will have indicated their consent selection within the first year of this requirement being active. You should consult with your lawyer to determine how to handle consent collection and overall GDPR compliance for your own business.

    2. What happens to pre-existing data, and do we need to send the consent management landing page link to all existing users?

    Data that is used to perform the domain registration contract will be maintained in our system for as long as is legally required. For pre-existing data that now requires consent, we will request that consent on a timeline that has been deemed appropriate by our Legal team. We will send the consent management landing page link to the end user at three potential points in the domain lifecycle: when new registration is created, when a domain transfers into our system, or when a domain is renewed. Additionally, resellers may send out the link at their discretion via the option that will be in the control panel or the new API call that we will be offering.

    3. Compliance sounds as simple as gaining consent from clients. If their consent has been given, then I’m covered under the GDPR, right?

    It’s not that simple, in part because there are clearly defined limitations around what constitutes legitimate consent, all of which are outlined in our Consent blog post. Furthermore, the GDPR’s requirements go beyond consent to include things like data minimization, secure processing and storage of data, and more. I can say that from the domain services perspective, we’ve got things covered. This compliance will be achieved through a combination of contract-based and consent-based data processing and data minimization. If you are collecting and storing personal data for your own purposes, beyond what is required by us, we recommend that you talk to a lawyer who is familiar with the GDPR to fully assess the risk that you’re taking by not updating your own processes to comply with the new law.

    4. How will domain transfers work moving forward? If a reseller cannot see who owns a domain how can they initiate its transfer with confidence that the request is legitimate?

    As mentioned in the question, the problem with continuing to use the transfer process as it stands today is that the gaining registrar would not reliably know where to send the initial Form of Authorization (FOA), since the registrant email will no longer be publicly available to them. To address this issue, the Registrar and Registry Stakeholder Groups’ joint TechOps (Technical Operations) sub-group has sent a letter to ICANN, proposing changes to the transfer process. They suggest that the initial Form of Authorization should be optional, and instead, possession of the transfer authorization EPP code will be required to initiate the transfer. Then the current registrar, which does know the owner’s email, would send a mandatory confirmation FOA (this FOA is currently optional), and the transfer would only proceed if the domain owner completes the FOA sent by the current registrar within 5 days.

    The letter in which this change was proposed was sent to ICANN very recently, so we don’t yet know how ICANN will respond. Changing the transfer process is not a simple task, as it’s a consensus-based policy with a specific protocol that must be followed to approve any modifications. Each registrar will have development work to do once the course of action has been determined, but the domain community is united in working towards a timely and viable solution.

    5. How does the law address proving identity? As an example: I can create a domain using the registrant name “Donald Duck”. If another Donald Duck discovers this and asks for the info to be removed, what proof must he provide to verify that he is, in fact, the same Donald Duck that registered the domain?

    The choice to give consent, and the related ability to request erasure of one’s personal data, is all tied to a user profile which consists of a unique combination of the data elements we require contractually: name, organization, email and country. If two registrants share the same name but have a different organization, email, and/or country, they are considered to be two separate people, with distinct user profiles in our system. If a request for erasure comes in from someone who does not match the full contact data set associated with a domain, but that someone still claims to be the registrant and data subject for that domain, our Compliance team would work to address the issue.

    6. The current system in place requires law enforcement to have warrants or legal grounds in order for them to obtain the Whois information for a privacy-protected domain. If they get access to the gated Whois, does this mean that they can access this information without having to provide proof of legal grounds to get the data?

    Access to the gated Whois will only reveal information which is currently (prior to May 25 2018) public. It will not reveal the Whois information for privacy-protected domains. In fact, the Whois output for privacy-protected domains will be the same in both the public and gated Whois, and we will continue to require a court order or other legal documentation for access to this information, as we do today.

    7. Can we run our own privacy service, i.e. have our information show in Whois?

    This is a complex decision for a reseller to make, for a few reasons. There are requirements in our Reseller Agreements around what privacy or proxy services may be used for domains on our platform. Additionally, ICANN has requirements for any privacy or proxy provider and is working now on an accreditation process for providers of those services. We encourage any reseller to review their options with the help of their legal counsel and the operative reseller agreement before beginning to offer such a service.

    8. When will you publish the final updates being made to your contracts?

    While we appreciate that uncertainty around these changes is difficult, we hope that an industry-standard amendment will make things easier for both our resellers and the industry as a whole. At the same time, we know that we can’t wait too long before sharing those changes with you. If the industry-wide amendment is not ready for distribution by the end of March, then in early April, we will release our own contract changes to our partners.

    9. Can a non-EU domain registrant waive the protections and keep their data public?

    Not at this time. We believe that providing such an option puts data at risk and exposes it unnecessarily, but this is currently the subject of discussions within ICANN and with various European DPAs, and we will reevaluate our implementation from time to time in light of further policy developments and guidance received from government authorities.

    10. How will the fines for non-compliance be monitored and collected, and who will be enforcing them against US companies?

    Each EU country, and in some countries each region, has a Data Protection Authority (DPA) who enforces the GDPR. If you have a presence in an EU country, that is likely the DPA with whom you would interact. If you do not, the DPA of the country where the violation occurred would probably be the enforcer. The enforcement process will rely on reporting, meaning the EU has not indicated that it plans to conduct audits, but instead, will investigate potential GDPR violations as they are brought to the DPAs’ attention.

    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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • The GDPR in 25 Minutes

    March 12, 2018

    GDPR, Industry Insight

     Like

    Views: 7676

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

    If you’re looking for a short and sweet summary of the GDPR (well, as short and sweet as a summary of any legal policy can be), this is the video for you! Presented by one of our resident GDPR experts, our Reseller webinar explains the fundamental concepts of the GDPR, why it matters to service providers, and offers some tips on how to prepare. Created with Resellers in mind, it also provides a concise overview of the reseller-impacting changes we’re making at Enom.

    If you’re looking for more info on one of the topics that we touch on here, check out our GDPR blog posts. We also provide a handy Reseller FAQ on our GDPR resource page.

    Note: The information contained in this video is non-exhaustive and should not be considered legal advice. You should consult with your lawyer to determine the impacts of the GDPR on your business.

    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

    • 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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR basics & best practices resources (Published on Nov. 9, 2017)

    Read More

  • GDPR-Related Contract Changes

    March 5, 2018

    Announcement, Featured, GDPR

     Like

    Views: 6983

    If you’re reading this, chances are you have questions about the GDPR and how Enom is preparing. We’ve got answers! Sign up for our GDPR webinar on March 7 or March 8 to learn from one of our GDPR experts.

    The GDPR can be approached in terms of three fundamental concepts:

    1. Consent and control

    2. The Right to be forgotten

    3. Transparency

    We’ve talked about two of these concepts in past blog posts, and today we’ll look at the third: Transparency.

    Transparency is one of the core principles in the GDPR, emphasized in Article 5 of the policy, which states that personal data must be “processed lawfully, fairly and in a transparent manner in relation to the data subject,” and must be collected for “specified, explicit and legitimate purposes.” In short, the data subject has to be kept informed as to what data is being collected and how that data is being used.

    One of the main ways that we inform our clients about how their data is being used is through our contracts, and we are now ready to share more information about the upcoming changes to our reseller and end-user service agreements, which are being made as part of our GDPR implementation efforts.  

    Before we dive into the specifics, I want to emphasize again how important it is to read the GDPR for yourself, and to engage legal counsel who is competent to support your business through the process of coming into compliance with the GDPR.

    As we work in partnership with our clients to ensure that we accept, collect, process, and share personal data in a GDPR-compliant manner, there will be changes to our contracts, in the form of either a stand-alone Data Processing Agreement or an Addendum to the Reseller Agreement and Domain Registration Agreement. Regardless of whether we take the stand-alone-agreement or addendum route, there are a few things that you need to be aware of as a reseller.

    Changes to Our Contracts with Registries

    As a registrar, we have a Registry/Registrar Agreement in place with every registry with which we are accredited. We expect that many of these Agreements will be updated by the affected registries to be compliant with the GDPR. To this point, however, we’ve seen inconsistent approaches from the European ccTLD registries, and no GDPR-related contract updates from gTLD registries. We are working together with other industry groups to standardize a model for what these contractual changes will look like; without a standardized approach, we would have to negotiate individual amendments with each registry, a difficult undertaking to complete by May 25, 2018, given the number of registries with which we partner.

    Moving Toward an Industry-Standard Approach to Contracts

    Given the changes we expect to see from registries, changes we expect registrars will make, and changes that we believe will be recommended by ICANN, we are hopeful that industry-standards will develop in the coming weeks which we can incorporate in our changes to our own agreements. These efforts are ongoing, but once a final decision about exact language has been made, we will update you. While we appreciate that uncertainty around these changes is difficult, we hope that an industry-standard amendment will make things easier for both our resellers and the industry as a whole. At the same time, we know that we can’t wait too long before sharing those changes with you. If the industry-wide amendment is not ready for distribution by the end of March, then in early April we will have our own contract changes out to our partners.

    Changes to Our Contract with Reseller Partners

    Our amendments to our reseller agreement will outline the obligations for both ourselves and our clients that are necessary to ensure that every user on our platform is fully protected in a way that aligns with the GDPR. We expect that contract changes will track certain standardized language that has been approved by the European Commission in years past, such as this European Commission decision, which provides some standardized contract language for data sharing.

    Here are some of the changes that you can expect to see in our Reseller Agreement which governs the services we provide to resellers. These updated requirements will apply both to us and to our resellers:

    Data Storage
    • All personal data must be stored securely and handled with appropriate protections
    • Any subcontractors who are allowed to access data also must have adequate security in place
    Data Sharing
    • Any data sharing must be done in accordance with the GDPR  
    • Data that is shared must be maintained securely by both the sending and the receiving parties
    • Any data exporter will be liable for damages suffered by the data subject for any violations of the GDPR
    Disclosure
    • The data subject will be informed about the collection and sharing of their personal data in a GDPR-compliant manner
    • All contracted parties (including Tucows and the reseller partner) agree to work cooperatively with Data Protection Authorities if questions arise about the use and sharing of personal data

    Changes to Our Contract with Registrants (End-Users)

    For our Domain Registration Agreement, which governs our relationship with the domain registrant, changes will include:

    • Clear explanation of which data elements are required by contract — we require the registrant’s first and last name, organization name (if provided), email address, and country; Registry agreements may extend this contractual data set.
    • Confirmation that, if a third-party’s contact information is used as the domain’s administrative, billing, or technical contact, the registrant will have the appropriate contract and/or consent with that third-party to satisfy the GDPR’s requirements around data use

    Moving forward

    Rest assured, there will be no major surprises found in the changes to the Master Services Agreement or Domain Registration Agreement, provided your business is GDPR compliant. As always, we’re taking care of the heavy lifting to minimize the effort required on your end. We hope this allows you to remain focused on your day-to-day business and whatever internal changes you may need to make to come into compliance with the GDPR. Take a look at the European Commission’s standard contract text, and keep an eye out for our future updates. And don’t forget to sign up for our GDPR webinar, where we’ll share more details about exactly how this new regulation is affecting the Enom domain service offering. Hope to see you there!

    Learn more about the GDPR:

    GDPR Updates – Understand Enom’s approach to the policy

    • 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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • GDPR Resources: The Right to Be Forgotten

    February 1, 2018

    GDPR, Industry Insight, Uncategorized

     Like

    Views: 3675

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

    Our last GDPR post covered the basics of the right to erasure, as outlined in the GDPR. This week, we’re expanding on the topic by highlighting a few recently published resources that address the requirement’s potential impact on service providers and the domain industry, and explore some paths to compliance.

    GDPR Compliance Models From ICANN

    I wanted to start off on a more general, but highly significant, development in the domain world. ICANN’s “Legal Analyses, Proposed Compliance Models, & Community Feedback” page has been updated with several models for GDPR compliance. I would strongly encourage everyone interested in the topic to familiarize themselves with the contents of this page. Domain providers have been working on GDPR compliance for months, if not longer, and the ECO playbook (“CM3” on this page) is the result of collaborative efforts from many key players within the industry, including Tucows. While this work was being done, the internet community awaited— with great anticipation—the release of ICANN’s own official approach.

    After a long silence, ICANN came back with three suggested models, each of which has significant flaws. To name a few, the ICANN

    models focus mainly on Whois, rather than the whole ecosystem of data sharing that a typical domain registration ties into, and the models continue to require collection and sharing of more data elements than our assessment believes are acceptable under the principle of data minimization (which restricts data processing to those elements necessary to provide the contracted service). At present, there’s an industry conversation around what model can be accepted both by contracted parties (registrars and registries) and ICANN, but we are proceeding with our GDPR implementation work as planned, relying on our legal counsel to help find the balance between compliance with ICANN and the GDPR itself.

    Fuhgettaboutit: the GDPR “Right to Erasure”

    This article delves into the details of the right to erasure and its operational impacts on service providers. Placing an emphasis on the wide scope of the requirement, it provides a general perspective, not specific to the domain name industry, and gives the reader a good sense of how much work fulfilling just a single erasure request could entail.

    GDPR, Right of Erasure (Right to be Forgotten), and Encryption Key Management

    The GDPR requires that data be held securely which, in a digital world, usually requires encryption. But one thing I hadn’t considered was using encryption not only for security but also to fulfill right-to-erasure requests. That’s what’s proposed here: if the encryption key no longer exists, the data can never be revealed, and essentially no longer exists. Receive a request-to-be-forgotten from a customer? Erase the key that decrypts all their personal data, and the data itself is effectively erased. I will admit that I’m not an encryption and data security expert, but it seems to me that there’s a difference here—encryption can be broken, or could already be compromised, so I’m not convinced that we can equate the erasure of a key to the erasure of the data the key decrypts. I’d love to hear from people in that field as to whether this is indeed a viable approach to data erasure and, more specifically, if it would satisfy the requirements laid out in the GDPR.

    Where does this leave us?

    At this point, it seems clear that service providers across industries should be thinking about right-to-erasure requirements and the significant work it will take to reach a state of compliance. What’s still a bit unclear is the “how” of it all. Encryption key management, which we’re sure to see further discussion about, may prove be a viable method for some providers, and other approaches are sure to surface in the months leading up to May 25, 2018.

    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

    • 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

  • The GDPR’s Right to be Forgotten

    January 18, 2018

    Featured, GDPR, Industry Insight

     Like

    Views: 7166

    New Year’s resolutions aren’t for everyone, but I think most of us like the idea of a restart, the sense that slates can be wiped clean (to an extent), and that a departure from one’s current path is possible. This notion of a fresh start takes on a higher level of significance in the digital era. These days, many of us have a substantial online presence that lives both in public-facing platforms like Facebook or Twitter and in the private databases of our service providers, and I think we all feel entitled to some level of control over our personal digital histories. The right to erasure, as outlined in the GDPR, is meant to give individuals this control.

    What is the right to be forgotten?

    Article 17 of the GDPR outlines the data subject’s right to erasure, also known as the right to be forgotten. It gives each data subject the right to request that a controller erase the subject’s personal data. It also requires the controller to comply with any such request “without undue delay” as long as one of six specific legal grounds applies. On top of this, it states that in cases where the controller has made personal data public, the controller must reach out to any other controller who is processing the data and inform them about the request for erasure so that the appropriate steps can be taken. Finally, Article 17 lays out several exceptions where the right to erasure does not apply. These include instances when processing of data is necessary for “exercising the right of freedom of expression and information,” for “compliance with a legal obligation,” or for “the establishment, exercise or defense of legal claims.”

    Legal grounds for processing data

    If you think back to our post about obtaining consent, you’ll recall that the GDPR gives several legal bases for using personal data. The two that most commonly apply to the domain registration world are when the processing is necessary for the fulfillment of a contract, and when the data subject consents to the processing. Our Registration Agreement outlines exactly what data is required in order to register a domain, so the data elements included there are what are required to fulfill the contract. Any extra data that someone chooses to provide, such as a phone number to be used as a backup authentication method, would be processed under the legal basis of consent.

    What data falls under the right to erasure?

    “The right to be forgotten” is not as straightforward as the phrase’s catchy nature might imply. While a data subject can place a request to a controller to have their data erased, the request is only legitimate under certain legal grounds. I’ll lay these out and then narrow our focus to what they mean for Enom (and very likely, for you!).

    These legal grounds include:

    • The data is no longer needed for the purpose for which it was originally collected,
    • The processing is based on consent and the data subject withdraws that consent,
    • The data subject exercises their right to object under Article 21 of the GDPR,
    • Processing is not lawful (there was no legal basis in the first place),
    • The controller is subject to a legal obligation that requires the erasure of the data,
    • Some things related to children’s rights, which don’t apply since we don’t sell domains to children.

    For Enom’s purposes, data that is processed based on consent is subject to the right to erasure — the data subject can withdraw their consent, the controller must erase this data, and, if the data has been made public, notify other controllers or processors to do so as well. Enom also uses data that is processed based on a contract and is not subject to the right to erasure; a request to erase would not apply to those data elements. In these cases, erasing the data would require terminating the contract. Even then, there are other legal obligations around data retention that may come into play, such as regional laws that require data to be stored for certain time periods.

    How can a person exercise their right to erasure?

    Article 7 of the GDPR lays out how consent works as a legal basis for data processing, and also requires that consent may be withdrawn at any time, specifically stating that “It shall be as easy to withdraw as to give consent.” We’re fulfilling this requirement by ensuring that the consent management landing page remains available and easily accessible to each data subject to whom we provide services. On this page, a subject can view the existing consent settings and also change or withdraw consent. A withdrawal request will trigger a process on our side to find and delete any data that is held based on consent. Data that is required by contract, however, would remain intact. This gives the data subject complete control over the use of their personal data, while also ensuring that the domain registration itself is not interrupted unnecessarily.

    Looking ahead

    The opportunity for a fresh start provided by the GDPR’s right to erasure is a year-round thing, not confined to the first of January. But now, with the glitter from New Year’s parties still stuck in our carpets, it might be a good time to think about how you’re preparing to provide this option to your clients. In our own development process, our mantra has been “it must be as easy to withdraw consent as it is to give it, and when erasure is requested, it must be completed ‘without undue delay’.” Work with your legal team to determine which of the data elements you collect are subject to the right to be forgotten, and develop a process to fulfill those requests promptly and completely. Giving your clients easy access to a “fresh start” will certainly require some development work on your end, but it’s an opportunity to employ some great UX and reassure them that you take the principles of transparency and privacy seriously.

    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)
    • 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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • GDPR Resources: Consent

    January 4, 2018

    Featured, GDPR, Industry Insight

     Like

    Views: 6385

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

    The GDPR’s requirements around consent for data processing are complex, and we aren’t the only ones thinking about what this means for our business or how to best comply with the regulation. Below, we’ve shared a few links that give some added context around consent as it relates to the GDPR.

    How the GDPR will disrupt Google and Facebook

    The title says it all. This article speculates on how Google’s and Facebook’s current consent request processes might have to change in order to become compliant with the GDPR’s consent and data use requirements. It lays out a GDPR risk scale, examines where different consent methods fall on this scale, and then evaluates personal data use by Facebook and Google to estimate where those different data uses rank and what changes the tech giants may need to make in order to continue processing this data in a post-GDPR world. The conclusion is that, while much of this personal data processing can be done in a way that is GDPR-compliant, the requirement to obtain consent will disrupt the ability to use data for marketing and advertising purposes. The extent to which this impact will be visible to the average user remains to be seen.

    WP29 Guidelines on Consent under Regulation 2016/679

    In our GDPR Resources: Whois Changes post, we looked at a letter that the Article 29 Working Party (“WP29”) sent to ICANN; here’s another great publication from the same advisory body, offering guidelines on how consent can be used as the legal basis for data processing under the GDPR. WP29’s interpretation of the GDPR aligns with our own understanding of the consent requirements and serves as a helpful resource for anyone working to create their own consent request processes.

    ICANN’s GDPR legal analysis

    The second and third memos from Hamilton Advokatbyrå have been published, following the first memo which we discussed in a previous GDPR Resources post. The most recent memo focuses on how the Whois system would need to change to be compliant with the GDPR, and refers to a conclusion drawn in the first memo: although consent would be a possible legal basis for publication of Whois information, it would not result in a fully accessible Whois like we have today, since data subjects will be able to withdraw consent, preventing any “extra” data (which isn’t necessary to providing domain registration services) from being published. Anyone keeping up with GDPR policy will want to keep a close eye on these Hamilton memos and the domain industry’s responses to them.

    We’re happy to see that many of the assessments and practices being discussed by other key players in the industry are in line with our own plans for a gated Whois system and revamping of our consent request processes. We want to support our resellers through this transition by providing useful resources and maintaining a high level of transparency about our own GDPR implementation plans. Sign up for GDPR updates to make sure you’re kept in the loop!

    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)
    • Whois-related resources (Published on Dec. 7, 2017)
    • GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)

    Read More

  • Consent and the GDPR

    December 21, 2017

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 8391

    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: 5105

    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

  • How will the GDPR impact Whois?

    November 23, 2017

    Announcement, Featured, GDPR, Industry Insight

     Like

    Views: 12429

    In the weeks since my last update, a lot of behind-the-scenes work has gone on for our GDPR implementation project. One aspect of this project, which we can now share more specific information about, concerns changes to the Whois system. I also have some details around how collecting and processing data will influence both our Reseller Agreement and resellers’ own end-user service agreements (and we’ll share some recommendations on that). The information here is geared towards those who resell Enom services, but our clients who have registered a domain directly with us may also find it helpful.

    Update: March 6, 2018

    Before we dive into Whois changes, I want to go back to something that was mentioned in our initial GDPR post – to whom does the GDPR apply? At the time, we were proceeding on the basis of applicability by citizenship, meaning that the GDPR would apply to EU Citizens. Since that post went live, however, our legal analysis has led us to interpret the GDPR as applicable to any individual residing in the EU, regardless of their citizenship. Even more recently, we made the decision to work toward a unified implementation plan that will extend the same heightened privacy protections to all Enom reseller partners and end-users, regardless of their location. Learn more about our GDPR approach.

    Changes to Whois

    The Whois directory is a powerful tool. You can look up who owns a domain to find their phone number, email, even their postal address. You can check when a domain was first registered, where it’s hosted, when it expires — that’s a lot of information available with just a few clicks. And because this system has been around for so long, and is such a fundamental aspect of the internet, we often assume that how it currently works is how it should work. But just because something has been a certain way for a long time doesn’t mean it must always be that way, and the GDPR’s looming deadline has prompted the re-examination of many processes and policies.

    Instead of “how have we always done this?”, we’re asking questions such as “what’s the best way to do this?”,  “what information is it truly necessary to include?” and “is there a legitimate legal basis for this process?”

    What will change?

    The GDPR was drafted and brought into law without consideration for its effects on the domain name industry, leaving us to interpret how this regulation applies to our world. One particularly impactful section of the GDPR is Article 5, which lays out “principles relating to processing of personal data.” This is highly relevant to the Whois system, which is essentially just a repository of data, much of which is personally identifiable information about individuals. Warning: we’re going to briefly venture into the legal thicket here, but bear with me!

    Under the GDPR, personal data may be collected and processed only when there is a legal reason to do so. For example, one such justification would be the performance of a contract; another is a situation where the data subject (the person to whom the data pertains) has given explicit consent for their data to be processed or collected.

    The principle of data minimization requires that the data collected be relevant and limited to what’s truly necessary to carry out the agreed-upon purpose for which the data is being collected. To add to this, the principles of purpose limitation and confidentiality limit the handling of personal data such that it cannot be processed or shared for any purpose other than that to which the individual initially agreed.

    Simply put, under the GDPR:

    1. We can only collect the minimum amount of data necessary to perform a specific action (e.g. register a domain)
    2. Data can only be shared when there’s a legal basis to do so
    3. Data can only be shared when necessary to fulfill the intended purpose of the data collection

    So how will this impact Whois? Well, it’s certainly difficult to argue that there’s a legal basis for openly sharing contact details of a domain’s owner, administrator, or technical contact in the public Whois record. And we can’t claim that it helps to accomplish the original purpose for which the information was collected (registering the domain). This means that the public Whois system as it exists today is incompatible with the principles of data privacy that the GDPR affirms.

    All that being said, the GDPR recognizes that there are times when there is a real, justifiable need for a third party to obtain personal data, such as domain ownership information, and these “legitimate interests” are also provided for within the policy. Think about, for example, an intellectual property lawyer who wants to know the owner of a domain in order to submit a trademark dispute, or a law enforcement officer tracking down the people behind a phishing scheme; they should be able to find out who owns the domain name under investigation. We need some way for Whois information to be provided to the people and organizations who have a legitimate reason for requesting it — but one that doesn’t involve publicly exposing this sensitive data by default.

    A different kind of Whois

    This leads us to one of the biggest domain industry changes prompted by the GDPR: a gated Whois system.

    Not all parts of a domain’s Whois record constitute personal data. The registrar information, initial registration, last update and expiry dates, domain status, and nameservers will all remain publicly available as they are today.

    The registrant information — name, organization, address, phone number, and email — is personal data that can no longer be published in the public Whois. Instead, we plan to provide authenticated access in a specific and limited manner, so that those with legitimate reason to request personal data can access the information they require while the privacy of individuals remains protected.

    We’ve summarized changes to the Whois output in a quick PDF:  

    Don’t worry — this basic user data will still be visible to resellers through the Reseller Control Panel. As we work out the legalities, which will include updates to our Reseller Agreement, we’ll keep you updated.

    Do we still need Whois ID Protect?

    Absolutely.

    Regardless of any changes to the Whois system, Whois Privacy will remain a valuable service to registrants worldwide. Even when the public Whois “goes dark”, it is certain that there will still be a gated Whois, where registrant data will be made available to parties with a legitimate interest. So, while the audience for registrant data may no longer be the entire public, it will still be sizable. This is where Whois Privacy comes in — if privacy is active on a domain, the personal data in the registration record will remain protected from those with access to the gated Whois. The service also provides a way for third parties to contact the domain owner via the privacy service email address displayed in the Whois output, an option that will not be provided as part of GDPR data protection. In addition, the personal data associated with a domain that is protected by Whois privacy will not be shared with registries.

    Now, there will always be the occasional, ostensibly savvy registrant who’s tempted to simply supply false information, seemingly avoiding the need for Whois ID Protect altogether. This is something we would never suggest. For legal reasons, ownership disputes being one example, it’s important that the domain contact information be accurate. Additionally, the registration agreement that all domain owners accept as part of registering a domain through an Enom Reseller confirms that all information provided will need to be accurate, current, and reliable. These are ICANN imposed conditions, and registrants risk having their domain suspended or canceled if these requirements are not met.

    Reseller changes coming in the new year

    All this talk about new restrictions on data processing and collection, and the various process changes they entail, brings me to my final point: how will it all impact you, our resellers? In the lead-up to May 2018, we’re doing as much as possible on our side to minimize the changes you have to make on yours. But despite all our best efforts, there will inevitably be things you need to do as a reseller.

    This involves another (even briefer) journey into the legal thicket. According to our interpretation, Enom is a data controller (we determine “the purposes and means of the processing of personal data”) for specific data elements: registrant first and last name, organization, email address, and country. This is all the information we require in order to enter into the registration agreement with the domain owner. For all other data elements (e.g. address, phone, and fax numbers, among others), we are simply a data processor. The difference here is that we are handling this data on behalf of either the registry or the reseller, without actually requiring it ourselves. For example, we don’t need a registrant’s physical address to provide them with a domain name, but you may require it for billing purposes. Various data requirements will also exist at the registry level. As a data processor, we store and transmit this information on behalf of both registries and resellers, and in order for the exchange of all this information to occur, it must be covered in a GDPR-compliant agreement.

    To that end, one thing that is definitely coming is an update to our Reseller Agreement — we need to add some information around what we require as a data controller, as well as the changes mentioned earlier, which will remove any concern around resellers accessing clients’ personal data in the Control Panel.

    As a reseller, you’ll want to work with your own legal team to review your customer agreements and work through any changes that may need to be in place before that May 25th deadline. We’ll also have some recommended language for resellers to include in end-user service agreements, so stay tuned.

    What’s next?

    Next month’s GDPR update post will focus on how we plan to request consent from individuals for the use of their personal data. Until then, we’ll continue working hard on our implementation. As a reseller, you can use this time to seek your own legal advice, and think about what information you’re collecting from customers — how does it align with the GDPR’s principles of data minimisation, purpose limitation, and confidentiality?

    You can wrap your head around the basics, and find helpful context on our GDPR page. Our previous blog post also highlights some fantastic resources that outline emerging GDPR best practices. And finally,  we 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)
    • Consent and the GDPR (Published on Dec. 21, 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

  • The nTLD Reseller Starter Guide: Which new gTLDs should I offer?

    November 14, 2017

    Uncategorized

     Like

    Views: 4046

    If you currently sell or are considering selling domain names as part of a business, you may have asked this question to yourself before. The huge variety of gTLDs out there can turn the task of curating a lineup that makes sense for your business into a rather daunting undertaking. Instead of getting bogged down by all the variables that could weigh into your final decision, I suggest you focus on the handful of key considerations that really matter. The questions below will help you better evaluate TLDs and equip you to make smart choices as you expand or refocus your offering. And in case you still feel stuck, we’ve included a list of extensions you might consider.

    Is the TLD easy to implement?

    Most of the new gTLDs fall into the “easy-to-implement” category, free to be registered by anyone, anywhere, much like a .COM. Others have strict registration requirements, such as a local presence in their associated geographic area, or an affiliation with a particular professional group. If you ever need to verify whether an extension you’re considering is restricted, take a quick look at our TLD reference chart.

    The TLDs we’ll highlight in this post are all easy to implement, but that’s not to say you should steer clear of those that are restricted. In fact, offering restricted TLDs can be a great way to cater to a niche market. For example, many firms might find the credibility of a .LAW extension advantageous. Similarly, the appeal of geoTLDs like .NYC, .BARCELONA, or .BERLIN among local citizens make them a great choice if you attract a significant volume of customers in any of these cities. If you think you’re likely to sell a high volume of a certain restricted extension, the payoff may well be worth the extra implementation efforts involved. It really comes down to knowing your audience and presenting them with options they are likely to find meaningful.

    Is there a high level of interest in the TLD?

    Unless you’re catering to a highly specific market, you’ll benefit from starting with TLDs that have wide appeal. This appeal can be generated by both the generic nature of the extension (.WEBSITE or .ONLINE), or its specificity (.CLOUD, .BLOG, .SHOP, .STORE or .DESIGN). Note that each of those last five extensions has an unambiguous meaning that resonates with a huge number of potential buyers.

    This doesn’t mean a small TLD offering shouldn’t include more niche extensions. Again, the level of interest your customers show for a particular TLD will always depend on who your customers are. I had a musician friend, for example, that was thrilled to launch her new business with a .STUDIO name. And I’m willing to bet there are a lot of artists out there who might be open to a similar departure from the traditional, more corporate-sounding extensions.

    Does the pricing make sense?

    Most potential nTLD buyers compare new possibilities to .COM alternatives. So presenting them with fresh, viable options in a similar price range is smart. There are many solid performers, with broad applications, that fall into this category. Of course, this isn’t to say that a high price tag should deter you from offering an extension that seems particularly well-suited to your customer base.

    It’s also not just the initial purchase price you should be aware of. Simple and predictable pricing structures are an important factor in building an enduring customer base. So while offering TLDs with substantial first-year discounts might translate into increased registrations, you could find yourself unpleasantly surprised by relatively low renewal rates. A customer who purchases a domain on promotion might not be put off by a slightly higher renewal fee. But there are numerous registries that present enticing first-year TLD price tags in the .COM range, with renewal fees that might be 10x greater. These kinds of discrepancies not only deter savvy buyers from making the initial purchase, and put a dent in your renewal rates, but also place you at risk of angering customers who are caught totally off guard by the increase.

    In short, it’s advantageous to offer first-year promotional prices, as they can be a real incentive to potential buyers. But it’s also important to make sure you’re transparent about the renewal price, displaying it clearly within your purchase flow. For those who sell domains as a part of a larger bundle or package, the renewal price, and the margin it allows for, should be factored into your pricing structure.

    Is the renewal rate and customer quality fairly high?

    It’s been a few years since the launch of the first nTLDs, which means we’re now in a much better position to evaluate their long-term potential. When determining the value of a new extension, look into its renewal rate and whether its registrations are, generally, being used in a meaningful way. Arguably, there’s a link between the two.

    That latter point is what I mean by “customer quality”. If you’re a hosting provider or CMS business, you stand to make more money off customers who are actually using their domains. They’re certainly far more likely to show interest in email, SSL and hosting services. They’re also more likely to renew. Not to mention, there’s a case to be made that websites that have valuable content, and employ a new TLD, effectively function as an advertisement for the extension itself. That certainly can’t hurt an extension’s organic growth over time.

    In this regard, .BLOG is a standout – according to ntldstats, only 27% of its registrations are “parked”, a term applied to any domain “in use as a parking page [displaying ads], or without any content.” To put this number in perspective, the average parked page percentage for the TLDs we highlight in the chart below is roughly 53%.

    Still feeling a little lost?

    That’s fair! The paradox of choice is a powerful thing. Here are some suggestions that might serve as good place to start. Judging them based on the checklist above, these TLDs don’t necessarily score high across the board, but they are all easy-to-implement and offer the potential to target a sizable audience – some because of their generic nature and global recognizability, and others because of their appeal to a specific, but substantial, market.

    To reinforce my early point: while we haven’t focused on geoTLDs in this post, they represent a sizable portion of the nTLD pie. Depending on your target market, they can be incredibly profitable.

    If you’re ready to explore what options might work best for your business, you can view all available TLDs at enom.com.

    Read More

  • GDPR Resources: Basics & best practices

    November 9, 2017

    Featured, GDPR, Industry Insight

     Like

    Views: 4624

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

    If you’re anything like me, you’ve spent the days since our first GDPR blog post thinking nonstop about the policy’s potential impacts on the domain world. Okay, maybe you have other things to do with your time… But luckily, there are a lot of great minds at work on this issue. This week, I’d like to share a few links that give some useful background information and starting points as you think about what the GDPR means for you and your business.

    1. IAPP: Top 10 Operational Impacts of the GDPR

    The International Association of Privacy Professionals wrote ten articles looking at different aspects of the GDPR. I particularly liked their review of what Consent looks like under the GDPR and their Consequences for GDPR Violations piece really brought home just how much this new regulation overshadows other data privacy-laws, including the EU’s previous Data Protection Directive, in terms of its scope and enforcement mechanisms.

    2. ICANN: Data Protection/Privacy Issues

    ICANN is the global nonprofit organization that coordinates the technical and operational services of the internet. This page on ICANN’s website lists various data privacy-related projects, including information and resources about ICANN’s work related to the GDPR. Especially of interest are the October 18 blog post and the November 2 announcement from the Contractual Compliance team; the blog post acknowledges that the GDPR will affect how Whois is displayed, and the November 2 statement talks about how contractual obligations will be handled in a post-May-25-2018 world. Both are important starting points in understanding how aspects of the industry are likely to change under the GDPR; ICANN and the organization’s larger community have yet to determine a consistent, official approach to responding to the challenges presented by the policy.

    3. GeoTLD.Group: GDPR Info Page

    As its name might suggest, this not-for-profit represents the interests of the various registries that operate geographic top-level domains worldwide. The GeoTLD Group has put together several useful reports and presentations about the GDPR, including a review of best practices from registries that already follow similar regional data-privacy laws. They also conducted a general survey of the domain industry which provides insight into the policy’s impact on domain-related businesses and what measures these companies are incorporating into their implementation plans.

    Ultimately, I find it reassuring that so many different groups are thinking about what changes might be needed for compliance with the GDPR. Getting your business ready can seem like a daunting task, but seeking legal counsel and familiarizing yourself with the basic concepts will ensure that you’re prepared. You can subscribe for updates and helpful resources on our GDPR page.

    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)
    • Whois-related resources (Published on Dec. 7, 2017)

    Read More

  • The GDPR: what it is and why it matters to you

    October 30, 2017

    Announcement, Featured, GDPR, Industry Insight, News

     Like

    Views: 5888

    Update: March 6, 2018

    Previously, we had announced plans to apply GDPR-related requirements and processes only to domains registered by EU-local individuals. We have since changed our approach and now plan to extend these heightened privacy and security requirements to all registrants and reseller partners. This streamlined solution ensures that our platform is secure and GDPR-compliant, and recognizes that there are privacy laws worldwide, beyond the GDPR, which must be respected.

    “Data privacy by design, data privacy by default.” You may have heard this phrase recently, on Twitter or in blog posts, but where does it come from? What does it really mean? Most importantly, how does it affect your customers and their domain names?

    What is the GDPR?

    The European Union’s General Data Protection Regulation (“GDPR”), coming into effect in May 2018, lays out a new set of rules for how the personal data of people living within the EU (“EU-local individuals”)* should be handled. It sets out the protection of personal data as nothing less than a fundamental human right, alongside other rights such as freedom of expression, freedom of thought, and the right to a fair trial. The GDPR is complex and far-reaching, and we’ll look at a few of the most impactful areas in this blog post. You can also keep an eye out for updates on our dedicated GDPR page.

    Data privacy by design, data privacy by default

    How many times have you bought a concert ticket online or RSVP’d to an event, only to find your inbox unexpectedly filling up with the concert venue’s newsletters and invitations to other events that are only tangentially related? Wouldn’t it be great if service providers had to get permission to use your contact information for anything other than what you’d provided it for in the first place?

    That type of clear, informed consent is one of the basic requirements in the GDPR. Any business taking in your personal data not only has to explain what they need it for, they’re also simply not allowed to require you to provide more information than the absolute minimum they need to get the job done. What’s more, they can’t use your info for any purpose other than that to which you agreed to in the first place. This puts you in charge of how your info is used from the very start — by design and by default — instead of making you unsubscribe after the fact.

    Direct mail campaigns aren’t as popular as they used to be, but I still get a few pieces of paper mail each week, and I’m always both amused and a little scared at how companies I’ve never heard of get my contact information. A friend of mine used to put the name of the service provider in the second line of his address every time he signed up for something new, and he was amazed to find that his credit card and telephone providers shared his info with any number of sales companies.

    Online marketers these days use email rather than postal mail, of course, but the underlying issue of your personal data being shared by someone you trusted with it remains, and the GDPR takes aim at this problem as well. Not only should companies’ use of your data remain within the limits of what you consented to, but the data needs to be stored securely, accessed only for the reasons already agreed upon, and cannot be shared with third parties outside the bounds of this regulation and what you consented to.

    Quick, transparent reporting on data security breaches

    We all know mistakes happen, and security best practices are constantly evolving. Living in the world means accepting some measure of risk, and it seems that every few days there’s a news story about a major data breach affecting hundreds of thousands of people — but usually by the time we hear about it, the breach happened months ago, leaving sensitive information exposed to the world and the affected people unaware. The GDPR addresses this with a timeframe around breach notifications, requiring that people whose information has been compromised are notified as soon as possible. This notice must include an explanation of what happened, what’s being done to fix it, and what the affected people should do to protect themselves. This type of information empowers each person to respond the way they think is best in each circumstance in order to protect their own privacy.

    The right to be forgotten

    I once created an account with a subscription box service, the kind that would send me new makeup every month. Only after I signed up did I discover that they were all sold out… I wouldn’t get anything for at least six months, if not longer — I can’t wait that long for new lipstick! I canceled the account, but couldn’t get them to stop emailing me, asking me to reactivate, choose my colours, pick my brands. Why can’t they just forget all about me? Or, for a perhaps more serious example, how often do we hear stories about people who lose out on job opportunities for which they would be very well-suited, just because of youthful indiscretions that still come up high in online search results?

    That’s another important aspect of the GDPR: the right to be forgotten. Under these new rules, people can go back to service providers and revoke the consent to use their data, requiring the provider to remove all records and essentially erase them, giving them a fresh start. Now, this may not be without consequences (some services can’t be provided without personal information) and may not always be applicable (sometimes personal information has to be kept for reasons of public interest or relating to legal claims), but it’s certainly a lot more effective than sending an “unsubscribe” email, blocking the sender’s email address, and hoping for the best.

    How does this apply to the domains world?

    You might be thinking, “I’m not even in the EU! Why does it matter?” Are you a reseller with clients in the EU? Does your business have the potential to process the data of EU-locals? You now need to ensure that you’re obtaining permission from these customers to use their personal data, and meeting the updated requirements surrounding its handling. This should involve a talk with your lawyer(s). Though we’re making an effort to provide resources and context, the information we’re providing should not be considered legal advice. Seeking professional, legal counsel from someone who is familiar with your specific situation is critical.

    If you’re an Enom reseller, you’ll also need to familiarize yourself with the platform-wide changes we’ll be making (I recommend subscribing to receive GDPR updates). Among other changes, we’re working on amending our Agreements with our resellers, including Privacy Agreements, to allow resellers full access to the info in the Control Panel without any concerns around GDPR violations.

    While the rules outlined in the GDPR apply only to EU-local individuals*, changes to how data is collected and handled may happen on a global scale as companies modify their existing practices to ensure they are compliant with these new regulations. We will try to minimize any disruption to our domain management and registration processes for registrants and resellers.

    Going back to the “data privacy by design and by default” idea, what it means is that all these regulations around protecting personal information can’t just be afterthoughts, they need to be “baked in”, part of the system that’s on unless you turn it off. We’ll be empowering our clients to understand what information we hold and how it’s used, to give consent to us for that use, and to request erasure of data in cases where consent cannot be provided.  

    Changes we’re making at Enom

    These data privacy protections touch almost every aspect of the domain onboarding process and lifecycle. We’re working through our detailed plans now, and will soon be able to share more information about our implementation; today I will share some highlights. As we work through this project, we’re keeping two things in mind: our need to operate within the bounds of legal requirements, and our commitment to keeping domain purchase and management as straightforward, simple, and instantaneous as possible for the end-user.

    Thinking about consent, we’ll implement a post-purchase consent process, similar to the Registrant Verification request we send when a new domain is registered. We may combine the two into a single request if both verification and consent are needed at the same time. Watch for details on this process in upcoming blog posts and our GDPR page.

    We already store your data securely, but we’re doing some internal review to see how we can strengthen our protections to keep information safe. Thinking back to the example of the marketing company who shared info with third-party companies, I want to make it clear that Tucows does not share personal data beyond what’s needed to provide the service that the client ordered. We never sell our client’s personal information, and we certainly aren’t going to start now.

    Although in a perfect world every domain would stay with Tucows forever, I know that, realistically, some people want to use other Registrars, or don’t want to renew every domain they have registered until the end of time. And when they’re no longer our client, they may not be comfortable with Tucows storing their personal data. That’s where the right to be forgotten comes in; we’ll be reviewing our data retention procedures, and putting in place a method for people to request erasure of personal data from our platform. As I said earlier, this is not without consequences, but in some cases (like my ill-fated makeup box subscription) it’s necessary.

    Conclusion and Next Steps

    I hope that this overview of the GDPR and the changes we’re looking at making has been helpful, and explains why this new regulation is important not only for our European clients, but for our resellers worldwide. I know it’s a lot of information, and that you have many questions. We’ll be reaching out to resellers on implementation details soon, and keeping you informed as we move through this process. Until then, check out our blog and GDPR page for more details as May 25 2018 approaches!

    *Initially, this post employed the terms “EU citizens” and “EU customers” in place of “EU-local individuals.” The term “EU-local individuals” was introduced to provide clarity.

    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)

    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

1 2 … 15 Next »

FEATURED POSTS

  • Colleagues review ICANN's temporary specification requirements.

    What Domain Resellers Should Know About ICANN’s Temporary Specification

    September 18, 2018

  • 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

  • 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 |