In May, Google generated a tempest in the cybersecurity teakettle with this announcement on Twitter:
Today, Google Registry is launching eight new top-level domains: .dad, .phd, .prof, .esq, .foo, .zip, .mov and .nexus.
The human interest benefits of .dad and .foo top-level domains (TLDs) notwithstanding, there’s also some reason for cybersecurity concern there. Sharp-eyed readers will notice that that list includes both .zip and .mov TLDs, even though these are most commonly associated with file types (not URLs).
What’s the problem? In a nutshell, these new TLDs introduce the possibility of user confusion (either intended or unintended) that could lead to a breach.
Specifically, if you give people a written phrase they mistakenly assume to be a file, with a .zip or .mov file type, and clicking that phrase instead launches them to a website of unknown safety, there may be security ramifications.
If we augment this reasoning with Murphy’s Corollary of Cybersecurity — “anything malicious actors can leverage for ill effect, they will leverage for ill effect” — we arrive at the conclusion that Google’s new top-level domains look like bad news. And indeed this is just the conclusion reached by many.
What a tangled web we weave…
It’s certainly true that we can imagine security-problematic scenarios. For instance, consider the way many apps and services attempt to recognize partially-written domains (such as google.com) and automatically convert them into a clickable hyperlink for easy web access.
This being the case, such apps and services might, in the future, inadvertently steer users to sites users never intended to visit by presenting an automatically-generated hyperlink to a .zip or .mov URL, though no such hyperlink was intended by the original text’s author (who only meant a file).
Bad actors recognize this possibility and may register such domains and create malicious websites in order to harvest user credentials, personal identification, banking information, and other sensitive data.
In fact, it appears that this theoretical scenario is already playing out. Internet services firm Netcraft published a report stating that phishing attacks based on these new TLDs are already underway based on such commonly-cited “domains” as microsoft-office.[zip], e-mails.[zip], and report2023.[zip].
What has Google got to say for itself?
Such has been the uproar that Google has already responded on this subject. Let’s consider its response to WIRED this month on a point-by-point basis:
The risk of confusion between domain names and file names is not a new one. For example, 3M’s Command products use the domain name command.com, which is also an important program on MS DOS and early versions of Windows.
Yes, that’s true, but it seems a tenuous point because hardly anyone is using MS-DOS or early versions of Windows. And let’s be honest, how many people are routinely accessing 3M’s website?
This means that very few people in 2023 would associate the phrases .com and command.com with anything but a URL, and very little confusion exists on that topic. Such is certainly not the case for .zip and .mov. So I’m not sure that’s a very powerful rebuttal on Google’s part.
In addition, arguing that you are only piling on an old problem is hardly a responsible attitude.
Google also said:
Applications have mitigations for this (such as Google Safe Browsing), and these mitigations will hold true for TLDs such as .zip.
Some applications have some mitigations, yes. But since Google can’t and doesn’t control what non-Google developers choose to develop, this point seems questionable as well. Google simply has no way to know whether, or how, future applications and services developed worldwide will handle this issue.
More apt, in my opinion anyway, was Google’s third remark:
We will continue to monitor the usage of .zip and other TLDs, and if new threats emerge we will take appropriate action to protect users.
This conveys more reassurance since it amounts to Google alluding that it will shut down problematic domains once they’re established as problematic.
Here, though, I still find fault with Google because they’re just saying they’ll react to proven threats. What works best in cybersecurity, on the other hand, is a proactive strategy to prevent a given class of threat from manifesting in the first place.
Google surely knows that, and arguably Google should have given it more weight before launching these two TLDs at all.
So are the new .zip and .mov TLDs a nightmare?
On balance, I doubt these new TLDs will be earth-shattering.
I think this for a number of reasons:
- The general problem of uncertain URLs leading people to security-dubious sites has been around almost as long as the web itself. While it remains unsolved, and will probably never be fully solved, by and large, it has not been a security disaster. I don’t really perceive .zip or .mov TLDs as dramatically worsening that situation, so much as adding to it by some small percentage.
- The fact that these new TLDs have generated as much attention as they have heavily implies that developers will be taking this situation into account in writing new code. Many, if not most, may simply opt not to include such auto-translation — at least not any time soon — specifically to avoid the reputational hit they might otherwise sustain. Others may give users this capability only as a selectable preference (thus making it opt-in, and offloading the responsibility for unfortunate consequences onto users). Very few, I would think, will always generate hyperlinks with no controls granted to users whatsoever.
- Google itself is surely not interested in taking a larger PR hit than it already has. It will, as it has promised, act aggressively to monitor and shut down malicious TLDs involving .zip and .mov. Yes, it’s true, as I said earlier, that this is a reactive rather than proactive solution… but the bigger the PR problem Google faces if malicious TLDs do emerge as a serious issue, the more resources it will allocate in response. And the more resources they allocate, the more difficult it will be for malicious actors to succeed with this particular vector.
What do you think? Do these new TLDs warrant serious consideration from security teams? Or are they simply another item on a long list of possible-but-improbable attack vectors to keep an eye on?
What to read next