Blockchain crisis looming for new gTLD next round

New gTLD applicants could face more of a threat from blockchain-based alternative naming systems next year than perhaps they first thought.

ICANN is coming under pressure to give additional rights to the owners of top-level strings that act like TLDs on blockchains, potentially adding friction — and six figures of extra costs — to applications for matching strings.

In the recently closed public comment period on the current draft Applicant Guidebook, two blockchain naming firms focused on the risk posed from name collisions should a gTLD get delegated that matches a blockchain TLD.

More importantly, ICANN’s influential Security and Stability Advisory Committee expressed the same views.

Alexander Urbelis, general counsel and CISO of Ethereum Name Service, said in his comments that many operators of alt-TLDs will apply for their DNS matches in next year’s application round, adding:

ICANN should consider that a new gTLD, for which an identical string already exists in an alternative name space, should be considered a compromised asset, and that delegating such gTLDs may subject ICANN, and applicants, to substantial liability. In addition to the technical issues posed by name collision, such delegations could also result in consumer confusion, difficulties with resolving queries (particularly as access to alternative names is increasingly integrated into mainstream web browsers), security risks, and broken authentication systems

Shifting gears, Urbelis then goes on to espouse the exactly opposite view to what you might expect from an operator of a blockchain naming system:

We urge ICANN to ensure that operators of strings in alternative names spaces are not given preferential treatment in the upcoming new gTLD application round, either deliberately or inadvertently. Such operators should not be rewarded for choosing to operate outside of ICANN governance and policies, particularly when the results of such preferential treatment could be so devastating for the stability of the DNS, as well as consumer trust in the new gTLD program and the DNS itself.

However, he concludes that alt-TLDs should be considered during the application process, specifically when ICANN’s evaluators conduct the String Similarity Evaluation.

we note that the string similarity evaluation does not appear to account for strings that may exist in alternative name spaces that are not under ICANN governance. Given the proliferation of such strings and alternative name spaces in recent years, ICANN should not ignore their existence by considering string similarity within only the ICANN-governed DNS, particularly due to the technical issues outlined above in connection with name collision.

Currently, this evaluation stage only looks at similarity to existing TLDs, some strings blocked by policy, and other applied-for strings.

If Urbelis’ advice were taken on board, an application for .clown, for example, could find itself ruled similar to alt-TLD .down, which is on the Handshake naming system and available at some registrars.

ENS runs .eth as a blockchain TLD. While the company claims over 1.6 million names registered there, .eth can never make it to the consensus DNS because ETH is the protected three-letter code for Ethiopia and therefore blocked by a Guidebook policy that is pretty much locked-in.

Unstoppable Domains, which markets dozens of alt-TLDs, focused on name collisions in its brief comment to ICANN, seeking extra clarity in how the collision assessors will decide whether a string is “high risk”.

The current AGB says evaluators will look at both quantitative data — measurements of traffic for non-existent TLDs to the root servers for example — and unspecified “qualitative” factors. Unstoppable’s head of operations Michael Campagnolo wrote:

If ICANN wants to help applicants to assess their risk pre-application submission, examples and sources of qualitative evidence should be described and made available to applicants prior to, and in a reasonable amount of time before the opening of the application window, similar to the quantitative information.

The subtext here, it appears, is that Unstoppable wants to know if non-DNS qualitative factors, such as the existence of an alt-TLD matching an applied-for string, will be taken into account.

That’s a good question, and as the AGB currently stands it appears to be up to the Technical Review Team that will conduct the name collision evaluation on each application.

The Name Collision Analysis Project working group, which came up with most of the current name collision rules, seemed to have mostly ignored alt-TLDs in its work due to difficulty and timing.

Unstoppable points out that applicants with strings deemed at high risk of collisions could incur extra fees of $100,000 to $150,000, on top of the $227,000 standard application fee, so the extra clarity on the rules could avoid applicants having to reach deeper into their pockets.

While ICANN is adept at ignoring or merely paying lip service to self-serving public comments filed by commercial entities, it is bound by its bylaws to take the advice of its Advisory Committees seriously.

Comments filed by the 17-member SSAC will carry more weight, and SSAC is warning that collisions between DNS and non-DNS naming systems could raise security risks, promote instability, and create user confusion.

SSAC’s SAC130 (pdf) — formal Advisory Committee advice — makes four recommendations related to name collisions. One is:

The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.

If ICANN adopts the SSAC recommendations, it seems the TRT will be encumbered with the heavy burden of figuring out how, when and why an alt-TLD and an applied-for gTLD create risks so unacceptable that the applied-for string should be blocked.

Another question that has been raised in recent weeks is whether alt-TLD operators should be able to use mechanisms such as Community Priority Evaluation and Community Objection to secure their TLDs or disrupt other applications.

Could Unstoppable, for example, claim that its cohort of .wallet alt-TLD registrants constitute a protected “community” and thus get a priority approval?

The company could certainly try, but experts in the policy-making community and ICANN staff seem to think the point-based CPE mechanism is designed in such a way to make such a claim incredibly difficult to back up.

ICANN will consider all of the public comments over the coming weeks and months before making changes, if any, to the AGB.

There are hundreds of thousands of alt-TLDs out there — over 6,000 are even carried by a handful of ICANN-accredited registrars — but it’s not clear how many are actually used.

With that in mind, should ICANN offer additional protections to blockchain-based alt-TLDs, many new gTLD applicants would face the very real risk of additional friction and huge extra costs.

My brain explodes trying to understand MMX’s new blockchain deal for .luxe

Minds + Machines has abandoned plans to launch .luxe as a gTLD for luxury goods and instead made a deal to sell it as an address for cryptocurrency wallets.
If you thought it was a silly move marketing .ws as meaning “web site” or .pw as “professional web”, you’re probably not going to like the backronym MMX has in mind for .luxe:
“Lets U Xchange Easily”.
Really.
Tenuous though that marketing angle may be, the concept behind the newly repurposed TLD is actually quite interesting and probably rises to the level of “innovation”.
MMX has inked a deal with Ethereum Name Service, an offshoot of Ethereum, an open-source blockchain project.
Ethereum is largely used as a cryptocurrency, like BitCoin, enabling people to transfer monetary value to each other using “wallet” applications, though it has other uses.
I’m just going to come right out and say it: I don’t understand how any of this blockchain stuff works.
I’ve just spent an hour on the phone with MMX CEO Toby Hall and I’m still not 100% clear how it integrates with domains and whether the .luxe value proposition is really, really cool or really, really stupid.
I’ll just tell you what I do understand.
Currently, when two Ethereum users want to transfer currency between each other, the sender needs to know the recipient’s wallet address. This is a 40-character nonsense hash that makes an IPv6 address look memorable.
It obviously would be a lot better if each user had a human-readable, memorable address, a bit like a domain name.
Ethereum developers thought so, so they created the Ethereum Name Service. ENS allowed people to use “.eth” domains, like john.eth, as a shorthand address for their wallets. I don’t know how it works, but I know .eth isn’t an official TLD in the authoritative root.
About 300,000 people acquired .eth domains via some kind of cryptographic auction process that I also don’t understand. Let’s just call it magic.
Under the deal with MMX, some 26 million Ethereum wallet owners will be able use .luxe domains, dumping their .eth names if they have them.
The names will be sold through registrars as usual, at a price Hall said will be a little bit more than .com.
Registrants will then be able to associate their domains with their 40-character wallet addresses, so they can say “Send $50 to john.luxe” and other crypto-nerds will instantly know what to do. Ethereum wallets will apparently support this at launch.
Registrars will need to do a bit of implementation work, however. Hall said there’ll be an API that allows them to associate their customers’ domains with their wallets, and to disassociate the two should the domain be transferred to somebody else.
This is not available yet, but it will be before general availability this November, he said.
What this API does is beyond my comprehension.
What I do understand is that at no point is DNS used. I thought perhaps the 40-char hash was being stored in the TXT field of a DNS record, but no, that’s not it. It’s being stored cryptographically in the blockchain. Or something. Let’s just say it’s magic, again.
The value of having a memorable address for a wallet is very clear to me, but what’s not at all clear to me is why, if DNS is not being queried at any part of the Ethereum transaction, this memorable address has to be a domain name.
You don’t need a domain name to find somebody on Twitter, or Instagram, or Grindr. You just need a user name. Why that model couldn’t apply here is beyond me.
Hall offered that people are familiar with domain names, adding that merchants could use the same .luxe domain for their web site as they use for their Ethereum wallets, which makes sense from a branding perspective.
The drawback, of course, is that you’d have to have your web site on a .luxe domain.
The launch plan for .luxe sees sunrise begin August 9, running for 60 days. Then there’ll be two weeks for .eth name holders to claim their matching .luxe names. Then an early access period. GA starts November 6.
While it should be obvious by now I don’t fully “get” what’s going on here, it strikes me as a hell of a lot more interesting way to use .luxe than its originally intended purpose as a venue for luxury goods and services.
Let’s face it, depending on pricing it would have turned out either as a haven for spammers, a barely-breaking-even also-ran, or a profitable business propped up by a couple thousand trademark owners paying five grand a year on unused defensive regs.