@ariadne@social.treehouse.systems is it the one with the @ symbol?

@ariadne At least Firefox somewhat lessens the impact of this:

@ariadne Oof

@ariadne @dysfun This is going to make little Bobby Tables look trivial isn't it?

@ariadne

Ha, easy! You simply have to compare the angle of the slashes to the ones after https: obviously in the first link the angle is too flat which indicates that it is a special character and no slash. So this is the link more likely containing the malware. As I said: Really obvious!

... we'll be fine.

@ariadne oh my, that's bad

@ariadne @thisismissem before reading had a look at that image and that @ is insidious

@ariadne and @deno_land uses "@" character in versioning of modules:
https://deno.land/x/version@v1.1.0

What could *possibly* go wrong.

Centrally blocking .zip in AdGuard I guess.
Can’t fool DNS.

https://social.treehouse.systems/@ariadne/110379902620355886

@ariadne I can tell but only because my fonts are garbage

@ariadne yes, and I did not cheat. The slashes in the first arent legit. Hard to see. Nicely done.

@ariadne it might be worth blacklisting the entire .zip TLD with something like pi-hole

@ariadne nah, / is not allowed in the userinfo part of a url

@ariadne

@ariadne but!

$ python3 uricheck.py https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip                     
Not an URI: https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip

So anything that parses that as an URI is defective.

… let’s see what my Fediverse instance/client/whatever does: https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip ← should not be a link

@ariadne . . . . . . D'aaaaaugh! That's so insidious.

@ariadne Clearly, both result in evil, but the second one delivers evil in the form of Kubernetes.

@ariadne the only answer I would accept:

Both are equally as horror-inducing and you should be reported to HR for asking this in an interview.

@ariadne This looks like a Chromium bug because unicode is not permitted in domain names. I believe any standards compliant browser will first resolve the string in “punycode” (real name) which breaks the chain of possible exploits before a page gets loaded (see RFC 3490).

Perhaps some DNS pre-caching trick could work? I don’t think DNS has the same transcoding requirement (see the toASCII requirement)

< release the standard nerds! 😈>

I miss the days when Google was competent.

@ariadne Big yikes. I don't know the dirty details of ICANN's approval process for new top level domains, but isn't this exactly the sort of thing they should be auditing for?

@ariadne pardon my ignorance here, but both urls point to github.com using https. And that would pass on the rest of the URL to the web server at github who would then return results with a certain content type. So why would either represet a risk unless you are using some Microsoft web browser that does stuff it shouldn't? Normally, the @ in a URL would be right after the host name to include username/password combination, But after the first /, it would be passed as the "GET" to web server

@ariadne

I think 2nd one is legitimate.

@ariadne There is no way they didn't know what they are doing with this.

@ariadne its the first, github archives doesn't have an @ symbol

nore that i only know this from packaging software for my distro, otherwise i wouldnt know which one it is

@ariadne @schenklklopfer Wow, took me 5 minutes to understand, whats going on.

@ariadne Why on earth did we make Google de facto rulers of the internet

@ariadne Dear lord.