Israeli registrar denies “arms dealer” claims

Israeli registrar GalComm has denied being involved in a widespread malware distribution scheme after being fingered by a security outfit.

Last month Awake Security accused the registrar, officially Communigal Communication Ltd, of being “at best complicit in malicious activity”.

The firm published a report entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars” which linked GalComm to a network of malicious Chrome browser extensions the firm said can steal sensitive data from users who have them installed.

It identified 111 such plug-ins, which it said have been downloaded 33 million times, using over 15,000 domains registered via GalComm.

GalComm has around 48,000 domains registered in gTLDs at the last count, so that’s a sizable percentage of the registrar’s business.

Awake came to the conclusion that GalComm was well-aware of what its customers were up to.

Now, the registrar has sent a cease-and-desist notice to Awake, CC’d to ICANN (pdf), in which it denies all knowledge and responsibility for the malware.

GalComm’s line, to summarize, is that it’s just a registrar, and that it has no obligation to monitor how its customers use their domains.

It adds that the domains in question amount to 10% of its DUM. Still a pretty big chunk.

The company wants Awake to retract its report by today, which it has not yet done, or it will call in the lawyers.

Emoji domains now easier to use

Emoji domains have become marginally easier to navigate to in the last month, following an update to Google’s Chrome browser.
Google has added “Emoji” to the context menu that appears when users right-click in any editable text field — including the address/search bar.
Clicking the option brings up a searchable list of common emojis that can be inserted into the address bar for either search or, with the addition of a typed-in TLD, navigation.
TLDs currently supporting emojis include .ws, .fm and .to. ICANN has ruled out support for emojis in the gTLDs for security reasons.
When the domain is resolved, the emojis render in the address bar as Punycode-converted Latin characters beginning with the usual “xn--” prefix, at least under my default configuration.
The whole process is still a bit fiddly, so I wouldn’t all rush out to build your businesses on emoji domains just yet.
The context menu feature appears to have been on the experimental track in Chrome for at least a month, but was more recently turned on by default, at least on all the Chrome 69 installs I’ve tested.
If you don’t get the emoji option in your context menu, you should be able to turn it on by navigating to chrome://flags/#enable-emoji-context-menu and selecting the Enabled option.

Here’s how to display new IDN gTLDs in Chrome

A lot of people have noticed since the first four new gTLDs were delegated yesterday that Google’s Chrome browser doesn’t seem to handle internationalized domain names.
In fact it does, but if you’re an English-speaking user you’ll probably need to make a few small configuration changes, which should take less than a minute, to make it work.
If you’re using Chrome and you click this link http://nic.сайт chances are your address bar is going to automatically translate it and display it as http://nic.xn--80aswg/.
As far as the DNS is concerned, these are the same URLs. They’re just displayed differently by Chrome, depending on your browser’s display languages settings.
If you want to see the Cyrillic version in your address bar, simply:

• Go to the Chrome Settings menu via the toolbar menu or by typing chrome://settings into the address bar.
• Click the “Language and input settings” button. It’s in the Advanced options bit, which may be hidden at first. Scroll all the way down to unhide.
• Click the Add button to add the languages you want to support in the address bar.

Right now, you can see all three active IDN gTLDs in their intended scripts by adding Arabic, Chinese (Simplified Han) and Russian. As gTLDs in other scripts are added, you’ll need to add those too.
Simple.
Thanks to DNS jack o’ all trades Jothan Frakes for telling me how to do this.

Public Suffix List to get monthly new gTLD updates

New gTLDs are set to be added to the widely used Public Suffix List within a month of signing an ICANN registry agreement, according to PSL volunteer Jothan Frakes.
This is pretty good news for new gTLD registries.
The PSL, maintained by volunteers under the Mozilla banner, is used in browsers including Firefox and Chrome, and will be a vital part of making sure new gTLDs “work” out of the box.
If a TLD doesn’t have an entry on the PSL, browsers tend to handle them badly.
For example, after .sx launched last year, Google’s Chrome browser returned search results instead of the intended web site when .sx domain names were typed into the address/search bar.
It also provides a critical security function, telling browsers at which level they should allow domains to set cookies.
According to Frakes, who has been working behind the scenes with other PSL volunteers and ICANN staff to get this process working, new gTLDs will usually hit the PSL within 30 days of an ICANN contract.
Due to the mandatory pre-delegation testing period, new gTLDs should be on the PSL before or at roughly the same time as they are delegated, with plenty of time to spare before they launch.
The process of being added to the PSL should be fairly quick for TLDs that intend to run flat second-level spaces, according to Frakes, but may be more complex if they plan to do something less standard, such as selling third-level domains, for example.
Browser makers may take some time to update their own lists with the PSL updates. Google, with its own huge portfolio of applications, will presumably be incentivized to stay on the ball.

Apple, Google and Microsoft still don’t understand new TLDs

The world’s most-popular web browsers are still failing to recognize new top-level domains, many months after they go live on the internet.
The version of the Safari browser that ships with the Mountain Lion iteration of Apple’s OS X appears to have even gone backwards, removing support for at least one TLD.
The most recent versions of Google’s Chrome and Microsoft’s Internet Explorer also both fail to recognize at least two of the internet’s most recently added TLDs.
According to informal tests on multiple computers this week, Safari 6 on Mountain Lion and the Windows 7 versions of Internet Explorer 9 and Chrome v24 all don’t understand .post and .cw addresses.
Remarkably, it appears that Safari 6 also no longer supports .sx domains, despite the fact that version 5 does.
Typing affected domain names into the address bars of these browsers will result in surfers being taken to a search page (usually Google) instead of their intended destination.
If you want to test your own browser, registry.sx, una.cw and ems.post are all valid, resolving domain names you can try.
The gTLD .post was entered into the DNS root last August and the first second-level domain names went live in October.
The ccTLDs .sx and .cw are for Sint Maarten (Dutch part) and Curacao respectively, two of three countries formed by the breakup of the Netherlands Antilles in 2010.
ICANN approved the delegation of .cw in October 2011 and second-level domains there have been live since at least July 2012 (that’s when the registry’s site, una.cw, went live).
SX Registry’s .sx was delegated in December 2011 and sites there have been live since early 2012. It went into general availability in November.
Safari v5 on Windows and OS X recognizes .sx as a TLD, but v6 on Mountain Lion does not.
The problems faced by .post and .cw on Chrome appear to be mostly due to the fact that neither TLD is included on the Public Suffix List, which Google uses to figure out what a TLD looks like.
A few days after we reported last May that .sx didn’t work on Chrome, SX Registry submitted its details to the PSL, which appears to have solved its problems with that browser.
It’s not at all clear to me why .sx is borked on newer versions of Safari but not the older ones.
If the problem sounds trivial, believe me: it’s not.
The blurring of the lines between search and direct navigation is one of the biggest threats to the long-term relevance of domain names, so it’s vital to the industry’s interests that the problem of universal acceptance is sorted out sooner rather than later.

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.

Firefox gives greater visibility to domains

Mozilla has reportedly dropped the http:// from the address bar in the latest pre-release version of the Firefox browser, in order to make the domain more prominent.
The changes, spotted over at ConceivablyTech, would also remove the trailing slash from URLs and present everything other than the top and second level of the domain in gray text.
So instead of
http://www.example.com/
you’d see something like
www.example.com
Google Chrome already does something similar, although it presents the lower levels of the domain in the same shade text as the top two.
The blog reported that the https:// will continue to be displayed for encrypted pages.
Earlier this year, Google was reported to be working on a Chrome UI that dropped the address bar altogether, which struck me as one of the more idiotic ideas — from a choice of many — to come out of the company.

Browser makers brush me off on DNSSEC support

A couple of weeks back, I emailed PR folk at Microsoft, Mozilla, Google and Opera, asking if they had any plans to provide native support for DNSSEC in their browsers.
As DNS uber-hacker Dan Kaminsky and ICANN president Rod Beckstrom have been proselytizing this week at the Black Hat conference, support at the application layer is the next step if DNSSEC is to quickly gain widespread traction.
The idea is that one day the ability to validate DNSSEC messages will be supported by browsers in much the same way as SSL certificates are today, maybe by showing the user a green address bar.
CZ.NIC has already created a DNSSEC validator plugin for Firefox that does precisely that, but as far as I can tell there’s no native support for the standard in any browser.
These are the responses I received:

Mozilla: “Our team is heads down right now with Firefox 4 beta releases so unfortunately, I am not going to be able to get you an answer.”

Microsoft: “At this stage, we’re focusing on the Internet Explorer 9 Platform Preview releases. The platform preview is a developer and designer scoped release of Internet Explorer 9, and is not feature complete, we will have more to share about Internet Explorer 9 in the future.”
Google: No reply.
Opera: No reply.

In 11 years of journalism, Apple’s PR team has never replied to any request for information or comment from me, so I didn’t bother even trying this time around.
But the responses from the other four tell us one of two things:

• Browser makers haven’t started thinking about DNSSEC yet.

Or…

• Their PR people were just trying to brush me off.

I sincerely hope it’s the former, otherwise this blog post has no value whatsoever.

Google blocks Go Daddy for ‘hosting malware’

(UPDATED) Google is currently blocking Go Daddy’s web site, calling it dangerous, because one of its image-hosting domains has been flagged for hosting malware.
Chrome users visiting pages on godaddy.com, including its storefront, currently see the standard Google alert page: “Warning: Visiting this site may harm your computer!”
Go Daddy’s main page seems to be affected because it uses images hosted at img5.wsimg.com, a Go Daddy domain.
A bit of a poke around reveals that the whole of wsimg.com is currently considered a malware site by Google’s toolbar on non-Chrome browsers, and also by the Google search engine.
The question is, of course, whether this is a simple false positive or whether bad guys have somehow managed to inject malware onto Go Daddy’s servers.
Go Daddy’s web site takes revenue in the six figures every hour, so if this is a false positive I can only imagine the content of the phone calls between Scottsdale and Mountain View right now.
But Go Daddy has been a target for the bad guys in recent weeks, with attacks against its hosting customers proving an irritant that the company can’t seem to shake off.
The company was also the victim of a phishing attack yesterday. I’d be surprised if the two incidents are connected.
UPDATE: Warren Adelman, Go Daddy’s chief operating officer, just called to say that this was indeed a false positive.
“Google erroneously flagged some of our image servers,” he said. “We need to go into this with Google, but there wasn’t any malware on our end.”
Adelman said Go Daddy has a pretty good idea what happened, but that it proved hard to get hold of the relevant people at Google on a Sunday morning during Memorial Day weekend.
Further details may be forthcoming later this week. For now, Google has apparently unflagged the servers in question, and Adelman expects the situation to be resolved within the hour.