Missed our .ORG Webinar? We’ve got you covered. Below you’ll find a recording of the live presentation as well as links to the downloadable .ORG Toolkit and Webinar PDF.
Watch the .ORG Webinar
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.
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.
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.
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.
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.
This represents a decrease from the previous period but is level with Period 1 and the overall rate of denied disclosure requests.
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.
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.
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.
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).
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:
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.
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.
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.
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).
Here, the domain includes the full trademark “Rolex” but is in use by a different company whose registered name (Petrolex) includes that trademark.
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.
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.
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.
Founded in 1999 by two students offering web-design services, Hostnet has grown into one of the largest and most customer-friendly hosting providers in the Netherlands. Today, they offer domain names, website hosting, a website builder, and other business services to a growing number of customers. Since 2000, they’ve used Tucows to power domain registrations and management for a large part of their business.
Here’s a snapshot of our conversation with Bas Schouten, Product Manager (Domains), Hostnet BV. We touch on Hostnet’s successful journey and how their partnership with Tucows (Enom’s parent company) has helped them create value for end-customers and capture growing business opportunities.
In the beginning, Hostnet was selling hosting and domain names from an attic. This was back in the days when customers placed their orders via fax. Needless to say, it involved a lot of manual work. A lot has changed over the years. For one thing, orders are no longer sent via fax, but via the Hostnet webshop. Requesting and registering a domain name is now automatic. But we’ve also expanded our product offering. In addition to hosting and domain names, we’ve added solutions such as email, Microsoft Office 365, and various other Managed Services.
In 20 years we have become one of the largest and most customer-friendly hosting providers in the Netherlands. During this time, we grew to a 50-person, then 100-person company. Along the way, there have been milestones in the number of registered domains and active hosting packages we have under management.
Hostnet has been a Tucows reseller since 2000—nearly 20 years. Tucows is our valued partner in areas such as domain registration and SSL certificates. By working together with Tucows, Hostnet has been able to offer registrations under multiple top-level domains (TLDs) since 2000. Tucows also helped us effectively expand our top-level domain offering when the new TLDs became available, starting in 2014.
With the right marketing, new top-level domains can be the biggest opportunity (growth rate wise) at this time, which is great. I think, in general, customers like new domains, although there are many new extensions that are just too long/niche to be actively used. The beauty of new extensions such as .SITE, .ONLINE and .TECH—all of which are popular in the Netherlands—is that domains in these zones are so valuable when the more traditional options (like .NL or .COM) are already taken. This has already begun to happen to a large extent.
I’d say .ONLINE and .SITE are quite popular in the Netherlands. In fact, .ONLINE is currently Hostnet’s best performing new domain extension and tops the charts in terms of sales volume and growth rate. I believe that .ONLINE is the largest new extension in the Netherlands.
With the eCommerce market booming, we are also seeing a good uptake for .STORE, with live websites from our customers growing consistently on this extension.
Other than that, .NL and .COM are well-known in this region.
We have made the most of Tucows’ promotions mostly by reducing the pricing to our customers for those TLDs, in some cases paired with marketing initiatives such as Social Media posts or mentions in newsletters. In addition, some registry partners, such as Radix, consistently put forth content that has helped us keep the offers fresh and exciting for our customers. These efforts, in most cases, contributed to a significant rise in sales.
My recommendations would definitely include .ONLINE, .STORE, .SITE, .SHOP and .APP. All of these are great TLDs. .ONLINE and .SITE are more generic, while the other three clearly state what they’re used for.
New extensions definitely offer a lot more options to choose from and allow people to register a domain that may be unavailable under the more conventional .NL and .COM TLDs. More importantly, new domain extensions are an opportunity to state more clearly what your website or product is all about.
I am most proud of the exceptional service we provide to our customers. We’re professionals who are reachable by phone, chat, and email most of the week and are committed to assisting our customers with any problem, as thoroughly as possible. Hostnet is definitely a customer-first business and that has significantly contributed to our growth and success over the last two decades.
This post was sponsored by Radix. Many of their TLDs, including the super popular .ONLINE, .STORE, and .TECH are on sale now through Enom. Learn more.
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.
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:
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.
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.
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.
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:
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.
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.
It has been more than a year since Tucows, Enom’s parent company, launched our Tiered Access Compliance & Operations portal, sometimes called “Gated Whois,” and it’s been around six months since we shared our first set of statistics on how and by whom this platform is being used. Today’s update brings our statistics current through mid-October 2019. We hope that this data will provide insight into how we handle requests for non-public personal data.
It’s important to remember that these statistics represent disclosure requests by a third party asking for personal data which is not publicly available. Each request is examined by a member of our legal team, who reviews the request and decides what data, if any, should be disclosed based on applicable law and our ICANN obligations. This review can be intensive and time-consuming but is essential to processing the data we’re entrusted with in accordance with our commitment to the protection of personal data.
We received 467 requests for data in the period from February to mid-October 2019 and 2617 requests total to date.
We are pleased to note that we did not find significant spikes in requests during this reporting period, unlike our previous report where request volumes increased around ICANN meetings, suggesting that some portion of those requests were submitted in order to skew the data towards an argument that disclosure requests are not being processed in a timely or appropriate manner.
Here’s an illustration of the volume requests over time since we’ve launched Tiered Access:
Perhaps more interesting than the overall numbers is how the current reporting period compares to the previous one: comparing request and response statistics as users become more accustomed to the new system and have learned how to effectively request data; the comparisons below are percentages.
We continue to see a significant rate of duplicate requests. These include requests from the same source and from multiple requestors, each purporting to represent the same interests. When we receive a second request from the same requestor, we refer them to our prior correspondence—whether that included a request for more information (most often the case) or disclosed personal data. When we receive a request for the same domain’s data from a different party, we encourage the two parties to work together to determine which one represents the legitimate purposes for the data disclosure. We do this whether the data were previously disclosed or not.
As before, a statistically-significant amount of all requests come from the same single requestor mentioned in our previous report; this is the largest individual requestor using our Tiered Access system. However, their requests have dropped by half—last time we shared stats, this requestor represented nearly 65% of all requests, while for period 2 they make up 30% of all disclosure requests submitted to our Tiered Access system. We have worked with this requestor to refine and improve the quality and type of their requests, which has resulted in a decrease both in requests sent and requests denied.
Although it makes up only a very small percentage of overall requests (1.5%), requests for access to our entire registration database have doubled from period 1 to period 2. The majority of these types of requests come from security researchers.
As stated above, users of our Tiered Access Compliance & Operations system are vetted by our legal team, and disclosure is limited to those with a demonstrated legitimate legal interest. There are a few broad categories of requestors who typically have a legitimate purpose that would allow us to disclose the data—for example, while we do receive requests that are unsolicited offers to purchase a domain, this is not a legitimate purpose for disclosure, as there are other ways to accomplish the same goal without necessitating disclosure of personal data.
The main tracked requestor types are “commercial litigation”, who need access to personal data in order to bring a legal claim of rights against the registrant; law enforcement, carrying out an investigation or in the course of their work; and security researchers, who use certain aggregate data to identify trends in digital abuse. In the chart below, “other” indicates all other requestors, including Certificate Authorities, resellers, and unaffiliated individuals.
Despite recent concerns raised by security researchers—who comprise the bulk of requests for access to our entire database—the significant majority of all disclosure requests continue to come from commercial litigation interests. We continue to work with security researchers to develop ways for them to access the information they need while protecting the personal data of our customers.
Since law enforcement historically had unrestricted access to the entire registration database, when a law enforcement officer from a jurisdiction we operate in indicates a need for data that would previously have been public, we do disclose the data to them. Law enforcement officers from other jurisdictions must still show legitimate purpose.
The attitude we have seen throughout this process indicates a culture of entitlement to private personal data and a frustration about the requestor’s obligation to prove that they have a legitimate basis to access personal registrant data.
In February 2019, the Registrar Stakeholder group published recommended minimum requirements for requesting non-public registration data. This valuable resource has been slow to gain traction in the community of requestors, though we continue to educate requestors individually. Our follow-ups, asking for information sufficient to show legitimate purpose, continue to be ignored, indicating to us that our responses to disclosure requests are unmonitored and that those disclosure requests themselves may be spurious or automated.
We work on an ongoing basis both with trade groups and individual requestors to emphasize the importance of balancing rights—the requestor’s right to personal data necessary to defend their legitimate rights against our customers’ right to privacy. Our work includes participation in the EPDP, an effort at ICANN to solidify the rules surrounding how disclosure of personal data should proceed.
We believe that we have developed a viable disclosure model—an opinion shared by trade groups who have indicated that the Tucows Tiered Access Compliance & Operations platform is an industry standard—and are happy to share additional details with other data custodians and with requestors to improve and harmonize the process across the industry. I will be at ICANN 66 in Montreal and available to discuss.