Category: domain names

Connect.com domain name acquired by Hubspot for $10 million

[NB: As I’ve noted on Twitter,

I don’t appreciate folks who are not citing my work. So, I’m “on strike”. That being said, I’ll make an exception for an eight-figure domain name transaction.]

Hubspot disclosed in a SEC filing (see p. 20) that they acquired the Connect.com domain name for USD $10 million:

In the three months ended June 30, 2022, the Company purchased the rights to the domain name “connect.com” for $10.0 million.

I’d write a longer analysis, but as I said, I’m on strike. People should appreciate that very few are actually doing original research. If you use their hard work , then you should cite and link to it, rather than just taking the results of that research to generate page views, attention, or advertising revenue (remember, this site has no ads). Don’t be a parasite or a ‘taker’. Be a giver.

There’s an important ICANN comment period about transfers policy, where I’ve asked for a deadline of mid-September in order to complete my own comments in a thorough manner. Ensuring domain names aren’t stolen should be everyone’s priority, but that working group would lower security by eliminating an important safeguard (namely the ability to “NACK” a transfer before it has completed). The Internet Commerce Association submitted a comment a couple of days ago,  echoing some of the concerns I expressed on my blog. But, my concerns and comments go far deeper, and I need the time to write them all up.

If you appreciate this work, why don’t you take a moment and contact them to reiterate the need for a mid-September deadline? (see their contact info in my previous blog post here)

Update: Elliot Silver reported on the change of ownership of of the domain name in an April blog post (although, at the time the price was not known). DomainGang also recently reported on a matching TM filing. (these articles didn’t impact my research, but are worth mentioning regardless)

Die Hard Opposition To Reduced Security For Domain Name Transfers

A few days ago, I wrote about a dangerous proposal at ICANN to reduce security of domain name transfers. They extended the public comment period by 2 weeks (which is still insufficient for me), so they’re now due August 16, 2022.

Here’s a simple metaphor to understand what’s really going on. Under the current system, it’s like owning a savings account at Citibank (where it’s protected by 2FA, etc.).  You want to transfer that to Wells Fargo (where it would also be protected by 2FA, etc.). You request the transfer (between banks) and they coordinate it securely (with checks and balances throughout). It’s a safe process, a verified process.

Instead, under the new “faster and easier” proposal, to make things “better”, they want you to convert your savings account into a BEARER BOND at your Citibank Branch (i.e. the new TAC, transfer authorization code, formerly known as the AuthInfo code is essentially the ‘keys to the kingdom’ so that anyone holding that code controls the future of that domain), and then walk it across the street or across town to deposit it at your Wells Fargo account. What could possibly go wrong?

Maybe if it’s a $10 ‘asset’, converting it into a bearer bond (or cash, for a less interest metaphor, with a less creative blog post title) is no big deal. But, if it’s a $1 million asset or $640 million asset**, you start to get a little bit worried! So, I’ve been vehement that there are inherent risks carrying around a bearer bond, even for a short time! No, no, they say….this is BETTER! LOL You’re crazy, George, bearer bonds are the way, they say! Can’t you see it?

So, I’m trying to argue for at least a “certified cheque” with my name on it, or better yet a WIRE TRANSFER between banks (secure, just a little bit slower). But, they insist on BEARER BONDS as being the future!

Frustrating!

P.S. **Credit to “Die Hard” for the Bearer Bonds idea.

Double Red Alert: Domain Registrars Seek Power Grab To Deny Outgoing Transfers Of Legal Domains They Dislike

As I noted in a prior post on the weekend, there’s an important ICANN public comment period that ends on Tuesday August 2, 2022 regarding the transfers policy. It contains serious security flaws that would make domain name hijacking easier, by removing the ability to NACK the transfer after the transfer request has been initiated. I won’t be able to submit comments by Tuesday, and have asked that they extend the deadline.

However, in my research I came across another startling power grab by registrars (who dominate the composition of that working group), that was inserted into the recommendations.  Recommendation #19 at the bottom of page 32 of the report contains the following text:

ICANN Transfers Policy Rec #19

They propose to broaden the discretion of registrars to block an outgoing domain name transfer, from the limited “evidence of fraud” to the far broader “Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies.”

I had tweeted about this on the weekend:

and noted that it was “ripe for misuse”, since a use that one registrar forbids (politics, porn, casino, crypto, etc.) that isn’t illegal everywhere (like FRAUD) would trap a domain at that registrar (and ultimately lead to its deletion, if it couldn’t be renewed). A registrant couldn’t transfer the domain name to a registrar where that use is legal.

This is what happens when the working group is dominated by participation of registrars, without considering what the impact is for registrants. It’s one-sided and unbalanced.

Indeed, the transcript of that working group’s May 24, 2022 call is quite telling. [I literally stumbled upon that randomly this morning, while looking for something else]

On pages 15-16, Owen Smigelski of NameCheap (formerly of ICANN, and before that Sunrider — interesting lawsuit here that mentions him and also here) states:

But the rationale behind broadening the reasons for this denial is because evidence of fraud—fraud has a very specific definition. It means deceit of some type or trying to scam somebody or an illegal activity in there. It could be considered a very narrow definition. There are certain scenarios that might come up where a registrar might want to block the transfer for violation of terms of service.

So for example, Namecheap doesn’t want our services being used for hate speech but somehow somebody registers a domain name that’s hosting a Nazi website or a Holocaust denying website. Technically, that’s not fraud and we wouldn’t be able to block such a transfer. But if we wanted to, under our terms of service, which
says, you can’t post hate speech, we decided we want to block that transfer, we’d be able to do that as a material violation of our agreement as opposed to being forced to let somebody put something out there that us as a company does not want to escape further into the wild.

This is incedibly poor reasoning, indeed dangerous for registrants. It’s one thing to say “we don’t want you as a client”, but another thing to say “we’re going to prevent you from taking your domain elsewhere” over a dispute of the terms of service (as opposed to actual criminal activity).

While despicable, hate speech is legal in the United States. (Inciting violence isn’t legal, but hate speech itself is legal) Same goes for Nazi and Holocaust denying websites, at least in the United States (where NameCheap is based, and the jurisdiction of its registration agreement).

Volker Greimann immediately pushed back against that in the working group, saying (page 16 of the transcript):

I agree in principle but I think the language is a bit
too broad because simply put, a registrar can make anything a material violation of the registration agreement. We certainly have non-payment of fees in there. We have provision of incorrect registration data in there. We have all kinds of things that we consider a material violation of our registration agreement. And we might not want to have all of them be a reason for blocking a transfer. So I think we need to be a bit more specific. It’s hard [inaudible].

On pages 17-18 of the transcript, Mr. Smigelski brought up the concept of “guardrails”:

And Volker, I agree that that’s a concern and that’s why I want to put those guardrails in there and implementation note, which would be in a report and then, carried forward into an eventual policy to give some more guidelines on that. Happy to consider other wording to put that in there. I was just trying to give some flexibility to the registrars who might want to block for whatever reason. But also, at the same, making [inaudible] you didn’t cross a T properly, so we’re going to deny the transfer.

Yet, if you go back to the actual text in Recommendation #19 above, there are no guardrails! It’s just a pure power grab. Indeed, Mr. Smigelski literally said above “I was just trying to give some flexibility to the registrars who might want to block for whatever reason.”

Read that again! “…who might want to block for whatever reason.”

Zak Muscovitch (of the Internet Commerce Association, which is pro-registrant, but representing the Business Constituency (BC) in his participation in the working group; the BC  is essentially captured by trademark holders — i.e. it’s mostly a clone of the Intellectual Property Constituency) entered the debate on page 20 of the transcript:

This isn’t a hill that I would come close to dying on, but I’m just wondering, if there is a registrant that is violating a registrar’s domain use or anti-abuse policies or Namecheap’s anti-hate speech policies, that’s one thing. But let’s imagine a registrar that—because registrars can write in anything they bloody well want into a registration agreement. They can say that you’re not allowed to use a domain name for anything about the color blue. And so, someone’s using it for the color blue and maybe the registrar has the right to disable them from using the domain name at their registrar.

But if that registrar [sic — should be “registrant”] wants to move it to another registrar, that doesn’t have this policy, there’s another willing registrar, what’s the problem with the registrar of records saying, yeah, get the hell out of our registrar with that blue-related use of your domain name. If you could find someone else that doesn’t have that policy and tolerates it, by all means, it’s out of our hair. I think there’s an important distinction between permitting a registrant to use a domain name not one that’s registered in violation of one’s policies, but getting them out of there is a different thing.

With all due respect to Zak, it might be a “hill worth dying on” (although there are so many bad things coming out of ICANN, it’s tough to pick and choose!). It’s a very dangerous proposal. It’s being sneaked into the transfers policy recommendations, which few people are monitoring (because it’s supposed to be a “technical” working group), instead of having a broader debate in an anti-abuse working group (where the definition of “abuse” is very carefully monitored).

Let’s take a look at NameCheap’s registration agreement to see precisely what they consider to be undesirable:

You agree not to use the Services provided by Namecheap, or to allow or enable others, to use the services provided by Namecheap for illegal or improper purposes. As such, you agree not to:

  • violate the laws, regulations, ordinances or other such requirements of any applicable Federal, State or local government, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct) and applicable consumer laws in respect of fair lending, debt collection, organic farming (if applicable), disclosure of data and financial regulation;
  • transmit any unsolicited commercial or bulk email, not to be engaged in any activity known or considered to be spamming or Mail Bombing;
  • cause repetitive, high volume inquiries into any of the services provided by Namecheap (i.e. domain name availability, etc.);
  • infringe any copyright, trademark, patent, trade secret, or other proprietary rights of any third-party information;
  • use the Services for content that will profess hatred for particular social, ethnical, religious or other groups;
  • use the Services to distribute viruses, malware, abusively operating botnets, phishing, Trojan horses, worms, time bombs, corrupted files, or any other similar software or programs that may damage the operation of a computer or a person’s property;
  • contain warez; contain any kind of proxy server or other traffic relaying programs; promote money making schemes, multi-level marketing or similar activities; contain lottery, gambling, casino; contain torrent trackers, torrent Portals or similar software;
  • redirect to another website without their permission and/or to impersonate another person or company;
  • use for the purposes of impersonating another person or entity such as redirecting a domain to another website without permission and/or using a domain to send fraudulent or abusive emails;
  • use the Services in a manner that is violent or encourages violence;
  • violate the Ryan Haight Online Pharmacy Consumer Protection Act of 2008 or similar legislation, or promote, encourage or engage in the sale or distribution of prescription medication without a valid prescription;
  • use the Services for fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law.

One can see immediately that it’s very broad (like most registration agreements at registrars). Note how the very first sentence states that it’s not just “illegal” purposes, but also “improper“, which is extremely broad and subjective. Indeed, NameCheap (or any other registrar granted such discretionary powers to block outgoing transfers) would presumably be judge, jury, and executioner, and wouldn’t rely on an actual court to make a decision.

I’m not going to go through every point in their agreement (since I already made the “hate speech” arguments above), but let’s take a look at the “spam” language, namely “transmit any unsolicited commercial or bulk email”. The word “any” is quite powerful (i.e. just 1 message is enough! How would domains of political parties ever survive, given how often their messages are marked as spam?), especially when combined with the fact that it’s not just your own behaviour as domain name owner that matters — one also needs to police “others” as per the very first line above.

Would a domain name like Gmail.com pass that test, given it allows others to send messages? Gmail.com is used by a considerable number of spammers. Of course, Google takes anti-spam measures seriously, but one could easily interpret that domain as being in violation of NameCheap’s agreement. Google is very powerful and would fight back, so NameCheap would never use that weapon against someone like them. Instead, they would tend to use that weapon against the less powerful. However, the less powerful are those that most need to be protected against misuse of such discretionary powers. Raise your hand if you’re less powerful than Google…(of course, Google doesn’t have Gmail.com at NameCheap).

How about the part about “redirect to another website without their permission” — would the famous Loser.com domain be trapped by such a policy? It has been redirected to numerous sites (like that of Al Gore), presumably without permission.

Actually, going back to the “hate” text, their terms are “profess hatred for particular social, ethnical, religious or other groups;” Would it be a violation of their agreement to say that you “hate spammers” or  “hate the New York Yankees and their fans” or “hate dumb lawyers in ICANN working groups with too much time on their hands”? Spammers, New York Yankees fans and dumb lawyers in ICANN working groups with too much time on their hands are certainly “groups” and thus fall under “other groups“.

How about the part about “infringe any copyright”? Any site with user-generated content regularly has challenges in that regard. But, you’re at NameCheap’s discretion. They simply want the power to go after the “bad guys”, to trust them not to misuse their discretionary power.

I think that the people we should mistrust are those who seek extraordinary and one-sided powers in the first place.

In conclusion, this report is replete with dangerous proposals that will harm registrants. An extension of time is needed so that the public can fully digest the report and submit high quality comments.

Red Alert: ICANN Working Group Wants To Make It Easier To Hijack Domain Names

There’s an important ICANN public comment period that ends on Tuesday August 2, 2022 regarding the transfers policy. I haven’t finished my own comments yet, but I thought it important to sound the alarm, as only 4 comments have been submitted to date.

Andrew Allemann of DomainNameWire.com had blogged about this topic in June, yet it seems that wasn’t enough to get folks engaged. [although, perhaps folks are sick of being ignored, given ICANN comment periods are notorious for being shams]

One of the biggest changes, as Andrew noted, would be the elimination of the ability to reject a pending transfer request (before the transfer has been completed), aka “NACKing” the transfer. (in contrast, an “ACK” would approve a transfer) This was recommendation #2 on page 18 of the report. This is a recipe for disaster. The registrant would be notified after the domain transfer has already completed, and would not have ample opportunity to reject a pending transfer. A fast-acting domain name thief could successfully complete a transfer before a registrant is even aware of a pending transfer.

This sham report hides the enormous negative impact that this change would have, by not even mentioning in their analysis the number of times the “NACK” procedure has saved a domain from an unauthorized transfer. Andrew’s own comment submission wondered about those stats, asking:

It would be interesting to hear from registrars about how many times customers try to stop fraudulent transfers after receiving the FOA.

I found the numbers he sought. Page 11 of the initial report linked to a separate “Status Report” from 2019.  Page 12 of that Status Report mentioned that there were approximately 4,968,000 domain transfer per year, roughtly 0.3% of total domain name registrations. Chart 4 on page 23, and the table on page 24, show that “NACKs” are done an average of 12,348 times, vs. an average of 414,000 transfers per month. That means that approximately 1 in every 34 domain name transfers is NACKed!

That means, in the course of a year (12 months), approximately up to** 150,000 domains are saved from unauthorized transfer attempts by the “NACK” system. [Update August 1: the data didn’t have the granularity to specify the reason for each NACK, so I changed the word “approximately” to “up to”, since conceivably a NACK might take place for another reason.]

Ask yourself this: Why did the working group not put these numbers directly into their own report? 

This ICANN working group foolishly proposes to eliminate this “security in depth” procedure, instead proposing that a new system be designed to allow one to “undo” a transfer. (to be determined in a future phase of the working group). That proposal disregards 2 obvious problems:

  1. The immense damage that can take place in a short time when a domain name is hijacked (e.g. resetting passwords of linked 3rd party accounts by hijacking emails, e.g. bank accounts, crypto accounts, social media, etc.) cannot simply be undone by reversing a domain transfer.
  2. An “undo” procedure for domain transfers was already hotly debated in the past, and rejected, as it would severely impact the secondary market for domain names. This was the “Expedited Transfer Reversal Policy” (ETRP) in the IRTP-B working group, that I led the charge against in 2010 (see the public comments on that proposal here). It should be obvious that “sellers’ remorse” and pure fraud would be the result if a former registrant could simply undo a transfer. [They mention the ETRP on page 31 of the report, but didn’t go into detail as to why it was soundly rejected by the community, after considerable debate.]

This horrible report from ICANN literally exacerbates a problem (increased unauthorized/fraudulent transfers via lowered security), and then seeks to resurrect a rejected policy from the past to “solve” the problem!

How did such a flawed report get so far? One of the problems was the composition of the working group, with domain name registrants severely underrepresented (see pp. 46-47 for the names of those responsible for the report). I’ve pointed this out for other working groups (e.g. the RPM PDP was dominated by pro-complainant participation; the recent IGO working group showed even more shocking unbalanced participation). Of course, I’m unfairly banished from all ICANN working groups.

There’s more to say about this garbage report, but time is of the essence so I’m posting this article today, before I’ve completed my own comments. I’ll also request an extension of the comments deadline (others should do so too), given few in the community are aware of the negative impacts of these proposals, dropped in the summertime when few are paying attention.

P.S. To request that the comments deadline be extended (I requested it be extended until the 2nd week of September), your best bets are to contact:

  1. Emily Barabas of ICANN: email on ICANN website
  2. Roger Carney of GoDaddy (chair of working group): email via mailing list archives

P.P.S. After additional research, I found a newspaper article in the Globe & Mail titled “Canada saw surge in phone-number fraud in 2019, 2020, figures show” (POSADZKI, ALEXANDRA; page B2, Sept. 29, 2021) The article is paywalled, but I found the print article using a different database. That article notes that there were 21,589 fraudulent customer ports in the Canadian phone number system over a 10 month period from mid-2019 to 2020. These are similar to domain name thefts, but for phone numbers. Roughly 1 percent of transfers were unauthorized (with a peak in a single month of 2.5%). By reducing security of domain name transfers, ICANN would be making similar attacks on domain names easier. The damage from a domain name hijacking might be far greater in many cases than the payoff from phone fraud. This is the kind of data that should inform policymaking, yet is missing from the ICANN working group’s analysis.

P.P.P.S. If you need ‘evidence’ of the deadline being unreasonable, I
point to the comments last year by Mike Rodenbaugh, on behalf of the
IPC:

“I should have spoken up earlier about the unreasonable timeframe to require constituency comments be drafted in July. Anyway now I do need to note that the IPC written comments will not be ready by tomorrow. We have struggled to coordinate during the July holiday season (for many). But we are fully in motion now. We are still taking input and drafting responses, and hope to have a constituency position at least as to the Phase 1 questions in the next 2 or 3 weeks.”

in response to an unreasonable timeframe. Unlike the IPC, which is able to provide continuing input due to their representation within the working group itself, the broader community is not adequately represented (particularly registrants), meaning that the public comments are their only opportunity for feedback to the working group.

Update: July 31, 2022

There was an article about how Canadian mobile phone porting requests were made more secure, by adding verification:

The carriers have launched a new mobile number porting system that requires customers to respond to an SMS confirmation before porting occurs.

It essentially offers additional verification to ensure a request from another provider to transfer a customer’s service. It also confirms that the telephone number is generated by the customer and not a fraudster. If the customer doesn’t confirm the request then the transfer will not take place.

Unlike domains, where a transfer goes through if there’s no response to the ACK/NACK email, the cell phone porting out verification is better. By default the phone number won’t port out if there’s no response.

Here’s an example of what that verification looks like, in the Canadian mobile phone system (see the “Transferring Your Public Mobile Number To Another Service Provider” section at the very bottom):

Transferring Your Public Mobile Number To Another Service Provider​

To help protect our customers from fraud, Public Mobile will send you an SMS text message should we receive a request to transfer your mobile phone number to another carrier. This step is designed to protect your account by confirming if the request is genuine or fraudulent.

The SMS text will read as follows: Public Mobile message: We’ve received a request to transfer this phone number to another service provider. To approve this request, please reply “Yes”. If you did not request this transfer, please reply “No”. Please note that you must respond within 90 minutes. If we don’t receive a response within this time, the request will be automatically cancelled. For any issues with this number transfer, contact our Porting Team. Thank you.

While not perfect (it doesn’t tell you which provider it’s being switched to, which is a potential vulnerability), it’s better to have this layer of protection. With the ACK/NACK that we currently have with domains, one can see which registrar it’s being moved to, which is an important piece of information (if it’s being moved to the wrong registrar, you can cancel/reject the transfer).

Yet, ICANN’s working group wants us to go BACKWARDS, and reduce security.

Second Update of July 31, 2022

It’s not feasible for me to complete my submission by the current deadline of Tuesday August 2, 2022. So, I instead submitted a 2 page request for an extension of time to ICANN. See the request here (and also the PDF attachment).

ICANN Staff Ignore UDRP Public Comments That Don’t Fit Their Agenda

ICANN staff recently prepared a “Revised Uniform Domain Name Dispute Resolution Policy (UDRP) Policy Status Report (PSR)” (see PDF here) for the consideration of GNSO Council, and to guide any future policy development at ICANN. They even prepared a red-line version (see PDF here) to show what changes were made since the public comment period which ended in April 2022. The main change is the last 4 pages of the document, which has a list of “suggested improvements” submitted by the community.

My own company’s submission can be read here. Starting at the bottom of page 8 of the main PDF, I submitted numerous topics that should be addressed in a review. For example:

  • explicit opt-out provision
  • limitation period for complaints
  • optional “legal contact” within WHOIS
  • time to respond to complaints should be expanded, based on the age of the domain
  • “registered in bad faith” date to be explicitly set as the creation date of the domain
  • explicity permit transfers of ownership within related entities without impacting UDRP date tests
  • formal mediation step
  • ensure court review (for which I submitted an entirely separate PDF!)
  • merging URS and UDRP into a single procedure
  • greater oversight for providers and panelists

Now here’s the fun part — go try to find these referenced in the ICANN staff prepared document! They’re not there! (I suggest others who submitted their own comments review the ICANN summary, to see whether their own input was ignored.)

This demonstrates the bad faith on the part of ICANN staff, that public input that does not fit their agenda is completely ignored.

In conclusion, as I’ve pointed out repeatedly, ICANN public comment periods are a sham.

ICANN IGO Working Group Chair Disspain Admits They Would Be Significantly Challenged On Scope

As we’ve noted in our recent blog posts, here, here, here and here, the ICANN GNSO Council intends to vote (on Thursday May 19, 2022, tomorow!) on a controversial Final Report which would severely harm the rights of domain name registrants to judicial review of an adverse UDRP decision. This is in sharp contrast to the charter of that working group, which required that the rights to judicial review be preserved.

In my review of the call transcripts, it’s clear that the Chair of the Working Group, Chris Disspain, knew and understood that they had to preserve those rights to judicial review. In fact, on the January 10, 2022 working group call, here’s what he had to say:

And the bottom line is, irrespective of all of that, that our charter, our instructions from the GNSO Council very clearly states that our solutions should not affect the rights and ability of registrants to quality judicial proceedings, a court of competent jurisdiction, whether following a UDRP or URS case or otherwise. [pp.38-39]

Boom! Yet, as discussed in prior blog posts, that very standard that they were entrusted to meet was simply not met. Rights to judicial review are severely harmed, and not preserved. “Quality judicial proceedings” and a “court of competent jurisdiction” are sacred – yet this final report, if adopted, would effectively be taking those rights away from registrants.

Chris Disspain went on! On page 39, he continued:

So I would argue that we would be significantly challenged on scope, I suspect, if we were to make a recommendation that required an IGO to go to court and to not have a substantive hearing on the merits, which of course is what would happen if IGOs were successful in claiming their immunities.

That is why yesterday’s “friendly amendment” is a sham and an obscene document.

By exempting IGOs from the mutual jurisdiction clause, they enhanced the ability of IGOs to successfully assert immunity (as the mutual jurisdiction clause would usually be interpreted as a waiver of immunity). They are in violation of their charter. They would and should be “significantly challenged on scope.” There would be no “substantive hearing on the merits” at courts. As the Final Report itself concedes:

Conversely, the EPDP team acknowledged that removing this requirement for IGO Complainants could prejudice a registrant’s right and ability to have an initial UDRP or URS determination reviewed judicially, in that a successful assertion of immunity by an IGO means that the court in question will decline to proceed with the case. [pp. 23-24]

They “prejudiced” the rights to judicial review – the working group failed to preserve them.

As the Internet Commerce Association argued in their own comment submission:

Preliminary Recommendation #3 – exempting IGOs from the usual requirement of agreeing to a Mutual Jurisdiction for a challenge to a UDRP transfer without guaranteeing the right of a registrant to have its case heard on the merits – is unjustified and should not be
accepted by the GNSO. By exempting IGOs from agreeing to the Mutual Jurisdiction requirement, registrants are left with the very real possibility that a national court will refuse to assume jurisdiction in a post-UDRP action to overturn a UDRP transfer order; leaving the registrant without any meaningful redress or ability to have its case heard on the merits.

The proposal (Option 1 under Recommendation #4) to eliminate all substantive recourse for errant UDRP and URS decisions in the event that an IGO successfully avoids a court proceeding by asserting immunity after ICANN has stripped away the Mutual Jurisdiction requirement, is unconscionable and effectively repudiates the GNSO’s mandate to the EPDP which inter alia, requires that any policy option preserve registrants’ rights to judicial review. Such right to judicial review can only entail a substantive review, not merely an opportunity to receive a dismissal. [page 1] [NB: the recommendations were renumbered in the final report]

By ignoring this, not only did the working group fail to listen to the affected stakeholders. They also, by Chris Disspain’s own words, violated their charter.

I had planned to write other blog posts in advance of tomorrow’s GNSO Council, about how the review of public comments was a sham, looking at how the Public Comment Review Tool paid mere lip service to serious comments. [e.g. look at how people would submit very lengthy comments, but instead of actually digesting and considering the very valid points, the working group would simply label them “CONCERNS” and  “DIVERGENCE”! They pretended to review the public comments thoroughly, but would actually simply skim over them, with no debate, analysis or discussion most of the time, even to novel arguments. No attempt to actually refute the valid points raised by people. If I had more time, I would give numerous examples, but here are some points I wish to note.

I gave 20 reasons against arbitration, and they were ignored. (see pages 43-48 of my comments) Contrast those with pages 35-38 of the final report’s recommendations, or anywhere else they mentioned arbitration.  Basics like open justice (the open court principle) are ignored, as they propose hiding the arbitration filings, and only making the decision public.

Furthermore, I addressed the “Policy Impact Analysis” on page 51 of my comments. On page 17 of their February 14, 2022 call transcript, they claimed that those were important comments, and that they’d go back to them!

“CHRIS DISSPAIN: ….One, can you make sure that you refer us back to this particular comment when we deal with that section?”

I went through all the transcripts (and Zoom calls) and did not find any evidence that they ever went back to it. None of their proposed metrics would ever find that this policy had failed! (this was also a major concern of mine with the New gTLD program) In other words, by failing to provide any metrics which could show that their proposals had a negative impact on registrants, there’d be no way to challenge this policy in the future.

They could have limited the initial impact of a proposed policy change by grandfathering existing domain name registrations, or limiting it to new gTLDs, as per pages 49-50 of my public comments. This was ignored. Opt-out was ignored. The “Notice of Objection” system was mistakenly rejected, because the group was captured. It was a fair solution that really should have had a serious look by fair-minded individuals (not allowing the IGOs to simply veto it, because they thought they could get away with exempting themselves from mutual jurisdiction).

Instead of seriously analyzing feedback, they made jokes. E.g. in response to a serious analysis of unbalanced participation (pages 27-30 of my comments), which showed that Chris Disspain spoke 49.8% of the words on calls (excluding staff), as well as an entire history of the UDRP (and explanation of why the mutual jurisdiction clause was added) the Chair’s only remark was:

CHRIS DISSPAIN: I’m very disappointed. I was going for 50%

(see page 16 of February 14, 2022 transcript) This illustrates the lack of maturity and lack of seriousness with which the working group conducted its review of the public comments. If you were not agreeing with the initial report, your concerns were laughed off.

In conclusion, I wish to emphasize again that the working group failed to deliver what it was supposed to deliver, namely a set of recommendations that preserved the rights of registrants to judicial review. As such, this report should be entirely rejected. I can give ample evidence of all the process flaws that made them lose their way. But, in the end, it’s the actual recommendations that are the deliverables, and those deliverables simply fail to deliver what was promised.

 

ICANN Registrars Constituency Attempts To Rewrite History Of The New IGO Working Group

As we’ve noted in our recent blog posts, here, here, here and here, the ICANN GNSO Council intends to vote (on Thursday May 19, 2022, 2 days from now)  on a controversial Final Report which would severely harm the rights of domain name registrants to judicial review of an adverse UDRP decision. This is in sharp contrast to the charter of that working group, which required that the rights to judicial review be preserved.

In a shocking new development, today the ICANN Registrars Stakeholder Group proposed a “friendly amendment” saying:

We believe it is important to have it on record (in the motion) that there are scope and principles stipulated by the Council at the outset and against which Council has evaluated and determined that the recommendations in the Final Report are consistent with such scope and principles.

The email from Greg DiBiase of Amazon, didn’t appear to have an attachment with that kind of friendly amendment (the DOCX attachment at the bottom seems to be the original motion, not an amended version).

[Note on May 18: after additional review (in ChromeOS it was invisible text in the browser’s viewer), by downloading the attachment and loading it in Google Docs, the text is similar to the above, in item 10. i.e.

10. The GNSO Council has determined that the five (5) final EPDP recommendations in the EPDP team’s Final Report are consistent with the scope and principles set out in the Addendum to the RPMs PDP Charter and the subsequent EPDP Charter.

Regardless, it appears that people now realize that in fact the final report is deficient, as we’ve argued all along, as its recommendations do not actually preserve judicial review. As such, its recommendations are out of scope.

This obscene “friendly amendment” appears to be some form of damage control, or perhaps something that can be used to gaslight opponents of the final report, or just the worst form of historical revisionism one can imagine.

They’re trying to move the goalposts, after the game has already been played. It’s clear that the Final Report’s recommendations are outside the scope of the actual standard set by the GNSO Council before the working group began.  That means the report has to be rejected in its entirety.

This is particularly obscene given that the first IGO working group (the one that I participated on) was falsely accused of going beyond its scope (see my comments here, including pages 5-10) , and the GNSO Council took unprecedented action to undermine its consensus findings.

Elsa Saade made that point to the GNSO Council in 2019, when the first IGO working group’s final report was at GNSO Council for review, saying:

I was saying that I don’t think that we’re being completely honest with ourselves and the reasons why we are not taking on the full recommendations that the group had consensus on. And if we, I mean, I personally would vote to have all of them go through and then see how the Board would take it forward, but in terms of – because especially because if we do not do that we’re setting a precedence for the GNSO Council which had not been set before I’d say in terms of a back channel, I don’t – I’m going to dare say but a back channel sabotage in a way. I’m putting it out there on the record in my own personal capacity here. So that’s why I think we should take it on fully and take this – have this go through fully as a full recommendation set or list. [page 45 of transcript]

That truth still resonates. Back channel sabotage is what blocked the first working group’s thoughtful final report. Dishonest conduct, including this obscene “friendly amendment” which attempts to rewrite history, should not be rewarded.

The rules of the GNSO Council permit the vote on the IGO final report to be deferred by 1 meeting, as per page 8 of their operating procedures which state:

At the request of any Council member, for any reason, consideration of the Final Report may be postponed for no more than one (1) meeting, provided that such Council member details the rationale for such a postponement.

I suggest that Thursday’s vote be postponed until the June 2022 ICANN meeting, so that the full community can consider and thoroughly review the implications of this Final Report, one which would severely harm the rights of domain name registrants to judicial review (and which is thus out of scope of its charter).

Rather than attempt to win the hearts and minds of the community, through hard work and sound analysis, to form a true consensus, it’s clear that those who wish to take away domain name registrants’ rights are prepared to instead go down the path of dishonesty.

Any “friendly amendment” that tries to claim that this report is actually in scope would simply be a blatant lie, an attempt to say that “black is white” or “up is down”. It would further delegitimize ICANN and its leadership (including GNSO Council members) as fair-minded people can easily see the actual truth and history for themselves.

New ICANN IGO Working Group Didn’t Preserve Registrants’ Rights To Judicial Review

Next week (May 19, 2022, see agenda item #5), the ICANN GNSO Council intends to vote on the new IGO Working Group’s Final Report. However, that report fails at the most basic level, as per the instructions from GNSO Council that initiated that new working group.

I’ve written about this topic extensively, including posts last Thursday and Friday. My most detailed comments were submitted to ICANN in its public comment period. But, let’s go to the most basic problem with the report.

Page 4 noted that the work was initiated to see:

“whether an appropriate policy solution can be developed that is generally consistent with [the first four recommendations from the GNSO’s IGO-INGO Access to Curative Rights PDP] and:

a.accounts for the possibility that an IGO may enjoy jurisdictional immunity in certain circumstances;

b. does not affect the right and ability of registrants to file judicial proceedings in a court of competent jurisdiction;

c.preserves registrants’ rights to judicial review of an initial [Uniform Domain Name Dispute Resolution Policy or Uniform Rapid Suspension decision; and

d. recognizes that the existence and scope of IGO jurisdictional immunity in any particular situation is a legal issue to be determined by a court of competent jurisdiction.”

Note in particular “c” that they must PRESERVE registrants’ rights to judicial review. But, their recommendations do NOT do this, when they exempt IGOs from the mutual jurisdiction clause. That was their “Recommendation #2: Exemption from Submission to “Mutual Jurisdiction”” on page 12 of the report.

A careful reading of the report shows that they actually sneaked in the word “seek” in the summary of that recommendation, i.e. they wrote:

“2.1.2. Recommendations to Address IGO Immunities While Preserving a Registrant’s Right to Seek Review of a UDRP or URS Decision Issued Against It” [emphasis added]

It’s not enough to simply “seek” that review – one must actually have the review itself in the courts! And they removed the word “judicial” — it’s not just a “review” that matters, it’s a judicial review that must be allowed (in the courts).

Notice that their “explanatory text” on page 13 actually OMITS the above section (c) wording! They wrote:

“…recommended policy solution must [account] for the possibility that an IGO may enjoy jurisdictional immunity in certain circumstances; … not affect the right and ability of registrants to file judicial proceedings in a court of competent jurisdiction whether following a UDRP/URS case or otherwise; and … [recognize] that the existence and scope of IGO jurisdictional immunity in any particular situation is a legal issue to be determined by a court of competent jurisdiction”.

i.e. they took the wording of point “b” above, but didn’t quote “c”, namely:

c.preserves registrants’ rights to judicial review of an initial [Uniform Domain Name Dispute Resolution Policy or Uniform Rapid Suspension decision

This is the dishonesty I’ve spoken about repeatedly about this working group. The final report literally hides the most important standard of any recommendation, a standard that this working group did not meet.

As I noted in Friday’s post, the working group members themselves acknowledged during their deliberations that registrants’ rights are not being preserved!

For example, Jay Chapman said:

So really what the problem is as I see it, the current proposal as written today, it doesn’t provide for due process. It’s a forced process. And at best, it seems to me to be somewhat intellectually dishonest. And I think everyone kind of knows it on the call.

With the mutual jurisdiction requirement also currently sought to be disposed of, it seems to be kind of a wink-wink on the registrant being able to find relief or at least a decision on the merits I suppose by going to court. It’s kind of like the group wants to say, well, good luck with that, Mrs./Mr. Business Registrant. There won’t be any jurisdiction in the court and thus no remedy for you.

Without giving every example (I encourage folks to read my full comment submission), Paul McGrady noted:

Thanks, Chris. It was just the nerdy thing that I put into the chat that a waiver of the right to go to court, those rights that are being given up could really never fully be captured in an arbitration mechanism because the rights in Poland are different than the rights in South Africa, which are different than the rights in the U.S. or whatever. So what we would be doing is creating some sort of amalgam of protections for registrants in the arbitration process that we, I guess, think best blend all the various rights around the world. Then we would be offering that to registrants in lieu of their local protections. And as I said before, I think in the chat, the optics of that, they’re hard to get your arms around that. We don’t want ICANN be accused of overreach, for what it’s worth. Thanks.

The final report tries to dance around this deficiency through misdirection! They “emphasize” on page 9 that:

The inclusion of an arbitration option in the UDRP and URS does not replace, limit, or otherwise affect the availability of court proceedings to either party, or, in respect of the URS, the ability to file an appeal within the URS framework. Either party continues to have the right to file proceedings in a court, up to the point in time when an arbitration proceeding is commenced (if any).

But, that’s missing the point, and misleading people! It’s the exclusion of the mutual jurisdiction clause that has the effect of not preserving registrant’s rights to judicial review. ICANN has no ability to stop anyone from filing a court proceeding. What matters is what happens in the courts after the case is filed, and whether the proposed changes have an impact on things (they obviously would have a severe negative impact on registrants).

They falsely claim on page 19 that they believe they’re “preserving existing registrant rights.” This concern was raised by many in the public comment period, not just myself. But, then they misstate and misrepresent the objections of the public, on page 25:

The Public Comments demonstrated strong concerns, particularly amongst individual commentators, regarding the EPDP team’s proposal to exempt IGO Complainants from the requirement to agree to submit to a Mutual Jurisdiction, to the extent that it would result in limitations on the registrant’s ability to file court proceedings against an IGO or in compelling a registrant to go to arbitration. These commentators emphasized that the outcomes of the EPDP should not reduce or otherwise adversely affect the rights of registrants.

They emphasized that folks were concerned about the “registrant’s ability to file court proceedings” — that’s not the issue; instead, what matters is what would happen at court after the case got filed (i.e. it would be tossed out on a technicality, if IGOs asserted immunity, which they certainly would do if they were exempted from the mutual jurisdiction clause).

They added the ambiguous text “These commentators emphasized that the outcomes of the EPDP should not reduce or otherwise adversely affect the rights of registrants.”, but then didn’t address those actual concerns, i.e. the prejudicial impact of what would happen once you got to court.

To fake people out, then the final report didn’t actually CHANGE the substance of the recommendation (i.e. final report vs. initial report). On page 25, they tried to pretend that they did:

Clarify that its proposal to exempt an IGO Complainant (as defined) from the requirement to agree to submit to a Mutual Jurisdiction does not alter or limit a registrant’s ability and right to initiate court proceedings;

But, that is simply “explanatory text” that didn’t actually change the recommendation itself! And furthermore, that explanatory text is misleading, because it was never in dispute that registrants could “initiate court proceedings” — what people were concerned about was what would  happen at court once you got there.

By removing the mutual jurisdiction clause for IGOs, the expected outcome at court would be vastly different, as everyone knows (that’s why the IGOs have been fighting this issue for 2 decades, as they don’t want the courts to ever be able to make a decision on the merits, even when they’ve initiated the overall dispute by filing a UDRP in the first place). Registrants’ rights would be severely prejudiced at court, not preserved. Even the working group itself acknowledge this prejudicial impact, on pages 23-24:

Conversely, the EPDP team acknowledged that removing this requirement for IGO Complainants could prejudice a registrant’s right and ability to have an initial UDRP or URS determination reviewed judicially, in that a successful assertion of immunity by an IGO means that the court in question will decline to proceed with the case.

That should have been the end of the working group’s attempt to keep the exemption from the mutual jurisdiction recommendation!

Instead, the working group tried to redirect people’s attention to the language of item (b) above, namely:

“does not affect the right and ability of registrants to file judicial proceedings in a court of competent jurisdiction;” (emphasis added)

i.e. but no one really cares about just the ability to “file” a case. ICANN has no power to stop anyone from filing a case (emphasis above on “file“). What matters is item (c) above:

c.preserves registrants’ rights to judicial review of an initial [Uniform Domain Name Dispute Resolution Policy or Uniform Rapid Suspension decision; (emphasis added)

Which the working group simply ignored. There would obviously be no actual “judicial review” at all, as the case would be tossed out on a technicality, as IGOs successfully assert immunity (once they’re exempted from the mutual jurisdiction clause).  Again, registrants’ rights would be severely prejudiced at court, not preserved. That’s unacceptable, and doesn’t match what GNSO Council told the working group to do.

Why is a decision in court so important? It was explained in depth in the detailed public comments, or in a much briefer and older article by Wendy Seltzer. Instead, this working group believes that it’s “enough” to allow someone who disagrees with the outcome of an ICANN-designed process (UDRP) to simply go to yet another ICANN-designed process (an “arbitration” as an alternative to the courts). ICANN’s UDRP has been criticized as being one-sided in favour of complainants for 20+ years, and now they believe they can be trusted to come up with something superior to the courts? That’s nonsense. The fact that working groups and processes have been manipulated to even get to this stage shows that ICANN doesn’t work, and that court processes are essential to ensure justice.

Remember, not a single IGO has ever had a UDRP appealed to court! Why would an actual criminal fraudster engaged in cybersquatting, who IGOs pretend to be after, ever expose themselves? IGOs truly want to prevent legitimate registrants who have faced an injustice at the UDRP (e.g. the ADO.com or IMI.com disputes) from obtaining justice through their national courts.

In conclusion, this final report is a sham, an obscene attempt to deprive domain name registrants of basic and sacred rights that they’ve had since the inception of the UDRP. It is a demonstration of what happens when policy-making is dominated by a powerful and unrepresentative “few”, at the expense of the underrepresented “many”. It must be opposed to ensure justice and due process for domain name owners.