GDPR Archives - Enom BlogEnom Blog |

Highlights from ICANN66 Montreal

November 25, 2019

GDPR, Industry Insight, News

Like

Views: 262
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
Tiered Access Data Disclosure Update

October 30, 2019

GDPR, Industry Insight

Like

Views: 509
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.

Data disclosure requests

We received 467 requests for data in the period from February to mid-October 2019 and 2617 requests total to date.
- 36% of requests received in this period resulted in registration data being disclosed to the requestor
- 45% were incomplete and the requestor did not respond to our followup for further information, so no data were disclosed
- 10% were denied, following a determination that the requestor did not have an adequate lawful basis
- 9% of requests resulted in “disclosure” of Whois Privacy information—that is, the same information already publicly available to a requestor
Disclosure request outcomes – Period 2

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:

Compared against our last report

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.

Disclosure request outcomes compared
- Increase in disclosure of non-public data from 25% to 35% and decrease in incomplete requests from 69% to 45%
  These changes are likely a result of our efforts to work with high-volume requestors to improve the quality of their requests
- Increase in denied requests from just under 5% to just over 11%
  We attribute this to small-volume and single requestors who recently discovered our Tiered Access portal and do not yet understand how to submit a request that allows us to adequately evaluate their legitimate rights against the privacy rights of the registrant. We will work to better describe the request process at the point of access.
- Increase in requests for data where the domain has Whois Privacy enabled from 3% to 9%
  When a domain uses one of our Whois Privacy services, we instruct requestors to submit legal process before disclosing the underlying personal data. We also, however, provide the privacy data, as the email address can be used to contact the registrant directly.
Duplicate requests

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.

Who wants data?

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.

Requests by Requestor Type

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.

Ongoing work

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.
Read More
The Evolution of the Domain Transfer Process

July 16, 2019

GDPR, Industry Insight

Like

Views: 879
ICANN’s Inter-Registrar Transfer Policy (IRTP) defines the procedures and rules for domain name transfers. When it was first introduced in 2004, the Policy was limited to inter-registrar transfers. Over the years, it has been revised by Policy Development Process (PDP) Working Groups and expanded to include governance of domain ownership transfers and a transfer dispute process. But the original rules for inter-registrar transfers remained mostly unchanged until May 2018, when the Temp Spec came into effect, modifying the process for a post-GDPR world where Whois data, which had long been the primary means of transfer verification, was no longer publicly available.

But the Temp Spec is temporary. So what’s the long-term plan?

The last few months have been interesting. First, we’re now in the gap between the Temp Spec’s expiration and any formal update to the Transfer Policy. ICANN’s Expedited Policy Development Process (EPDP) team has recommended continuing to use the process outlined in the Temp Spec in the interim. The EPDP team also made several recommendations as to how the Transfer Policy should be modified, which we can expect to see reflected in those updates.

Secondly, and much to the delight of domain policy enthusiasts (we exist!), the Transfer Policy came due for review by the GNSO Council. This is a standard practice for all ICANN Consensus policies: once a policy has been in place for a number of years, ICANN Staff compiles a report on its effects, which the GNSO Council uses to decide if the policy needs to be modified. This time around, the decision is a pretty clear one—the fact that we’re still following the Temp Spec method instead of the pre-GDPR transfer process points to the need to update the Policy. The Revised Inter-Registrar Transfer Policy Status Report is almost a formality, given the circumstances, but it includes some findings and related suggestions which will hopefully spark data-driven improvements to the Transfer Policy alongside the necessary GDPR-motivated updates.

Recent Transfer Policy changes

It’s been just over a year since Enom made necessary changes to our domain transfer process, and domains are still moving into and out of our platform smoothly. The biggest difference between our pre- and post-GDPR transfer process is that we are no longer able to use a “Form of Authorization” to confirm a domain owner’s transfer request. Instead, the authcode is used to verify that the request is valid and to initiate the inbound transfer within the registry system. We also now direct all transfer-related messaging to the registrant contact, since we no longer use an administrative contact for gTLDs.

These changes are in keeping with the Temp Spec and with what we anticipate to be the future of the Transfer Policy. They’re also aligned with the work being done by the registrar and registry joint TechOps team: developing a more streamlined, user-friendly transfer process that remains secure against domain theft.

Transfer Policy Status Report

The Report discusses the impact that the Temp Spec had on the inter-registrar transfer process, but its overall scope is broader, with a focus on three main goals that transfer-related PDP working groups have been considering since they first began exploring how to improve the transfer process in 2005:

– Portability

– Preventing abuse

– Providing information¹

The related central questions are:

– Can registrants easily transfer their domain names?

– Are processes standardized and efficient for registrars?¹

Takeaways from the Report

The Report shows ICANN Compliance has noted a steady decline in the rate of transfer-related Compliance tickets, suggesting that there are fewer overall concerns about the process, perhaps because domain owners have gained experience with it. However, ICANN’s Contractual Compliance metrics do show that transfer issues remain the second-most common reason for people to contact ICANN Compliance, following only Whois inaccuracy concerns. This suggests that there’s room for simplification and further education around the transfer process.

Another takeaway from the Report is that there was a significant spike in inter-registrar transfers in late 2016, likely caused by registrants changing their registrar just before the new Change of Registrant (COR) process and related lock came into effect. The Report also notes that immediately following the introduction of the COR lock requirement, ICANN Compliance began to receive a significant number of complaints about it.² This tracks with our own customer service data which indicates frustration and confusion about COR locks generally, and we will be interested to see how COR lock complaint numbers change over time.

As acknowledged in the Report, ICANN cannot directly track abusive transfers, as such situations are not reported consistently and cannot be independently verified.

ICANN’s suggestions for improvement

ICANN provides four suggestions for how to enhance the Transfer Policy moving forward, and we have some thoughts on each of them.

ICANN Suggestion 1: Require registrars to log when a domain owner obtains their transfer authorization code.²

Our perspective: Logging when an authorization code is retrieved by an end-user is a great idea, although implementation would be complicated. In many domain management interfaces, this code is visible by default on the domain name details page—there is no affirmative request to retrieve the code. So for many resellers and registrars, this requirement would involve significant development work, but that work is well worth doing.

ICANN Suggestion 2: Provide a process or options to remove the 60-day COR transfer lock to better serve registrants’ needs.²

Our perspective: The 60-day transfer lock has indeed proven to be a nuisance to both registrars and registrants, and there is some confusion as to whether and how it may be removed after it has been applied. We welcome clarification of the requirements but expect it to be a long process including consideration of whether alternative verification safeguards would become necessary.

ICANN Suggestion 3: Clarify the Transfer Policy section about when a transfer can be denied due to non-payment.²

Our perspective: This change would be a useful clarification. The section of the Policy where this is laid out can be confusing and difficult to parse, so making it more straightforward should help registrars more easily understand their rights and obligations in this regard.

ICANN Suggestion 4: Clarify if the Change of Registrant process is applicable when the real underlying contact info is updated on a domain with an active Whois Privacy service.²

Our perspective: This has been a topic of discussion between us and ICANN for quite some time. We believe that, if the underlying ownership data on a privacy-protected domain changes, that’s a Change of Registrant. If the purpose of the COR process is to protect domain owners against hijacking, this is just as important for domains using Whois privacy as it is for those without. ICANN, however, argues that privacy-protected domains are effectively owned by the privacy service, and so COR is not applicable. We want this issue to be clarified, but at this point it’s a question of contractual interpretation, which always needs to be approached with care.

We appreciate that ICANN’s Contractual Compliance team has provided these suggestions and, if the GNSO Council decides that the Transfer Policy needs to be updated, which certainly seems to be the case, we look forward to working with the multistakeholder community to review these and other possible changes to the Policy.

The future of the IRTP

We always advocate for processes that keep things simple for the registrant while maintaining a high level of security and accountability. Tucows (our parent company) staff are part of the TechOps team, participating in the group’s efforts towards streamlining the transfer process to make domain transfers easier for domain owners while maintaining security against unauthorized transfers. Our hope is that the transfer process in use today under the Temp Spec will simply be turned into official policy. After all, it’s been in effect for over a year with no demonstrable detriment to domain owners.

Our Support metrics show that domain transfers make up a significant portion of Support interactions, with most questions focused either on ccTLDs with special processes, or general transfer status requests (“When will my transfer be complete?”). We’re working on providing more information to our customers and resellers via our Knowledge Base, which we hope will help support you through this process.

The work that we do in the ICANN community is complex, as is its impact on registrants and resellers. It’s important to make sure the decisions we’re making are data-driven, rather than based on gut feelings that could turn out to be incorrect or only accurate for a small portion of users. This report is a great start; we’re glad to see critical review and engagement with the process and hope that the data provided in the Inter-Registrar Transfer Policy Status Report will be taken into consideration as part of future efforts towards updating the Transfer Policy.
1. ICANN Org. “Revised Inter-Registrar Transfer Policy Status Report .” Icann.org, ICANN, Mar. 2019, 4.
2. ICANN Org. “Revised Inter-Registrar Transfer Policy Status Report .” Icann.org, ICANN, Mar. 2019, 31-32.
Read More
ICANN Updates: EPDP Phase 1 Final Report

April 3, 2019

Announcement, GDPR, Industry Insight

1

Views: 1284
ICANN’s Expedited Policy Development Process (EPDP) team has issued their Phase 1 Final Report, marking the end of this stage of the project. The recommendations from this Report will become mandatory as of February 29, 2020, but contracted parties (registrars and registries) are permitted to implement them sooner. We’re still determining what specific changes we’ll need to make, but here’s an overview of the expected operational impacts that you should be aware of.

Changes to which data elements are required for ICANN-regulated TLDs

The EPDP team has recommended that:
- the Admin contact no longer be used at all
- the Tech contact be entirely optional and minimized: only name, phone number, and email address.
Needless to say, we are pleased with this outcome. For months now, Tucows has argued against the continued mandatory collection of Admin and Tech contact data, as it violates the GDPR’s requirement for data minimization. We still allow our reseller partners to pass along these data sets, but we only use them if the registry specifically requires them; if they do not, we simply hold these data on our platform and do not share them with the registry or data escrow provider.

How is OpenSRS handling this change?

OpenSRS will need to delete the Admin contacts we hold for existing domains, unless it’s used for a TLD where the registry contractually requires an Admin contact. Before we delete any data, however, we’ll make sure that the registries have made the required changes on their side. This will ensure that no registrations fail at the registry level due to “missing data.” An additional point to consider is that some domains registered under the 2009 RAA rules do not have any associated Registrant contact info, because at the time the domain ownership information was stored in the Admin contact fields. We’ll ensure that the domain owner information is up to date before removing any of the Admin contact data.

What should resellers do?

We’re doing our best to minimize any work these changes could create for resellers. Right now, our suggestion is to audit which fields you currently list as mandatory in any signup and domain update forms that you provide to your customer base. You may need to make some adjustments and be ready to implement them once the recommendations outlined above are officially required. We’ll provide plenty of notice before implementing changes on our end.

Changes to which data are displayed in the public Whois

The public Whois record will continue to be mostly redacted. However, the EPDP has recommended that registrars display the registrant state and country fields. We’ll soon begin work to reflect this change in the Whois data output for all domains under our accreditation.

Special case: publishing registrant Organization Whois data

In theory, the Organization field holds non-personal data, so displaying it in the public Whois should not be an issue. In reality, however, the Organization field frequently does contain personal data. For this reason, the EPDP team has recommended that the Organization field should be published, but only in a way that avoids the accidental exposure of personal data.

So, how will this be accomplished?

Registrars have been asked to contact all existing domain owners to confirm whether or not they want their Organization info published. If the registrant opts in, the registrar can then publish the Organization data. If the registrant does not opt into publication, or does not respond at all, the data in the Organization field can either be kept on file with the registrar but redacted from the public Whois, or deleted entirely.

What should resellers do?

For the long-term, the EPDP team recommends a more proactive approach where a “disclosure, disclaimer or confirmation” is presented to domain owners as they enter data into the Organization field. This notice would explain both options and give the registrant the opportunity to decide if they want this information published or not. If you collect data through an online sign-up form, you may want to consider how to incorporate this notice. We’re considering how to best implement this recommendation in a way that will be clear to domain owners and represent a minimal workload for our resellers.

Changes to which domain name contact data are shared

Much of the heavy lifting here has been done. As part of our initial GDPR implementation last year, we did a full audit of our TLD offerings to determine which data elements should be shared with the registry by default, as required under our contract with the registry, and which should only be shared if the domain owner gives their explicit consent to do so.

Over the next few months, we expect to receive updated contracts from all the ICANN-accredited registries we work with. Depending on what the various registry contracts include, we may make adjustments to our data processing framework. We could end up sharing more or less data by default for specific TLDs, and may stop the collection of some “optional” data elements.

What should resellers do?

These adjustments will not create any work for you, the reseller, but you should be aware that some of the TLD-specific data sharing settings will be adjusted. You can always refer to Tucows’ Data Use Information page for details about the legal basis for processing the data we collect for any TLD.

Next steps

Hopefully, this review has left you with a good sense of what to expect over the coming months. We’ll have more updates as the EPDP team begins Phase 2 (Standard Access Model, formally referred to as the “Unified Access Model”) and works through the Implementation Review Team (IRT) process, which will turn these Phase 1 recommendations into actual policy.
Read More
Enom’s Tiered Access Directory: eight months later

February 19, 2019

GDPR, Industry Insight

Like

Views: 1654
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.

Whois (pun intended) requesting registration data?

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.
Read More