The report Redirection in the COM and NET Domains dated July 9, 2004 was prepared by the ICANN Security and Stability Advisory Committee (SSAC) in response to the actions of VeriSign? on September 15, 2003. On that date VeriSign? implemented its Site Finder service across the COM and NET domain name extensions. The Site Finder service changed the way that the registries responded to user look-ups of unregistered domain names by replacing existing default error pages with a uniform web page service that suggested content to Internet users (a practice otherwise known as "wildcarding"). As a result of VeriSign? 's actions the SSAC contended that in their opinion the Site Finder service violated ICANN general policy, diminished user decision making, subjected users to violations of privacy, and that local ISP technical responses reduced overall Internet coherence. Thus, the SSAC report recommended that ICANN insist upon the suspension of the Site Finder service.

It is the contention of this paper that the SSAC report and the position of ICANN, to urge the prohibition of "wildcarding" by ccTLDs, merely represents the biased self interested opinions of ICANN. And furthermore that ICANN is now itself furthering the deterioration of user privacy and security, an act it has continued to accuse the wildcarding practice of.

First, consideration must be given to the fact that the dispute discussed in this report arose out of the fact that ICANN_'s legal/contractual authority is limited to generic top level domains (gTLDs) like the COM, NET, and ORG registries. In this dispute, _ICANN asserted that VeriSign? had overstepped the terms of its contract with the United States Department of Commerce (and subsequently ICANN). This authority over VeriSign? 's actions arises only because of ICANN_'s specific contractual relationship with VeriSign? (and their predecessor Network Solutions, Inc.) regarding the administration of the COM and NET registries. Beyond the realm of gTLDs _ICANN has no true authority, which is why they have never taken action against any ccTLD, ISP, or Internet Browser company that has or is currently providing a Site Finder like service. Thus, ICANN can only make suggestions, and those suggestions are merely opinions that heavily reflect the organization's academic and ideological policy viewpoints.

Second, the SSAC report asserts that a Site Finder like service will deprive end users of decision making, and potentially subject those users to violations of privacy. In the context of the present reality of Internet commerce and usage since the 2004 date of this report, both of these arguments have little if no relevance at all to any ccTLDs attempt at wildcarding their respective extension. First, "user decision" in the way the SSAC report describes is today almost completely nonexistent. This is due to the simple fact that today most every major ISP and Internet Browser Company currently employs a similar Site Finder like service in order to capture millions of dollars in revenue from end user typographical errors. Thus, "user decision" as defined by the SSAC report is under most circumstances a thing of the past. Second, the potential violations of privacy that the SSAC describes, such as the tracking of user behavior, have in the time since the report become so commonplace that "user privacy" has essentially been redefined. Today most every major website, ISP, and Internet Browser collects data regarding user behavior to a much greater extent than was ever collected by Site Finder. Furthermore, today, ICANN is in the process of enabling the rapid expansion of gTLDs, something that has caught the attention of the Federal Trade Commission as having the potential to further Internet fraud through the use of misleading domain names. Additionally, some studies have recognized that Internet users associate legitimacy of a website with the level relevancy of its domain name. Thus, the question must be asked whether ICANN, through expanding gTLD extensions, is knowingly capitalizing on the likelihood that "bad actors" may have a greater opportunity to present their frauds through relevant domain names?

Third, the SSAC report discusses concerns over technical problems that arose from ISPs reacting to the implementation of the Site Finder service. In the context of ccTLDs who want to implement a wildcard for the benefit of their registry there are several points that should be considered in evaluating the merit of _ICANN_'s claim:

A. The Request For Comment (RFC) Documents, foundational principles of Internet administration, specifically permit the use of wildcards in RFCs 1034 and 1035.

B. The SSAC themselves concede that all of the problems experienced in relation to the Site Finder service were most likely only experienced because of the immense size and heterogeneity of the COM and NET domain spaces. They further concede that the addressed problems "might not be visible in another TLD" that employed a Site Finder similar service, and thus imply that such a service could operate with no adverse effects when implemented in smaller scale situations.

C. Many ccTLDs have operated wildcards for years on their respective extensions with benefits to their registries. As Joel Disini CEO of the ".ph" extension said in a 2010 ICANN meeting report on the subject, "The wildcard is a tremendous resource. It would be a shame to throw it away."

In conclusion, the 2004 SSAC report and any subsequent related opinions reflect technical and ideological concerns that are today either wholly irrelevant or easily addressed. As such, it is my contention that the general recommendations of the SSAC report and ICANN solely reflect a position more of self interested preemptive influencing rather than substantive concern. ccTLDs around the world should be able to wildcard at their will, free of unwarranted interference from ICANN.

No reader not already fully informed about the supposed problem that was so important seven years ago could determine from this essay: (1) what it was; (2) what has changed since; or (3) why we should care now. Those are the points that the next draft should put, with absolute clarity in the minimum number of words possible, in the introduction. Thereafter, the outline should call for the further development of each point, with increasing priority in allocation of space. From why we should care—spelled out in full from the point of view of the user of the Web, given that browsers (stupid as they are) are intelligent enough to supplement the even stupider system that is DNS by real-time associative searching—will arise the question whether there is actually anything that needs to be done. A further question may be whether the ire against ICANN has been justified in any way, or is simply to be regarded as a sort of primitive, inherited, ancestral bias.