ICANN ICANN Email List Archives

[rap-initial-report]


<<< Chronological Index >>>    <<< Thread Index >>>

RAP Initial Report comments of Leap of Faith Financial Services Inc. (March 27, 2010)

  • To: rap-initial-report@xxxxxxxxx
  • Subject: RAP Initial Report comments of Leap of Faith Financial Services Inc. (March 27, 2010)
  • From: George Kirikos <gkirikos@xxxxxxxxx>
  • Date: Sat, 27 Mar 2010 14:00:45 -0700 (PDT)

Comments on Registration Abuse Policies Initial Report

Submitted By: George Kirikos
Company: Leap of Faith Financial Services Inc.
Company URL: http://www.leap.com/
Date: March 27, 2010

As a participant in the RAP Working Group for a period (up until October 22, 
2009; one can view all our posts on the mailing list for the workgroup), I had 
a chance to observe it closely, and believe much of the work does not reflect 
the views of the public. In typical ICANN fashion, it was captured and was 
driven by special interests with their own agendas. Their "votes" and 
"consensus" reflect only those who stayed until the very end, rather than those 
who gave up on the entire captured proces.

That being said, our views on each recommendation follow:

(A) CYBERSQUATTING (Recommendations #1 and #2)

We disagree with recommendation that UDRP be revisited in order to "address 
cybersquatting." This appears to be a biased recommendation, in favour of 
complainants who already overwhelmingly win at UDRP. If UDRP is to be 
revisited, it should be in order to address reverse domain name hijacking by 
complainants who misuse the system. Also, there should be formal contracts 
between ICANN and UDRP providers as a precondition to any amendment of the 
UDRP, indeed as a precondition of the continuation of the existing UDRP 
process. UDRP should not be a mandatory process, as we have seen all to often 
that mandatory arbitration is often one-sided. Indeed, NAF (a current UDRP 
provider) has been widely criticized for its processes in consumer arbitrations 
as documented at:

http://en.wikipedia.org/wiki/National_Arbitration_Forum
http://domainnamewire.com/2010/03/22/study-shows-million-dollar-domain-arbitrators-and-udrp-bias/
http://domainnamewire.com/2009/07/22/national-arbitration-forum-panelist-sued-for-judicial-misconduct/
http://domainnamewire.com/2009/12/28/2009-domain-dunce-award-panelist-andrew-f-christie/
http://forum.icann.org/lists/sti-report-2009/msg00010.html

Furthermore, the entire report fails to live up to the Affirmation of 
Commitments:

"To ensure that its decisions are in the public interest, and not just the 
interests of a particular set of stakeholders, ICANN commits to perform and 
publish analyses of the positive and negative effects of its decisions on the 
public, including any financial impact on the public, and the positive or 
negative impact (if any) on the systemic security, stability and resiliency of 
the DNS."

The report is not data-driven, and does not analyse positive and negative 
effects. It also does not focus on recommendations that reduce abuse ex-ante, 
like WHOIS verification, which we've long advocated:

http://forum.icann.org/lists/whois-accuracy-study/msg00003.html

Instead of focusing on prevention and proactive solutions, the report focuses 
on reactive solutions that are ill advised. Focus is on "bring in the death 
penalty, hire more police, spend more after the crime has been committed" 
rather than "design smart policies that prevent criminal abuse in the first 
place" like verified WHOIS (i.e. criminals want to hide in the shadows; 
verified WHOIS makes them move on to something else, an easier target).

Recommending that the UDRP definition be changed was a point desired by some 
who see that the number of UDRPs has been falling. They seek to broaden the 
definition of "what is a crime" in order to reverse hijack more domain names or 
to cause more domain name disputes to occur. UDRP is a "business" to them, and 
when "sales volumes" are down, they need a "solution." 

This is a demonstration of the capture of the ICANN processes by those working 
against the public interest. Ordinarily, if crime was down (e.g. fewer UDRPs, 
less TM infringement), the people and society would be rejoicing. Not so with 
these special interests. If crime is down, they want the definition of crime to 
be changed, turning more and more people into so-called "criminals" so they can 
benefit.

Similarly, the RPMs in the new TLD process (like the URS) were widely 
criticized, but were "accepted" by ICANN because it wants to bring in new TLDs 
"at any cost", even at the expense of the public. The URS was a way to buy the 
support of the TM lobby, who don't care about new TLDs, but many of whom seek 
to reverse hijack and harm legitimate registrants in existing TLDs. TM 
lobbyists should use the court system to seek out and punish the real abusers, 
rather than twist ICANN to extend the breadth of TM protection far beyond what 
the law actually permits.

Concluding our discussion on the cybersquatting recommendations, the proper 
forum is the court system, unless *both* parties seek arbitration. The only 
legitimate role for ICANN is to ensure that accurate WHOIS exists (using WHOIS 
verification), so that private parties can settle their disputes between 
themselves. The workgroup overstepped its bounds and scope, as cybersquatting 
goes into domain name "use", and is not a "registration" issue (as was deeply 
discussed on the mailing list).

(B) FRONT RUNNING

We disagree with their recommendation of "do nothing". Indeed, I was 
responsible for maintaining the "Front Running" topic on the wiki, and 
identified very serious issues whereby registry operators can use "inside 
information" to their advantage. We listed several important points on the wiki:

https://st.icann.org/reg-abuse-wg/index.cgi?domain_front_running

As per our prior discussions on proactive smart policies, as a preventive 
measure (i.e. eliminating all the loopholes in advance, rather than try to fix 
the problems that crop up later), we reiterate our own views from the wiki and 
mailing list, including:

(i) Better disclosure by registrars as to their privacy policy and how they use 
customer information, including availability checks for domain names 

(ii) Better disclosure by registry operators as to their privacy policy and how 
they use information, including availability checks and DNS traffic for 
unregistered domain names.

(iii) Requiring registry operators to produce and publish lists of all 
registered domain names with expiry dates, lists of post expiration domain 
names (with expected deletion date, etc.), and daily diffs, so that 
availability checks can be performed locally by registrars, registrants, and 
3rd parties, thereby enabling greater privacy.

(iv) Prohibiting registrars and/or registry operators from using/disclosing 
availability checks (including DNS traffic to unregistered domains), and/or 
creating "Chinese Walls" between different TLDs managed by a registry operator. 
Alternatively, creating rules as to how those availability checks can be used 
(e.g. instead of being able to use/sell real-time results, one might permit 1 
hour old results to be sold, to permit novel idea creators sufficient time to 
complete registrations within an hour).

(C) GRIPE SITES; DECEPTIVE AND/OR OFFENSIVE DOMAIN NAMES 

Obviously so out of scope to even be considered by the workgroup at all. This 
is the kind of stuff that kills brain cells, and causes people to walk away 
from the process. Ever heard of a concept called "freedom"?? Hello?? However, 
I'm sure some observers in China or Iran loved the minority view on this issue.

As per discussions above, verified WHOIS is all that matters. Let the parties 
handle matters privately, if there's an issue at all. As long as the 
responsible party/owner is evident, there's no need for ICANN to be involved. 
If it's a criminal issue, let the police handle it. ICANN is not and should not 
be the global court, police, law maker, judge and jury.

(D) FAKE RENEWAL NOTICES

This is a case where better education is the obvious solution, as well as 
better security at registrars. Let's face the facts: there will always be dumb 
people, and no matter what you do, there will be people who fall for these 
scams. If the scammers are breaking the law, the civil courts are the proper 
avenue (e.g. suit by a registrar against the scammers), or criminal courts 
(e.g. governments enforcing laws against deceptive marketing). One will recall 
Network Solutions had to settle a complaint with the Federal Trade Commission:

http://www.ftc.gov/opa/2003/09/networksolutions.shtm

(E) DOMAIN KITING/TASTING

Non-issue, given the AGP loophole was removed. As we've long said, an 
application of simple economics would have solved this issue ages ago. Things 
that are "free" will tend to be abused. They lead to "corner solutions" in 
economics which can be very ugly (but which are those that abusers will 
exploit, as they do with spam, for example, where the cost of sending emails 
approaches zero).

http://en.wikipedia.org/wiki/Corner_solution

If we want nicely-behaved "interior" solutions, we must be careful to ensure 
that the costs are zero if and only if they *should* be. Where benefits are 
greater than zero, and costs are zero, then you'll tend to get 
abuse/overuse/infinity as the mathematical outcome (like spam).

(F) MALICIOUS USE OF DOMAIN NAMES

This issue really was out of scope of the "registration" aspect of the 
workgroup. The "alternate" view was of course silly, yet had the support of 3 
members who wanted ICANN to compel mandatory practices.

As for the "non-binding best practices", that's like arguing against apple pie 
and ice cream. However, I will stand against the "unanimous support" in that 
there's nothing stopping the community from developing these "best practices" 
without ICANN's involvement. In particular, the recommendation said:

"
This 
effort
 should 
be 
supported 
by
 ICANN
 resources"

In other words, they want ICANN money! Some of these people or their allies 
might stand to benefit personally, if ICANN "supported the effort" with a paid 
consulting gig or compensated them for their travel and hotels so that they can 
"study the best practices" further in hot climates during the cold of winter 
where they live.

ICANN's budget has already swelled to enormous levels, with a huge overpaid 
staff (everyone knows that Rod Beckstrom is greatly overcompensated compared to 
comparable non-profits, as is much of the ICANN staff) and a traveling circus 
that even that even the IOC has become jealous. Yet, let's make the budget even 
bigger, they say! It's a recession, and lobbyists/consultants/lawyers have 
families to feed too! Give us a "taste" of the ICANN spoils! Domain registrants 
won't notice a million here or a million there!

ICANN should be getting smaller and be more focused on a narrow technical 
mission. If professional and non-professional lobbyists want free trips around 
the world to support their pet causes and pet concerns, ICANN should not be the 
venue for that. It costs absolutely zero for people to create a mailing list 
via Google Groups or Yahoo Groups. Why should what we call "ICANN" (which is 
really "domain name registrants" who ultimately pay for the entire show) be 
expected to cough up more "resources" (read that as "money") for the narrow 
interests of a group?

That's socialism of the worst kind, and represents taxation and income 
redistribution. Socialists are all too quick to call for "resources" for their 
pet causes, if someone else is paying for the party. That has to end.

If ICANN "resources" are to be devoted to this recommendation, they should be 
limited to a budget of $1/yr.

The proper solution, as we repeat again, is to have verified WHOIS. Nothing 
kills "malicious use of domain names" faster than forcing miscreants to 
identify themselves. We've all known this for the last 10+ years, so let's stop 
dancing around the real solution and get it done.

(G) WHOIS ACCESS

I won't repeat our prior recommendations on WHOIS. See above.

Some registrars continue to not provide port 43 access, in violation of their 
agreements with ICANN. In particular, they often block residential IP 
addresses, even ones that haven't queried them before (i.e. they say it's for 
"rate limiting", but that's not true as it's coming from static residential IP 
addresses that never queried them before).

Ultimately, there should be a WHOIS archive that is comparable to the TM 
document retrieval system (with history) at USPTO.gov, like a land registry 
keeps (i.e. don't throw away data). Let's move to thick WHOIS, too, for all 
gTLDs (including com/net).

(H) UNIFORMITY OF CONTRACTS

This appears to be another attempt to compel creation of "abuse policies" in 
every agreement, that go far and above common legal standards. We saw this in 
the .info abuse policies, for example, where they had ridiculous definitions of 
"spam" and "abuse" for example, that were overly broad and open to any 
interpretation.

We are strongly against real abuse, but the proper venue is in the court 
system, where folks are confronted using their true and verified WHOIS. 

What the workgroup really decided (i.e. those who stayed until the very end) 
was "let us do more work, as we know better than everyone else, including 
lawmakers on what abuse is, and we want to cram it down everyone's throat." 
This is insulting to those who want to really end abuse, by going after the 
root causes. Most abuse happens due to anonymity and throwaway domains by 
cybercriminals. Instead of focusing where the real problem is, fixing WHOIS 
(not just domain WHOIS, but also IP address WHOIS via ARIN, etc.), this 
workgroup's prime recommendation is "let's force everyone to change their 
contracts". How silly.

Take a look at some of the actual words of the recommendation (which are buried 
on page 91, rather than be revealed on the opening pages of the document):

"The establishment of minimum Registration Abuse baselines, if any are 
determined by such a PDP, will begin to introduce predictability in a rather 
chaotic world. More importantly, minimum standards will enable market 
participants to better mitigate or eliminate registration abuse in a more 
coordinated and unified manner by raising the bar in a method where ALL equally 
participate in the mitigation or elimination of abuse."

In other words, we have people who want to make global laws via ICANN. That is 
very dangerous, and we oppose this. This is what happens when you have a little 
publicized workgroup dominated by special interests.

One need only look at what happened with the .info abuse policy, which I 
discussed at:

http://www.circleid.com/posts/86215_potential_danger_ahead_dot_info_policy/

where you end up with crazy language like "in its discretion." The same for 
.org, where there's no real due process, see:

http://www.circleid.com/posts/20090108_pir_anti_abuse_policy_domain_names/

Yahoo, Gmail, and Hotmail users send out a lot of spam. Would a registry 
operator sudden have the "discretion" to delete Yahoo.com, Hotmail.com, or 
other valuable domain names, without any due process? Of course, VeriSign might 
(or might not) be scared of Yahoo, Google or Microsoft lawyers. But, perhaps 
you have a valuable domain name that VeriSign would like to auction off (using 
the Centralized Listing Service that ICANN approved, but which Verisign has yet 
to launch), or another for-profit registry might covet to auction, or perhaps 
your political views differ from those of a registry and they'd like to shut 
you down. Are you big enough to scare away their lawyers? Or, maybe they'll 
just take your valuable domain, claiming "abuse" and auction it off for their 
own benefit. One should worry about the dangerous precedent that would be set 
if we go down this road.

(I) UNIFORMITY OF REPORTING

Nothing controversial here. As we've previously advocated, there should be XML 
documents and maybe even APIs, so that reporting and reuse of data can be 
simplified. Using XML formats (including for all UDRPs) would also save a lot 
of money due to improved automation.

(J) COLLECTION OF BEST PRACTICES

We reiterate our past concerns of the "funding" requirement. It's hilarious to 
see people essentially lobbying and making self-serving requests for "more 
spending" and then perhaps down the road they'll see consulting contracts or 
even jobs come out of all this. ICANN needs to be focusing on a narrow 
technical role, instead of engaging in mission creep.

Of course, I expect ICANN will ignore this comment. It's in ICANN staffers' 
interests to grow as an organization. They can all make more money and improve 
their job security being part of a staff of 200, rather than a staff of 100 or 
50 or 20, because suddenly the "comparable" that they are compared to changes, 
and layers of "managers" (i.e. friends) are needed to supervise everyone.

CONCLUSION

In conclusion, internet abuse is a serious problem, one that we and most 
legitimate registrants (and the broader public too) have a deep interest in 
reducing. However, this workgroup's proposed solutions are not the answers, for 
the most part. They demonstrate a lack of basic economic knowledge.

To reduce abuse, one needs to make it less profitable. One can only reduce 
abuse by either (1) reducing the benefits of abuse (difficult for ICANN to 
impact) or (2) raising the cost of being an abuser (bingo!).

How do you raise the costs? This workgroup doesn't give the right answers. The 
right answer is to make it very difficult for them to be anonymous (so that 
they risk being caught), and that requires verified WHOIS. This is proactive 
and prevents abuse from ever happening, as abusers are economically rational 
and will weigh the risks and rewards when deciding whether to engage in abusive 
conduct. If you make abuse risk-free, you'll get more of it. This is the core 
reason behind all abuse, and rather than tackle it, the workgroup just gave 
faulty recommendations that will keep those in the "anti-abuse consulting" 
industry employed for another 20 years, at the public's expense. The public 
deserves better.

Sincerely,

George Kirikos
http://www.leap.com/




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy