Cool trick - they're using HTTP auth URLs[1] so that the @ sign is doing a lot of the heavy lifting (plus some clever unicode slashes). It's an old school phishing trick, with the additional layer of looking like a genuine zip file.<p>Not sure if this trick would be too effective in real life, Firefox and likely others will give you warnings when logging into a site like this, as this form of HTTP auth is way deprecated. However, this is the strongest example against .zip I've seen yet though, from someone who didn't buy into the initial panic.<p>Side note - I'm using .zip for something legitimate! <a href="https://HN.zip" rel="nofollow noreferrer">https://HN.zip</a> is a little weekend project for an offline-caching read-only Hacker News (I lose reception in the Subway a lot so it makes it easier to navigate). It's not done yet though - still pretty rough around the edges. Maybe in a week or two I'll do a Show HN and see if anyone cares.<p>[1] <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#access_using_credentials_in_the_url" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...</a>
Here's the original source by the author: <a href="https://scribe.rip/@bobbyrsec/the-dangers-of-googles-zip-tld-5e1e675e59a5" rel="nofollow noreferrer">https://scribe.rip/@bobbyrsec/the-dangers-of-googles-zip-tld...</a><p>While I think that we really don't need a .zip domain, this trick falls apart when not shown as an image. Hovering over either URL should tip you off. Firefox shows the actual link in the bottom left.
As an "old school" web developer, the `@` sign in the URL was an <i>instant</i> dead giveaway to me, but I'm willing to bet almost <i>nobody</i> outside of those sorts of "old school" tech circles is gonna even notice that.
From Google's domain delegation application (<<a href="https://gtldresult.icann.org/applicationstatus/applicationdetails/535" rel="nofollow noreferrer">https://gtldresult.icann.org/applicationstatus/applicationde...</a>>):<p>> <i>28. Abuse Prevention and Mitigation [...] all registered domain names will be subject to a Domain Name Anti-Abuse Policy (“Abuse Policy”). The Abuse Policy will provide CRR with broad power to suspend, cancel, or transfer domain names that violate the Abuse Policy. We plan to post the Abuse Policy on a publicly facing website at nic.zip⁄abuse</i><p>The policy document in question cannot, in fact, be found at that* address (because they're using a wildcard URL-rewriting redirect for nic.zip that ends up pointing to a bogus URL on registry.google).<p>* Actually, anyone familiar with IANA applications will be aware that the applications posted publicly end up, coincidentally enough, mangling all references to URLs because slashes get transformed into U+2044 FRACTION SLASH, so if you actually tried to dereference <i>that</i>, you'll end up on a path dealing in punycode TLDs—specifically "xn--zipabuse-g03d" in this case, which has not (yet) been delegated to anyone.
The trick here is the "@" in the URL, which makes everything before it a user name.<p>It is an old trick, and browsers tend to throw a fit before opening URLs with user names.
<a href="https://github.com/kubernetes/kubernetes/archive/refs/tags/@v1271.zip">https://github.com/kubernetes/kubernetes/archive/refs/tags/@...</a><p>I get a: "404: Not Found" from the site "codeload.github.com"