Greek .eu domains to be deleted

EURid has started warning registrants that their Greek-script .eu domains will be deleted this year.

The names will no longer work after November 14, the company said yesterday.

It’s part of the registry’s three-year plan to phase out mixed-script internationalized domain names, which are considered poor security practice.

The affected domains are Greek-script IDN.eu names, not IDN.IDN names using the Greek-script .ευ.

.ευ was introduced in 2019, after an amusingly Kafkaesque, yet typically ICANN, decade-long effort to crowbar the ccTLD through its IDN Fast Track rules.

Because EURid had been accepting Greek-script second-level names under its base Latin .eu domain for some time, it grandfathered existing registrants by “cloning” their .eu names into .ευ, albeit with only a three-year lifespan.

There were only 2,694 .ευ domains registered at the end of 2021, so one must assume that the number of domains on the deleting list must be smaller.

Kafka turns in grave as ICANN crowbars “useless” Greek TLD into the root

ICANN has finally approved a version of .eu in Greek script, but it’s already been criticized as “useless”.
Yesterday, ICANN’s board of directors rubber-stamped .ευ, the second internationalized domain name version of the European Union’s .eu, which will be represented in the DNS as .xn--qxa6a.
There’s a lot of history behind .ευ, much of it maddeningly illustrative of ICANN’s Kafkaesque obsession with procedure.
The first amusing thing to point out is that .ευ is technically being approved under ICANN’s IDN ccTLD Fast Track Process, a mere NINE YEARS after EURid first submitted its application.
The “Fast Track” has been used so far to approve 61 IDN ccTLDs. Often, the requested string is merely the name of the country in question, written in one of the local scripts, and the TLD is approved fairly quickly.
But in some cases, especially where the desired string is a two-character code, a string review will find the possibility of confusion with another TLD. This runs the risk of broadening the scope of domain homograph attacks sometimes used in phishing.
That’s what happened to .ευ, along with Bulgaria’s Cyrillic .бг and Greece’s own .ελ, which were rejected on string confusion grounds back in 2010 and 2011.
Under pressure from the Governmental Advisory Committee, ICANN then implemented an Extended Process Similarity Review Panel, essentially an appeals process designed to give unsuccessful Fast Track applicants a second bite at the apple.
That process led to Bulgaria being told that .бг was not too similar to Brazil’s .br, and Greece being told that .ελ did not look too much like .EA, a non-existent ccTLD that may or may not be delegated in future, after all.
But the EU’s .ευ failed at the same time, in 2014. The appeals review panel found that the string was confusable with upper-case .EY and .EV.
Again, these are not ccTLDs, just strings of two characters that have the potential to become ccTLDs in future should a new country or territory emerge and be assigned those codes by the International Standards Organization, a low-probability event.
I reported at the time that .ευ was probably as good as dead. It seemed pretty clear based on the rules at the time that if a string was confusable in uppercase OR lowercase, it would be rejected.
But I was quickly informed by ICANN that I was incorrect, and that ICANN top brass needed to discuss the results.
That seems to have led to ICANN tweaking the rules yet again in order to crowbar .ευ into the root.
In 2015, the board of directors reached out to the GAC, the ccNSO and the Security and Stability Advisory Committee for advice.
They dutifully returned two years later with proposed changes (pdf) that seemed tailor-made for the European Union’s predicament.
A requested IDN ccTLD that caused confusion with other strings in only uppercase, but not lowercase (just like .ευ!!!) could still get delegated, provided it had a comprehensive risk mitigation strategy in place, they recommended.
The recommendation was quickly approved by ICANN, which then sent its implementation guidelines (again, tailor-made for EURid (pdf)) back to the ccNSO/SSAC.
It was not until February this year that the ccNSO/SSAC group got back to ICANN (pdf) to approve of its implementation plan and to say that it has already tested it against EURid’s proposed risk-mitigation plan (pdf).
Basically, the process in 2009 didn’t produce the desired result, so ICANN changed the process. It didn’t produced the desired result again in 2014, so the process was changed again.
But at least Greek-speaking EU citizens are finally going to get a meaningful ccTLD that allows them to express their EUishness in their native script, right?
WRONG!
I recently read with interest and surprise a blog post by domainer-blogger Konstantinos Zournas, in which he referred to .ευ as the “worst domain extension ever”.
Zournas, who is Greek, opened my eyes to the fact that “.ευ” is meaningless in his native tongue. It’s just two Greek letters that visually resemble “EU” in Latin script. It’s confusing by design, but with .eu, a ccTLD that EURid already manages.
While not for a moment doubting Zournas’ familiarity with his own language, I had to confirm this on the EU’s Greek-language web site.
He’s right, the Greek for “European Union” is “Ευρωπαϊκής Ένωσης”, so the sensible two-letter IDN ccTLD would be .ΕΈ (those are Greek characters that look a bit like Latin E).
That would have almost certainly failed the ICANN string similarity process, however, as .ee/EE is the current, extant ccTLD for Estonia.
In short (too late), it seems to have taken ICANN the best part of a decade, and Jesus H Christ knows how many person-hours, to hack its own procedures multiple times in order to force through an application for a TLD that doesn’t mean anything, can’t be confused with anything that currently exists on the internet, and probably won’t be widely used anyway.
Gratz to all involved!

EU IDN not banned after all

The European Union request for the Greek-script ccTLD .ευ has not been thrown out, according to ICANN.
Last week DI reported that .ευ was the only one of three IDN ccTLD requests — the other two being Bulgaria’s .бг and Greece’s .ελ — to fail a test for confusing similarity on appeal.
.ευ was found to be confusingly similar to .EY and .EU, but only when in upper case.
The similarity panel’s decision would mean, I reported, that .бг and .ελ would be delegated but .ευ would not, under ICANN rules.
I wondered aloud what the Governmental Advisory Committee would think about that, given that it had lobbied for the creation of the appeals process in order to get an earlier rejection of .ευ overturned.
Shortly after publishing the article, ICANN reached out to say I was wrong and ask for a correction.
“We (ICANN) have not rejected the .ευ application,” a spokesperson said.
“Due to the unprecedented nature of the split results, the issue needs to be discussed at the senior management and Board level before a final decision is made,” he said.
The “split results” refers to the fact that there was found to be no confusing similarity with .ευ in lower case.
However, the ICANN rule I referred to says (which my emphasis):

The rule is that if the appearance of the selected string, in upper or lower case, in common fonts in small sizes at typical screen resolutions, is sufficiently close to one or more other strings, it is probable that a reasonable Internet user who is unfamiliar with the script perceives the strings to be the same or confuses one for the other.

That’s adapted almost verbatim from the original recommendations of the ccNSO. The only addition ICANN made was to add the clearly important clause “in upper or lower case” to the text.
It seemed pretty straightforward to me — confusing similarity exists regardless of case.
I pointed this out to ICANN last Wednesday and asked where I could find the rule that said the ICANN board or staff get to review a “split results” finding but have yet to receive a reply.

Bulgaria and Greece win IDN ccTLDs on appeal

Campaigns in Bulgaria and Greece to get ICANN to un-reject their Cyrillic and Greek-script ccTLD requests have proven successful.
The first decisions handed down by ICANN’s new Extended Process Similarity Review Panel this week said Bulgaria’s .бг and Greece’s .ελ are not “confusingly similar” to other ccTLDs after all.
However, a third appeal by the European Union over the Greek .ευ was rejected on the grounds that the string is too confusingly similar to .EV and .EY when in upper case.
Confusing strings should not be delegated, under ICANN rules, due to the risk of exacerbating the prevalence of security risks such as phishing attacks.
Bulgaria’s initial request for .бг was turned down in 2010 after a panel found it looks too similar to Brazil’s existing ccTLD, .br.
Greece’s bid for .ελ had been blocked for looking too much like .EA, a non-existent ccTLD that could be delegated to a new country in future.
While the initial panel’s process was pretty opaque, the newly published “extended” reviews appear to have employed a fairly scientific methodology to determine similarity.
Twenty American undergraduate student volunteers were shown pairs of strings briefly on screens designed to simulate web browsing. They then had to pick out which one they’d seen.
The volunteers were also shown pairs of similar-looking Latin-script ccTLDs that already exist, in order to establish a baseline for what should be considered an acceptable level of confusability.
The Greek and Bulgarian strings were both found to be less confusing than existing pairs of Latin-script ccTLDs and were therefore given the thumbs-up. The EU string flunked in upper case.
Under ICANN’s rules, it appears that .бг and .ελ can now proceed to delegation, while .ευ has been forever rejected.
The three reports can be downloaded here.
It will be interesting to see how the ICANN Governmental Advisory Committee will react to this.
It was pressure from the GAC — driven by the European Commission and Greece — back in 2012 that forced ICANN into creating the appeals process.
At ICANN’s meeting in Prague that year, the GAC said:

The GAC is of the view that decisions may have erred on the too-conservative side, in effect applying a more stringent test of confusability between Latin and non-Latin scripts than when undertaking a side by side comparison of Latin strings.

Now the EU seems to have been told that it still can’t have its requested ccTLD, and the standard applied was exactly the same standard as applies to Latin ccTLDs.
Will the GAC accept this determination, or stomp its feet?