MENU
  • Enom.com
  • Resellers

Enom Blog

GDPR
Category

  • Data Privacy Day 2021: Data Protection by Design

    January 28, 2021

    Advice, GDPR, Industry Insight

     Like

    Views: 269

    January 28 is Data Privacy Day! Privacy a topic we’re hugely passionate about, and we’re really proud of the work we do to protect the personal data we’re entrusted with and to advocate for the privacy rights of domain owners and our resellers. It should go without saying that we approach data protection with great care and consideration year-round, but it’s nice to have a dedicated day when we pause to reflect on why data privacy is so important. I’m taking this as an opportunity to highlight some quick data privacy tips which are ready to be shared with your customers (TikTok video below), recap what Tucows (Enom’s parent company) accomplished in 2020, and provide some insight into our plans for the year ahead.

    Data privacy tips for your customers

    Here are things that all of us should know when sharing our data online, also available in TikTok form.

      1. You have the right to access your data and correct inaccurate information
        Every company you share your data with should have this functionality. Check the app settings or contact them to find out more.
      2. You have the right to know if a company is sharing your data and a right to give or withdraw your consent to share it.
        Privacy settings are super important in controlling which information apps and services can share. Make sure you keep track of them!
      3. If you consented to optional data use, you can withdraw consent at any time.
        When you click “I consent,” that’s not permanent! You can change your mind and take back control of your information.

     

    Data protection by design at Tucows

    We work hard to ensure that high standards of privacy and data protection are present in our products and services from start to finish. But what does this process actually look like?

    Planning

    Data protection begins in the planning phase, where we conduct comprehensive reviews called Data Protection Impact Assessments (DPIAs) for any new product or service we want to introduce that touches personal data. This includes changes and additions to our reseller services, as well as any tools or applications we adopt internally. These Assessments help us identify and document any possible risks to the data, and our methods of mitigating those risks.

    Implementing

    In the product development and implementation phases, and while services are active in our platforms, we follow regulatory requirements for data protection, adhere to industry best practices for security measures, and have robust processes in place to respond to customer privacy concerns and fulfill data subject access requests.

    Review

    We have also put in place a new annual review process for our Data Protection Impact Assessments. This involves looking back at all the services we’ve completed DPIAs for, to see if there were changes to how those products or services handle data or any updates that require further data protection work on our part.

    Tucows’ progress in 2020

    Privacy and data protection work is so essential, but it’s perhaps not the most exciting topic, except to me and my fellow privacy and policy nerds. Nonetheless, we think it’s important to highlight some of the goals we achieved in 2020 related to data protection.

    Creating greater transparency

    The most visible change was the launch of our updated Data Sharing Preferences (a unique URL where domain owners can set their preferences) and Data Sharing Practices pages. These resources now more clearly explain how and why we process personal data. We also now offer translation of these pages into eight languages, helping data subjects access the information in the language that they’re most comfortable reading.

    Advocacy work within ICANN

    Within the ICANN policy development world, we worked hard to ensure that the privacy rights of our domain customers are respected. We continue to advocate for policy changes to promote “data protection by design and default” within the domain name system, such as ensuring that registration data is only disclosed to third parties when there’s a valid legal reason to do so. This cause has been central to our public speaking engagements in 2020, including a recent webinar where we shared domain data disclosure statistics from the registrar and registry community (available here, look for September 22 in the chart).

    Keeping a pulse on global privacy developments

    From the broader international perspective, the biggest change we saw in 2020 was the invalidation of the EU-US Privacy Shield framework, which we blogged about in November.

    Plans for the future

    Looking ahead to 2021, Tucows’ Privacy Team’s goal is to continue the work we started in 2020 in an expanded and enhanced manner. This includes working to improve how we disclose data processing practices and options to users on our platform.

    Our advocacy work with ICANN will remain a priority, specifically ensuring that policy requirements are in alignment with our obligations under data protection regulations, and that when newly-approved policies are implemented they permit adherence to relevant privacy laws.

    Finally, we’re avidly following developments to Canadian privacy law with the incoming Canadian Consumer Privacy Protection Act, and working with our contacts in Canada’s Ministry of Innovation, Science, and Economic Development to advocate for privacy rights in the tech industry.

    If you have any questions about data protection and privacy as they relate to our Domains, Email, and SSL products, get in touch!

    So, that’s what we’re looking forward to in the year to come. How will you celebrate Data Privacy Day? Personally, I plan to eat cake and reset all my passwords.

    Read More

  • 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

  • Whois History and Updated Tiered Access Statistics

    September 17, 2020

    GDPR, Industry Insight

     Like

    Views: 2138

    keys on surface.

    The Internet as we know it may be fairly new, but that short history doesn’t mean it’s not also filled with cycles and repetition.

    Back in 2003, ICANN convened the Whois Task Force, intended to improve the ability of Whois services to contribute to the stability and security of the Internet while balancing the need to protect the privacy of the personal data involved. The Task Force’s goals of defining the purposes of Whois services overall—and of specific points of contact—as well as determining what data should be public and how to provide access as needed to nonpublic data, is remarkably similar to the work done in the EPDP, which was recently tasked with updating ICANN policy to adhere to the GDPR and other relevant privacy and data protection legislation while ensuring lawful disclosure of registration data where necessary.

    In 2005, in that same Task Force, the RrSG proposed the creation of an “Operational Point of Contact” to help address a specific issue:

    the amount of data that ICANN requires registrars to display in the Whois is facilitating all sorts of undesirable behaviours like renewal scams, data-mining, phishing, identity theft, and so on.

    The RrSG proposal was intended to enable contact with the relevant person responsible for the domain while also maintaining the privacy of personal data—again, similar to what the EPDP would later attempt—but other groups on the Task Force focused instead on limiting data protection to only a small subset of domain owners in order to retain as much access as possible.

    The Final Task Force Report on Whois Services, from 2007, gained support from the registrar and registry stakeholder groups (RrSG) and the non-commercial stakeholder group, but did not receive the business or intellectual property constituencies’ support.  The policy development world seems stuck in a loop, with the EPDP’s final report likely fated to end identically, despite our hopes that the ICANN Community will be able to break that cycle.

    Abusive use of publicly-available domain registration data, which RrSG members call out regularly, including in the early ‘00s and again in the EPDP, takes many different forms. Although it’s been some time since they’ve popped up in the news, those who follow the domain industry will know of Brandon Gray Internet Services, also known as NameJuice or Domain Registry of America. Their history of gathering Whois data to spam registrants with emails disguised as domain name renewal notices is well-documented1, as is the damage done to domain owners and other Internet users. Typical complaints centered around registrants not knowing who their domain provider is or why a domain has been transferred away from their preferred registrar, paying for services that were unnecessary or nonexistent, and inability to manage domains after the transfer was completed. This began early in our Internet history, when domain owners were less experienced in managing services and had fewer data privacy and protection rights—or at least lower awareness around how to exercise those rights. In recent years, NameJuice has managed to stay under the radar, carefully crafting their solicitations to remain within the bounds of “marketing” and to avoid legal and compliance action.

    Abusive use of domain registration data took the form of bulk scraping of publicly-available data from the Whois system; this data was then packaged and sold by enterprising cybercriminals to both security researchers with valid purpose and those seeking to use it for purely commercial purposes. Because security researchers benefited from this arrangement, they kept their heads in the sand about the accumulation of the data—one of the first instances of cybercrime tools for hire.

    When unrestricted access to Whois data was terminated in May 2018, these data aggregators continued to sell previously-collected data. This mass processing of historic and ongoing registration data is illegal. Even data that is public may only be processed in a manner compliant with data protection regulations, including the GDPR; this means that the organization doing the processing must have a legal basis to do so and make sure the data subject (the registrant) is fully informed.

    Scraping is specifically prohibited in registrars’ terms of service for Whois data, yet security researchers, commercial litigators, and other parties seem eager to use such illicitly-obtained personal data while continuing to fight for access to information that was obtained through cybercrime.

    Tucows is not blameless; we should have more aggressively prosecuted these “WhoWas” service providers2 while they were at the peak of their scraping and selling of this data, instead of merely implementing technical means to attempt to prevent their criminal activity (including rate limiting and requiring CAPTCHAs for lookups). While we did send cease and desist letters on multiple occasions, when these were ignored we did not take any additional action. We regret not having done so, especially as these companies continue to sell access to customers’ personal data to their complicit clients.

    At this point, since registration data is mostly redacted unless and until the domain owner decides to make it public, bulk gathering up of registration data is a decreasing concern but is still very much on our radar.

    This history should be kept in mind when reviewing this or any of our prior blog posts3 discussing the reasonable disclosure of previously-public Whois data. It is within the context of this profligate access to and abuse of Whois data that the flood of access requests registrars have received must be understood.

    Responses to Denial Requests

    Recently, the rhetoric from professional data requestors has shifted toward allegations of incorrect denials. Since we began tracking requests over two years ago, Tucows has denied only 241 requests, or 7% of all requests. We do not count abandoned requests as denials, as others do. Since May 2018, 51% of all requests are abandoned following our reasonable requests for additional information; this rate has dropped with each period.

    Most often, requests ask for all data we have, including information that was never publicly available and information that relevant courts have deemed to be illegal to share. When we respond to a request for “Registrant, Admin, Tech-C, Billing, and all other domains owned by the registrant”, we consider that to be a request for “previously-public Whois data”. Billing information would require a subpoena and reverse Whois lookups have never been a function of the Whois database, despite the criminal services discussed above.

    Of those 241 denials, vanishingly few of them have been disputed by the requestor—the handful of times it has happened, when our Legal team discussed the concern with the requestor, the end result was no disclosure. This tells us that our request review process is working properly, allowing us to filter out invalid requests and ensure that only those requestors who actually demonstrate a legitimate need for the data and commit to handling it with appropriate protections are able to obtain personal data.

    More complaints have been about the data we disclose being inaccurate. We do not specifically track this, but this type of response has been coming in often enough that we are working on providing an easy way of reporting a Whois inaccuracy to us—rather than having to report to ICANN to then convey to us. This will be available from within our TACO system, since only people with access to non-public personal data would be able to indicate that the information may be incorrect; this will include the standard process of suspension of the domain in the event of no response from the registrant within the ICANN-mandated time frame.

    Recent Tiered Access Statistics

    The statistics provided below are for the period beginning 1 March 2020 and ending 31 August 2020 (Period 4).

    Requests for Data Disclosure

    In Period 4, Tucows received 527 disclosure requests; our overall total since we began tracking this in May 2018 is 3,4004.

     

    75% of requests resulted in disclosure of domain registration data

    This represents an increase of 13% compared to Period 3, which itself was double the rate of Period 2. As we discussed in the Period 3 report, this indicates improvement in the quality of the requests that we receive.

    9% of requests were incomplete and, when we asked for additional information, the request was abandoned

    This is a drop from the previous period and can likely be attributed to our ongoing outreach efforts and each requestor’s increasing familiarity with the process. We are beginning to see new requestors who already know to follow the RrSG-Recommended Minimum Required Information for a Whois Data Request. The part of the request most frequently missing is an assurance to only use the data for lawful purposes and to destroy the data after it is no longer needed.

    11% of requests were denied, following a determination that the requestor did not have an adequate lawful basis

    This remains concerningly high. Unlike abandoned requests, where asking for additional information results in the requestor deciding not to follow up with the request, denied requests represent a failure of the requestor to adequately evaluate the legal implications of their request. As discussed in our Privacy and Lawful Access to Personal Data blog post, the primary reason that requests get denied is that no human reviewed the requests before they were submitted. The requests are for domains that may match all or part of a trademark but represent no threat to the mark for a variety of reasons. Our job is to balance the rights of the requestor—usually an intellectual property owner or its representative—against the data protection and privacy rights of the registrant. Where a review of the domain—even the content hosted on it—results in confirmation that there is no danger to the mark, the balance favors privacy.

    4% of requests were for domains with an active Whois Privacy service, so only the publicly-available privacy service data were disclosed

    While we are pleased to see this number reduced compared to the last period, we see some repeat requestors regularly asking for data they know to be behind one of our Whois Privacy services. This seems to be an attempt at “checking a legal box”: they are not asking for data they don’t know to be concealed, but rather, they are specifically not asking for the concealed data in the manner that they know will result in its disclosure, allowing them to indicate to their customers that they’ve gone through the process of requesting data but were “denied” without having to take the time and expense to file the actual paperwork that would result in its disclosure. We continue to reserve the right to blocklist requestors that regularly abuse our request process.

    Requested vs. Disclosed

     

    As mentioned above, the increase in disclosure rates for this reporting period shows improvement in the quality of the requests that we receive.

    Compared Against Previous Reporting Periods

     

    Requests Over Time

    Here’s an illustration of the total volume of requests Tucows has received since the launch of our Tiered Access platform:

     

    The number of requests appears to have stabilized, concurrent with the increase in quality of requests, a positive trend indicative of the industry as a whole settling into the new data protection landscape.

    Disclosure Request Outcomes, Compared

     

    We are pleased to note that the rate of incomplete and abandoned requests continues to drop.

    Duplicate Requests

     

    Duplicate requests have decreased, which we like to see, but an interesting new type of duplicative request that we have begun to see is that the owner of the intellectual property is reaching out to request data disclosure months or even years after the same data were already disclosed to a party claiming to be a representative of that owner. This is not tracked and currently remains rare but is an interesting insight into the relationships between professional data aggregators and the intellectual property owners they purport to represent.

    Categories of Requestors

    As readers of this blog series will know, we have grouped requestors into four main categories for tracking purposes. The main tracked requestor types are:

    • commercial litigation, which request disclosure of personal data in order to bring a legal claim of rights against the registrant;
    • law enforcement, carrying out an investigation or otherwise in the course of their work;
    • security researchers, who use certain aggregate data to identify trends in digital abuse; and
    • other, which includes Certificate Authorities, resellers, private individuals, and sometimes even the registrants themselves.

    At 84% of total requests, commercial litigation remains overwhelmingly the most frequent requestor type and, within that requestor type, professional data aggregators are the largest part. We are seeing a slight increase in Law Enforcement requests, up to 12% in Period 4.

    We look forward to continuing to provide legally permissible access to non-public domain name registration data, including tracking the statistics for future review and insight into our industry.

     


    1 Further reading:

    • Brandon Gray Internet Services Inc. Litigation
    • ICANN Notice of breach of registrar accreditation agreement
    • ICANN Notice of suspension of registrar’s ability to create new registered names or initiate inbound transfers of registered names
    • Ontario registrar stopped from selling dot ca domains
    • Domain registry of America get slapped in UK
    • ASA Adjudication on Domain Registry of America

    2 DomainTools has the dubious distinction of being the most well-known of these PII-aggregators but is by no means the only. WhoisXMLAPI, who.is, and WHOXY also sell current and former personal data to their customers and, in some cases, operate an extortion scheme whereby a registrant can request exemption from this illegal sale.

    3 You can find data for Period 1 in Enom’s Tiered Access Directory: eight months later, for Period 2 in Tiered Access Data Disclosure Update, and for Period 3 in Privacy and Lawful Access to Personal Data at Tucows.

    4 “Total” numbers for a period may change after the period is reported because, although we have mostly successfully educated requestors about how to submit requests, we sometimes find requests that were misrouted—we deal with these when they are discovered but we count them as of the date of request, potentially changing numbers after we have reported them in a blog post. The impact is minor, so we do not feel the need to update prior posts but felt it prudent to indicate why the numbers might be slightly different if you’re comparing across posts.

    Read More

  • Privacy and Lawful Access to Personal Data at Tucows

    March 13, 2020

    GDPR, Industry Insight

     Like

    Views: 1566

    keys on surface.

    Tucows provides reasonable, lawful access to non-public registration data; this means constantly working to balance the privacy rights of registrants against the rights of third parties, most of which, in our experience, are related to intellectual property rights (90% of all requests). In addition to the usual statistics, this update also includes a deep dive into actual examples of some problematic disclosure requests, a discussion of the reasoning behind denials, and what this means for the industry conversation about disclosure requests.

    These ongoing updates are intended to provide insight into the disclosure requests Tucows receives and to serve as useful data for discussion as our industry moves toward a holistic policy governing the disclosure of private data.

    Tiered Access Statistics

    The statistics discussed below include data through the end of February 2020 (“Period 3”). Each request is a request for personal data regarding the registrant of a domain where that information is not publicly available. A member of the Compliance and Legal team reviews every request individually to balance the rights of the data subject and the legitimate interests of the requestor to determine whether and how much data should be disclosed; this includes consideration of Tucows’ contractual requirements as well as applicable laws—both privacy laws and intellectual property laws. This work is time-consuming and intense but there’s no other way to make sure that we’re making the right decisions about when to disclose the personal data we’re entrusted with.

     

    Requests for Data Disclosure

    Tucows received 238 requests for data in Period 3 (from mid-October 2019 to the end of February 2020), and 2,864 requests in total since the Tiered Access portal went live in May 2018.

    Previously, data for Period 1 was discussed in Tucows’ Tiered Access Directory: a look at the numbers and for Period 2 in Tiered Access Data Disclosure Update.

     

    Disclosure Request Outcomes – Period 3

    62% of requests received in this period resulted in registration data being disclosed to the requestor

    This rate of disclosure is about double what it was in the previous two periods (24% in Period 1 and 36% in Period 2), indicating higher quality requests. This is likely related to the use of the RrSG Minimum Required Information for Whois Data Requests, which was drafted by ICANN’s Registrar Stakeholder Group (RrSG) to help standardize requests for domain data disclosure. Requests that use this format are easier to review (all of the required information is included in a predictable format) and deficiencies are simple to communicate to the requestor. It may also be due to Tucows’ outreach efforts to educate requestors about this format. This higher rate should be considered illustrative of success and a positive movement toward appropriate disclosure of personal data to parties with a legitimate purpose.

     

    17% of requests were incomplete and the requestor did not respond to our followup for further information, so no data were disclosed

    Despite formal outreach and personalized responses to each request, a significant number of requests are incomplete and responses seeking further information are ignored by the requestor. This is because either there is no party on the other end to review responses that do not include data (the request is automated and not appropriately monitored) or there was no reason to make the request in the first place and pushback had the correct effect of preventing unnecessary disclosure of personal data.

     

    6% of requests for data were denied, following a determination that the requestor did not have an adequate lawful basis

    This represents a decrease from the previous period but is level with Period 1 and the overall rate of denied disclosure requests.

     

    12% of requests resulted in “disclosure” of Whois privacy information—that is, the same placeholder information already publicly available to a requestor

    Parties experienced with our data disclosure request process have recently begun to specifically request data for domains clearly indicated in the public Whois as using Tucows’ Whois privacy services. In some cases, this has been accompanied by a dropoff in requests for the personal data of registrants without Whois privacy. In other cases, there has been no dropoff in requests for non-Whois privacy domains but the format of the request has changed, indicating that the requestor is aware of the fact that there is Whois privacy on the domains but is attempting to get the underlying data without submitting a subpoena, as is Tucows’ current process.

     

    Requested vs. Disclosed

    Compared Against Previous Reporting Periods

     

    Requests Over Time

    Here’s an illustration of the total volume of requests Tucows has received since the launch of Tiered Access:

    The number of requests appears to have stabilized, concurrent with the increase in quality of requests. Again, this is a positive trend as both requestors and the Tucows family of registrars have acclimated to the new privacy legal landscape.

    Disclosure Request Outcomes, Compared

    It may seem counterintuitive but an increase in disclosure rates means that request quality overall is improving and signals a positive move toward appropriate disclosure.

    Duplicate Requests

    Additional information on duplicate requests can be found in Tucows’ Tiered Access Directory: a look at the numbers (for Period 1) and Tiered Access Data Disclosure Update (for Period 2).

     

    Categories of Requestors

    As noted above and in previous blog posts, disclosure of registration data is only granted when the requestor has demonstrated a legal basis to access the data. While requestors can be categorized into a few broad groups, inclusion in a certain group does not determine if and which data are disclosed. Each request is—and must be—evaluated on its individual merits. Requestors therefore are grouped below solely for analysis’ sake. The main tracked requestor types are:

    • commercial litigation, which request disclosure of personal data in order to bring a legal claim of rights against the registrant
    • law enforcement, carrying out an investigation or otherwise in the course of their work
    • security researchers, who use certain aggregate data to identify trends in digital abuse
    • other, which includes Certificate Authorities, resellers, private individuals, and sometimes even the registrants themselves.

     

    Requests by Requestor Type

    As you can see, Commercial Litigation has made up the bulk of requests since Tucows began tracking this data. Typically, these requestors are either companies that are created specifically to request this type of information on behalf of large corporate clients or are lawyers hired or employed primarily to request this type of information.

    Also included in this category, however, are individual rights holders attempting to protect their rights (sometimes intellectual property, sometimes personal privacy rights) without the advantage of a company or a lawyer devoted to that purpose. Especially in light of the Preliminary Recommendations found in the EPDP Phase 2 Team’s Initial Report, it is important to ensure that individual rights holders continue to have a reasonable means of requesting the information necessary to protect their rights.

    The rate of requests by Security Researchers is deceptively low because it is counted differently. Most requests are counted by the number of domains requested; when a request is received for the entire database, however, that is counted as just one request, not millions. Some Law Enforcement requests fall into this category, as do nearly all requests from Security Researchers. We currently do not allow unfettered access to our database to anyone and are working with representatives of both groups to come up with a means of providing the data necessary to conduct their investigations while protecting the privacy rights of individuals.

    The Importance of Human Review


    We regularly receive requests for disclosure of registration data which we deny after reviewing the request, the requestor, and the relevant data (including the domain name itself and any content that may be hosted there). In the interests of transparency and advancing industry discussion on this topic, we’ll share some real-life examples of denied requests along with the reasoning behind our decision below. For some of these, the domain names in question are relevant and therefore the requestor may become evident. We should emphasize that, due to the sheer volume of requests from certain requestors, a trademark or corporation may appear more than once. This should not be taken to mean that all requests from these requestors are invalid or are treated differently than any other requestor; the domain names are simply used as examples.

    It is concerning that these invalid requests which, upon meaningful review, are readily apparent as invalid even to a layperson, continue to be submitted. This underscores the fact that any attempt at automation will result in numerous false positives and that meaningful human review is essential prior to disclosure.

    These requests fall into three broad categories: duplicates, an issue with the allegedly infringed trademark, or fair use. As the majority of disclosure requests Tucows has received to date are for alleged trademark infringement, the examples below may fall primarily into that category; again, it should not be assumed that this is the only type of invalid request.

    Duplicate Requests

    Prior posts (Period 1 and Period 2) have addressed the matter of duplicates and, as there has been a statistically-significant dropoff in duplicate requests, it will not be discussed here.

    Issues with the Request

    Many disclosure requests include a list of all trademarks potentially infringed by a specific domain or set of domains; this is not ideal as the domain name must be compared to the list rather than to a single trademark that is being infringed and it is often not apparent to the reviewer which trademark is the issue. This lack of specificity also suggests that the request originates from an automated system.

    A shocking number of disclosure requests relate to domains not registered with the Tucows family of registrars—sometimes these domains are not registered at all. We have even received a disclosure request alleging trademark infringement for a domain that predated the trademark’s registration. These issues point to the limitations of automation and the necessity of meaningful human review, which we’d like to see more of on the requestors’ side.

    Fair Use

    The final category, fair use, includes multiple examples that are obvious to a layperson as non-infringing. Not included here are edge cases that ought to be adjudicated by a competent authority (whether at UDRP or in a local court).

    petrolexcompany.com
    Here, the domain includes the full trademark “Rolex” but is in use by a different company whose registered name (Petrolex) includes that trademark.

    instantmonogram.com
    letsfacethebook.com
    In each of these cases, the domain name contains the whole trademark separated by additional characters (“Insta[…]gram” or “Face[…]book”) but bears no relation to any infringement of it. While these domains no longer have any hosted content, at the time of review, they were in use by a company specializing in personalized t-shirts and other apparel and by a biblical outreach group, respectively. Both of these are clearly fair use and should never have resulted in a request for data disclosure.

    boucheriefacedeboeuf.com
    lincolnstainedglass.com
    zharfambook.com
    These do not contain the full trademark but only portions of it or portions of misspellings previously adjudicated at UDRP (here, “f…bo” and “insta”). The domains boucheriefacedeboeuf.com and zharfambook.com remain active, in use by a butcher and what appears to be a literacy site. While lincolnstainedglass.com no longer has any hosted content, at the time of review, a small stained glass company was using it for their business. Again, these are clearly fair use upon meaningful human review.

    addictedtofacebook.org
    banned-by-facebook.com
    divestfacebook.com
    facebooksucks.org
    protestfacebook.org
    saynotoinstagram.com
    While each of these domains uses the full trademark (“Facebook” or “Instagram”), they nevertheless evince an indication that the domain is or will be used to discuss grievances with the company in question. Tucows takes no position on the merits of these discussions but notes that trademark use should not be used as a cudgel against speech.

     

    The Tucows process for disclosing data remains aligned with industry best practices and we continue to be actively involved at ICANN both to closely align our processes with expected policy outcomes and to ensure that the rights of all individuals are respected in those policies. We look forward to continuing to share these statistics on a regular basis to contribute to broader industry understanding of the registration data disclosure landscape.

    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

1 2 … 6 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 |