Featured

Update: My participation rights have now been eliminated at ICANN working groups

Just to followup on the earlier blog post of today, I received the following email from Keith Drazek (GNSO Council Chair),

Dear Mr. Kirikos,

Receipt of your letter is acknowledged.

We note and regret that you have elected to not accept and agree to abide by ICANN’s Expected Standards of Behavior (ESOB).

As such, per the notice provided in the Council Leadership Team’s letter of 29 March, you will be placed in observer status in the RPM PDP WG and any other GNSO-related forum until such time we receive the necessary communication confirming acceptance of the ESOB, or until such time the ICANN Ombuds rules that you may return to member status following any appeal.

Sincerely,

Keith Drazek
GNSO Chair (on behalf of the GNSO Council Leadership Team)

So, unless I “bend the knee” and “swear an oath of fealty” (or unless the ICANN Ombudsman says I can return), I’m forever banished. Is that reasonable and proportionate?

And, this affects participation for all working groups (not just the RPM PDP), even though there’s no issue in the IGO PDP!

 

Featured

ICANN Threatens to Restrict Participation Rights of critic George Kirikos

ICANN, in an affront to free speech and due process, has threatened to restrict my participation on important domain name policy issues, and I think it’s crucial that these topics be brought before the public for debate. Continue reading “ICANN Threatens to Restrict Participation Rights of critic George Kirikos”

Our Comments to ICANN Opposing the Dot-NET Registry Agreement Renewal With Verisign

On April 19, 2023, I highlighted negative aspects of the proposed .NET Registry Agreement between ICANN and Verisign.

The public comment period ends on Thursday May 25, 2023 at 23:59 UTC (i.e. tomorrow), and I just submitted my company’s final comments.

I encourage others who care about the rights of registrants to do the same.

Others, including the Internet Commerce Association and TurnCommerce have submitted substantial comments. All of the public comments can be read here.

Red Alert: ICANN and Verisign Proposal Would Allow Any Government In The World To Seize Domain Names

ICANN, the organization that regulates global domain name policy, and Verisign, the abusive monopolist that operates the .COM and .NET top-level domains, have quietly proposed enormous changes to global domain name policy in their recently published “Proposed Renewal of the Registry Agreement for .NET”, which is now open for public comment.

Either by design, or unintentionally, they’ve proposed allowing any government in the world to cancel, redirect, or transfer to their control applicable domain names! This is an outrageous and dangerous proposal that must be stopped. While this proposal is currently only for .NET domain names, presumably they would want to also apply it to other extensions like .COM as those contracts come up for renewal.

Continue reading “Red Alert: ICANN and Verisign Proposal Would Allow Any Government In The World To Seize Domain Names”

Our January 30, 2023 Comments to ICANN Regarding IGO Issues and Preserving The Rights of Registrants

ICANN has a public comment period for the Final Report from the EPDP on Specific Curative Rights Protections for IGOs, which proposes to harm registrants’ rights, by making IGOs (intergovernmental organizations like the UN) exempt from the mutual jurisdiction clause of the UDRP/URS. This would mean that a domain owner’s rights to judicial review of an adverse UDRP/URS decision would be prejudiced.

Our comments can be read on the ICANN site, along with all the other public comment submissions. [including those of the Internet Commerce Association]

Continue reading “Our January 30, 2023 Comments to ICANN Regarding IGO Issues and Preserving The Rights of Registrants”

VPN.com v. George Dikian court case update of January 27, 2023

Konstantinos Zournas of OnlineDomain.com was the first to break the news concerning the lawsuit filed by VPN.com against “George Dikian”.

Today, both sides filed a “Joint Rule 26(f) Report” [PDF] which summarizes the case from the point of view of each side, and sets out scheduling going forward. Since it’s such a short document, it’s an excellent introduction to the dispute, for those who’ve not been following it from the beginning.

The entire docket can be followed via CourtListener.

Visualizing the Security Benefits of the Losing FOA for Domain Name Transfers

I’ve written extensively about the security implications of the “Losing FOA” step of domain name transfers. It’s the opportunity for registrants to “ACK” or “NACK” a pending transfer, before it completes. I wrote about this again yesterday,  and that post linked to all prior writings.

I wanted to give readers direct visual evidence of why the Losing FOA is so important as a security mechanism, so I intiated a transfer of a domain name from my company’s portfolio at Tucows/OpenSRS to GoDaddy. After I input the transfer code (currently called the “AuthInfo Code”, but it will be renamed the “Transfer Authorization Code” or “TAC”) at GoDaddy, Tucows/OpenSRS sent me (as registrant) an email, with a link to a page that would allow me to immediately approve the transfer (i.e. “ACK” it), or to reject the transfer (“NAK” it). Here’s a screenshot:

Example of OpenSRS Losing FOA page, allowing registrants to accept or reject an outgoing transfer request
Example of OpenSRS Losing FOA page, allowing registrants to accept or reject an outgoing transfer request

As you can clearly see, the page contains text saying:

The domain name listed above will be transferred to:

New Registrar
GoDaddy.com, Inc.

and gives me the opportunity to accept the transfer, or decline it (I’ve just left things in a pending state for now; I’ll perhaps “ACK” the transfer in a few days).

Had the transfer code been compromised, with an attacker using it at a different registrar, I’d have been able to immediately detect the unauthorized transfer request and stop it before it completed, as I’d be able to see that it wasn’t transferring to GoDaddy.

In conclusion, this is an important security mechanism, given that there is otherwise no protection for misuse of the transfer code once it’s generated. Without this important safety mechanism, the registrant is “on their own”.

[P.S. In case you were wondering about the domain I used for the test transfer, “Big Swinging Dick” is a Wall Street term mentioned in the book “Liar’s Poker” — “If he could make millions of dollars come out of those phones, he became that most revered of all species: a Big Swinging Dick.” And of course, I own the dot-com (through my company).

P.P.S. What if an attacker had used a compromised transfer code at GoDaddy before I did, and I mistakenly approved an incorrect transfer into their account, rather that my own account at GoDaddy? That’s a vulnerability that I’ve advocated be addressed, by showing the full WHOIS “before” and “after” the proposed transfer (while it’s still in a pending state, to allow the current registrant full transparency of how the WHOIS would change, should they accept the transfer). See section G (pp. 23-25) of my full submission to ICANN. Although, even under the status quo, at least the domain name would be at a “friendly” registrar (i.e. a legal jurisdiction that I had specifically wanted to transfer the domain), where presumably the force of law could be used to correct things.]

Response to ICANN Working Group Regarding Domain Name Transfer Issues

In August, I submitted extensive comments on behalf of my company to ICANN regarding proposed changes to domain name transfer policy.

I’d written multiple blog posts before then, warning about the negative ramifications should their recommendations be adopted. See herehereherehere and here for those past articles on the topic.

In September, I participated (as a member of the public, not as a member of the working group) in the public ICANN75 session on the topic (I wrote another blog post immediately before that session.). After that session, one of the ICANN working group members posted some thoughts on my proposals.

As I’ve yet to be invited to participate directly in that working group (which might correct the severe unbalanced and unrepresentative participation, where registrants’ views are not being taken seriously), I’ve written a public response to that email. You can read that response here (while it’s 20 pages long, it’s very generously spaced, so it shouldn’t take long to read and digest).

There is a lot wrong with this working group’s report and ongoing deliberations. The public deserves more than mere lip service during an ICANN75 meeting. We deserve active engagement throughout the remainder of the working group’s efforts, especially given the unbalanced participation at present.

Banxa announces AUD $3 million sale of crypto-related domain names, with more to come

Publicly-listed Banxa has announced the sale of AUD $3 million worth of crypto-related domain names to Independent Reserve (an Australian crypto exchange). 1 $AUD is worth approximately USD $0.67 at the time of this post.

Continue reading “Banxa announces AUD $3 million sale of crypto-related domain names, with more to come”

ICANN75 Session of the Transfer Policy Working Group is Friday at 10:30PM Eastern Time

The ICANN75 session of the ICANN Transfer Policy Review PDP Working Group will be taking place in less than 12 hours from this blog post, at 10:30 PM Eastern Time on Friday, September 16, 2022. [10:30 MYT (UTC+8), 17 September 2022]

Remote participation is available via Zoom (you’ll need to create an ICANN account to access the links to the Zoom room, as per the above session link).

As I’ve noted in my lengthy comment submission, there are very serious problems with the working group’s recommendations.

Furthermore, that working group’s review of the public comments is superficial at best. As an example, watch the Zoom recording of this past Tuesday’s working group call. (unfortunately, the written transcript of the call isn’t posted yet on the GNSO’s calendar page).

Did the working group even mention, in discussions of removal of the Losing FOA, my citing of the SSAC report, from page 39 of my comment submission, to:

“Treat transfer attempts as a security event (check and re-check).”

Nope! Apparently such an important point was not worth mentioning on their call! It demonstrates the importance of the Losing FOA.

There’s a certain arrogance in the working group, as if they know better than the public. e.g. Jim Galvin of Afilias (a member of the SSAC) claimed he was “not especially persuaded by most of these comments” and that he didn’t believe “that there’s new information here” (see the “rough transcript” produced by Zoom at around 44:22 into the call, or listen to the actual call; the rough transcript isn’t perfect).

Galvin claimed that he “could sit here and go through, and I think I would have a specific response to each one of these comments” (at around 44:53 into the call). I openly challenge him to do so!

I even reached out to him, to have a telephone call, to go through my concerns to see what his “response” would be. I’ve not heard back, yet.

At 1 hour and 10 minutes into the call, Galvin asserts that “there really is no diference between the FOA and the notification.” He then goes on to claim “the notification has the same properties. It neither adds nor removes them.”

This is demonstrably false!

If I validly create a TAC (transfer authorization code), to transfer a valuable domain name from Tucows to GoDaddy (as an example), and provide that TAC to a buyer or to an escrow company, but then see (via the Losing FOA) that the transfer is actually going to Alibaba or a Russian registrar, I’d be able to NACK (cancel) the transfer, as it’s not going to the correct destination.

That involved no compromise of the registrar’s control panel, but involved misuse of the TAC after it was properly generated, but before it was properly used at the correct gaining registrar).

This is a perfect demonstration that their analysis is completely wrong. The removal of the Losing FOA would have demonstrably made one worse off.

Galvin claims that “all bets are off” if an attacker gains access to a registrar’s control panel (because the attacker can change registrant contact details, so the registrant wouldn’t be able to receive the Losing FOA). Again, his analysis is wrong. Perhaps at a poorly-designed registrar, his analysis might be fine. But, a properly-designed security-conscious registrar wouldn’t immediately make those critical changes. They would seek verification first! I documented in my lengthy submission that I carefully separate out the registrar control panel details and contacts, so that they’re independent of the domain name contacts.

Later on that call, at around 1 hour and 14 minutes, Jim Galvin demonstrates to us all that he didn’t actually do his homework and understand the working group’s report, as he was unaware that the 5 day window after the gaining registrar submits the transfer was being eliminated. How embarrassing for him, and embarrassing for SSAC. He says “maybe I’m missing something  here” — yes, Galvin and others are missing a lot!

In conclusion, it’s clear that these working group members are not doing a proper review of the public comments. They have tunnel vision, and are working from the starting point that they “know better” than the public who submitted serious concerns about their dangerous proposals. If you share these concerns and have time on Friday night (North American time) to attend the ICANN75 session remotely, please do so.

 

Domain Owners Might Want To Enable Lockdown Mode

Apple recently released iOS 16 for the iPhone, which introduced a new security setting called “Lockdown Mode” (this feature will also be coming soon for the iPad and macOS). It increases the security of your device, to defend against some “extreme” attacks.

Owners of valuable domain names (or other digital assets like crypto/NFTs), CEOs, celebrities, journalists, and other “high value targets” might want to enable Lockdown Mode for extra protection.