The Dangers of Google’s .zip TLD

The fact that browsers will silently strip out everything before @, including &quot;fake&quot; slashes is surely the real problem here. That .zip is now a valid TLD doesn&#x27;t strike me as making the situation vastly worse - something like <a href="https:&#x2F;&#x2F;github.com&#x2F;kurbernetes&#x2F;@latest.dev&#x2F;package.zip">https:&#x2F;&#x2F;github.com&#x2F;kurbernetes&#x2F;@latest.dev&#x2F;package.zip</a> seems just as likely to fool a recipient not being 100% vigilant. (To be fair, that used real slashes - all the substitute slash characters do actually look noticeably different to a regular slash - perhaps surprisingly there&#x27;s no &quot;non-breaking slash&quot;. Actually the big solidus ⧸ is pretty close but HN seems to block me using it in a URL!)

&gt; Can you quickly tell which of the URLs below is legitimate and which one is a malicious phish that drops evil.exe?<p>Yes? When you hover the first link the browser says &quot;v1271.zip&quot;, and when you hover the second link it says &quot;<a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;archive&#x2F;refs&#x2F;tags&#x2F;v1.27.1.zip">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;archive&#x2F;refs&#x2F;tags&#x2F;v...</a>&quot;<p>You don&#x27;t even need a .zip domain to do this, just assign a misleading link i.e. [google.com](badsite.com). If the argument is going to be no one looks at the on hover link preview, then why bother even paying for a .zip domain in the first place? Going further, you can also just buy a similar domain to confuse people, which might even work better than buying the .zip since then you _might_ even catch careful people that glance at the on hover preview.

&gt; In an email client, we could make it even more convincing, and change the size of the @ operator to a size 1 font<p>Doesn&#x27;t change the underlying issue, but plain text email would have stopped that part of it!<p>Of course, that&#x27;s banned at work because then the signature wouldn&#x27;t have the approved font and picture in it, and therefore it&#x27;s not Corporate (TM) enough.

While I get it... there are plenty of risks just with high characters in domain names. I would simply suggest the &quot;hover&quot; view for links don&#x27;t show the translated punycode character encoding for domains.<p>I think it would be far more of an issue if .lan or .local were ever able to make it past icann for a registrar. What&#x27;s funny to me, is the number of web forms that haven&#x27;t been updated to allow anything other than .com&#x2F;net&#x2F;org for signup.

You can block all .zip with the following uBlock Origin filter:<p><pre><code> ||zip^ </code></pre> Tell everyone you know.

Blue Coat Systems warned about the .zip domain quite some time ago.<p><a href="https:&#x2F;&#x2F;www.cio.com&#x2F;article&#x2F;220242&#x2F;the-webs-10-most-shady-neighborhoods.html" rel="nofollow">https:&#x2F;&#x2F;www.cio.com&#x2F;article&#x2F;220242&#x2F;the-webs-10-most-shady-ne...</a>

What is the argument in favor of these TLDs existing other than corruption&#x2F;extortion?

I blackholed .zip and .mov in my DNS servers.