Is this why digital archery is borked?

Another possible explanation has been put forward for ICANN’s suspension of digital archery, this time by one of the third-party digital archery service providers.
The ambitiously named Digital Archery Experts says it alerted ICANN to the presence of a technical problem a week ago.
Chief technology officer Dirk Bhagat described it thus:

Instead of generating the timestamp immediately, we believe the TAS timestamp generation process may be delayed by increases in system load…
Since most applicants are aiming for the 000 millisecond variance at the minute mark, this can introduce varying timestamps since applicants are shooting for the exact same second on the minute. We have also noted that our results were a lot more consistent when attempts were made to hit the target at various offsets after the minute mark, for example, aiming for 15:32:07 instead of 15:32:00.

It’s not exactly rocket science. In short, he’s saying that the TAS can’t handle too many applicants logging in and shooting at the same time; more load equals poorer performance.
This won’t be news to many applicants, some of whom saw downtime last week that seemed to be caused by a meltdown of the sluggish Citrix virtual machine software.
It also seems to be consistent with the hypothesis that the massive amount of calibration going on — much of it by digital archery service providers themselves — has caused more load than TAS can handle.
With only 20% of applications currently assigned a timestamp, and only a week left on the clock, the situation could only have been exacerbated by lots of last-minute arrows being fired.
While digital archery may be conceptually similar to grabbing a dropping domain or hitting a landrush, it seems pretty clear that TAS is not as redundantly provisioned as the typical registry SRS.
Bhagat said that ICANN could mitigate the impact of the problem by separating timestamp generation as much as possible from the parts of the infrastructure impacted most by system load.
This might all be academic, however.
ICANN suspended digital archery yesterday, a day after new gTLD program director Michael Salazar quit for reasons unknown.
Digital archery and batching are high on the agenda here at ICANN 44 in Prague, and many attendees hope that the controversial system may be gone for good before the week is out.
That includes some members of the Governmental Advisory Committee, which in an open meeting yesterday seemed to be coming to the conclusion that it would advise ICANN to ditch digital archery.
The GAC and the ICANN’s board’s new gTLD program committee are having their first public facetime this afternoon at 1630 local time, at which a better sense of how both plan to proceed might emerge.

DI launches new gTLD application tracker with built-in string similarity checker

I’m excited to announce the launch of a comprehensive new gTLD application tracking service, featuring a unique built-in string similarity checker, right here on DI.
The service will provide the foundation for all of DI’s new gTLD program analysis over the coming months and years, and is designed to bring together all the best information about each application under one roof.
DI PRO subscribers can start playing with it now here.
All 1,930 applications can currently be searched and sorted by applicant, string, back-end registry provider, and status.

Users can also cross-reference applications in contention sets and read salient extracts from each application.
The gTLD application database will shortly be linked to the existing PROfile service, meaning DI PRO subscribers will have access to a database of over 3,000 domain name industry companies.
More features and bid-by-bid analysis will be added as the program progresses, but the feature I’m most excited about today is the string similarity checker, which is already built into every application profile.
This tool checks for visual and phonetic similarity with other applications, existing gTLDs and ccTLDs, as well as strings that are specially protected by the ICANN Applicant Guidebook.
Semantic similarity functionality will be added in the next few days.
Similarity is important for two reasons:
1) the String Similarity Panel, which will create new contention sets based on similar but not identical strings in a couple of months, and
2) the String Confusion Objection, which enables applicants to force rivals into the same contention set based on visual, aural or semantic similarity.
In testing, it’s already thrown up some possible future objections and contention sets that I had not previously considered, and early beta testers — applicants themselves — tell me they think it’s fantastic.
Here’s a screenshot from one of the .sex applications, to give you a taste.

Note that, unfortunately, the string similarity feature does not currently support the relatively small number of IDN string applications.
If you’re not already a DI PRO subscriber, you can sign up instantly here using PayPal. If you have any questions about the service, please email subs@domainincite.com.

Is digital archery bugged too?

ICANN’s digital archery system, which will be used to decide the fates of many new gTLD applicants, may have a bug, according to one applicant.
In a must-read post over on CircleID, Top Level Domain Holdings CEO Antony Van Couvering presents some intriguing evidence that ICANN’s system may be mis-recording timestamps.
Van Couvering hypothesizes that that when applicants’ clicks are recorded before their target time, the software records “the wrong seconds value, but with the right milliseconds value”.
He’s asked ICANN to look into the issue, and has added his voice to those clamoring for gTLD batching to be scrapped entirely.
With so many applicants using custom software to fire their arrows, millisecond differences will be hugely important.
However, as Van Couvering notes, ICANN does not plan to reveal applicants’ scores until July 11, so it’s impossible to tell if this alleged “bug” in the test suite is replicated in the live firing range.
The digital archery system uses the now-notoriously flawed TLD Application System.
JUNE 12 UPDATE:
In a follow-up post, Van Couvering reports, based on a conversation with ICANN, that the “bug” was indeed present, but that it was in the presentation layer, rather than the underlying database.
In other words, it was cosmetic and unlikely to influence the outcome of the batching process.

Google Chrome handles new TLDs badly

Sint Maarten’s new .sx country-code top-level domain has been online for at least a couple months now, but Google’s Chrome browser appears to be still a bit wary of it.
Typing “registry.sx” and “nic.sx” into Chrome’s combined URL/search bar today, instead of being sent to my chosen destination I was instead sent to a page of Google search results.
The browser presented the message “Did you mean to go to http://registry.sx?”.

Once my intentions were confirmed, Chrome bounced me to the registry’s web site and seemed to remember my preference on future visits. Other Chrome users have reported the same behavior.
Chrome is understood to use the Public Suffix list to figure out what is and isn’t a domain, and .sx does not currently appear on that list.
Internet Explorer and Firefox (also a Public Suffix list user) both seem already to resolve .sx names normally.
While not a massive problem for .sx, which has just a handful of second-level domains active, new gTLD applicants might want to pay attention to this kind of thing.
Chrome has a significant share of the browser market – about 15% by some counts, as high as 38% by others.
Launching a new gTLD without full browser support could look messy. Chrome isn’t blocking access to .sx, but its handling of the new TLD is not particularly graceful.
Imagine a scenario in which you’ve just launched your dot-brand, and instead of arriving at your web site Chrome users are instead directed to Google (with the top sponsored result a link you’ve probably paid for).
ICANN is currently pondering ways to promote the universal acceptance of TLDs for precisely this reason.
Searches for the pop producer Will.I.Am prompt Chrome to attempt to find an address in the Armenian ccTLD.

Newbie domain registrant discovers Whois, has Twitter meltdown

The need for the domain name industry to enforce accurate Whois is often cited by law enforcement and intellectual property interests as a consumer protection measure.
But most regular internet users haven’t got a clue that Whois even exists, let alone what data it contains or how to use it.
A study (pdf) carried out for ICANN’s Whois Review Team last year found that only 24% of consumers know what Whois is.
This stream of tweets I chanced across this afternoon, from what appears to be a first-time domain registrant, is probably more representative of consumer attitudes to Whois.
UPDATE (April 27): I’ve removed the tweets per the request of the Twitter user in question.

No Google boost for new gTLDs

Companies hoping to reap search engine optimization benefits from applying for keyword gTLDs related to their industries are in for a rude awakening today.
Google engineer Matt Cutts said that it’s “just not true” that relevant gTLDs will automatically rank higher than their equivalent .com domains.
In a post on Google+, Cutts wrote:

Google will attempt to rank new TLDs appropriately, but I don’t expect a new TLD to get any kind of initial preference over .com, and I wouldn’t bet on that happening in the long-term either. If you want to register an entirely new TLD for other reasons, that’s your choice, but you shouldn’t register a TLD in the mistaken belief that you’ll get some sort of boost in search engine rankings.

The post was in response to an article by ARI Registry Services CEO Adrian Kinderis, in which he postulated that dot-brand and keyword gTLDs can help build credibility, leading to SEO benefits.
Kinderis wrote:

Ultimately, the big question is: will car.insurance rank higher than carinsurance.com (for example)? All the evidence suggest the answer is yes, provided that the .insurance namespace builds value and perhaps verification into its space to ensure it is a signpost for good, trusted and authoritative content.

In response to Cutts’ post, Kinderis said he’s sticking by his opinion.

Dyson says new gTLDs will kill the DNS

Former ICANN chair Esther Dyson thinks apps and new gTLDs will cause internet users to abandon domain names.
In an article for TechPresident entitled “Is the Open Web Doomed? Open Your Eyes and Relax“, Dyson writes:

Right now, we’re moving slowly from open data and APIs and standards, to a world of Facebook and apps. We’re likely to see abandonment of the DNS by consumers both because of those apps, and a tragedy of the commons where new Top-Level Domain names (.whatevers and .brands) confuse users and lead to more use of the search box or links within apps.

The point seems to run counter to the rest of her argument, which is that the open web will continue to be used even while Facebook carves away its own little corner of it and that the whole “walled garden vs open web” war is fought in cycles.
(At least, I think that’s what she’s saying, it’s not an easy read.)
I always find these arguments confusing.
If consumers are not using the DNS, where are these “search boxes” and “links within apps” sending them? IP addresses? How do the consumers know they got to where they wanted to go?

Verisign: our DNS was not hacked

Verisign today reiterated that the recently revealed 2010 security breaches on its corporate network did not affect its production domain name system services.
In a statement, Verisign said:

After a thorough analysis of the attacks, Verisign stated in 2011, and reaffirms, that we do not believe that the operational integrity of the Domain Name System (DNS) was compromised.
We have a number of security mechanisms deployed in our network to ensure the integrity of the zone files we publish. In 2005, Verisign engineered real-time validation systems that were designed to detect and mitigate both internal and external attacks that might attempt to compromise the integrity of the DNS.

The statement followed several news reports that covered the hacks and speculated about the mayhem that could ensue if Verisign’s root or .com zone systems were ever breached.
The information the company has released so far suggests that the attacks were probably against back-office targets, such as user desktops, rather than its sensitive network operations centers.

New gTLD applications briefly vanish after glitch

A software glitch in ICANN’s TLD Application System was apparently to blame for a number of “disappearing” new generic top-level domain applications today.
At about 4pm UTC today, two Neustar executives tweeted that some applications, among them the company’s own .neustar dot-brand application, had vanished from their TAS accounts.
TAS is the web-based application, presented as a series of questions, which applicants must use to file and pay for their new gTLD applications.
Several other applicants were also believed to be affected.
It took about two hours for ICANN to sort the problem out.
A spokesperson later said: “A display issue occurred in TAS, it has been corrected. All data is now visible & no information was lost.”
It’s the second technical problem to be reported in TAS this week.
On Tuesday, consultant Fairwinds Partners reported that some applicants had problems filling out their TAS profiles, preventing them from completing their applications.
Frankly, I’d be more surprised if this kind of thing didn’t happen.
TAS is brand new custom-built software, and as anyone who’s ever written software will tell you, no amount of testing can substitute for production use when it comes to finding bugs.

Typosquatting is huge but not dangerous, study finds

A study of typosquatted domain names has found that the practice is reaching pandemic levels for the largest brands, but that there’s surprisingly little malware distribution going on.
The security company Sophos surveyed 2,249 domains that were one letter different to the .com sites of Facebook, Google, Twitter, Apple and Microsoft, and found that two thirds resolved.
Not all of those 1,502 sites were malicious typosquats; some were legitimate sites that just happened to have similarly spelled names (such as goole.com and witter.com) Sophos noted.
Apple was the most-squatted company, according to this method: resolving Microsoft typos were at 61%, Twitter at 74%, Facebook at 81%, Google at 83% and Apple at 86%.
Sophos concluded that “there is a significant typosquatting ecosystem around high-profile, often-typed domain names.”
But it did not find as much malware as it was expecting, with only one domain leading to a malware site, 0.07% of the total.
However, 2.7% of the URLs “fell into the loose category of cybercrime”, which “means they are, or have been, associated with hacking, phishing, online fraud or spamming”.
The report, which also fingers parking services from Demand Media, Sedo, Oversee and Bodis as the recipients of 37% of the typo traffic, contains much more data and is well worth a read.
Annoyingly, it appears that Sophos only surveyed .com domains, so the data doesn’t really tell us much about the impact of TLDs (such as .co) on the typosquatting problem.