ICANN 79: anonymous trolls and undercover lawyers

Transparency, an ICANN watchword since day one, was a noticeable thematic undercurrent at the community’s 79th public meeting in Puerto Rico last week.

The problem of lawyers representing unnamed clients in policy-making groups was raised in several fora, while another section of the community seems to have separately been infiltrated by the same kind of anonymous trolls that plagued ICANN during its infancy.

Governments were especially keen that the GNSO clean house by tightening up its disclosure rules, following an abortive attempt at reform at the Hamburg meeting last October, and they found allies in the Contracted Parties House, which had killed off the reform after deciding it did not go far enough.

Under the current GNSO rules of engagement, everyone who volunteers to participate in policy-making has to file a Statement of Interest, disclosing information such as their employer, community group affiliations, and so on. Among other things, volunteers are asked:

Do you believe you are participating in the GNSO policy process as a representative of any individual or entity, whether paid or unpaid? Please answer “yes” or “no.” If the answer is “yes,” please provide the name of the represented individual or entity. If professional ethical obligations prevent you from disclosing this information, please so state.

The exemption is believed to be designed primarily for American lawyers in private practice, some of whom say they may sometimes be ethically prevented from disclosing the identity of their clients.

But this creates problems for community volunteers, and for the rest of us.

For policy-makers: sometimes, in a working group, you won’t know who you’re really arguing with. The guy opposite, in the expensive suit who keeps inexplicably rubbing her nostrils, could be a mouthpiece for almost any corporation, industry association, or government.

For the rest of us: we don’t know who is really making the policies that impact how domain names are sold, managed, and regulated. Those may seem trivial issues in the grand scheme of things, but they touch on issues such as free speech, data privacy, and how much money comes out of your pocket when you buy a domain.

An attempt last year by the GNSO to update its SOI rules was shot down by the Contracted Parties House because the proposed changes kept the lawyer disclosure exemption.

The Non-Contracted Parties House gave the changes their unanimous approval.

The GNSO Council Committee for Overseeing and Implementing Continuous Improvement, which came up with the changes, looked at 351 SOIs from two recent large policy working groups and found that “a maximum of 0.03% members were making use of the exemption.”

I think that means just one person.

But the scale of the issue is irrelevant compared to the principle, according to some.

Swiss GAC rep Jorge Cancio noted during a session with the CPH last week, “even if there’s a very small number of cases where people use some exceptions for not explaining whom they are working for, even if it’s just 10 people out of 1,000 participants, this already tarnishes the whole of the system”.

Registries Stakeholder Group chair Sam Demetriou concurred: “We believe in and we are strong supporters of the multistakeholder model, but in order for a model to be multistakeholder, you need to know who those stakeholders are. It is inherent in the entire system and the definition.”

The GAC’s position is that everyone participating in policy-making needs to be up-front about their interests, in accordance with global norms. In a session with the GNSO Council, UK rep and vice-chair Nigel Hickson urged the GNSO to sort out the SOI issue before ICANN meets again, set for Kigali this June, because ministers will be present, wanting answers.

Separately at ICANN 79 last week, there was a parallel debate going on about whether a group affiliated with ICANN should force its members to even file SOIs at all.

The Universal Acceptance Steering Group isn’t technically an ICANN body — a Supporting Organization or Advisory Committee — but it is funded and supported by ICANN and carries out ICANN work. It’s been around since 2015 but so far hasn’t required members to submit SOIs.

As anyone who attended or remotely lurked on the ICANN 79 Public Forum last week will know, the UASG came in for a lot of criticism, mostly from remote participants, some of whom have managed to pull off the near-miraculously impressive achievement of having a non-existent Google footprint.

I’m not of course suggesting that some of the people in the Public Forum chat room were trolls using pseudonyms, but… actually, yes, that is what I am suggesting.

These participants had beef with the UASG for imposing a new strict SOI requirement — rules coming into force right now give participants a few months to file their SOIs or get kicked off the UASG mailing list — and suggested UASG leadership had broken with ICANN rules by unilaterally imposing the requirement.

Said mailing list is notable for being lightly used, but with occasional traffic spikes, usually during discussions of anything related to elections or UASG leadership, from participants using free webmail addresses and often what appear to be joke names (Yisrael Memshelet, really?).

Sometimes, these participants have helped steer the mailing list discussion, and at least one question from an aforementioned Google-resistant remote participant was read out at last week’s Public Forum and responded to (kinda) by a board member. ICANN received so many remote UASG questions during the Public Forum that it said it would provide a consolidated written response after the meeting.

It seems ICANN is suffering from twin related transparency problems right now — lawyers who don’t want to reveal their clients, and trolls who don’t want to reveal their identities — neither of which is ideal for its legitimacy.

ICANN meeting venue “insensitive and hurtful”

ICANN has taken some criticism over the decision to host its flagship Universal Acceptance 2024 meeting in Serbia.

An individual named Dmitry Noskov has written to ICANN to complain that the Universal Acceptance Steering Group will hold its “Keystone” meeting — the main event of the UA Day series of meetings around the world — later this month in Belgrade. He wrote (pdf):

Given the current global tension in the region due to ongoing conflict and the close cultural and historical ties between Serbia and Russia, which have led to diplomatic and trade actions by several countries against Russia, I am concerned about the implications of holding the event in Belgrade. It is crucial to consider the potential perception of insensitivity or hurtfulness to global sentiments, especially to those affected by the conflict.

Unlike most of Europe, Serbia has maintained a somewhat neutral stance on Russia’s invasion of Ukraine and there is reportedly large popular support for Russia, and a large Russian population, in the country. Russia and Serbia are old allies.

ICANN has taken a generally pro-Ukraine stance. It donated $1 million to relief efforts in 2022 after the war started. It also lobbied against the Russian nomination for ITU secretary-general. Russia’s ccTLD registry cut off its ICANN funding last year.

CEO Sally Costerton replied (pdf) to Noskov to say that the choice of Belgrade as the keystone UA Day event for 2024 was made by the UASG.

The UA Day event in Belgrade is being hosted by local ccTLD registry RNIDS, which runs .rs and the Cyrillic equivalent .срб.

Is this why WhatsApp hates some TLDs but not others?

Developers of major pieces of internet software, including the world’s most-popular messaging app, may be relying on seriously outdated lists of top-level domains.

That’s the picture that seems to be emerging from one new gTLD operator’s quest to discover why WhatsApp doesn’t recognize its TLD, and many others including major dot-brands, as valid.

And ICANN isn’t interested in helping, despite its declared focus on Universal Acceptance, the CEO of this registry claims.

When most social media apps detect the user has inputted a URL or domain name, they automatically “linkify” it so it can be easily clicked or tapped without the need for copy/paste.

But when Rami Schwartz of new gTLD .tube discovered that .tube URLs sent via WhatsApp, said to have two billion users, were not being linkified, despite the TLD being delegated by ICANN almost eight years ago, he set out to find out why.

Schwartz compiled a spreadsheet (.xlsx) listing which gTLDs are recognized by WhatsApp and which are not and discovered a rough cut-off point in November 2015. TLDs delegated before then are linkified, those delegated after were not.

According to my database, 468 TLDs have been delegated since December 2015, though not all are still in the root. That’s about a third of all TLDs.

This means that, for example, .microsoft domains linkify but .amazon and .apple domains do not; .asia domains linkify but .africa and .arab domains do not; .london works but .abudhabi doesn’t. Even .verisign missed the cut-off.

If WhatsApp users include a “www.” or “http://” then the app will linkify the domain, even if the specified TLD does not exist.

During the course of a discussion on the web site of the Public Suffix List — which maintains an open-source list of all TLDs and the levels at which names may be registered — it was discovered that the problem may be deeper rooted than the WhatsApp app.

It turns out a library in the Android operating system contains a hard-coded list of valid TLDs which hasn’t been updated since November 24, 2015.

Any app relying on Android to validate TLDs may therefore be susceptible to the same problem — any TLD younger than seven years won’t validate. Schwartz tells us he’s experienced the same issues with the Facebook app on Android devices.

The problem is of particular concern to Schwartz because he’s been planning to market .tube as a form of link-shortening service, and without full support among the most popular messaging apps such a service would be much less attractive.

“I can’t launch this now if it’s not going to work in WhatsApp, if it’s not going to work in Facebook,” he said.

While engineers from Facebook/WhatsApp parent Meta now seem to be looking into the problem, Schwartz says his complaints fell on deaf ears for a long time.

He additionally claims that “ICANN doesn’t really care about universal acceptance” and his attempts to get the Org to pay attention to the problem have been brushed off, despite ICANN making Universal Acceptance one of its key priorities.

Schwartz says ICANN is much more interested in UA when it comes to internationalized domain names (those in non-Latin scripts, such as Arabic or Chinese) and not the technical issues that underpin the functionality of all TLDs.

“I’ve no idea why ICANN makes the decisions it makes, but I think it has to do with inclusion, I think it has to do with diversity, I think it has to do with a lot of things — not technical,” he said. “But this is a technical issue.”

ICANN maintains a set of UA technical resources on its web site and supports the work of the independent Universal Acceptance Steering Group.

Universal Acceptance – making the internet work for everyone [Guest Post]

Editor’s note: this is a guest post written by Aman Masjide, head of compliance at new gTLD registry Radix.

Back in 2014, to foster innovation and to better the choice in domain names, ICANN introduced new generic top-level domains through its New gTLD Program. It was a monumental move that enabled businesses, individuals, and communities across the globe to mark their presence on the internet.

Allowing users to be present digitally in their chosen language (non-ASCII characters and scripts) gave opportunities to local businesses, civil societies, and governments to better serve their communities.

Analysys Mason conservatively estimates that there is scope of $9.8 billion growth in potential revenue from both; existing users who are using new domain names and from new internet users coming online through Internationalized Domain Names (IDNs).

To achieve this, Universal Acceptance of new gTLDs and IDNs is critical in making the Internet more accessible to the next billion users. Founded in February 2015, the Universal Acceptance Steering Group (UASG) undertakes activities to promote Universal Acceptance of all valid domain names and email addresses.

Through its ambassadorship and local Initiative programs, UASG promotes Universal Acceptance globally. Their efforts are divided and executed through five working groups that include:

• Technology Working Group
• Email Address Internationalization Working Group
• Communications Working Group
• Measurement Working Group
• Local Initiatives Working Group

Before we get into the acceptance of new domain extensions (nTLDs), we must first understand what acceptance means and how it’s measured.

The Universal Acceptance Steering Group’s mission sums up acceptance in one short statement: “All domain names and all email addresses work in all software applications.”

While this is a simple understanding of the concept, for an end user of an nTLD, this statement further branches out into multiple questions such as:

• Will my domain name work on all platforms/applications–online or offline?
• Will my email address on a new domain extension get accepted on all websites/platforms and pass all the validation tests?
• Will my emails on new domain extensions, once accepted, stop going into the junk folder?
• Will I be able to use all the features of a website/platform irrespective of my domain extensions? For example, will a social media platform accept a new domain extension in the bio, comments, posts, messenger, etc, and process it exactly like any other legacy TLD?

The Universal Acceptance (UA) of all domain names and email addresses requires that every piece of software is able to accept, validate, process, store, and display them correctly and consistently.

As a new domains registry, it was critical for us to understand what the gaps were and how to close them so that the internet operates the same for nTLD users as it does for the legacy TLD users.

Initial research concluded that UA readiness issues occur when applications are not able to handle the following categories of a domains name or email addresses:

Domain Names

• New short top-level domain names: example.fun, example.site
• New long top-level domain names: example.berlin, example.space
• Internationalized Domain Names: παράδειγμα.ευ

Email Addresses

• ASCII@ASCII; new short or long TLD: ekrem@misal.istanbul
• ASCII@IDN: john@société.org
• Unicode@ASCII: 测试@example.com
• Unicode@IDN: ईमेल@उदाहरण.भारत
• Unicode@IDN; right to left scripts: لیم@لاثم.عقوم ای

For Universal Acceptance to succeed, it needs to be examined holistically.

Over the years, UASG working group members have conducted several gap analysis on programming languages and frameworks, networking command-line tools, web browsers, websites, and have made great strides in acceptance of new domain extensions.

According to UASG’s FY 2020 report, tests conducted on top websites showed that

• The acceptance rate of emails on short nTLDs has increased from 91% in 2017 to 98.3% in 2020.
• The acceptance rate of emails on long nTLDs has increased from 78% in 2017 to 84.8% in 2020.

Note: The table above compares the 2020 results to the earlier 2017 and 2019 testing results.

Two important caveats should be remembered in this case:

• Different email addresses were tested (but they were of the same type).
• The websites tested in 2020 were different from previous ones as they were the 50 most popular in the 20 countries rather than the 1,000 most popular globally.

However, these results may still be used to compare overall trends.

Universal Acceptance Readiness Report 2020 (pdf) also segregated test websites as per different categories such as eCommerce, government, education, etc and the results were promising.

Such studies help UASG ambassadors and advocates to identify and focus on websites of a specific category that require immediate attention. We conducted a similar study at Radix where we analysed top websites belonging to different categories. These were the results (click to enlarge):

While the acceptance rates for new short and new long cases is more than 80% under most categories, we see a drastic dip when a domain is on an IDN TLD. Such comparisons highlight problem areas and provide direction to ambassadors and members who are advocating for Universal Acceptance.

Radix’s contribution to UASG

UA is something that affects nTLD users the most. This is why it’s crucial to focus on the feedback that we receive from them. At Radix, we work closely with our users to ensure we have the first hand information on any UA related issues faced by the customer.

The feedback could be about linkification, validation or acceptance of emails on nTLDs on different websites and platforms. Radix also actively invests its resources in gap analysis by testing various websites and social media platforms. We are also part of the ambassadorship program promoting and supporting local and global UA initiatives.

Here are some of the UASG initiatives that Radix is part of:

• Participating in the Technical And Measurement working group
• Participating in workshops on Universal Acceptance such as:
  – India Internet Week 2020 Online Edition
  – FICCI – Bhashantara – Panel Discussions
• Sharing gaps and issues reported by customers to UASG

At Radix, our objective is to ensure that nTLDs are accepted across websites and platforms. To achieve this, we actively work with UASG and share as many issues and gaps noticed and reported by customers.

Contribution by other registries

A key objective for most registries is to ensure great customer experience when it comes to their nTLDs and I’ve always admired it when registry operators have actively taken initiative and participated in the five UASG groups mentioned above.

One of the ways to do this is to capture all the queries and complaints reported by their customers/registrar partners and share it with UASG. This will help their support team direct their resources in solving the problems and encouraging those websites to become UA compliant.

Contribution by registrars

When it comes to UA-related issues, registrars are the first in chain to receive a complaint or feedback from the user. Therefore, it’s crucial that their support teams have all the necessary information needed on how to best handle such complaints.

For now, they can:

• Inform the customer about the potential UA issue and raise a request on behalf of the customer with UASG. Issues can be logged at – https://uasg.tech/global-support-center/
• Report these instances to the Registry Operator so that they can connect and follow up with UASG.
• Join any of the five working groups and participate.

The path ahead

The UASG is consistently compiling and sharing all the important information needed for organizations and developers to become UA ready. This is not only about ensuring the readiness of a system to accept certain TLDs or emails, but also about realising the full potential of an organization by connecting with people and businesses that might not be even on it’s radar.

Every successful step taken by an organization towards UA readiness is also a step towards equality and inclusiveness on the internet.

Guest poster Aman Masjide leads compliance and abuse mitigation at Radix.

Data beats Merdinger to head universal acceptance group

Email entrepreneur and internationalized domain name expert Ajay Data has been named as the new chair of the group that is struggling to promote the universal acceptance of top-level domains across the internet.
Data, who replaces Afilias COO Ram Mohan after a four-year term, beat GoDaddy’s VP of domains Rich Merdinger in a secret ballot of the Universal Acceptance Steering Group this week.
The number of votes each candidate received were not disclosed.
India-based Data is founder and CEO of Xgenplus, a developer of enterprise email servers with a focus on support for non-Latin scripts and internationalized domain names.
He’s been intimately involved in all things IDN for many years.
The UASG is an independent group, which receives funding from ICANN, dedicated to reaching out to software and web site developers to ensure their systems can support domain names in all scripts, including IDNs, as well as raise awareness of new gTLDs.

New gTLDs still a crappy choice for email — study

New gTLDs may not be the best choice of domain for a primary email address, judging by new research.
Over 20% of the most-popular web sites do not fully understand email addresses containing long TLDs, and Arabic email addresses are supported by fewer than one in 10 sites, a study by the Universal Acceptance Steering Group has found.
Twitter, IBM and the Financial Times are among those sites highlighted as having only partial support for today’s wide variety of possible email addresses.
Only 7% of the sites tested were able to support all types of email address.
The study, carried out by Donuts and ICANN staff, looked at 749 websites (in the top 1,000 or so as ranked by Alexa) that have forms for filling in email addresses.
On each site, seven different email addresses were input, to see whether the site would accept them as valid.
The emails used different combinations of ASCII and Unicode before the dot and mixes of internationalized domain name and ASCII at the second and top levels.
These were the results (click to enlarge or download the PDF of the report here):

The problem with these numbers, it seems to me, is the lack of a control. There’s no real baseline to judge the numbers against.
There’s no mention in the paper about testing addresses that use .com or decades-old ccTLDs, which would have highlighted web sites that with broken scripts that reject all emails.
But if we assume, as the paper appears to, that all the tested web sites were 100% compliant for .com domains, the scores for new gTLDs are not great.
There are currently over 800 TLDs over four characters in length, but according to the UASG research 22% of web sites will not recognize them.
There are 150 IDN TLDs, but a maximum of 30% of sites will accept them in email addresses.
When it comes to right-to-left scripts, such as Arabic, the vast majority of sites are totally hopeless.
UASG dug into the code of the tested sites when it could and found that most of them use client-side code — JavaScript processing a regular expression — to verify addresses.
A regular expression is complex bit of code that can look something like this: /^.+@(?:[^.]+\.)+(?:[^.]{2,})$
It’s not every coder’s cup of tea, but it can get the job done with minimal client-side resource overheads. Most coders, the UASG concludes, copy regex they found on a forum and maybe tweak it a bit.
This should not be shocking news to anyone. I’ve known about it since 2009 or earlier when I first started ripping code from StackOverflow.
However, the UASG seems to be have been working on the assumption that more sites are using off-the-shelf software libraries, which would have allowed the problem to be fixed in a more centralized fashion.
It concludes in its paper that much greater “awareness raising” needs to happen before universal acceptance comes closer to reality.

Companies losing $10 BILLION by ignoring new gTLDs — report

The world economy is “conservatively” losing out on almost $10 billion of annual revenue due to a lack of support for new gTLDs and internationalized domain names, according to an ICANN-commissioned research report.
The report, conducted by Analysys Mason for the semi-independent Universal Acceptance Steering Group, calculated that patchy new gTLD support means $3.6 billion of activity is lost, with lack of IDN support costing $6.2 billion.
Despite “new” gTLDs being around for a decade and a half, there are still plenty of web sites and apps that incorrectly assume that all TLDs are either two or three characters. Others don’t support non-Latin scripts.
This leads to internet users abandoning transactions, the report says, when their email addresses are rejected as invalid.
Mason calculated the $3.6 billion number by multiplying the estimated number of email addresses using new gTLD domains (152 million) by the estimated average annual revenue generated per email address ($360), then calculating what portion of these transactions cannot happen due to incomplete TLD support.
Earlier research by .CLUB Domains suggests that 13% of sites do not support new gTLDs, so that’s the number Mason used. The researchers then cut the number in half, to account for the 50% of people it reckons would simply switch to an email address in a legacy TLD name.
That gets you to $3.6 billion of potential revenue lost for want of gTLD support.
Another, more cynical way to spin this would be to say that new gTLDs are causing $3.6 billion of economic damage. After all, if everyone were to use legacy TLDs there would be no problem.
For the IDN number, Mason calculated how many users of five major language groups (Russian, Chinese, Arabic, Vietnamese and Indian languages) are not currently online, then estimated how much revenue would be generated if just 5% of these users (17 million people) were persuaded online by the existences of IDN TLDs.
The report was commissioned in order to raise awareness of the financial benefits of universal acceptance.
The UASG has spent most of its efforts so far focusing on UA as a “bug fix” to be communicated to engineers, so the report is intended to broaden its message to catch the attention of the money people too.
The report, which goes into much more detail about how the numbers were arrived at, can be downloaded here.

Group forms to stop new gTLDs breaking stuff

A little over a year into the live phase of the new gTLD program, a group of domain industry companies are getting together to make sure the expansion is supported across the whole internet.
A new Universal Acceptance Steering Group has formed, with the support of ICANN and the Domain Name Association, to help fix many of the compatibility problems facing new gTLD registrants today.
“The basic problem is that these new types of domains and email addresses just break stuff,” Google’s Brent London said during a UASG meeting at the ICANN meeting in Singapore last week.
“You try to use an internationalized domain or a long new gTLD, or even a short new gTLD, or certainly an internationalized email address and you’re likely to run into problems,” he said. “What we’re doing is going around asking developers to make their products work.”
Universal acceptance is a long-understood problem. Even 15 years after the approval of .info there are still web sites that validate email addresses by ensuring the TLD is no longer than three characters in length.
But the 2012 new gTLD round has brought the issue into sharper focus, particularly given the introduction of internationalized domain names, IDNs, which use non-Latin scripts.
Over the last year we’ve seen scattered examples of popular software — including browsers, instant messaging and social media apps — not recognizing new gTLD domains as domains. The problems I’ve seen are usually fixed quite quickly.
While I’ve not seen any deal-breakers that would prevent me registering a new gTLD domain, I gather that IDN email addresses are often basically unusable, due to the chain of dependencies involved in sending an email.
In my experience as a programmer, supporting all TLDs is not a particularly challenging problem when you’re coding something afresh.
However, when bad practices have been coded in to large, sprawling, interdependent systems over decades, it could be likened to the Y2K problem — the so-called Millennium Bug that caused developer headaches worldwide at the end of the last century.
There’s also a tonne of bad advice on the web, with coders telling other coders to validate domains in ways that do not support an expanding root.
UASG members think the problem is large-scale and that it’s a long-term project — 10 years or more — to fix it satisfactorily.
Members include Donuts, Google, Microsoft, Go Daddy and Afilias.
The DNA has started creating a repository of information for developers, with the aim of describing the problem in plain English and providing code samples. Along with other UASG members, there’s a plan to conduct outreach to make more people aware of the acceptance issue.
You can check out the repository in its unfinished state here.
ICANN is getting involved in a coordination role. After the UASG’s inaugural meeting in Washington DC a few weeks ago, ICANN hosted a session during ICANN 52.
It’s also hosting a mailing list and the group’s first conference call, which will take place tomorrow at 1600 UTC.