MENU
  • Enom.com
  • Resellers

Enom Blog

News
Category

  • Do Privacy Shield Rulings Impact Enom?

    November 3, 2020

    GDPR, Industry Insight, News, Uncategorized

     Like

    Views: 1611

    If you follow data privacy news, you may have heard that the EU-US Privacy Shield was invalidated recently, and as an Enom reseller, you might be wondering how that affects our services. TL;DR: It doesn’t.

    We’ll get into the details of Privacy Shield, what it was used for, and what happens now that it’s been invalidated, but essentially, it let U.S.-based businesses lawfully transfer the personal data of EU individuals to the US by signing on to a series of privacy and data protection commitments.

    Now that the EU-US Privacy Shield is no longer an option, companies transferring data will have to look into the other possibilities remaining to them under the GDPR. This is something you may already be looking at for your own business; for your Enom domain reseller services, we’ve got it covered.

    What does the GDPR say about cross-border data transfer?

    When we think about the GDPR and other data privacy laws, we tend to think they restrict or entirely prevent the use of personal data in the name of privacy. That’s not entirely incorrect—a big part of protecting personal data is limiting its use—but it’s also not the whole story. Another aim of the GDPR is to allow or even enable the transfer of personal data, as long as the data remains protected. When the data remains within the EU, it stays under the direct purview of the GDPR, and so ensuring that it remains protected is fairly straightforward, since the same rules apply both before and after the transfer. But what about when sending data out of the EU?

    The GDPR offers three basic options for how to transfer data to a “third country” outside the EU.

    Option 1: an “adequacy decision”

    The European Commission can review a country’s data protection laws and determine that they offer an adequate level of protection for personal data. The Commission maintains a list of countries with adequacy status; Canada is included, but only for data protected under Canadian privacy law (which does not cover personal data being processed by the government! Oh, Canada—room for improvement!)

    Option 2: appropriate safeguards

    The second option for transferring data is referred to as “appropriate safeguards,” which includes the Standard Contractual Clauses, a pre-approved contract provided by the European Commission which can be appended to any agreement.

    Option 3: derogations

    Derogations are exceptions for certain circumstances, which should only be used rarely and as a last resort.

    What was the EU-US Privacy Shield? What happened to it?

    The EU-US Privacy Shield was a special type of adequacy decision, a framework set up by the European Commission and the US Department of Commerce which US-based businesses could commit to follow. It provided assurances related to data protection and data subject rights that are similar to what we are familiar with from the GDPR; once a business signed on to those commitments, they became legally binding and enforceable. These commitments included:

    • providing transparent information to individuals about rights related to their data
    • providing dispute resolution for individuals who brought complaints related to how their data is handled
    • meeting purpose limitation and data retention obligations and requirements around accountability

    Now that the EU-US Privacy Shield has been invalidated, businesses can no longer rely on it as an adequacy decision. Instead, any transfer of data from the EU into the US needs to be protected by some other method—either appropriate safeguards or derogations. We know that derogations are limited, generally to be used for one-time transfers or exceptional circumstances.

    So where does that leave businesses who need to transfer data, including domain providers? They will have to add the proper assurances into their contracts, typically by use of standard contractual clauses—which is what we have done since 2018.

    How does Enom handle cross-border data transfer without the Privacy Shield?

    Lucky for us, it’s not a problem. We don’t have to make any changes to how we protect data when transferring it to the US because we don’t rely on the EU-US Privacy Shield framework.

    The Privacy Shield framework was only available to American companies, which right away excludes two of Tucows’ (our parent company) main domain businesses. Enom is American, but OpenSRS is a Canadian company, and Ascio is European. Enom could have signed on to the Privacy Shield framework, but Tucows wanted a single approach to apply to all their businesses.

    When we built out our processes for GDPR compliance, we adopted Standard Contractual Clauses provided by the European Commission to govern how we protect personal data.

    The Standard Contractual Clauses have been incorporated into our contracts with our resellers, vendors, and other service providers via a Data Processing Addendum. This means that when domain registration data is sent to registries or data centers in the US these contractual commitments can be relied on to govern how the data is handled and to ensure that each data subject’s rights are always respected. Specifically, through the Data Processing Addendum, we commit to complying with GDPR obligations, including confidentiality and information security controls, cooperation with supervisory authorities, and appointing a Data Protection Officer. The Addendum also documents our obligations related to ongoing testing and review of security measures, the reasons we process data, and what third-party providers we work with. We closely watch for any updates to the Standard Contractual Clauses, as we want to remain current with any standards provided by the European Commission.

    What do I need to do as a reseller?

    For the data processed related to our services, absolutely nothing! You’ve already accepted our Reseller Agreement, so it’s all handled. If you want to learn more, though, you can look for yourself to see the Standard Contractual Clauses in our Data Processing Addendum (which is incorporated into our Reseller Agreement by reference), and you can compare them to the version published by the Commission.

    You can also consult your own data protection counsel. This blog post is intended to be helpful and to share with you how we view data protection at Enom, but it is not intended as legal advice and should not be seen as a replacement for independent legal counsel.

    Read More

  • SSL Certificate Validity Periods Reduced to 1 Year

    July 2, 2020

    News, SSL

     Like

    Views: 2657

    man holds lock in his hand.

    Back in February of this year, Apple announced that as of September 1, 2020, its Safari browser will no longer trust newly registered SSL certificates with validity periods of two years. Two-year certificates registered up until August 31, 2020, will be trusted, but those registered on or after September 1, 2020, will not. To prevent incompatibility with specific browsers, Enom will implement a one-year max on SSL certificates in our system, as of August 15, 2020. Below we provide a bit of background information behind this change and, most importantly, outline what it means for Enom resellers.

    Why are SSL/TLS validity periods being reduced to 1 year?

    In the lead up to this change, there’d been for years an ongoing discussion in the Certificate Authority/Browser community around validity periods. On the one hand, shorter validity periods improve security by reducing the window of exposure if a certificate is compromised, and ensuring certificate holders are regularly updating their information (company name, address, active domains, etc). On the other hand, shorter validity periods mean more work for certificate users.

    Just a few years ago, the maximum validity period was reduced from three years to two. Back in August of 2019, ballot SC22, which proposed a further reduction to one year, failed to pass at the CA/Browser Forum (the industry’s self-governing body). Apple then made the independent decision to enforce this new maximum as part of their “ongoing efforts to improve web security” for Safari users. And when one of the major browsers imposes a change, the industry accommodates.

    How will this change SSL/TLS registrations on Enom?

    As of August 15 Enom will only offer one-year validity periods for all our SSL certificates. Here’s what this will look like:

    1. As of August 15, the Enom Control Panel will only provide the option to register certificates for one year
    2. As of August 15, all API requests to register (PurchaseService) or update an SSL must be submitted with a NumYears value of 1, or must omit the NumYears value entirely. Submitting a period value other than 1 will generate an error.

    Engaging with your Customers

    While this change may create a bit more work for website admins, it also creates a great opportunity for you to reach out to your customers and sync up about their SSL and security needs. Some may want to take advantage of the current two-year period and repurchase their certificates prior to August 15.

    Read More

  • Tucows Approaches to COVID Related Domain Registration

    April 9, 2020

    Industry Insight, News

     Like

    Views: 23260

    From an early point in the current global crisis, it was clear to Tucows (Enom’s parent company) that we were going to need to do something new and different in how we responded to COVID-19 related domain registrations. Many of these domains are registered for good, helpful purposes, such as community organization, dissemination of healthcare information, and recording people’s experiences through this pandemic. Others, however, purport to sell COVID-19 cures, vaccines, or tests, none of which are legitimately available on the market today and all of which pose a significant health risk to the general public.

    This blog post is going to run through the what, why, and how of our response to problematic or abusive COVID-19 related domain names and provide suggestions as to how our resellers and other hosting and CMS companies can help.

    Before we dive in, we want to emphasize that this global pandemic is an exceptional situation, requiring Tucows to explore approaches we would not consider in other circumstances.

    In helping to develop the DNS Abuse Framework, Tucows spent substantial time considering how domain names may be used to cause a threat to human life, and this work has been immensely valuable within the context of the COVID-19 pandemic. It is also important to note that our response to each and every issue that we find is contextual and dependent on the specific circumstances. We expect to return to our regular procedures as the pandemic and corresponding risks subsides.

     

    Our actions

    There are three major components to our COVID-19 related activities: identification, assessment for harm, and stakeholder engagement.

    Identification

    Tucows uses a relatively simple keyword search on all domains registered since December 2019 to flag relevant domains for manual review. We are also matching domain names on our platform to a number of externally-sourced COVID-19 related blocklists. Every day, members of our Compliance teamwork through our list of COVID-19 related registrations.

    Assessment for Harm

    As we mentioned above, a considerable number of COVID-19 related domain registrations are doing good and important things. We’ve seen many official websites from communities, hospitals, and other organizations come online over the past few weeks. Often, it is faster and easier for these organizations to use the website builder products offered by our reseller partners than for these organizations to host and build a site on their own infrastructure.

    As Tucows is primarily concerned with domain names that represent threats to human life, we are prioritizing looking for those that resolve to websites purporting to sell COVID-19 tests or cures. We are deeply worried about the possibility that someone could take a fake test and then, based on those results, continue to spread COVID-19 in their community, endangering many others. We have found very few of these sites so far, but when we do, we ask the registrant for documentation that proves their legitimacy and authorization to sell. This is very similar to our standard practice for addressing reports of harmful online pharmaceuticals.

    At this time, we have yet to see a site offering an unambiguous (albeit fake) cure that presents a risk of imminent human harm. We have seen cure-adjacent sites, purporting, for example, the (dubious) benefits of high-doses of vitamin C and the practice of alternative medicine. We’ve flagged these for review, but have not removed them from the DNS at this time.

    Other types of Harm

    We have also seen a number of COVID-19 phishing, botnet, and malware abuse issues; fortunately, we already have clear and well-established practices for dealing with these. For reports of misinformation, disinformation, price gouging, or fraud, we are working with regulators and law enforcement wherever possible to address these websites as we do not have the appropriate tools or experience to assess these independently.

    Engagement with Stakeholders

    An important component to all of the above has been communicating consistently with a variety of different stakeholders. This has included a number of our reseller partners who have seen large numbers of COVID-19 registrations. It has also included conversations with different law enforcement agencies, governments, and regulators. Our goal in these conversations is both to be transparent in what we can and cannot do and to ensure that the work of assessing website content is handled by those who are appropriately trained and empowered to do so wherever possible.

     

    Why Review?

    At least one major registrar has effectively blocked incoming COVID-19 related domain registrations. Tucows has chosen not to do this for a number of reasons; the primary one is that the Internet is an immensely powerful tool, especially in times of crisis where coordination is essential. The amazing sharing of information, mashups of data, official sites and even art that we’ve seen in our review is a daily reminder that allowing for creation is important. We think it’s important that registrants are able to respond as they see fit to the crisis, without impediment or delay. This approach vastly increases our burden and puts us in the uncomfortable position of having to assess the level of harm represented by a COVID-related domain and the website to which it resolves. However, we feel these circumstances are exceptional and are determined to do our part.

     

    Steps our resellers can take

    Hosting companies, CMS providers, and ecommerce platforms are in a better position than domain registrars to address content-related issues. Tucows resellers who offer these services may have the ability to remove specific pages or items from online stores whereas registrars have only one very blunt tool: we can take down the domain. To this end, we are also encouraging our resellers to monitor their registrations and platforms for COVID-19 related content. Now is an excellent time to review your Terms of Service and consider how you might apply them in the current circumstances. If you’re a Tucows reseller and would like assistance identifying COVID-19 related registrations, please reach out via help@enom.com.

     

    Report COVID-19 Related Abuse

    If you would like to report a COVID-19 related domain registered with Tucows that appears to be problematic, please submit an abuse complaint here: https://tucowsdomains.com/report-abuse/

    Lastly, like all complicated problems, COVID-19 requires a regular review of our processes and iterating where possible in a very short amount of time. We, like you, very much look forward to a return to normalcy.

    Read More

  • Highlights from ICANN66 Montreal

    November 25, 2019

    GDPR, Industry Insight, News

     Like

    Views: 3206

    Montreal in November is not as bad as it sounds; the weather is crisp and clear, the snow isn’t too deep yet, and it doesn’t get dark until a reasonable time in the evening. It’s still not my top choice for a travel destination at this time of year, but the ICANN conference definitely made it all worthwhile. For those who couldn’t make it out to Montreal, here are the highlights.

    How best to handle DNS abuse

    While changes necessitated by the GDPR were a hot topic at ICANN66, we were pleased to see a lot of discussion about DNS Abuse and how best to address it. Front and centre in these conversations was the “Framework to Address Abuse”, a document signed by Tucows and other major registrars and registries hoping to standardize our industry’s approach to DNS Abuse. In that Framework, Tucows and our co-signatories proposed a definition of DNS Abuse that we believe is correct and appropriately limited, while also describing a set of non-DNS Abuse categories on which we would, nonetheless, take action. The plenary session on DNS Abuse was the most well-attended session at any ICANN meeting so far.

    It’s impossible to summarize such a broad topic and intense discussion (you can, however, watch the whole thing online!), but here are the key takeaways:

    • DNS Abuse is a topic that the community is working to address
    • There’s concern around who should respond to Abuse and how to do so in a proportional manner
    • There are already tools in place that ICANN Compliance could use to help in this effort

    We’re committed to working within our space to address Abuse, and we look forward to collaborating with other groups in the domain name industry as this work continues.

     

    You guessed it… the GDPR

    The impact of the GDPR and other data privacy regulations on the Domain Name System remained a primary focus for ICANN66. Both the Expedited Policy Development Process (EPDP) team (the group that works to determine what the permanent replacement to ICANN’s Temp Spec must include and address) and the Implementation Review Team (the group responsible for transforming the EPDP’s Phase 1 recommendations into Consensus Policy) made good use of the opportunity for face-to-face meetings.

     

    Work from the EPDP team

    The EPDP team is in Phase 2 of their work, developing a System for Standardized Access and Disclosure (SSAD) by which third-parties can obtain non-public gTLD registration data. It’s a large project, and the work is divided up into a series of “building blocks,” each examining different aspects of this system, such as accreditation (for third-parties in search of data), data retention requirements, and auditing.

    We think this is a useful approach, but some core questions remain unanswered, including the fundamental one: who is the entity making the disclosure decision? 

    When a third-party requests access to registration data, will that be relayed to the relevant registrar or registry operator, or will the SSAD operator make that determination? Could a standalone SSAD operator have all the relevant information needed to appropriately decide if the request should be fulfilled or denied? Could a registrar or registry operator provide data to be disclosed via the SSAD while remaining compliant with data protection laws? As the building blocks get finalized these underlying open issues are brought to the forefront, and we’re getting closer to the point where the EPDP can’t continue its work without these answers.

    To that end, ICANN has set up a “Strawberry Team,” a group of ICANN staff working in parallel to the EPDP team. Just before ICANN66, they sent a proposed model for registration data disclosure to the European Data Protection Board, asking for feedback.

    There’s a general sense of frustration among EPDP members around the lack of communication about this; the team had asked ICANN to share any proposals or models with them before sending it out to groups like the Data Protection Board, and that didn’t happen here. There’s also concern that this work should be happening within the multistakeholder model rather than alongside it.

    Ultimately, if the European Data Protection Board (EDPB) provides advice, that can only be a good thing. However, as we wrote following ICANN64 in Kobe, it’s important to remember that any statement by the EDPB that the model is acceptable could easily be retracted in the future; it’s not a guarantee of legality. Instead, decisions around how to update ICANN contracts and Consensus Policies should be made by the ICANN Community, who are able to take relevant local laws and regulations into account while considering the policies our industry needs.

     

    Work from the Implementation Review Team

    Alongside the EPDP’s Phase 2 work, the Implementation Review Team (IRT) is in the midst of transforming the EPDP’s Phase 1 Recommendations into a “gTLD Registration Data Policy.” Once complete, this gTLD Registration Data Policy will replace the Temp Spec and permanently modify ICANN’s Registrar Accreditation Agreement (as well as other ICANN policies) to bring them into compliance with the GDPR and other data protection laws.

    This new policy will cover:

    • data collection
    • transfer of data from registrar to registry
    • transfer of data to data escrow provider
    • publication of registration data
    • logging
    • data retention requirements

    This gTLD Registration Data Policy will also include a section on “Reasonable Requests for Lawful Disclosure of Non-Public Registration Data.” You may be wondering how this ties into the EPDP team’s Phase 2 work developing a System for Standardized Access and Disclosure (SSAD): would they not go hand in hand? The difference is that the IRT’s Policy will govern how requests for data are handled when made directly to individual registrars or registry operators, while the SSAD is intended to be a standalone unified system with a single point of contact and operator.

    There is not yet an expected date for when the new gTLD Registration Data Policy will become effective, but we will keep you posted as things develop.

     

    Tucows’ involvement in the ICANN Community

    The Tucows team also presented on panels and attended sessions on a variety of other topics. We discussed expectations for RDAP, the successor to the Whois protocol, based on outcomes of the EPDP and IRT; we worked with the joint registrar and registry “TechOps” team on a set of topics, including best practices for transfer authorization codes.

    ICANN meetings are a unique combination of exhausting and exhilarating. Participants from all around the world come together to work on specific topics, with hundreds of sessions to choose from, and the public forums are always fascinating. We continue to work hard to make sure that the concerns of our customers and their registrants are represented at this important venue.

    Read More

  • Our Ongoing Commitment to Combatting DNS Abuse

    October 18, 2019

    Announcement, Featured, News

     Like

    Views: 3348

    Abuse is a significant problem on the Internet today and, as a provider of Internet infrastructure services, we constantly consider what role we should play in combatting this issue. We actively investigate and respond to reports of abuse, but like other registrars and registries, we’ve been alone in developing our approach—until now.

    Abuse has been a growing topic of conversation in our industry. Today, several major registrars and registries released a DNS Abuse Framework defining what types of abuse to the domain name system (DNS) we are the appropriate parties to take action on. It’s our hope that this commitment by DNS providers to address abuse on our platforms will help establish industry-wide standards that both protect free speech and ensure that the Internet remains free and open while keeping malicious online activity in check. 

    What is DNS Abuse? On the surface that should be easy to answer: it’s abusive use of the domain name system. But as you get into the details, there are often more questions than answers. Who decides what is abusive? Who should respond when it happens? As a domain name registrar, our obligations are spelled out in the Registrar Accreditation Agreement (RAA), but although we must “take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse,” (RAA 3.18.1) the RAA doesn’t provide a specific definition either of abuse or of what steps are reasonable.

    For some registries, Specification 11 of their respective Registry Agreements provides more assistance, referring to specific types of behavior as security threats: pharming, phishing, malware, and botnets. Until now, however, there has not been a consistent, common understanding of how to define abuse, meaning we haven’t been able to come to an agreement on who should respond when it happens.

    This new DNS Abuse Framework proposes a shared definition of DNS abuse, relying on the Internet & Jurisdiction Policy Network’s definitions of the four behaviors listed in the Registry Agreement plus spam (but only when spam email is used as a delivery mechanism for another type of abuse, such as malware). This Framework also considers additional types of abuse that DNS providers should respond to—even if we are not required to do so under our respective contracts. Reaching a common agreement about what constitutes DNS abuse is a crucial component of any industry-wide efforts to mitigate that abuse. 

    We encourage all Enom resellers to read through the Framework and become familiar with these types of abuse. To help, here’s a summary.

    Malware is software that is installed on a device, such as a computer or smartphone, without the owner’s consent and for malicious purposes (that’s where the “mal” comes from). This includes things like viruses or spyware.

    Botnets are networks of malware-infected computers, controlled remotely.

    Phishing is the term for a fraudulent or copycat email that tricks users into thinking it’s legitimate in order to obtain personal data or financial information such as credit card numbers.

    Pharming is the use of DNS redirection to bring Internet users to a different website than the one they intended to visit, in order to obtain personal data or financial information or install malware.

    Spam is unsolicited email; it is included in our definition of DNS abuse when it’s used as part of the delivery method for these other types of abuse, such as malware or phishing.

    As one of the collaborators of and signatories to this Framework, the Tucows family of registrars is committed to taking action when our services are used for these malicious purposes. As a community of stakeholders all seeking to provide safe and reliable Internet services, we’ve come together to find the most effective and appropriate means to mitigate these significant concerns. Since rules vary from jurisdiction to jurisdiction and there is no single global standard, we hope that this Framework helps to provide one. Having a consistent, industry-wide approach will help make responding to abuse faster and more successful, and this Framework can help those who encounter abuse online to know where to best direct their concerns so they’ll be addressed promptly.

    Read More

1 2 … 5 Next »

FEATURED POSTS

  • How to Win by Treating Your Customers as Members

    August 13, 2020

  • A Great Domain for Freelancers and Entrepreneurs? Try .ME

    June 22, 2020

  • Bandzoogle: website builder for musicians

    June 1, 2020

  • security lock and credit cards on keyboard

    Avoiding COVID-19 Cyberattacks with Security Best-Practices

    April 28, 2020

CATEGORIES

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

ARCHIVES

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

Report Abuse
Help Center
Contact Us

Resources

WHOIS Lookup
Maintenance Alerts
Developers
Products & Services

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

© 2021 Enom Blog |