Today I submitted comments on behalf of my company (Leap of Faith Financial Services Inc.) to ICANN regarding proposed changes to domain name transfer policy. You can read those comments in this PDF, or at ICANN’s public comment forum along with those of others such as the Internet Commerce Association. If you’d like to submit your own comments, the deadline is Tuesday August 16, 2022 at 23:59 UTC.
I’ve written multiple blog posts in the past few weeks, warning about the negative ramifications should their recommendations be adopted. See here, here, here, here and here for those past articles on the topic.
The comment submission reiterates and expands on those past articles. I also took a deep dive into each of the recommendations. It was a considerable effort (at least 40 hours, if not more) in a compressed time frame. It was truly stressful given the deadline would not be extended to mid-September (or beyond) as requested, to be a more reasonable schedule for the amount of work involved. As I note on page 5 of the submission, I could have used more time to reorganize, restructure and condense the material (which amounts to 60 pages!). Consider this a “draft” that wasn’t intended for publication, but is as good as it’s going to get in the time that was provided.
As I note in the conclusion, the most important section is Section E (generate a transaction ID at the gaining registrar, to input at the losing registrar; this way, we can eliminate the TAC). Also, retaining the “Losing FOA” (Section F), at least on an opt-in basis, to preserve the ability to ACK/NACK a pending transfer is critical. Those are the two big counterproposals, although lots of other stuff was important and needed to be said.
The unbalanced nature of the working group composition (registrars dominating) should concern everyone, as registrants’ interests are not being protected.
I’ve written extensively in the past couple of weeks regarding the ICANN transfer policy review’s initial report. You can read these past articles here, here, here and here. There has also been discussion at the NamePros forum. ICANN has been obstinate in their refusal to extend the comments deadline to mid-September (or beyond) as requested (comments are due August 16, 2022, less than a week from now). [Please do keep trying to get it extended, though! Many folks I’ve talked to are only now beginning to understand the negative ramifications of the report, and need more time to compose a thoughtful response.]
Domain name security, including security of the transfer process, is important enough that it calls for fresh ideas. I propose that ICANN issue a widely publicized and open “Call For Papers” or a competition of some sort, like the “XPRIZE” but for domain name transfer and security procedures. This would encourage academics, security researchers, security practitioners, “white hats” and others to take a deeper dive into the domain name transfer system. They would be encouraged and invited to come up with new ideas that would improve security of hundreds of millions of domain names, which are at the foundation of the multi-trillion dollar online economy.
I suggest that a portion of it, perhaps $250,000 to $500,000, be used to fund the total prizes and/or honoraria for an XPRIZE-style competition or call for papers. This is a small fraction of the $20 million.
Such funding would provide an economic incentive to draw new ideas and new eyeballs into the ICANN ecosystem, particularly from academia, rather than from “the usual suspects” who’ve dominated ICANN for the past 2 decades. Transfer security, and overall domain name security, is too important an issue to leave to those ‘usual suspects’.
[To make it clear that I personally would not financially benefit from such a competition, folks should be able to have any prizes/honoraria be directed to charities, rather than to themselves, as I would do to eliminate any conflicts of interest that might be seen from making this proposal.]
As previously discussed, there’s an initial report published by an ICANN working group that is making various recommendations regarding domain name transfers. One of the recommendations would eliminate the important “NACK” safeguard, which allows a registrant the ability to reject an unauthorized transfer attempt. My first blog post discussed why that’s a bad idea. A newer blog post highlighted the fact that the “AuthInfo Code” (to be renamed the “TAC” — Transfer Authorization Code) is the key to the kingdom” and thus its security is paramount. I compared it to the lack of security of a “bearer bond” (vs. a wire transfer).
Can we do better? I’ve come up with two different ideas.
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)
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!
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:
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.”
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.
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).
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.
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, roughly 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), approximatelyup 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:
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.
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!
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:
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
“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.
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).
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.