You won’t need a password for ICANN 68 after all

ICANN has ditched plans to require all ICANN 68 participants to enter a password whenever they enter one of the Zoom sessions at the meeting next week.

The org said today that it will use URLs with embedded passwords, removing the need for user input, after reviewing changes Zoom made last month.

These included features such as a waiting room that enables meeting hosts to vet participants manually before allowing them to enter the meeting proper.

ICANN said: “Please use these links cautiously, only share them on secure channels such as encrypted chat or encrypted e-mail, and never post them publicly.”

ICANN had said last month, before the Zoom changes, that it would require passwords in order to limit the risk of Zoombombing — where trolls show up and spam the meeting with offensive content. One ICANN Zoom session had been trolled in this way in March.

The org also said today that participants will be asked to give their consent to be recorded upon entry to a session.

“It is our hope that this small change empowers attendees by providing quick access and more control over the acceptance of our policies as it relates to attending virtual meetings,” ICANN lied, to cover for the obvious piece of legal ass-covering.

Refuse consent and see how far you get.

Irony alert! Data protection agency complains it can’t get access to private Whois data

A European data protection authority has complained to ICANN after a registrar refused to hand over one of its customers’ private Whois records, citing the GDPR data protection regulation, according to ICANN.

Compounding the irony, the DPA wanted the data as part of its probe into an alleged GDPR violation at the domain in question.

This is the frankly hilarious scenario outlined in a letter (pdf) from ICANN boss Göran Marby to Andrea Jelinek, chair of the European Data Protection Board, last week.

Since May 2018, registrars and registries have been obliged under ICANN rules to redact all personally identifiable information from public Whois records, because of the EU’s General Data Protection regulation.

This has irked the likes of law enforcement and intellectual property owners, who have found it increasingly difficult to discover the identities of suspected bad actors such as fraudsters and cybersquatters.

Registrars are still obliged to hand over data upon request in certain circumstances, but the rules are vague, requiring a judgement call:

Registry and Registrar MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.

While an ICANN working group has been attempting to come up with a clearer-cut set of guidelines, administered by a central body, this so-called SSAD (System for Standardized Access/Disclosure) has yet to come to fruition.

So when an unidentified European DPA recently asked a similarly unidentified non-EU registrar for the Whois data of somebody they suspected of GDPR violations, the registrar told it to get stuffed.

It told the DPA it would “not act against a domain name without any clear and unambiguous evidence for the fraudulent behavior” and said it would respond to legal requests in its own jurisdiction, according to ICANN.

The DPA complained to ICANN, and now ICANN is using that complaint to shame the EDPB into getting off the fence and providing some much-needed clarity about when registrars can declassify Whois data without breaking the law.

Marby wrote that registrars are having to apply their “subjective judgment and discretion” and will most often come down on the side of registrants in order to reduce their GDPR risk. He wrote:

ICANN org would respectfully suggest to the EDPB that a more explicit recognition of the importance of certain legitimate interests, including the relevance of public interests, combined with clearer guidelines on balancing, could address these problems.

…

ICANN org would respectfully suggest to the EDPB to consider issuing additional specific guidance on this topic to ensure that entities with a legitimate interest in obtaining access to non-public gTLD registration data are able to do so. Guidance would in particular be appreciated on how to balance legitimate interests in access to data with the interests of the data subject concerned

ICANN and the EDPB have been communicating about this issue for a couple of years now, with ICANN looking for some clarity on this largely untested area of law, but the EDPB’s responses to data have been pretty vague and unhelpful, almost as if it doesn’t know what the hell it’s doing either.

Will this latest example of the unintended consequences of GDPR give the Board the kick up the bum it needs to start talking in specifics? We’ll have to wait and see.

After Zoom trolling, ICANN 68 will be password-protected

If you want to show up to ICANN 68, which will be held online next month, you’re going to need a password.

ICANN said this week that it’s updating its Zoom software and standard configuration to require passwords. In a blog post outlining a number of changes to its Zoom instance, ICANN said:

The most impactful change is the new requirement that all meetings be secured with a password. This is the first step recommended by security professionals to keep meetings secure, and one which we had largely adopted org-wide prior to making it a requirement for all. We will make another announcement in the coming weeks regarding how this may impact joining meetings during ICANN68, as we work towards the best overall solution.

Quite how this could work while maintaining the usual openness of ICANN’s public meetings — which have always been free to attend basically anonymously — remains to be seen.

At ICANN 67, Zoom sessions that were open to the public simply required you to enter a name. Any name. At in-person public meetings, I don’t think you even need to show ID to get a hall pass.

The changes come in the wake of a “Zoombombing” incident during a minor meeting in March, during which trolls showed up via a publicly-posted link and flooded the session with “inappropriate and offensive” audio and imagery.

ICANN meeting got “Zoombombed” with offensive material

An ICANN meeting held over the Zoom conferencing service got “Zoombombed” by trolls last month.

According to the organization, two trolls entered an ICANN 67 roundup session for Spanish and Portuguese speakers on March 27 and “shared inappropriate and offensive audio and one still image” with the legitimate participants.

The session was not password protected (rightly) but the room had (wrongly) not been configured to mute participants or disable screen-sharing, which enabled the offensive material to be shared.

The trolls were quickly kicked and the loopholes closed, ICANN said in its incident report.

ICANN appears to have purged the meeting entirely from its calendar and there does not appear to be an archive or recording, so I sadly can’t share with you the gist of the shared content.

Zoombombing has become an increasingly common prank recently, as the platform sees many more users due to the coronavirus-related lockdowns worldwide.

Go here to help fight against coronavirus abuse

A coalition of over 1,000 security experts, domain name providers and others have got together to help coordinate efforts to combat abusive coronavirus-related domains.

A workspace on the collaboration platform Slack has been growing steadily since it was created a week ago, enabling technology professionals to exchange information about the alarming number of sites currently trying to take advantage of the pandemic.

You can join the channel via this link. Thanks to Theo Geurts of RealtimeRegister.com for passing it along.

The collection of chat rooms appears to have been created by Joshua Saxe, chief scientist at security software firm Sophos, March 19. There are currently 1,104 members.

There’s a channel devoted to malicious domains, which is being used to share statistical data and lists of bad and good coronavirus-related domains, among other things.

Across the workspace, a broad cross-section of interested parties is represented. Current members appear to come from security companies, governments, law enforcement, registries, registrars, ICANN, healthcare providers, and others.

It seems like a pretty good way for the technical members of the domain name industry to keep track of what’s going on during the current crisis, potentially helping them to put a stop to threats using domains they manage as they emerge.

As it releases free download, DomainTools says 68,000 dangerous coronavirus domains have been registered

More than 68,000 coronavirus-related domain names have been registered so far in 2020, according to data released by DomainTools today.

The domain intelligence services company has started publishing a list of these domains, updated daily, for free on its web site. You have to submit your email address to get it.

The download comprises a CSV file with three columns: domain, reg date, and Domain Risk Score.

This final field is based on DomainTools’ in-house algorithms that estimate how likely domains are likely to be used in nefarious activities, based on criteria including the domain’s connection to other, known-bad domains.

Only domains with a score of 70 or above out of 100 — indicating they will likely be used for activities such as phishing, malware or spam — will be included on the list, the company said.

The list will be updated daily at 0000 UTC.

You can find out more and obtain today’s list here.

Hacking claims resurface as .hotel losers force ICANN to lawyer up again

The fight over .hotel has been escalated, with four unsuccessful applicants for the gTLD whacking ICANN with a second Independent Review Process appeal.
The complaint resurrects old claims that a former lead on the successful application, now belonging to Afilias, stole trade secrets from competing applicants via a glitched ICANN web site.
It also revives allegations that ICANN improperly colluded with the consultant hired to carry out reviews of “community” applications and then whitewashed an “independent” investigation into the same.
The four companies filing the complaint are new gTLD portfolio applicants MMX (Minds + Machines), Radix, Fegistry, and Domain Venture Partners (what we used to call Famous Four).
The IRP was filed November 18 and published by ICANN December 16, but I did not spot it until more recently. Sorry.
There’s a lot of back-story to the complaint, and it’s been a few years since I got into any depth on this topic, so I’m going to get into a loooong, repetitive, soporific, borderline unreadable recap here.
This post could quite easily be subtitled “How ICANN takes a decade to decide a gTLD’s fate”.
There were seven applicants for .hotel back in 2012, but only one of them purported to represent the “hotel community”. That applicant, HOTEL Top Level Domain, was mostly owned by Afilias.
HTLD had managed to get letters of support from a large number of hotel chains and trade groups, to create a semblance of a community that could help it win a Community Priority Evaluation, enabling it to skip to the finish line and avoid a potentially costly auction against its rival applicants.
CPEs were carried out by the Economist Intelligence Unit, an independent ICANN contractor.
Surprisingly to some (including yours truly), back in 2014 it actually managed to win its CPE, scoring 15 out of the 16 available points, surpassing the 14-point winning threshold and consigning its competing bidders’ applications to the scrap heap.
There would be no auction, and no redistribution of wealth between applicants that customarily follows a new gTLD auction.
Naturally, the remaining applicants were not happy about this, and started to fight back.
The first port of call was a Request for Reconsideration, which all six losers filed jointly in June 2014. It accused the EIU of failing to follow proper procedure when it evaluated the HTLD community application.
That RfR was rejected by ICANN, so a request for information under ICANN’s Documentary Information Disclosure Policy followed. The losing applicants reckoned the EIU evaluator had screwed up, perhaps due to poor training, and they wanted to see all the communications between ICANN and the EIU panel.
The DIDP was also rejected by ICANN on commercial confidentiality grounds, so the group of six filed another RfR, asking for the DIDP to be reconsidered.
Guess what? That got rejected too.
So the applicants then filed an IRP case, known as Despegar v ICANN, in March 2015. Despegar is one of the .hotel applicants, and the only one that directly plays in the hotel reservation space already.
The IRP claimed that ICANN shirked its duties by failing to properly oversee and verify the work of the EIU, failing to ensure the CPE criteria were being consistently applied between contention sets, and failing in its transparency obligations by failing to hand over information related to the CPE process.
While this IRP was in its very early stages, it emerged that one of HTLD’s principals and owners, Dirk Krischenowski, had accessed confidential information about the other applicants via an ICANN web site.
ICANN had misconfigured its applicant portal in such a way that any user could very access any attachment on any application belonging to any applicant. This meant sensitive corporate information, such as worst-case-scenario financial planning, was easily viewable via a simple search for over a year.
Krischenowski appears to have been the only person to have noticed this glitch and used it in earnest. ICANN told applicants in May 2015 that he had carried out 60 searches and accessed 200 records using the glitch.
Krischenowski has always denied any wrongdoing and told DI in 2016 that he had always “relied on the proper functioning of ICANN’s technical infrastructure while working with ICANN’s CSC portal.”
The applicants filed another DIDP, but no additional information about the data glitch was forthcoming.
When the first IRP concluded, in February 2016, ICANN prevailed, but the three-person IRP panel expressed concern that neither the EIU nor ICANN had any process in place to ensure that community evaluations carried out by different evaluators were consistently applying the CPE rules.
The IRP panel also expressed concern about the “very serious issues” raised by the ICANN portal glitch and Krischenowski’s data access.
But the loss of the IRP did not stop the six losing applicants from ploughing on. Their lawyer wrote to ICANN in March 2016 to denounce Krischenowski’s actions as “criminal acts” amounting to “HTLD stealing trade secrets of competing applicants”, and as such HTLD’s application for .hotel should be thrown out.
Again, to the best of my knowledge, Krischenowski has never been charged with, let alone convicted of, any criminal act.
Afilias wrote to ICANN not many weeks later, April 2016, to say that it had bought out Krischenowski’s 48.8% stake in HTLD and that he was no longer involved in the company or its .hotel application.
And ICANN’s board of directors decided in August 2016 that Krischenowski may well have accessed documents he was not supposed to, but that it would have happened after the .hotel CPE had been concluded, so there was no real advantage to HTLD.
A second, parallel battle against ICANN by an unrelated new gTLD applicant had been unfolding over the same period.
A company called Dot Registry had failed in its CPE efforts for the strings .llc, .llp and .inc, and in 2014 had filed its own IRP against ICANN, claiming that the EIU had “bungled” the community evaluations, applying “inconsistent” scoring criteria and “harassing” its supporters.
In July 2016, almost two years later, the IRP panel in that case ruled that Dot Registry had prevailed, and launched a withering attack on the transparency and fairness of the ICANN process.
The panel found that, far from being independent, the EIU had actually incorporated notes from ICANN staff into its CPE evaluations during drafting.
It was as a result of this IRP decision, and the ICANN board’s decision that Krischenowski’s actions could not have benefited HTLD, that the losing .hotel applicants filed yet another RfR.
This one lasted two and a half years before being resolved, because in the meantime ICANN launched a review of the CPE process.
It hired a company called FTI Consulting to dig through EIU and ICANN documentation, including thousands of emails that passed between the two, to see if there was any evidence of impropriety. It covered .hotel, .music, .gay and other gTLD contention sets, all of which were put on hold while FTI did its work.
FTI eventually concluded, at the end of 2017, that there was “no evidence that ICANN organization had any undue influence on the CPE reports or engaged in any impropriety in the CPE process”, which affected applicants promptly dismissed as a “whitewash”.
They began lobbying for more information, unsuccessfully, and hit ICANN with yet another RfR in April 2018. Guess what? That one was rejected too.
The .hotel applicants then entered into a Cooperative Engagement Process — basically pre-IRP talks — from October 2018 to November 2019, before this latest IRP was filed.
It’s tempting to characterize it as a bit of a fishing expedition, albeit not a baseless one — any allegations of ICANN’s wrongdoing pertaining the .hotel CPE are dwarfed by the applicants’ outraged claims that ICANN appears to be covering up both its interactions with the EIU and its probe of the Krischenowski incident, partly out of embarrassment.
The claimants want ICANN to be forced to hand over documentation refused them on previous occasions, relating to: “ICANN subversion of the .HOTEL CPE and first IRP (Despegar), ICANN subversion of FTI’s CPE Process Review, ICANN subversion of investigation into HTLD theft of trade secrets, and ICANN allowing a domain registry conglomerate to takeover the ‘community-based’ applicant HTLD.”
“The falsely ‘independent’ CPE processes were in fact subverted by ICANN in violation of Bylaws, HTLD stole trade secrets from at least one competing applicant, and Afilias is not a representative of the purported community,” the IRP states.
“HTLD’s application should be denied, or at least its purported Community Priority relinquished, as a consequence not only for HTLD’s spying on its competitors’ secret information, but also because HTLD is no longer the same company that applied for the .HOTEL TLD. It is now just a registry conglomerate with no ties to the purported, contrived ‘Community’ that it claims entitled to serve,” it goes on.
ICANN is yet to file its response to the complaint.
Whether the IRP will be successful is anyone’s guess, but what’s beyond doubt is that if it runs its course it’s going to add at least a year, probably closer to two, to the delay that .hotel has been languishing under since the applications were filed in 2012.
Potentially lengthening the duration of the case is the claimants’ demand that ICANN “appoint and train” a “Standing Panel” of at least seven IRP panelists from which each three-person IRP panel would be selected.
The standing panel is something that’s been talked about in ICANN’s bylaws for at least six or seven years, but ICANN has never quite got around to creating it.
ICANN pinged the community for comments on how it should go about creating this panel last year, but doesn’t seemed to have provided a progress report for the last nine months.
The .hotel applicants do not appear to be in any hurry to get this issue resolved. The goal is clearly to force the contention set to auction, which presumably could happen at Afilias’ unilateral whim. Time-to-market is only a relevant consideration for the winner.
With .hotel, and Afilias’ lawsuit attempting to block the .web sale to Verisign, the last round of new gTLD program, it seems, is going to take at least a decade from beginning to end.

AlpNames died months ago. Why is it still the “most-abused” registrar?

Despite going out of business, being terminated by ICANN, and losing all its domains several months ago, defunct AlpNames is still being listed as the world’s most-abused registrar by a leading spam-fighting organization.
SpamHaus currently ranks the Gibraltar-based company as #1 on its list of the “The 10 Most Abused Domain Registrars”, saying 98.7% of its domains are being used to send spam.
But AlpNames customers and regular DI readers will recall that AlpNames mysteriously went titsup in March, then got terminated by ICANN, then had its entire customer base migrated over to CentralNic in April.
So what’s this about?

I asked SpamHaus earlier this week, and it turns out that Whois query throttling is to blame.
It seems SpamHaus only pings Whois to update the registrar associated with a specific domain when the domain expires, or the name servers change, or where it’s a new registration with an unknown registrar.
I gather that when CentralNic took over AlpNames’ customer base, it did so with all the original name server information intact.
So, SpamHaus’ database still associates the domains with AlpNames even though it’s been out of business for the better part of a year.
A SpamHaus spokesperson said:

This is a very unusual situation, as a huge majority of the domains that contribute to the Top 10 list in question are created, abused, and burnt quickly; meaning a change of registrar is exceptionally rare. However, in the case of these particular domains registered with AlpNames we can only assume that the sheer volume of unused domains was too high for the owner to use in one single hit.

The actual number of “AlpNames” domains rated as spammy by SpamHaus is pretty low — 1,976 of the 2,002 domains it saw were rated as “bad”.
GMO, at #4 on the list, had over 40,000 “bad” domains, but a lower percentage given the larger number of total domains seen.

Web.com got pwned

Web.com, which owns top 20 registrars Network Solutions and Register.com, got itself and millions of its customers hacked a few months ago.
The company disclosed last week that malicious hackers broke into its network in late August, making off with customer account information.
The attack was not discovered until October 16.
The compromised data included “name, address, phone numbers, email address and information about the services that we offer to a given account holder”, Web.com said.
“We encrypt credit card numbers and no credit card data was compromised as a result of this incident,” it added.
Customers are being told to change their password next time they log in to their services.
It’s not clear how many registrants were affected. The NetSol accreditation has over seven million domains in the gTLDs alone, while Register.com has almost 1.8 million.
Web.com said it brought on a private security firm to investigate the attack, and informed US law enforcement.

Emoji domains get a 😟 after broad study

Domain names containing emojis are a security risk and not recommended, according to a pretty comprehensive review by an ICANN study group.
The Country-Code Names Supporting Organization has delivered the results of its 12-person, 18-month Emoji Study Group, which was tasked with looking into the problems emoji domains can cause, review current policy, and talk to ccTLD registries that currently permit emoji domains.
The ESG didn’t have a lot of power, and its recommendations are basically an exercise in can-kicking, but it’s easily the most comprehensive overview of the issues surrounding emoji domains that I’ve ever come across.
It’s 30 pages long, and you can read it here (pdf).
Emojis are currently banned in gTLDs, where ICANN has to approve new Unicode tables before they can be used by registries at the second level, under its internationalized domain name policy, IDNA 2008.
But ccTLDs, which are not contracted with ICANN, have a lot more flexibility. There are 15 ccTLDs — almost all representing small islands or low-penetration African nations — that currently permit emoji domains, the ESG found.
That’s about 6% of Latin-script ccTLDs out there today. These TLDs are .az, .cf, .fm, .je, .ga, .ge, .gg, .gq, .ml, .st, .to, .tk, .uz, .vu, and .ws.
Five of them, including .tk, are run by notorious freebie registry Freenom, but perhaps the best-known is .ws, where major brands such as Budweiser and Coca-Cola have run marketing campaigns in the past.
The main problem with emojis is the potential for confusing similarity, and the ESG report does a pretty good job of enumerating the ways confusability can arise. Take its comparison of multiple applications’ version of the exact same “grinning face” emoji, for example:

If you saw a domain containing one of those in marketing on one platform, would you be able to confidently navigate to the site on another? I doubt I would.
There’s also variations in how registrars handle emojis on their storefronts, the report found. On some you can search with an emoji, on others you’ll need to type out the xn-- prefixed Punycode translation longhand.
In terms of recommendations, the ESG basically just asked ICANN to keep an eye on the situation, to come to a better definition of what an emoji actually is, and to reach out for information to the ccTLDs accepting emojis, which apparently haven’t been keen on opening up so far.
Despite the lack of closure, it’s a pretty good read if you’re interested in this kind of thing.