Last week, we shared updated statistics about data disclosure requests processed through our Tiered Access Compliance & Operations (TACO) platform. As promised in that post, we also want to connect that Tucows-specific data with the bigger picture. More specifically, we want to use our data to contextualize some of the figures ICANN provided in its recently-published SSAD Operational Design Assessment (ODA).
What is the SSAD ODA? And what’s an SSAD, for that matter?
ICANN recently published its SSAD ODA, a report which reviews the proposed Standardized System for Access and Disclosure (SSAD) of non-public gTLD registration data and provides information about the potential volume of use for this system, as well as the estimated costs to build and operate it.
The SSAD was recommended by the ICANN community through the multistakeholder policy development process (we wrote about it in our ICANN72 recap blog post) and may eventually be the “ICANN-official version” of TACO, run by a third party on ICANN’s behalf to provide a central request point for disclosure of previously-public registration data for all gTLDs across all registrars1.
Predicting demand is hard
It’s been difficult for ICANN and the broader community to estimate the SSAD request volume. There are reasons for this: no comparable industry-wide systems exist to serve as models, and the publication of current request volume is neither mandatory nor standardized.
In an attempt to address this gap in reliable volume data, the ODA collected information through surveys of data holders (registrars and registries) and data requestors. The results were interesting, if inconclusive.
And the survey says…
Contracted parties were invited to participate and report, as data holders, how many domains they have under management, the monthly average number of disclosure requests they received for 2019 and 2020, the total number of requests received, and into which categories the requestors fell (similar to how we share a breakdown of requests by requestor type). Participation was voluntary.
86 registrars and registries, out of thousands, responded, to indicate a collective total of 1699 requests per month (699/month for all registrars put together and 1000/month for all registries). For a full year, that would be a collective total of 20,388 requests; for registrars, that’s about 8,400 disclosure requests.
Potential requestors who are familiar with ICANN and aware of the survey provided data that is difficult to compare to the data holder responses, since the requestor responses were not combined (while the registrar and registry responses were) and the information provided in the ODA does not allow the reader to derive that total. The ODA reports that the majority of requestors sent fewer than 10 requests per month, while some claimed to have sent more than 2,000 disclosure requests per month (24,000 per year). It would be preferable to have a more directly comparable request rate and a broader sample.
Further, some groups anticipate submitting as many as 100,000 queries per month when the SSAD is fully operational. That’s a huge change, and raises the question: what is it that’s not happening now but will happen once there’s an SSAD? 100,000 queries per month is necessarily an automated request process, but the response process is necessarily more bespoke, and automated request processes always overwhelm human-review response processes.
So what did the ODA conclude?
The Operational Design Assessment provides a range of at least 100,000 and as many as 12,000,000 requests per year2.
This estimated range is stated to be derived from the data holder (registrar and registry) survey responses, data requestor (community) survey responses, inputs from the EPDP Phase 2 Working Group, and inputs from global law enforcement, who represent a subset of data requestors. This estimated range is notably different from the 20- to 24,000-per-year figure that was provided in the survey responses. Perhaps if we had the full picture of combined requestor rates, the logic of this estimate might become more clear.
Furthermore, these numbers do not match up with what Tucows has experienced with our Tucows-only SSAD, TACO.
Request volumes at Tucows and overall
Tucows receives an average of 1162 domain data disclosure requests per year (for the full details, look back at our TACO disclosure blog series). With our domains under management (DUM) of 19 million, that comes out to a request to registration ratio of 0.006%, or approximately one request for every 16,350 registered domains. If we consider that there are approximately 364.6 million domains registered in gTLDs3, and extrapolate the same request rate of 0.006%, that gives us about 22,300 disclosure requests per year—close to the total reported in survey responses by data holders and significantly lower than ICANN’s estimated lower limit of 100,000, which seems to be based solely on estimations by data requestors.
Where do we go from here?
Tucows decided several years back that we needed to build TACO to manage our own disclosure requests. We didn’t know then what the request volume would be, but we knew that we wanted something that would provide higher security and a better user experience than just sending emails back and forth. That decision also let us track these statistics, which we hope are valuable.
But is it worthwhile to build a similar, centralized system to manage disclosure requests for the data held by all registrars, especially in light of the ongoing requirement4 for registrars to process requests sent to them directly (instead of via the SSAD)? This is exactly the question that the Board has to wrangle as they consider the EPDP Phase 2 Recommendations, and it’s not an easy one—especially with the years-long history of work on and expectations around this issue.
Now that the user volumes have been approximated in the Operational Design Assessment, are they reliable enough to base a decision on? Other factors remain; in this post, we haven’t touched on the estimated costs of building and operating the SSAD but it’s worth examining whether the potential value that the SSAD would offer justifies those costs. There is also a significant question around the self-selection of respondents to the survey relied upon for data to draft the ODA. Our own experience also causes us to ask whether the hundreds of thousands of automated requests contemplated by some prospective users could all be deemed legitimate interest lookups, with no false positives.
We hope that sharing our disclosure request statistics and this review of the ODA help the ICANN Community contextualize the SSAD Operational Design Assessment and help inform the ICANN Board as they come to a decision that is in the best interests of the ICANN Community, the domain name system as a whole, and the broader Internet community.
ICANN73 starts today and runs through the week. We look forward to representing our reseller and registrant clients in the policy sphere, advocating for data-driven decisions that are in the best interests of the entire Internet community.
1Registrars and registry operators must also provide reasonable access to non-public gTLD registration data in response to requests sent to them directly; this will not end once the SSAD is fully operational.
2 Page 15, §1.1 General Assumptions
ICANN org assumes the following estimated user and system capacity levels as a basis for developing potential system design/capacity and costs for infrastructure and customer support operations:
- Between 25,000 and 3 million users.
- Between 100,000 and 12 million requests submitted annually.
3 https://www.verisign.com/en_US/domain-names/dnib/index.xhtml?section=executive-summary. Note that this includes ccTLDs, as does the Tucows TACO request rate, although the SSAD will be used for gTLDs only.
4 Temporary Specification §4 “Access to Non-Public Registration Data”, and the future Policy for gTLD Registration Data coming out of the Phase 1 EPDP.