Nightmare downtime weekend for some eNom and Google customers

Some eNom customers have experienced almost two days of downtime after a planned data center migration went titsup, leading to DNS failures hitting what users suspect must have been thousands of domains.

Social media has been filled with posts from customers complaining that their DNS was offline, meaning their web sites and email have been down. Some have complained of losing money to the downtime.

Affected domains include some registered directly with eNom, as well as some registered via resellers including Google Workspace.

The issue appears to have been caused by a scheduled data center migration, which was due to begin 1400 UTC on Saturday and last for 12 hours.

The Tucows-owned registrar said that during that time both reseller hub enom.com and retail site enomcentral.com would be unavailable. While this meant users would be unable to manage their domains, DNS was expected to resolve normally.

But before long, customers started reporting resolution problems, leading eNom to post:

We are receiving some reports of domains using our nameservers which are failing to resolve. Owing to the migration we are unable to research and fully address the issue until the migration is complete. This is not an expected outcome from the migration, and we are working to address it as a priority.

The maintenance window was then extended several times, by three to six hours each time, as eNom engineers struggled to fix problems caused by the migration. eNom posted several times on its status page:

The unexpected extension to the maintenance window was due to data migration delays. We also discovered resolution problems that impact a few hundred domains

eNom continued to post updates until it finally declared the crisis over at 0800 UTC this morning, meaning the total period of downtime was closer to 42 hours than the originally planned 12.

A great many posts on social media expressed frustration and anger with the outage, with some saying they were losing money and reputation and others promising to take their business elsewhere.

Help, it's Monday morning in the UK, I have a team who need to work. I have customers who want to place orders. I have a new partnership in progress which will be ruined at this rate. Please please let us know what is happening. #enom #enomdown @enomsupport

— Karen Burns (@cooper_karen) January 17, 2022

@enom @enomsupport What on the world is going on? Every 3 hours we get another boilerplate message saying “another 3 hours” This is completely unacceptable. How are you going to fix this and how are you going to make people whose work sites have been down all weekend whole?

— Andrew Pershing (@Sci_Officer) January 16, 2022

I almost have begrudging respect for how badly @enom has fucked the pooch with their migration. Blowing up your service so badly that your customers can’t even take their business elsewhere is some galaxy brain shit.

— Keith (@FilthySpecs) January 16, 2022

Same. I'm in a group with 6 other bloggers who also have the same DNS issue. Our sites have been down since yesterday. We're losing ad income & have readers who can't access the information they need.

— Elaina Newton (@TheRisingSpoon) January 16, 2022

Some said that they continued to experience problems after eNom had declared the maintenance over.

@enom your service status website states incorrect status for Google services? My email is still down!!! Also, getting error when logging in to enom domain management console!

— Tomislav Pavosevic (@tompavosevic) January 17, 2022

eNom primarily sells through its large reseller channel, so some customers were left having to explain the downtime in turn to their own clients. Google Workspace is one such reseller that acknowledged the problems on its Twitter feed.

Some customers questioned whether the problem really was just limited to just a few hundred domains, and eNom seemed to acknowledge that the actual number may have been higher.

Looks like one of the most severe internet outages I've seen in years is underway and has not hit MSM yet! @enom, "largest wholesaler of Internet domains" has screwed up a migration and taken possibly up to 2M domains offline.
Certainly my measly 100+ are dead.
See @enomsupport

— 😷Andy Stringer (@AndyStringer) January 17, 2022

At this point, we have been able to track a few hundred. If you have domains that are affected we encourage you to reach out to help@enom.com with the domain(s) in question.

— enomsupport (@enomsupport) January 16, 2022

I’m in contact with Tucows, eNom’s owner, and will provide an update when any additional information becomes available.

1 Comment Tagged: downtime, enom, google, google workspace, migration, tucows

XYZ bosses agree to pay $1.5 million to settle Fed’s loan scam claims

Some of XYZ’s top executives have agreed to pay $1.5 million to settle a US Federal Trade Commission lawsuit alleging they “deceptively” harvested vast amounts of personal data on millions of people and sold it “indiscriminately” to third parties including potential scammers and identity thieves.

The FTC says that the execs, through a network of interlinked companies, deceptively collected loan applications through at least 200 web sites, promising to connect the applicant with verified lenders, but instead sold the personal data willy-nilly to the highest bidder through a lead-generation marketplace.

The data was bought by companies that in the vast majority of cases were not in the business of providing loans, the FTC said. The buyers were not checked out by the XYZ execs and exposed consumers to identity theft and fraud, it added.

The allegations cover activities starting in 2012 and carrying on until recently, the FTC said.

“[They] tricked millions of people into giving up sensitive financial information and then sold it to companies that were not making loans,” Samuel Levine, director of the FTC’s Bureau of Consumer Protection said in a press release. “The company’s extraction and misuse of this data broke the law in several ways.”

“The FTC’s allegations were wholly without merit,” the defendants’ lawyer, Derek Newman, told DI in an email. “But litigation against the FTC is expensive and resource draining. For that reason, my clients chose to settle the case and move on with their business.”

“In fact, the FTC did not require any changes to my clients’ business practices that they had not already implemented before the case was filed,” he added.

The suit (pdf) named as defendants XYZ.com CEO Daniel Negari, COO Michael Abrose, business development manager Jason Ramin, and general counsel Grant Carpenter. Two other named defendants, Anisha Hancock and Sione Kaufusi, do not appear at first glance to be connected to the domains business.

The settlement (pdf) sees the defendants pay $1.5 million and agree to certain restrictions on their collection and use of data, but they did not admit or deny any liability.

The lead generation business was carried out via at least 17 named companies, including XYZ LLC (which appears to be a different company to the .xyz registry, XYZ.com LLC), Team.xyz LLC and Dev.xyz LLC. The FTC complaint groups them together under the name ITMedia.

Some of the companies are successors to Cyber2Media, the FTC said, a company that in 2011 had to settle a massive typosquatting lawsuit filed by Facebook.

Despite the personnel crossover, nothing in the complaint relates directly to the .xyz domains business, and the only domains listed in the complaint are some pretty nice .coms, including badcreditloans.com, personalloans.com, badcredit.com, fastmoney.com and cashadvance.com.

The complaint alleged deceptive representations and unfair distribution of sensitive information as well as violations of the Fair Credit Reporting Act. It reads:

In numerous instances, Defendants, through ITMedia’s actions, have shared and sold sensitive personal and financial information from consumers’ loan forms — including consumers’ full names, addresses, email addresses, phone numbers, birthdates, Social Security numbers, bank routing and account numbers, driver’s license and state identification numbers, income, status and place of employment, military status, homeownership status, and approximate credit scores—without consumers’ knowledge or consent and without regard for whether the recipients are lenders or otherwise had a legitimate need for the information.

Essentially, the complaint alleged that the defendants bullshitted consumers into handing over personal info thinking they were applying for a legitimate loan, when in fact the info was just being harvested for resale to sometimes dodgy buyers.

The complaint reads:

ITMedia’s practice of broadly disseminating consumer information, including to entities that share information with others whose identities and use of the information are unknown to ITMedia, exposes consumers to the risk of substantial harm from identity theft, imposter scams, unauthorized billing, phantom debt collection, and other misuse of the consumers’ information. Some consumers have complained that, shortly after submitting loan applications to ITMedia, they have received communications using the names of ITMedia websites to present sham loan offers or demands for repayment of counterfeit debt.

The $1.5 million settlement will be paid by “Individual Defendants and Corporate Defendants, jointly and severally”, according to court documents.

UPDATE: This article was updated shortly after publication with a statement from XYZ’s lawyer.

Comment Tagged: .xyz, ftc, identity theft, lawsuit, lead generation, new gTLDs, xyz.com

New gTLD pioneer MMX to wind up

MMX, the new gTLD registry also known as Minds + Machines, has decided to close down and de-list.

The company said today that it plans to return its remaining cash to investors through a tender offer and then cancel its remaining shares, which are listed on London’s Alternative Investment Market.

The cancellation plan is subject to shareholder approval at a February 7 general meeting, but the tender does not require approval.

MMX will buy back shares to the tune of £19 million ($26 million) at 10.4 pence per share, a premium of 26.1% on yesterday’s closing price and 24.8% on the last month’s average price.

It follows an $80 million tender offer completed in October.

MMX sold off its major assets — 22 new gTLD registry contracts — to GoDaddy last year in a $120 million deal, and has wound down its legacy registrar businesses.

Now, all that remains is a transition services agreement with GoDaddy, which will soon end.

There had been talk of using the AIM listing as a reverse-takeover vehicle for an operating business seeking quick access to the public markets, but it appears that’s no longer on the table.

If everything goes according to plan, MMX will cease to exist as a public company on February 22. Shareholders have until January 28 to accept the tender offer.

It seems the remaining shareholders will be losing out — if the tender offer is fully subscribed, they’ll only get to sell one share for every 1.485 shares they currently own.

Comment Tagged: acquisition, godaddy, mmx, new gTLDs

ICANN trying to strangle SSAD in the crib?

ICANN is trying to kill off or severely cripple Whois reform because it thinks the project stands to be too expensive, too time-consuming, and not fit for purpose.

That’s what many long-time community members are inferring from recent discussions with ICANN management about the Standardized System for Access and Disclosure (SSAD), a proposed method of normalizing how people request access to private, redacted Whois data.

The community has been left trying to read the tea leaves following a December 20 briefing in which ICANN staff admitted they have failed to even approximately estimate how well-used SSAD, which has been criticized by potential users as pointless, might be.

During the briefing, staff gave a broad range of implementation times and cost estimates, saying SSAD could take up to four years and $27 million to build and over $100 million a year to operate, depending on adoption.

The SSAD idea was thrown together in, by ICANN standards, super-fast time with a super-tenuous degree of eventual consensus by a cross-community Expedited Policy Development Process working group.

One of the EPDP’s three former chairs, Kurt Pritz, a former senior ICANN staffer who’s been heavily involved in community work since his departure from the Org in 2012, provided his read of the December webinar on a GNSO Council discussion this week.

“I’ve sat through a number of cost justification or cost benefit analyses in my life and got a lot of reports, and I’ve never sat through one that more clearly said ‘Don’t do this’,” Pritz said.

GNSO liaison to the Governmental Advisory Committee Jeff Neuman concurred moments later: “It seemed that we could imply from the presentation that that staff was saying ‘Don’t do it’… we should require them to put that in writing.”

“It was pretty clear from the meeting that ICANN Org does not want to build the SSAD. Many people in the community think its estimates are absurdly inflated in order to justify that conclusion,” Milton Mueller of the Internet Governance Project recently wrote of the same webinar.

These assessments seem fair, to the extent that ICANN appears seriously averse to implementing SSAD as the recommendations are currently written.

ICANN repeated the December 20 cost-benefit analysis in a meeting with the GAC this week, during which CEO Göran Marby described the limitations of SSAD, and how it cannot override privacy laws such as the GDPR:

It’s not a bug, it’s a feature of GDPR to limit access to data…

The SSAD is a recommended system to streamline the process of requesting data access. It cannot itself increase access to the data, as this is actually determined by the law. And so, in practice, the SSAD is expected to have little to no impact on the contracted parties’ ultimate disclosure or nondisclosure response to requests… it’s a ticketing system with added functionality.

While Marby stressed he was not criticizing the EPDP working group, that’s still a pretty damning assessment of its output.

Marby went on to reiterate that even if SSAD came into existence, people wanting private Whois data could still request it directly from registries and registrars, entirely bypassing SSAD and its potentially expensive (estimated at up to $45) per-query fees.

It seems pretty clear that ICANN staff is not enthused about SSAD in its current form and there’s a strong possibility the board of directors will concur.

So what does the policy-making community do?

There seems to be an emerging general acceptance among members of the GNSO Council that the SSAD proposals are going to have to be modified in some way in order for them to be approved by the board.

The question is whether these modifications are made preemptively, or whether the GNSO waits for more concrete feedback from Org and board before breaking out the blue pen.

Today, all the GNSO has seen is a few PowerPoint pages outlining the top-line findings of ICANN’s Operational Design Assessment, which is not due to be published in full until the board sees it next month.

Some Council members believe they should at least wait until the full report is out, and for the board to put something on the record detailing its reservations about SSAD, before any changes are made.

The next update on SSAD is an open community session, likely to cover much of the same ground as the GAC and GNSO meetings, scheduled for 1500 UTC on January 18. Details here.

The GNSO Council is then scheduled to meet January 20 for its regular monthly meeting, during which next steps will be discussed. It will also meet with the ICANN board later in the month to discuss its concerns.

1 Comment Tagged: epdp, gac, gdpr, gnso, ICANN, privacy, ssad, whois

ICANN trying to water down its transparency obligations

ICANN? Trying to be less transparent? Surely not!

The Org has been accused by some of its community members of trying to shirk its transparency obligations with proposed changes to its Documentary Information Disclosure Policy.

The changes would give ICANN “superpowers” to deny DIDP requests, and to deny them without explanation, according to inputs to a recently closed public comment period.

The DIDP is ICANN’s equivalent of a Freedom of Information Act, allowing community members to request documentation that would not be published during the normal course of business.

It’s often used, though certainly not exclusively so, by lawyers as a form of discovery before they escalate their beefs to ICANN accountability mechanisms or litigation.

It already contains broad carve-outs that enable ICANN to refuse disclosure if it considers the requested info too sensitive for the public’s eyes. These are the Defined Conditions for Nondisclosure, and they are used frequently enough that most DIDPs don’t reveal any new information.

The proposed new DIDP broadens these nondisclosure conditions further, to the extent that some commentators believe it would allow ICANN to deny basically any request for information. New text allows ICANN to refuse a request for:

Materials, including but not limited to, trade secrets, commercial and financial information, confidential business information, and internal policies and procedures, the disclosure of which could materially harm ICANN’s financial or business interests or the commercial interests of its stakeholders who have those interests.

The Registries Stakeholder Group noted that this is “broader” than the current DIDP, while the At-Large Advisory Committee said (pdf) it “essentially grants ICANN the right to refuse any and all requests”.

ALAC wrote that “rejecting a request because it includes commercial or financial information or documents an internal policy makes a mockery of this DIDP policy”.

Jeff Reberry of drop-catch registrar TurnCommerce concurred (pdf), accusing ICANN of trying to grant itself “superpowers” and stating:

Extremely generic terms such as “confidential business information” and “commercial information” were added. Frankly, this could mean anything and everything! Thus, ICANN has now inserted a catch-all provision allowing it to disclose nothing.

Other comments noted that the proposed changes dilute ICANN’s responsibility to explain itself when it refuses to release information.

Text requiring ICANN to “provide a written statement to the requestor identifying the reasons for the denial” has been deleted from the proposed new policy.

A collection of six lawyers, all prolific DIDP users, put their names to a comment (pdf) stating that “the change results in less transparency than the current DIDP”.

The lawyers point out that requests that are denied without explanation would likely lead to confusion and consequently increased use of ICANN’s accountability mechanisms, such as Requests for Reconsideration. They wrote:

Simply stated, the Revised Policy allows ICANN to obscure its decision-making and will ultimately cause disputes between ICANN and the Internet community — the complete opposite of the “accountable and transparent” and “open and transparent processes” required by ICANN’s Bylaws.

One change that didn’t get much attention in the public comments, but which certainly leapt out to me, concerns the turnaround time for DIDP responses.

Currently, the DIDP states that ICANN “will provide a response to the DIDP request within 30 calendar days from receipt of the request.”

In practice, ICANN treats this obligation like one might treat a tax return or a college essay — it almost provides its response exactly 30 days after it receives a request, at the last possible moment.

The revised DIDP gives ICANN the new ability to extend this deadline for another 30 days, and I don’t think it’s unreasonable to assume, given past behavior, that ICANN will try to exploit this power whenever it’s advantageous to do so:

In the event that ICANN org cannot complete its response within that 30-calendar-day time frame, ICANN org will inform the requestor by email as to when a response will be provided, which shall not be longer than an additional 30 calendar days, and explain the reasons necessary for the extension of time to respond.

The predictably Orwellian irony of all of the above proposed changes is that they come in response to a community review called the Cross-Community Working Group on Enhancing ICANN Accountability Work Stream 2 (WS2), which produced recommendations designed to enhance accountability and transparency.

Whether they are adopted as-is or further revised to address community concerns is up to the ICANN board of directors, which is of course advised by the staff lawyers who drafted the proposed revisions.

ICANN staff’s summary of the seven comments submitted during the public comment period is due next week.

Comment Tagged: accountability, alac, didp, ICANN, rysg, transparency, turncommerce, ws2

A decade after the last new gTLD round, Marby starts the clock on the next one

The next new gTLD application is moving a step closer this month, with ICANN chief Göran Marby promising the launch of its Operational Design Phase.

But it’s still unclear whether the ODP has officially started, and many community members are angry and frustrated that the process is taking too long, some 10 years after the last application window opened.

Marby published a blog post December 20 stating “the org has advised the Board that it is beginning the ODP”, but he linked to a December 17 letter (pdf) that told the board “the org is now transitioning to launch the ODP formally as of January”.

We’re well into January now, so does that mean the ODP has officially started? It’s not clear from what ICANN has published.

It seems either ICANN doesn’t yet want to pin down an exact date for the ODP being initiated, which starts the clock on its deadline for completion, or it’s just really bad at communications.

In September, the board gave Marby $9 million and 10 months for the ODP to come up with its final output, an Operational Design Assessment.

The project is being funded from the remaining application fees from the 2012 application round, rather than ICANN’s regular operations budget.

The text of the resolution gives the deadline as “within ten months from the date of initiation, provided that there are no unforeseen matters that could affect the timeline”.

Assuming the “date of initiation” is some point this month, the ODA would be therefore due to be delivered before the end of November this year, barring “unforeseen matters”.

The document would then be considered by the ICANN board, a process likely to be measured in a handful of months, rather than weeks or days, pushing a final decision on the next round out into the first quarter of 2023.

For avoidance of doubt, that’s the decision about whether or not to even have another new gTLD round.

As a reminder, the 2012 round Applicant Guidebook envisaged a second application round beginning about a year after the first.

Naturally, many would-be applicants are incredibly frustrated that this stuff is taking so long, none more so than the Brand Registry Group, which represents companies that want to apply for dot-brand gTLDs and the consultants that want to help them do so.

Overlapping with ICANN’s December 17 letter to the board, BRG president Karen Day wrote to ICANN (pdf) to complain about the lack of progress and the constant extensions of the runway, saying:

The constant delay and lack of commitment to commencing the next round of new gTLDs is unreasonable and disrespectful to the community that has worked diligently… these delays and lack of commitments to deliver the community’s work is an increasing pattern which risks disincentivizing the volunteer community and threatens the multistakeholder model

Day asked the board to provide more clarity about the ODP’s internal milestones and possible delaying factors, and called for future work to begin in parallel with the ODP in order to shorten the overall roadmap.

It’s worth noting that the ODP may wind up raising more questions than it answers, delaying the next round still further.

It’s only the second ODP ICANN has conducted. The first, related to Whois privacy reform, ended in December (after delays) with a report that essentially shat all over the community’s policy work, predicting that it would take several years and cost tens of millions of dollars to implement for potentially very little benefit.

The board is expected to receive that first ODP’s report in February and there’s no telling what conclusions it will reach.

While Marby has publicly indicated that he’s working on the assumption that there will be another new gTLD round, the ODP gives ICANN a deal of power to frustrate and delay that eventuality, if Org is so inclined.

Comment Tagged: brg, ICANN, new gTLDs, oda, odp, subpro

Monte Cahn revealed as third new gTLD buyer

Domain investor Monte Cahn has revealed himself as the third partner in the controversial acquisition of new gTLD .hiphop from UNR.

Cahn Enterprises named itself alongside already-reported consultant Jeff Neuman of JJN Solutions and publicly traded startup Digital Asset Monetary Network (DigitalAMN) as a partner in newly formed registry vehicle Dot Hip Hop LLC.

DHH bought .hiphop privately from Frank Schilling’s UNR last April at around the same time as UNR auctioned off the other 22 gTLDs in its portfolio, exiting the registry business.

Cahn founded the registrar Moniker, aftermarket pioneer SnapNames and gTLD auction coordinator RightOfTheDot.

RightOfTheDot’s Scott Pruitt has also joined DHH to lead marketing, Cahn’s press release revealed.

The new registry plans to lower the price of .hiphip domains, which currently retail for over $150 a year, as part of an effort to get broader adoption in the hip-hop cultural community.

The company is strongly pushing digital empowerment and “financial literacy” in an “underserved” community as a public benefit of its plans for the TLD.

The problem DHH continues to face is ICANN’s ongoing blocking of the transfer of .hiphop, and the other 22 UNR TLD contracts, due to confusion about the ownership status of matching TLDs on the Ethereum Name Service, a blockchain-based alt-root.

ICANN is fearful of alternative DNS roots which, if they ever gain broad appeal, in theory could break internet interoperability as well as eroding ICANN’s own uniquely powerful and uniquely lucrative authority over the DNS.

DHH’s Neuman recently accused ICANN of foot-dragging and retaliation over the delayed transfers, which is costing the DHH partners money while their legal status is in limbo and they are unable to sell any names.

ICANN’s top brass subsequently denied these accusations, saying the Org is merely following its established (and rather convoluted) appeals procedures.

While these procedures could delay approval of .hiphop’s transfer for another few months, forcing DHH to burn more capital, ICANN said it is “considering the potential impact on the requestor as we have been requested to do”, so it may cut DHH some slack.

3 Comments Tagged: .hiphop, cahn enterprises, dhh, DigitalAMN, dot hip hop, ICANN, jjn solutions, new gTLDs, unr

“National security” cited as registry says you have to ask its CEO if you want to register more than TWO domains

India, a country with some 2.2 million ccTLD domains, has implemented perhaps the strangest and most Draconian restrictions on bulk registration of modern times.

The local registry, NIXI, informed its registrars all over the world in late December that they will have to seek formal written permission directly from the CEO if a customer wishes to register more than two .in domains.

Registrars breaking the rules face losing their accreditation, NIXI said.

A terse notice (pdf) published on the registry’s web site, signed by CEO Anil Kumar Jain, reads:

It is decided that a written approval of CEO, NIXI is required if an individual Registrant submit a request for registering more than two domains.

In case a registered accredited company try to book domains more than 100 than also a written approval of CEO, NIXI is required.

In case any Registrar is booking domains violating the above norms NIXI has right to disallow/disconnect the domains booking under that category. A process may be initiated for de-accreditation of such Registrar.

Approval will be given within 24 hours of a request, regardless of weekends or holidays, the notice reads.

Asked for clarification, Jain told DI in an email that the “new procedure is drawn after reviewing national security concerns” and that “NIXI registry is not stopping any domain registration.”

“An individual can book up to 2 domains and a company can book up to 100 domains without permissions,” he wrote. “Permission sought is given within 24 hrs.”

The new rule has registrars scratching their heads, with one describing it as “crazy”, “very vague” and very difficult to enforce.

NIXI uses GoDaddy Registry as its back-end, but GoDaddy does not appear to be playing a role in the implementation of the new policy. A spokesperson said in a statement:

At this time, the responsibilities are on the registrars and it’s a discussion between NIXI and them. As the back-end provider, we work closely with .in on any changes they would like to make at the registry level.

2 Comments Tagged: .in, godaddy, nixi

Whois reform to take four years, cost up to $107 million A YEAR, and may still be pointless

ICANN’s proposed post-GDPR Whois system could cost over $100 million a year to run and take up to four years to build, but the Org still has no idea whether anyone will use it.

That appears to be the emerging conclusion of ICANN’s very first Operational Design Phase, which sought to translate community recommendations for a Standardized System for Access and Disclosure (SSAD) into a practical implementation plan.

SSAD is supposed to make it easier for people like trademark owners and law enforcement to request personal information from Whois records that is currently redacted due to privacy laws such as GDPR.

The ODP, which was originally meant to conclude in September but will now formally wrap up in February, has decided so far that SSAD will take “three to four years” to design and build, costing between $20 million and $27 million.

It’s calculated the annual running costs at between $14 million and $107 million, an eye-wateringly imprecise estimate arrived at because ICANN has pretty much no idea how many people will want to use SSAD, how much they’d be prepared to pay, and how many Whois requests they will likely make.

ICANN had previously guesstimated startup costs of $9 million and ongoing annual costs around the same level.

The new cost estimates are based on the number of users being anywhere between 25,000 and three million, with the number of annual queries coming in at between 100,000 and 12 million.

And ICANN admits that the actual demand “may be lower” than even the low-end estimate.

“We haven’t been able to figure out how big the demand is,” ICANN CEO Göran Marby told the GNSO Council during a conference call last month.

“Actual demand is unknowable until well after the launch of the SSAD,” an ICANN presentation (pdf) states. The Org contacted 11 research firms to try to get a better handle on likely demand, but most turned down the work for this reason.

On pricing, the ODP decided that it would cost a few hundred bucks for requestors to get accredited into the system, and then anywhere between $0.45 and $40 for every Whois request they make.

Again, the range is so laughably broad because the likely level of demand is unknown. A smaller number of requests would lead to a higher price and vice versa.

Even if there’s an initial flurry of SSAD activity, that could decline over time, the ODP concluded. In part that’s because registries and registrars would be under no obligation to turn over records, even if requestors are paying $40 a pop for their queries.

It’s also because SSAD would not be mandatory — requestors could still approach contracted parties directly for the info they want, for low or no cost, if they think the price of SSAD is too high or accreditation requirements too onerous.

“There’ll always be a free version of this for everybody,” Marby said on the conference call.

In short, it’s a hell of a lot of money for not much functionality. There’s a better than even chance it could be a huge waste of time and money.

An added complication is that the laws that SSAD is supposed to address, mainly GDPR, are likely to change while it’s being implemented. The European Union’s NIS2 Directive stands to move the goalposts on Whois privacy substantially, and not uniformly, in the not-too-distant future, for example.

This is profoundly embarrassing for ICANN as an organization. Created in the 1990s to operate at “internet speed”, it’s now so bloated, so twisted up it its own knickers, that it’s getting lapped by the lumbering EU legislative process.

The ODP is set to submit its final report to ICANN’s board of directors in February. The board could theoretically decide that it’s not in the interest of ICANN or the public to go ahead with it.

Marby, for his part, seems to be thinking that there could be some benefit from a centralized hub for submitting Whois requests, but that it should be simpler than the current “too complex” proposal, and funded by ICANN.

My take is that ICANN is reluctant to move ahead with SSAD as it’s currently proposed, but because top-down policy-making is frowned upon its hands are tied to make the changes it would like to see.

2 Comments Tagged: epdp, gdpr, ICANN, nis2, odp, privacy, ssad, whois

New year, new server, new functionality

Happy new year everyone!

I recently migrated DI to a new server that should allow me to both fix some issues that have bugged the site for a while, and also introduce new functionality.

It’s been a frustratingly complex process — my old hosting account was the best part of 20 years old and running incredibly outdated software that made it vulnerable and incompatible with modern must-haves.

It’s been a bit of a learning curve moving to a more modern platform, and I haven’t ironed out all the kinks yet, but I’m happy to announce that as of today Domain Incite is now SSL-enabled and mobile-friendly.

I’m not a phone person. I can’t imagine ever wanting to look at a web site on a phone, but I know lots of people do, and readers have sometimes complained that DI wasn’t particularly easy on the eye.

If that’s you, it should be easier to read from now on. You’re welcome.

I’ve also installed SSL, something else I’ve been asked about frequently. DI doesn’t ask you for any sensitive information, so I don’t know why anyone would want their traffic encrypted. But now it is, whether you like it or not.

Please do let me know if you find any weirdness or bugs in either of these features, or indeed anywhere else on the site, and I’ll do my best to address them.

7 Comments