Earlier this morning, our parent company, Tucows Inc. released some exciting news: we’ve officially acquired Ascio Technologies, another wholesale domain registrar that, like Enom, is dedicated to supporting a growing reseller network.
Enom and our sister brands, OpenSRS and EPAG, are thrilled to welcome Ascio to the Tucows family. The venture further solidifies Tucows’ position as the leading global wholesale domain registrar and is a natural step in expanding what we believe to be the best reseller-focused domains business in the industry.
The Ascio acquisition not only adds 1.8 million domains under management, but a thriving network of 500 resellers that fits squarely within Tucows’ core customer profile: ISPs, web hosting companies, and website builders. The move to acquire Ascio makes sense precisely because its business is so complementary to Enom’s. It will support Tucows’ efforts to scale and leverage synergies, while remaining focused on serving a specific customer base and investing in a platform and services that benefit resellers across all Tucows wholesale brands, Enom included.
Moving forward, it will be business as usual for all brands, Ascio included, as Tucows works to leverage the strengths of all brands to improve the business as a whole. Tucows has always been reseller-focused — it’s in our DNA — and this acquisition, much like that of Enom itself in 2017, is a testament to Tucows’ continued commitment to, and investment in, its wholesale domains business.
Tucows’ Tiered Access Compliance & Operations portal (which we commonly refer to as a “Tiered Access Directory” or “gated Whois”) launched at the end of May 2018. With its launch, our public Whois “went dark.” From that date forward, all personal registrant data has been redacted from the public Whois by default, and made accessible only via the gated Whois.
Most people saw this is a good thing—registrants deserve to have their personal information protected. A few argued that the change would impede efforts to identify and take legal action against cyber criminals and trademark or copyright violations. We’ve always advocated that a balance could be reached.
Now, eight months into our Tiered Access program, we’re looking back at the data access requests to see what the numbers reveal about how the system is working out.
The Big Picture
We have received more than 2100 data access requests since our Tiered Access system started last May, and of these requests:
Just over 25% resulted in applicable registration data being provided to the requestor
Only a small percentage of requests get denied: 4.6%, as of 13 February 2019
13% of all requests are duplicates
65% of all requests came on behalf of a single requestor; only 21% of these requests resulted in the provision of data, as the majority did not provide sufficient legitimate purpose, nor did the requestor respond to our request for more information
Perhaps surprisingly, 70% of data access requests are not fulfilled because the requestor did not respond to Tucows’ requests for additional information (including assurances regarding who the requestor was, how the data would be handled, and why the data were needed). For example, some requests failed to include the requestor’s own identity, their legal basis to access the information, or even which specific domain name they’re asking about. In all cases, we reply promptly to ask for the missing information but, so far, for 70% of the requests we have received, that information was never provided.
The vast majority of requests—just over 90%—come from commercial litigation interests and relate to a suspected intellectual property (copyright or trademark) infringement. The remaining 10% are spread across other types of requestors, including law enforcement, security researchers, registries, the registrants themselves, and third-parties interested in purchasing specific domains.
92% of requests were made by commercial litigation interests, mostly trademark interests (85%) but also some copyright (4%: fewer than 100 total copyright-related requests)
Within the “trademark” category, 76% of all requests are on behalf of a single entity. The next highest entity requestor accounts for only 7% of trademark requests.
Law enforcement requests account for less than 2% of all requests—this does not include warrants, as the intent of a gated Whois is to provide data which what had previously been publicly available; requests for additional information still require a warrant or subpoena
Fewer than 1% were requests from security researchers, one of the major groups who have expressed concerned about the loss of public Whois
Interestingly, we have had only a single request that appears to be related to illegitimate pharmaceuticals being sold online and zero requests related to terrorism. These are categories that we were led to believe we would receive a high volume of requests for.
Requests from ICANN Compliance
There are also a significant number of requests for personal data that we’ve excluded from the stats and total number referenced above: those made by ICANN Compliance. These were not included because, although ICANN Compliance has requested personal data from us in relation to complaints filed by third-parties, they have not yet demonstrated a legitimate purpose for processing that data. Since the introduction of our Tiered Access system in May, no Tucows-owned registrar has shared any personal registration data with ICANN Compliance; we have discovered that we can successfully help ICANN’s compliance investigation of registrant or third-party requests without disclosing any personal data to ICANN. We are always looking for innovative solutions that allow us all to rethink the traditional way of doing things.
What do these numbers tell us?
We see significant spikes of requests surrounding ICANN meetings:
These spikes and the prevalence of certain requestors strongly suggests an attempt to skew the data to create an argument against the loss of public Whois data. Regardless of that attempt, however, what we clearly see is a system working the way that it should: when sufficient legitimate interest is shown and assurances regarding the handling of data are made, the process of providing personal data is smooth.
The sky didn’t fall. The dire predictions that commercial litigation, law enforcement, and security research interests made prior to our GDPR implementation did not come to pass. Our Tiered Access team is able to respond to requests in a timely manner and to provide access to registration data when the requestor can demonstrate their legal basis for access. The system works well.
The future of Tiered Access
There remains much to be done regarding Tiered Access. The “Technical Study Group on Access to Non-Public Registration Data”, a recently-created group of ten members hand-picked by the ICANN Board, is engaged in technical work on Tiered Access, although not the thornier legal or policy challenges. There is a lot of work happening in the ICANN Community as well. The Expedited Policy Development Process (EPDP) Team work has not yet been finalized; a Registrar Constituency document outlining guidelines for requesting registrant data will be published soon; and there are ongoing informal discussions among registrars and other interests intended to streamline access and make it less difficult and confusing.
The EPDP’s Phase 1 Final Report, which will focus on data collection and, later, its Phase 2—which will be focused on a Standard Access Model—may affect what we collect and disclose in the future. We won’t know what the Tiered Access system will look like long-term until there is clarity around these items, which are still very much up in the air. That said, we’re in a position to adapt our system to meet the ICANN Community’s final requirements. In the meantime, we’ve created a solution that achieves an effective balance between protecting registrants’ right to privacy and providing legitimate third-parties timely access to the data they’re legally entitled to.
As we’ve said before, while it marks a big change in the domain space, the introduction of our Tiered Access Compliance and Operations system is a move in the right direction, in step with evolving privacy laws across the globe. Tucows remains committed to protecting registrant privacy and applauds the efforts underway by various governments to establish privacy-by-default standards.
If you sell .EU domains to UK residents, you may already be aware of an announcement made by the European Commission last March on the future of .EU domains registered to UK organizations and individuals. In short, once the UK officially withdraws from the European Union, individuals with an address in the UK and Gibraltar, and UK companies without a presence elsewhere in the EU, will no longer meet the eligibility requirements.
Much to the disappointment of the domain community, the European Commission has decided against “grandfathering” the 300,000 .EU domains already registered with a GI or GB country code, an action which would have allowed existing owners to renew their domains indefinitely, despite the country code no longer being eligible. We would have appreciated a more creative solution than existing registrants simply losing their right to ownership. Regardless, it’s time to start preparing affected registrants for this change.
No one knows how Brexit will proceed, but in late January 2019, EURid, the .EU registry, released details on how it would approach this transition. There are three possible scenarios:
Hard Brexit: The UK leaves the EU with no deal on March 30, 2019.
Soft Brexit: The UK leaves the EU on or after December 31, 2020, following a planned transitional period.
Soft Brexit with .EU Provisions: The UK leaves the EU with a planned transitional period, and the deal includes provisions for .EU domains.
Below you’ll find what each of these three scenarios would mean for .EU registrants based in the .UK.
Scenario 1 — In the event of a “hard Brexit”
If the UK leaves the EU on March 30, 2019, without having reached a withdrawal agreement, here’s what will happen. You can also jump to the summary table below.
Starting at March 30, 2019, 00:00 CET (March 29, 2019, 19:00 EDT), EURid will immediately stop allowing new registrations of .EU domains using a GB (Great Britain) or GI (Gibraltar) country code. For existing domains, EURid will no longer allow registrant transfers to GB or GI residents.
In March 2019, EURid will contact existing registrants who have listed a postal address with a GB or GI country code, giving them “the possibility to demonstrate their compliance with the .eu regulatory framework by updating their contact data.” For organizations, this would involve indicating a legally established entity in one of the eligible EU27 or EEA Member States. For individuals, this would involve updating their residence to a physical address located in one of the EU27 or EEA Member States.
The registrant may also choose to transfer the domain name to an EU resident.
Between March 30, 2019, at 00:00 CET (March 29, 2019, 19:00 EDT / 21:00 GMT time), when registrants are officially notified, and May 30, 2019, at 00:00 CEST (May 29, 2019, at 18:00 EDT), the registry will lock the impacted domains to prevent the following actions:
Registrant transfer (Ownership Change) to a non-EU registrant (Only Ownership Changes to an EU registrant will be permitted)
Auto-renew (ineligible domains will automatically enter Withdrawn status)
During this two-month window, UK registrants who wish to keep their domain active must update their contact info to satisfy the eligibility requirements or transfer the domain to an EU resident.
On May 30, 2019, at 00:00 CEST (May 29, 2019, at 18:00 EDT), any registrant who has failed to demonstrate their eligibility will have their domain placed in Withdrawn status — the domain won’t resolve (and any linked services will become inactive), but the registration record will remain on file with the registry. At this point, the registrant is still able to reactivate their domain by updating their registration data to satisfy the eligibility requirements, thereby removing the Withdrawn status.
On March 30, 2020, at 00:00 CET (March 29, 2020, 19:00 EDT), all ineligible domains in Withdrawn status will be deleted and made available for registration.
We know this is quite a lot to keep in mind, so here is a summary of the “hard Brexit” key dates and events:
Domains belonging to EU citizens living in the UK
There are, no doubt, many EU27 citizens who reside in the UK and own a .EU domain name. These registrants, though still EU citizens post-Brexit, would become ineligible on March 30, 2019, as the current EURid policy determines eligibility based on the physical address of the registrant.
However, the EU Commission has announced policy changes which would allow EU citizens based in the UK to regain eligibility. The registrants would, therefore, lose their eligibility upon the UK’s withdrawal from the EU on March 30 2019, but would likely become eligible again once the new .EU regulatory framework comes into force later this year. Unfortunately, it’s not yet clear how long of a gap there will be between the UK’s withdrawal from the EU and the implementation of updated .EU policy.
Scenario 2 — In the event of a “soft Brexit”
If the UK were to leave the EU on or after 31st December 2020, following a planned transitional period, EURid’s plan would be similar to the “hard Brexit” plan, but with an extended timeline. Here’s what would happen (summary table below):
In December 2020, EURid will contact existing registrants who have listed a postal address have with a GB or GI country code, giving them “the possibility to demonstrate their compliance with the .eu regulatory framework by updating their contact data.” Once again, for organizations, this would involve indicating a legally established entity in one of the eligible EU27 or EEA Member States. For individuals, this would involve updating their residence to a physical address located in one of the EU27 or EEA Member States.
The registrant could also choose to transfer the domain name to an EU resident.
Between January 1, 2021, at 00:00 CET (December 31, 2020, at 18:00 EST), when registrants receive their final notice, and March 2, 2021, at 00:00 CET (March 1, 2021, at 18:00 EST)the registry will lock the impacted domains to prevent the following actions:
Registrant transfer (Ownership Change) to a non-EU registrant (Only Ownership Changes to an EU registrant will be permitted)
Auto-renew (ineligible domains will automatically enter Withdrawn status)
During this two-month window, registrants who wish to keep their domain active must update their contact info to satisfy the eligibility requirements or transfer the domain to an EU resident.
On March 2, 2021, at 00:00 CET (March 1, 2021, at 18:00 EST), any registrant who has failed to demonstrate their eligibility will have their domain placed in Withdrawn status — the domain won’t resolve (and any linked services will become inactive), but the registration record will remain on file with the registry. At this point, the registrant is still able to reactivate their domain by updating their registration data to satisfy the eligibility requirements, thereby removing the Withdrawn status.
On 1 January 2022, at 0:00 CET (December 31, 2021, at 18:00 EST), all ineligible domains in Withdrawn status will be deleted and made available for registration.
Here is a summary of the “soft Brexit” key dates and events:
Domains belonging to .EU citizens living in the UK
As mentioned above, an updated .EU regulatory framework that will allow for .EU domains to be registered by EU citizens living in the UK will come into effect in 2019. Therefore, EU citizens living in GB or GI would NOT become ineligible as a result of a “soft Brexit.” Depending on how EURid implements the new policy directive from the EU Commission, EU citizens living outside of the EU could potentially be required to actively validate their eligibility in order to maintain their registration.
Scenario 3 — If provisions are made for .EU domains
In the event of a “soft Brexit” where the deal includes provisions for .EU domains, EURid would forgo the transition plans outlined in the scenarios above and instead adopt whatever transition plan the provisions call for.
Preparing for this change
The OpenSRS team is exploring how best to approach this situation and find solutions to minimize the impact on registrants. If you sell .EU domains we strongly encourage you to sign up for our.EU-Brexit Updates, an email series we will use to share developments, recommendations for resellers, and information about our own action plan, including how resellers can identify domains in Withdrawn status via the Control Panel and API.
Have you already given this situation some thought? If you’d like to share your approach, ask questions about this change, or provide feedback, please get in touch.
In the meantime, we have a few recommendations for our affected reseller partners.
1. Consider restricting multi-year renewals and registrations for .EU domains. This will help avoid situations where a UK customer pays a sizable renewal fee, only to lose their .EU domain a few months later.
2. Consider displaying a warning to registrants during the registration process It’s important that before registering a .EU domain, your UK-based customers are made aware of the impending change to the domain’s eligibility requirements. We recommend displaying a warning to customers attempting to register a .EU domain using a GB or GI address.
3. Keep in mind that the registry could contact your customers as early as March 23, 2019. We recommend preparing to contact your affected customers before March 23, 2019, so that, in the event of a hard Brexit, the notice from the registry doesn’t come as a surprise. Over the next couple of weeks, we’ll provide more information that will help to inform your communications.
3. Advise those registrants who can to update their information to meet the eligibility requirements as soon as possible. This will ensure their domain(s) does not fall into Withdrawn status and become inactive.
Once again, if you sell .EU domains, we highly encourage you to subscribe to our .EU-Brexit Updates series to stay up-to-date as things develop.
Although it may seem that the GDPR is the only thing that matters in the domain industry right now, it wasn’t the sole focus of ICANN 63, and we don’t want to lose sight of the other valuable work that came out of the conference.
Tucows is an active participant in the ICANN community: the Chair of the Registrar Stakeholder Group (RrSG) is our Analytics and Policy Director; some of our staff are members of the RDAP Pilot Project and PPSAI Working Group, and observers of the EPDP; and Tucows representatives collaborate with the RrSG’s Compliance and TechOps sub-teams to help develop and implement policies and processes that will benefit our customers and the community at large.
Privacy and Proxy Service Accreditation
One significant work track within the ICANN community is around accreditation for providers of Privacy and Proxy services. Right now, any registrar can offer a Privacy or Proxy (“P/P”) service — our version is called Whois Contact Privacy — for domains registered with them. However, one of the requirements in the 2013 RAA is that if ICANN adopts a policy establishing accreditation for P/P services, registrars must comply with that policy and become accredited to continue providing those services. Such a policy does not yet exist, but work towards one has been underway ever since that 2013 RAA requirement came into effect.
An Implementation Review Team (IRT) was then convened in January 2016, in order to “assist [ICANN Org.] staff in developing the implementation details for the Privacy and Proxy Services Accreditation Program, to ensure the implementation conforms to the intent of the Final Recommendations” (reference). In the two and a half years that followed, the PPSAI IRT worked hard to transform the recommendations into actual accreditation agreement language.
One significant part of their implementation work was focused on the question of when underlying registration data is to be revealed. Another was related to the cost of accreditation; even now there remains unresolved conflict between the IRT members and ICANN staff resulting from ICANN setting the P/P accreditation fees extremely high — on par with ICANN’s actual registrar accreditation fee — without being able to justify this price-point.
We said this post would be focused on the non-GDPR meetings at ICANN 63, but the effects of that data privacy regulation are so far-reaching, it’s hard to avoid. Because of the GDPR, the ICANN community is now working to standardize how access to non-public Whois data will be provided. As a result, the PPSAI IRT work will be “slowed down” until the EPDP is complete and the full landscape of the GDPR’s effects on our Registrar Accreditation Agreement obligations is understood.
This is important for our resellers and registrants, because once the IRT resumes regular work and the Privacy/Proxy Accreditation Agreement is finalized, we’ll need to sign on and pass the requirements along to our resellers. The significant area of concern here is the fees that we mentioned previously, and so when the IRT reconvenes we’ll be pushing to understand the justification for those fees as well as reduce them as much as possible.
RDAP, the Registration Directory Access Protocol, is the technical successor to Whois. As we’ve mentioned previously, Tucows is part of the RDAP Pilot Working Group, which met several times at ICANN63 in Barcelona to supplement the team’s regular weekly online meetings.
Since we’ve participated in the pilot project and already implemented an RDAP service (Tiered Access) for Tucows domain registration data, we’re a step ahead of many other registrars, who still operate solely on the Whois protocol. Using RDAP as the technical back-end allows us to define user access options at a very granular level. We can restrict access by the number of domains a user can query in a given time period, the data elements returned in response, and even which specific domains can be queried. We can also set the specific duration for which a user’s account remains active. These options were not available on the old Whois protocol, which would always return the same results to any query.
Participating in the RDAP Pilot has given us the unique opportunity to provide input towards the RDAP “profile,” which tells registrars and registries what an RDAP domain lookup response needs to look like from a technical perspective. Put another way, the RDAP profile is the technical underpinning that supports ICANN’s registration data policy requirements. We’re working to make sure the final required profile is aligned with what we believe to be legally compliant and appropriate, in accordance with ICANN policy. The draft profile has been released and the comment period is now complete. Currently, the RDAP team is analyzing the comments and considering modifications to the final RDAP profile.
The other big piece of work remaining for the RDAP team is determining how users will authenticate. There are two main options: OAuth, or using an SSL Certificate to identify the user, although more consideration may determine that the ability to choose one or the other depending on the use case might make the most sense. Whatever option the Working Group settles on, it’s important to keep in mind that this team will not determine who gets access to what data, and when — that’s not within the RDAP Working Group’s scope. Instead, this group is focused on creating the technical mechanisms to facilitate that access, which will need to coordinate with the work from the EPDP and whatever Unified Access Model is ultimately adopted.
The TechOps team is working on a proposed new transfer process, which is quite similar to what registrars are already doing post-GDPR. The general goal is to make transfers happen immediately instead of after the current 5-day waiting period, while also protecting the registrant with heightened security requirements. There are some very interesting open questions, such as: Who creates and controls the auth code, should it be the registrar or the registry? Should an auth code have a TTL, essentially a “use-by date”, or should it remain valid indefinitely? In what other ways can the strength and security of an auth code be improved? The team is also considering what an effective emergency transfer reversal process might look like.
In Barcelona, the group present at the TechOps meeting split into smaller work groups, each taking a section of the proposed new process to examine at a very granular level. I led the group working on how the losing registrar might verify the request to get the auth code. The proposal we reviewed allowed a third party other than the registrant to obtain the auth code, such as (for example) when an account holder wants to get the auth code for a domain that’s in their account but registered in someone else’s name.
Our team added in requirements to ensure that the requestor is verified sufficiently to prevent unauthorized transfers; we also opted to keep the notification to the registrant mandatory, ensuring they aren’t surprised by the transfer request and have a chance to contact their registrar if the request was improper. Our group agreed that even when bolstered with increased requirements around verification and notification to reduce the risk of domain hijacking, the option to allow someone other than the registrant to obtain the auth code should only be included in formal policy if there is an expedited transfer reversal process to go with it.
There was a shared dedication among participants in this session to ensuring that any new transfer policy is balanced — it needs to be a streamlined process that’s easy for the registrant to use, while also being secure enough to protect against domain theft.
ICANN Org has now put out a Policy Status Report and has solicited public comments on the transfer policy. Members of the TechOps group have submitted a comment, which will be included in the ICANN Staff Report that is due out on February 1 2019. We don’t yet know exactly how the changes to the transfer policy will unfold, but there’s certainly work to be done on how domain transfers are handled, and we’ll be a part of that work, representing our clients’ best interests.
We’ll keep our resellers posted as the various policy work we’ve discussed today progresses. Overall, we’re pleased with the level of cooperation we’re seeing among all those involved, and encouraged that our registrant-centric approach is being echoed by others working in policy development.
This is the second post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. Before diving in, we recommend taking a look at our recap of the EPDP team’s work leading up to and during the conference. You can watch this space for the final post in the series, which will cover ICANN work unrelated to the GDPR.
ICANN’s Temporary Specification requires registrars to provide a means for third parties (such as law enforcement agencies) to access a registrant’s personal data when there is a legitimate legal reason to do so. Enom met this requiring by introducing our Tiered Access directory, but we remain hopeful that an industry-wide solution will be developed.
Over the last several months, the idea of a unified access model, or “UAM,” has been floating around the ICANN community. With a UAM, the process for accessing registration data would be standardized, with a defined set of eligible users and rules for what data they may obtain. This could be handled at the credentialing level, with registrars and registries required to respect the accreditations provided by a central governing body, or it could go as far as to require that all Whois data is held by and accessed through ICANN itself.
The advantage to a unified model is that parties with legitimate reasons to access registration data could do so in a streamlined manner, and registrars would (in theory) be able to trust the credentials of any user working within this model.
This contrasts the current reality: today, in order to access registration data for domains, third parties must each independently obtain credentials from the appropriate registrar or registry. There is no central authority that we can trust to accredit eligible users, and no single source that a third party can work with to obtain registration data for domains registered with different providers.
Two ICANN stakeholder groups, the Intellectual Property Constituency (IPC) and the Business Constituency (BC), have been pushing the EPDP team to develop a UAM, as they are concerned that the current decentralized situation is confusing to users, wastes time, and ultimately hinders their constituents’ ability to protect and assert their legal rights. For example, let’s use the case of a commercial litigator trying to send a cease and desist letter for an instance of trademark violation. The IPC and BC groups claim that the attorney needs to start by using the Whois record to determine who owns the offending domain name, but navigating and managing credentials for various registrar portals is a nuisance.
The wider ICANN Community acknowledges the benefits of a unified access model, but also raised significant concerns about implementation. Holding all registrant personal data in a central repository creates a single point of failure for data breaches — if someone gains access to that central source, they can access the contact data for every gTLD domain. This may also put ICANN themselves at risk of liability if such a breach were to occur.
Even if the data itself were decentralized, remaining held by each individual registrar, we’re left with concerns about having a single organization (such as ICANN) control accreditation. Registrars and registries are legally accountable for how and why the data they hold is shared, but in using a UAM, they’d be relying on the credentialing body to require demonstration of legal basis for accessing registration data (hopefully every time data is requested for a given domain, since the legal basis must be specific to each piece of data). And, as illustrated by examples like our own litigation with ICANN over the collection of technical contact data, what is acceptable as a legitimate legal basis can be somewhat subjective. If ICANN’s new contractual requirements require participation in a UAM, registrars and registries may be obligated to provide registration data to third parties in cases where they are not satisfied that a sufficient legal basis has been demonstrated. This is similar to the difficult balancing of more general GDPR requirements against ICANN contractual obligations — the registrar or registry is put in the difficult position of needing to choose between breaching their contract or potentially violating the law.
What happens next?
One of the core requirements in the EPDP team charter is to create a system for providing access to registration data. There are “gating questions” laid out in the charter, which will allow the team to “establish a baseline set of data that is collected for each domain name registration,” determine who should hold this data, and how it can be shared and processed. These gating questions must be answered before the EPDP team can consider the question of how third-party access to data will be granted. So until recently, discussions about the “how” had been pushed down the road when they came up during EPDP meetings. But now the EPDP Initial Report is out and, unfortunately, there is no formal consensus on the answers to the gating questions. In light of this, some members of the team have resumed pushing to discuss access as soon as possible, specifically before the Final Report is issued.
The EPDP team will be meeting in person at the end of January 2019, and we’re eagerly watching to see what happens there, as well as how they respond to the feedback that we and other members of the ICANN community provide in response to their Initial Report.And as this post went to “press,” ICANN announced the assembly of a ten-man “Technical Study Group on Access to Non-Public Registration Data” (Domain Incite has a solid summary of this development). It’s unclear how ICANN selected the members of this team or how their work will fit into or align with the current technical work and in-progress policy development process. Both of these unknowns are extremely worrying. This type of group is unprecedented and their remit and charter are currently opaque. We remain committed to the multi-stakeholder process and will continue to hold ICANN Org accountable to it.