Spam is not our problem, major domain firms say ahead of ICANN 66

Eleven of the largest domain name registries and registrars have denied that spam is something they should have to deal with, unless it’s used to proliferate other types of abuse such as phishing or malware.
In a newly published “Framework to Address Abuse” (pdf), the companies attempt to define the term “DNS abuse” narrowly to capture only five (arguably only four and a half) specific types of online threat.
That abuse comprises malware, phishing, botnets, pharming and spam.
The companies agree that these are activities which registrars and registries “must” act upon.
But the document notes that not all spam is its responsibility, stating:

While Spam alone is not DNS Abuse, we include it in the five key forms of DNS Abuse when it is used as a delivery mechanism for the other four forms of DNS Abuse. In other words, generic unsolicited e-mail alone does not constitute DNS Abuse, but it would constitute DNS Abuse if that e-mail is part of a phishing scheme.

In other words, registrars and registries should not feel responsible for the billions of spams sent every day using their domains, unless the spam runs further malware, phishing, pharming or botnet abuse.
The signatories of the framework are Public Interest Registry, GoDaddy, Donuts, Tucows, Amazon Registry Services, Blacknight, Afilias, Name.com, Amazon Registrar, Neustar, and Nominet UK.
It may seem like they’ve presented a surprisingly narrow definition, but it’s in line with what current ICANN contracts dictate.
Neither the standard Registry Agreement nor Registrar Accreditation Agreement mention spam at all. Six years ago, ICANN specifically said that spam is “outside of ICANN’s scope and authority”.
Under the RA, registries have to oblige their registrars to ban registrants from “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law”.
They also have to maintain statistical reports on the amount of “pharming, phishing, malware, and botnets” in their zones, and provide those reports to ICANN upon demand. A recent audit found that 5% of registries, mainly dot-brands, were not doing this.
However, ICANN’s Domain Abuse Activity Reporting system, an effort to provide some transparency into how gTLDs are being abused, does in fact track spam. It does not track pharming, which is a fairly obscure and little-used form of DNS attack.
The DAAR report for September shows that spam constituted 73% of all tracked abuse.
The ICANN board of directors today identified DAAR as one of a few dozen priorities for the coming year.
Similarly, the cross-community working group known as the CCT Review Team, which was tasked with looking into how the new gTLD program has impacted competition and consumer trust, had harsh words for spam-friendly registries, and provided a definition of “DNS Security Abuse” that specifically included “high volume spam”.
The review recommended that ICANN introduce more measures to force contracted parties to deal with this type of abuse. This could include incentives for registries to clean up their zones and abuse volume thresholds that would automatically trigger compliance actions.
The new framework document comes in the context of an ongoing debate within the ICANN community about what “DNS abuse” is.
Two partners at Interisle, a security consultancy that often works for ICANN, recently guest-posted on DI to say that this term has become meaningless and should be abandoned in favor of “security threat”.
They argued that the definition should include not only spam, but also stuff like IP infringement, election interference, and terrorism.
But the main threat to contracted parties probably comes from the Governmental Advisory Committee, backed by law enforcement, which is pushing for stronger rules covering abusive content.
During a webinar last week, the US Federal Trade Commission, the FBI, and Europol argued that registries and registrars should be obliged to do more to combat abuse, specifically including spam.
“Whether or not you call it phishing or spam or whether it has a malware payload or not, ultimately it’s all email, and email remains the most common tool of cybercriminals to ensnare their victims, and that’s why we in law enforcement care about the domains used to send emails,” said Gabriel Andrews of the FBI’s Cyber Initiative Resource Fusion Unit, on the call.
Registries and registrars countered, using the same language found in the new framework, that generic spam is a content issue, and outside of their remit.
The two sides are set to clash again at ICANN’s annual general meeting in Montreal next month, in a November 6 face-to-face session.
While 11 entities signed the new framework, it’s arguably only nine companies. Name.com is owned by Donuts and both Amazon firms obviously have the same parent.
But it does include the two largest registrars, and registries responsible for running several hundred commercial gTLDs, dot-brands and ccTLDs.
While none of the signatories of the framework have a particular reputation for being spam-friendly, other companies in the industry — particularly some of the newest and cheapest new gTLDs — tend to attract spammers like flies to a turd.
Some of the signatories are perhaps surprising, given their past or ongoing behavior to tackle content-based abuse in their own zones.
Nominet, notably, takes down tens of thousands of domains ever year based on little more than police assurances that the domains are being used to sell counterfeit merchandise or infringe copyright.
The .uk registry also preemptively suspends domains based on algorithms that guess whether they’re likely to be seen as encouraging sexual violence or could be used in phishing attacks.
Donuts also has a trusted notifier relationship with the movie and music industries that has seen it take down dozens of names being used for mass copyright infringement.
PIR has previous endorsed, then unendorsed, the principal of a “UDRP for copyright”, a method of giving Big Content a way of going through due process to have domains taken or suspended.
Outside the spam issue, while the new registry-registrar framework says that registries and registrars should not get involved in matters related to web site content, it also says they nevertheless “should” (as opposed, one assumes based on the jargon usually found in internet standards, to “must”) suspend domains when they’re being used to distribute:

(1) child sexual abuse materials (“CSAM”); (2) illegal distribution of opioids online; (3) human trafficking; and (4) specific and credible incitements to violence.

These are exceptions because they constitute “the physical and often irreversible threat to human life”, the framework says.
Ultimately, this all boils down to a religious debate about where the line is drawn between “DNS” and “content”, it seems to me.
The contracted parties draw the line at threats to human life, whereas others want action on other forms of abuse largely because registries and registrars are in the best position to help.

Crunch time, again, for Whois access policy

Talks seeking to craft a new policy for allowing access to private Whois data have hit another nodal point, with the community now pressuring the ICANN board of directors for action.
The Whois working group has more or less decided that a centralized model for data access, with ICANN perhaps acting as a clearinghouse, is the best way forward, but it needs to know whether ICANN is prepared to take on this role and all the potential liabilities that come with it.
Acronym time! The group is known as the Whois EPDP WG (for Expedited Policy Development Process Working Group) and it’s come up with a rough Whois access framework it’s decided to call the Standardized System for Access and Disclosure (SSAD).
Its goal is to figure out a way to minimize the harms that Europe’s General Data Protection Regulation allegedly caused to law enforcement, IP owners, security researchers and others by hiding basically all gTLD registration data by default.
The SSAD, which is intended to be as automated as possible, is the working group’s proposed way of handling this.
The “hamburger model” the EPDP has come up with sees registries/registrars and data requestors as the top and bottom of the sandwich (or vice versa) with some yet-to-be-decided organizational patty filling acting as an interface between the two.
The patty would handle access control for the data requests and be responsible for credentialing requestors. It could either be ICANN acting alone, or ICANN coordinating several different interface bodies (the likes of WIPO have been suggested).
Should the burger be made only of mashed-up cow eyelids, or should it incorporate the eyelids of other species too? That’s now the question that ICANN’s board is essentially being posed.
Since this “phase two” work kicked off, it’s taken about five months, 24 two-hour teleconferences, and a three-day face-to-face meeting to get to this still pretty raw, uncooked state.
The problem the working group is facing now is that everyone wants ICANN to play a hands-on role in running a centralized SSAD system, but it has little idea just how much ICANN is prepared to get involved.
The cost of running such a system aside, legislation such as GDPR allows for pretty hefty fines in cases of privacy breaches, so there’s potentially a big liability ask of notoriously risk-averse ICANN.
So the WG has written to ICANN’s board of directors in an attempt to get a firm answer one way or the other.
If the board decided ICANN should steer clear, the WG may have to go back more or less to square one and focus on adapting the current Whois model, which is distributed among registrars and registries, for the post-GDPR world.
How much risk and responsibility ICANN is willing to absorb could also dictate which specific SSAD models the WG pursues in future.
There’s also a view that, with no clarity from ICANN, the chance of the WG reaching consensus is unlikely.
This will be a hot topic at ICANN 66 in Montreal next month.
Expect the Governmental Advisory Committee, which had asked for “considerable and demonstrable progress, if not completion” of the access model by Montreal, to be disappointed.

Sixty gTLD registries not monitoring security threats

Roughly 5% of gTLD registry operators have been doing no abuse monitoring, despite contractual requirements to do so, a recent ICANN audit has found.
ICANN checked with 1,207 registries — basically all gTLDs — between November 2018 and June, and found about 60 of them “were not performing any security threat monitoring, despite having domains registered in their gTLDs”.
A further 180 (15%) were not doing security checks, but had no registered domains, usually because they were unused dot-brands. ICANN told these companies that they had to do the checks anyway, to remain in compliance.
In all cases, ICANN said, the registries remediated their oversights during the audit to bring their gTLDs back into compliance.
ICANN does not name the non-compliant registries in the summary of the audit’s results, published yesterday (pdf).
Registries under the 2012 new gTLD base registry agreement all have to agree to this:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

It’s possible to keep tabs on abuse by monitoring domain blocklists such as SpamHaus, SURBL and PhishTank. Some such lists are freely available, others carry hefty licensing fees.
ICANN itself monitors these lists through its Domain Abuse Activity Reporting project, so it’s able to work out the differences between the levels of abuse registries report and what the empirical data suggests.
Registries typically either use these lists via in-house tools or license products provided by vendors such as Neustar, RegistryOffice, Knipp, CSC, DOTZON, Afnic, AusCERT, Shadowserver, Telefonica, Secure Domain Foundation and Netcraft, ICANN said.
Perhaps unsurprisingly, there’s a bit of disagreement between ICANN and some registries about how the somewhat vague obligations quote above are be interpreted.
ICANN thinks registries should have to provide information about specific domains that were identified as abusive and what remediation actions were taken, but some registries think they only have to provide aggregate statistical data (which would be my read of the language).
The contracts also don’t specify how frequently registries much carry out security reviews.
Of the 80% (965) of registries already in compliance, 80% (772) were doing daily abuse monitoring. Others were doing it weekly, monthly, or even quarterly, ICANN found, all of which appear to be in line with contractual requirements.

ICANN must do more to fight internet security threats [Guest Post]

ICANN and its contracted parties need to do more to tackle security threats, write Dave Piscitello and Lyman Chapin of Interisle Consulting.
The ICANN Registry and Registrar constituencies insist that ICANN’s role with respect to DNS abuse is limited by its Mission “to ensure the stable and secure operation of the internet’s unique identifier systems”, therefore limiting ICANN’s remit to abuse of the identifier systems themselves, and specifically excluding from the remit any harms that arise from the content to which the identifiers point.
In their view, if the harm arises not from the identifier, but from the thing identified, it is outside of ICANN’s remit.
This convenient formulation relieves ICANN and its constituencies of responsibility for the way in which identifiers are used to inflict harm on internet users. However convenient it may be, it is fundamentally wrong.
ICANN’s obligation to operate “for the benefit of the Internet community as a whole” (see Bylaws, “Commitments”) demands that its remit extend broadly to how a domain name (or other Internet identifier) is misused to point to or lure a user or application to content that is harmful, or to host content that is harmful.
Harmful content itself is not ICANN’s concern; the way in which internet identifiers are used to weaponize harmful content most certainly is.
Rather than confront these obligations, however, ICANN is conducting a distracting debate about the kinds of events that should be described as “DNS abuse”. This is tedious and pointless; the persistent overloading of the term “abuse” has rendered it meaningless, ensuring that any attempt to reach consensus on a definition will fail.
ICANN should stop using the term “DNS abuse” and instead use the term “security threat”.
The ICANN Domain Abuse Activity Reporting project and the Governmental Advisory Committee (GAC) use this term, which is also a term of reference for new TLD program obligations (Spec 11) and related reporting activities. It is also widely used in the operational and cybersecurity communities.
Most importantly, the GAC and the DAAR project currently identify and seek to measure an initial set of security threats that are a subset of a larger set of threats that are recognized as criminal acts in jurisdictions in which a majority of domain names are registered.
ICANN should acknowledge the GAC’s reassertion in its Hyderabad Communique that the set of security threats identified in its Beijing correspondence to the ICANN Board were not an exhaustive list but merely examples. The GAC smartly recognized that the threat landscape is constantly evolving.
ICANN should not attempt to artificially narrow the scope of the term “security threat” by crafting its own definition.
It should instead make use of an existing internationally recognized criminal justice treaty. The Council of Europe’s Convention on Cybercrime is a criminal justice treaty that ICANN could use as a reference for identifying security threats that the Treaty recognizes as criminal acts.
The Convention is recognized by countries in which a sufficiently large percentage domain names are registered that it can serve the community and Internet users more effectively and fairly than any definition that ICANN might concoct.
ICANN should also acknowledge that the set of threats that fall within its remit must include all security events (“realized security threats”) in which a domain name is used during the execution of an attack for purposes of deception, for infringement on copyrights, for attacks that threaten democracies, or for operation of criminal infrastructures that are operated for the purpose of launching attacks or facilitating criminal (often felony) acts.
What is that remit?
ICANN policy and contracts must ensure that contracted parties (registrars and registries) collaborate with public and private sector authorities to disrupt or mitigate:

• illegal interception or computer-related forgery,
• attacks against computer systems or devices,
• illegal access, data interference, or system interference,
• infringement of intellectual property and related rights,
• violation of laws to ensure fair and free elections or undermine democracies, and
• child abuse and human trafficking.

We note that the Convention on Cybercrime identifies or provides Guidance Notes for these most prevalently executed attacks or criminal acts:

• Spam,
• Fraud. The forms of fraud that use domain names in criminal messaging include, business email compromise, advance fee fraud, phishing or other identity thefts.
• Botnet operation,
• DDoS Attacks: in particular, redirection and amplification attacks that exploit the DNS
• Identity theft and phishing in relation to fraud,
• Attacks against critical infrastructures,
• Malware,
• Terrorism, and,
• Election interference.

In all these cases, the misuse of internet identifiers to pursue the attack or criminal activity is squarely within ICANN’s remit.
Registries or registrars should be contractually obliged to take actions that are necessary to mitigate these misuses, including suspension of name resolution, termination of domain name registrations, “unfiltered and unmasked” reporting of security threat activity for both registries and registrars, and publication or disclosure of information that is relevant to mitigating misuses or disrupting cyberattacks.
No one is asking ICANN to be the Internet Police.
The “ask” is to create policy and contractual obligations to ensure that registries and registrars collaborate in a timely and uniform manner. Simply put, the “ask” is to oblige all of the parties to play on the same team and to adhere to the same rules.
This is unachievable in the current self-regulating environment, in which a relatively small number of outlier registries and registrars are the persistent loci of extraordinary percentages of domain names associated with cyberattacks or cybercrimes and the current contracts offer no provisions to suspend or terminate their operations.
This is a guest editorial written by Dave Piscitello and Lyman Chapin, of security consultancy Interisle Consulting Group. Interisle has been an occasional ICANN security contractor, and Piscitello until last year was employed as vice president of security and ICT coordination on ICANN staff. The views expressed in this piece do not necessary reflect DI’s own.

ICANN’s new conferencing software has a webcam security bug

ICANN can’t catch a break when it comes to remote participation security, it seems.
Having just recently made the community-wide switch away from Adobe Connect to Zoom, partly for security reasons, now Zoom has been hit by what many consider to be a critical zero-day vulnerability.
Zoom (which, irrelevantly, uses a .us domain) pushed out an emergency patch for the vulnerability yesterday, which would have allowed malicious web sites to automatically turn on visitors’ webcams without their consent.
Only users of the installable Mac client were affected.
According to security researcher Jonathan Leitschuh, who discovered the problem, Zoom’s Mac client was installing a web server on users’ machines in order to bypass an Apple security feature that requires a confirmatory click before the webcam turns on.
This meant a web site owner could trick a user into a Zoom session, with their camera turned on by default, without their knowledge or consent.
If you’re in the habit of keeping your webcam lens uncovered, that’s potentially a big privacy problem, especially if you do most of your remote coverage of ICANN meetings from the toilet.
It appears that Leitschuh, who reported the problem to Zoom three months ago, took issue with what he saw as the company’s ambivalent attitude to fixing it in a timely fashion.
When he finally blogged about it on Monday, after giving Zoom a 90-day “responsible disclosure” period to issue a patch, the problem still hadn’t been fully resolved, he wrote.
But, following media coverage, Zoom’s new patch apparently removes the covert web server completely. This removes the vulnerability but means Apple users will have to click a confirmation button before joining Zoom meetings in future.
Zoom is used now for all of ICANN’s remote participation, from sessions of its public meetings to discussions of its policy-making working groups.
I really like it. It feels a lot less clunky than Adobe, and it’s got some nifty extra features such as the ability to skip around in recordings based on an often-hilarious machine-transcription sidebar, which makes my life much easier.
One of the reasons ICANN made the switch was due to a bug found in Adobe Connect last year that could have been used to steal confidential information from closed meetings.
ICANN actually turned off Adobe Rooms for remote participants halfway through its public meeting in Puerto Rico due to the bug.
The switch to Zoom was hoped to save ICANN $100,000 a year.

Airline hit with $230 million GDPR fine

British Airways is to be fined £183.39 million ($230 million) over a customer data breach last year, by far the biggest penalty to be handed out under the General Data Protection Regulation to date.
This story is not directly related to the domain name industry, but it does demonstrate that European data protection authorities are not messing about when it comes to GDPR enforcement.
About 500,000 BA customers had their personal data — including full payment card details — stolen by attackers between June and September last year, the UK Information Commissioner’s Office said today..
It is believed that they obtained the data not by hacking BA’s database, but rather by inserting a script hosted by third-party domain that executed whenever a customer transacted with the site, allowing credentials to be captured in real time.
The ICO said its decision to fine $183.39 million — which amounts to more than 1.5% of BA’s annual revenue — is preliminary and can be appealed by BA.
Under GDPR, which came into effect in May 2018, companies can be fined up to 4% of revenue.
The biggest pre-GDPR fine is reportedly the £500,000 penalty that Facebook was given due to the Cambridge Analytica scandal.
GDPR is of course of concern to the domain industry due to the ongoing attempts to make sure Whois databases are compliant with the laws.

PwC wants to be your Whois gatekeeper

PricewaterhouseCoopers has built a Whois access system that may help domain name companies and intellectual property interests call a truce in their ongoing battle over access to private Whois data.
Its new TieredAccess Platform will enable registries and registrars to “outsource the entire process of providing access to non-public domain registration data”.
That’s according to IP lawyer Bart Lieben, partner at the Belgian law firm ARTES, who devised the system and is working with PwC to develop it.
The offering is designed to give trademark lawyers access to the data they lust after, while also reducing costs and mitigating domain name industry liability under the General Data Protection Regulation.
TieredAccess would make PwC essentially the gatekeeper for all requests for private Whois data (at least, in the registries plugged into the platform) coming from the likes of trademark owners, security researchers, lawyers and law enforcement agencies.
At one end, these requestors would be pre-vetted by PwC, after which they’d be able to ask for unredacted Whois records using PwC as an intermediary.
They’d have to pick from one of 43 pre-written request scenarios (such as cybersquatting investigation, criminal probe or spam prevention) and assert that they will only use the data they obtain for the stated purposes.
At the other end, registries and registrars will have adopted a set of rules that specify how such requests should be responded to.
A ruleset could say that cops get more access to data than security researchers, for example, or that a criminal investigation is more important than a UDRP complaint.
PwC has created a bunch of templates, but registrars and registries would be able to adapt these policies to their own tastes.
Once the rules are put in place, and the up-front implementation work has been done to plug PwC into their Whois servers, they wouldn’t have to worry about dealing with Whois requests manually as most are today. The whole lot would be automated.
Not even PwC would have human eyes on the requests. The private data would only be stored temporarily.
One could argue that there’s the potential for abusive or non-compliant requests making it through, which may give liability-nervous companies pause.
But the requests and response metadata would be logged for audit and compliance, so abusive users could be fingered after the act.
Lieben says the whole system has been checked for GDPR compliance, assuming its prefabricated baseline scenarios and templates are adopted unadulterated.
He said that the PwC brand should give clients on both sides “peace of mind” that they’re not breaking privacy law.
If a registrar requires an affidavit before releasing data, the assertions requestors make to PwC should tick that box, he said.
Given that this is probably a harder sell to the domain name industry side of the equation, it’s perhaps not surprising that it’s the requestors that are likely to shoulder most of the cost burden of using the service.
Lieben said a pricing model has not yet been set, but that it could see fees paid by registrars subsidized by the fees paid by requestors.
There’s a chance registries could wind up paying nothing, he said.
The project has been in the works since September and is currently in the testing phase, with PwC trying to entice registries and registrars onto the platform.
Lieben said some companies have already agreed to test the service, but he could not name them yet.
The service was developed against the backdrop of ongoing community discussions within ICANN in the Expedited Policy Development Working group, which is trying to create a GDPR-compliant policy for access to private Whois records.
ICANN Org has also made it known that it is considering making itself the clearinghouse for Whois queries, to allow its contracted parties to offload some liability.
It’s quite possible that once the policies are in place, ICANN may well decide to outsource the gatekeeper function to the likes of PwC.
That appears to be what Lieben has in mind. After all, it’s what he did with the Trademark Clearinghouse almost a decade ago — building it independently with Deloitte while the new gTLD rules were still being written and then selling the service to ICANN when the time came.
The TieredAccess service is described in some detail here.

Court rules domain name list should stay secret

Publishing a list of every domain name in their zone is something that most TLD registries do automatically on a daily basis, but a court in Chile has ruled that doing so is a cybersecurity risk.
NIC Chile, which runs .cl, said last week that it has won an appeal against a Transparency Council ruling that would have forced it to publish a list of the domains it manages.
The Court of Appeals ruled that the registry was within its rights to refuse to hand over an Excel spreadsheet listing the 575,430 domains in .cl to the person who requested it.
The request was just for the list of domains, with none of the other data you’d find in a zone file and no Whois information about the registrants.
Nevertheless, the court unanimously ruled that to hand over the list would present “cybersecurity risks”, according to NIC Chile attorney Margarita Valdés Cortés.
NIC Chile said in a statement:

In this particular case, it was considered that the bulk delivery of domain names to a private individual could generate risks of cybersecurity of various kinds, both in access to information as a result of those domain names as well as the possibility that, by having such a list, attacks on servers, phishing, spam or others could be made easier. Similarly, the ruling of the Court of Appeals understood that the delivery of the data affects commercial and economic rights of the holders of these .CL domains, and considered that there is a legal cause that justifies NIC Chile´s refusal to turn over the list of all registered names.

Cortés said that the case will now go to the nation’s Supreme Court for a final decision, after the Transparency Council appealed.
Access to zone files is considered by many security researchers to be an invaluable tool in the fight against cybercrime.
NIC Chile has published the ruling, in Spanish, here (pdf).

Governments demand Whois reopened within a year

ICANN’s government advisers wants cops, trademark owners and others to get access to private Whois data in under a year from now.
The Governmental Advisory Committee wants to see “considerable and demonstrable progress, if not completion” of the so-called “unified access model” for Whois by ICANN66 in Montreal, a meeting due to kick off November 4 this year.
The demand came in a letter (pdf) last week from GAC chair Manal Ismail to her ICANN board counterpart Cherine Chalaby.
She wrote that the GAC wants “phase 2” of the ongoing Expedited Policy Development Process on Whois not only concluded but also implemented “within 12 months or less” of now.
It’s a more specific version of the generic “hurry up” advice delivered formally in last month’s Kobe GAC communique.
It strikes me as a ludicrously ambitious deadline.
Phase 2 of the EPDP’s work involves deciding what “legitimate interests” should be able to request access to unredacted private Whois data, and how such requests should be handled.
The GAC believes “legitimate interests include civil, administrative and criminal law enforcement, cybersecurity, consumer protection and IP rights protection”.
IP interests including Facebook want to be able to vacuum up as much data as they want more or less on demand, but they face resistance from privacy advocates in the non-commercial sector (which want to make access as restrictive as possible) and to a lesser extent registries and registrars (which want something as cheap and easy as possible to implement and operate that does not open them up to legal liability).
Ismail’s letter suggests that work could be sped up by starting the implementation of stuff the EPDP group agrees to as it agrees to it, rather than waiting for its full workload to be complete.
Given the likelihood that there will be a great many dependencies between the various recommendations the group will come up with, this suggestion also comes across as ambitious.
The EPDP group is currently in a bit of a lull, following the delivery of its phase 1 report to ICANN, which is expected to approve its recommendations next month.
Since the phase 1 work finished in late February, there’s been a change of leadership of the group, and bunch of its volunteer members have been swapped out.
Volunteers have also complained about burnout, and there’s been some pressure for the pace of work — which included four to five hours of teleconferences per week for six months — to be scaled back for the second phase.
The group’s leadership has discussed 12 to 18 months as a “realistic and desirable” timeframe for it to reach its Initial Report stage on the phase 2 work.
For comparison, it published its Initial Report for phase 1 after only six stressful months on the job, and not only have its recommendations not been implemented, they’ve not even been approved by ICANN’s board of directors yet. That’s expected to happen this Friday, at the board’s retreat in Istanbul.
With this previous experience in mind, the chances of the GAC getting a unified Whois access service implemented within a year seem very remote.

ICANN got hacked by crypto bots

ICANN had to take down its community wiki for several hours last week after it got hacked by crypto-currency miners.
The bad guys got in via one of two “critical” vulnerabilities in Confluence, the wiki software that ICANN licences from Atlassian Systems, which ICANN had not yet patched.
ICANN’s techies noticed the wiki, which is used by many of its policy-making bodies to coordinate their work, was running slowly April 11.
They quickly discovered that Atlassian had issued a vulnerability warning on March 20, but ICANN was not on its mailing list (doh!) so hadn’t been directly notified.
They also determined that a malicious “Crypto-Miner” — software that uses spare CPU cycles to attempt to create new cryptocurrency coins — had been installed and was responsible for the poor performance.
ICANN said it took the wiki down, restored it to a recent backup, patched Confluence, and brought the system back online. It seems to have taken a matter of hours from discovery to resolution.
The organization said it has now subscribed to Atlassian’s mailing list, so it will be notified of future vulnerabilities directly.