Honestly, I harbour just a smidgeon of hope that cases like this will nudge companies to reevaluate the whole “find text that could be a link with a missing protocol” feature and realise that it’s a terrible idea that causes more trouble than it solves. If you want a link, write a proper URL.
The embedded tweet shows another problem, too:
> Grrr... Because .zip is a valid TLD, it's impossible to know whether http://t.co/webB2l1Y9w should be a URL or a filename.
Twitter mangle your links to use t.co including the presented text, so that embedders have no way to determine that the text was supposed to be “example.zip” without following the link or the tweet link. There may have been some purpose to t.co quite a few years ago, but the reasons justifying it vanished completely a few years ago, leaving behind just something that is completely hostile to users and security common sense.
(This also reminds me of Cloudflare’s “email address protection” feature, which catches and mangles (in a you-need-to-run-our-JavaScript sort of way, so it doesn’t actually affect most people) various things that aren’t and can’t be email addresses, like package-name@1.2.3.)
I've only ever implemented this in hobby projects, but after a while my simple rule to detect links that are missing the protocol prefix became either having a www. prefix or having a slash after what could be a domain name.
Rickrolling in 2008: Boisterous Synth Music and Rick Astley
Rickrolling in 2023: Video is initially paused with a full title card visible, If you attempt to play it, you get 5 seconds of an AD playing before you can manually click a Skip button, then finally the synth music comes in...
My mobile setup is damn near as good as my desktop is. I got that all too familiar fill intro to groove we love to loathe same as it always was intended.
It could just as easily be configured to send a real payload if you're connecting from certain IP blocks, or if your user agent matches a certain version, etc. Advanced actors don't serve up a payload to any device that connects.
Excellent! We are fortunate the current owner of that domain is as others mention chaotic good.
Side note: Dungeons and Dragons role play is a meaningful part of our culture in ways I am sometimes amazed by. I think back in wonder to campaigns run on my bed, music playing in the background on my home assembled and built, custom for my room, sound system; people imagining, sharing, interacting with a quiet fire in their eyes, all of us holding onto a shared fantasy state for all it is worth.
Who knew?
I am sure some did, but I didn't. It was counter culture back then. And it was amazing! Text adventure games hold a little of the feel and at that time were kind of a bridge between normies and our scene with magic, fantastical creatures, artifacts, stories of love, evil, conquest, treasure, discovery and all of it intoxicating.
Safari extensions "Vinegar" and "Baking Soda" are also great at turning pretty much any web video player into a native html5 player and automatically blocking autoplay.
Funny that this is said from a .mobi website, which is also a file extension. Granted, .mobi files are much less used and much less standardly shared than .zip files, but still it made me smile.
Neither of those are used by general consumers on a regular basis. Those are used by people that are generally knowledgeable. I don't know why people can't wrap their head around this. .zip is used every day by people that aren't the best at understanding computer security. Massive difference.
The category of "tech literate enough to use zips but not enough to know not to blindly click links in emails and also aren't covered by their company's security policy" is a pretty niche group. Your grandpa isn't compressing zips and sending them around to family. Vast vast vaaaaast majority of people just use direct file uploads.
This is going to be a problem, but not for the average folk, but rather for IT teams with unstable rules and other software teams like Gmail who are likely to signal larger differences between attachments and just links.
> The category of "tech literate enough to use zips but not enough to know not to blindly click links in emails and also aren't covered by their company's security policy" is a pretty niche group.
As someone that has worked on a support desk in my youth, I can assure you that this is not true. I've seen 20-year-olds open bad attachments or fall for password reset phishing. A new one is a texting scam from your manager, etc asking you to do them a favor. Scammers are pretty good at what they do (even if it seems obvious to us), that's why the US is scammed out of billions a year. The new TLD is absolutely going to get people scammed. It might not be on a nightmarish level, but it's going to happen.
My co-founder will have trouble with this, as would several others.
Over the years, I have held enough varied and deep IT and development roles to warrant volunteer mentoring aimed at combating this kind of thing. My experience says the group of people hit by this is larger than many of us would expect.
My number one favorite approach is to share some stories and get others to do the same to get that convo up and running. Then set that baseline rule: if you were not expecting it, don't open it and or send it to me.
I get a few a month and from competent people.
Fact is we are often working hard with a lot on our minds. And then the slip happens. It is that momentary relaxing of discipline and hello!
no, but commonly used services like Google Drive often zip folder downloads automatically, so regular users have been conditioned to blindly accept .zip downloads. so even if grandpa himself doesn't know how to create a zip file, he might very well try to open a .zip link when he sees one.
Honestly I think while confusing, this will ultimately not wind up being a big deal. As it is, I have spotted literally hundreds of accidental links across the internet, caused by ccTLDs and gTLDs. Any time someone ends a sentence with a period and doesn't put a space after it it's extremely easy for it to become an accidental link.it isn't that hard to imagine :)
Doesn't necessarily mean it's great for ICANN to be granting all of these dumb top-level domain names, but it is a stronger argument against aggressive autolinking. It's always been crappy behavior anyways.
Side note: Outlook automatically converting addresses into Bing Maps links is quite frustrating when you copy+paste dozens of addresses a day for work.
Also, copy pasting links using the title of the page as the label and putting the actual link behind a "security scan" thingie so that it is incredibly annoying to just get a blank link.
Because these systems and conventions were first. ICANN should have considered the status quo instead of passing the buck to thousands of other preexisting implementations.
As I've said elsewhere, I don't think any of them was a big deal. Normal people don't send each other .com files, and users of .pl/.sh/.rs files are likely sophisticated enough to spot the difference. But tons of webmail users may click Photos.zip and open whatever it downloads. They already do in whatever phish mail they get, but thanks to autolinking now the boobytrapped links will be everywhere, including trusted sources.
It's only going to cause problems for software which tries to be too smart for its own good. Applications should not try to guess what the user meant in ambiguous situations because they will often get it wrong.
Until now they were mostly getting it right, and unintended links were more of a minor annoyance than a risk (e.g. it happens when talking about Perl or Rust files, but programmers aren't an easy phishing target).
No, it was mostly so cautious it only worked under very strict conditions (ie https and www had to be present or only certain domains) to the point of being useless. Others got quite a lot wrong such as reddit regularly cutting off valid links that left you having to manually copy the entire link anyways.
The same exact security issues that are present here with .zip are also possible with unintended links.
It was common to see viruses spread by someone sending an executable attachment called "amazon.com" or similar and have people click the link to open it. Most email providers now flat out strip attachments with .com extensions.
.com file weren't typically emailed to people, and there was no expectation that clicking on them would do something harmless like display some files or a document.
It's not a commonly used extension, and it's a dangerous file type, so users shouldn't be opening received .com files either way. OTOH .zip is quite common and has legitimate uses.
.exe is a more recently used file extension, luckily there isn't (yet) any TLD with that. Belize have .bz (and the domain tar.bz exists), but both the extension used is usually .bz2, and is not so commonly used for transmitting files, .gz would had more impact.
But in the end, is about applications, that may be showing/using 2 different things, URLs and filenames, with different namespaces and use cases, in a pretty similar way.
First thing I do when configuring a browser is disabling search in the url bar and activating the dedicated search bar.
Not only it is less ambiguous but I don't want google/duckduckgo or whichever search engine I am using all the domains, url and possibly credentials I am using and I am pretty sure I will do a typo once in a while.
It should be a best practice in any business entity yet I haven't seen any company enforcing this. Apparently everybody is fine leaking internal stuff.
Message someone and mention a file with a .zip extension, like "Go to Trusted Bank and download financials.zip". Since .zip is now a TLD, software could auto-link it to https://financials.zip. The receiver will think the sender legibility linked to financials.zip for their convivence, but in fact they'll be redirected to a URL with a malicious zip file.
> At least with HTML email, I can already link text to an arbitrary link.
The sender doesn't have to link to anything. Merely writing some non-whitespace characters, followed by a dot, followed by a TLD can trigger client software to automatically create a link, e.g. mentioning "attachments.zip" could cause client software - that is trying to be clever - to create a link to https://attachments.zip which might serve a malicious zip file. The receiver will think the sender created the link, but in actuality it was their own software that created it trying to be clever.
> This whole thing doesn't seem that important to me.
This affects any client software that creates auto-links for TLD's. The "solution" is software must never create an auto-link in the absence of a protocol, e.g. never auto-link "example.com" but "https://example.com" is ok.
Chat clients like whatsapp don't allow you to link text to an arbitrary link, but instead will automatically turns text "attachment.zip" into a link to http://attachment.zip
Arbitrary and numerous TLDs would make the root servers job a lot harder. As-is, the root servers serve a nearly static zone, and high traffic domains are distributed somewhat over several TLD's servers. It wouldn't be impossible to smoosh that all into one cluster, but it would be a bigger challenge than the status quo. You would also have a lot more administrative tension; there are several organizations that each run one or two letters of the root servers; getting them to all coordinate real time changes to a massive zone would be challenging. (I believe all the TLDs, and certainly all the majors are each run by one organization)
There are only 24^3 possible combinations of 3-letter file extensions, 34^3 if we start mixing in numbers. And they potentially will need to be constantly available for decades to come... We should probably use more sparingly to prevent a repeat of the IPv4 situation.
The embedded tweet shows another problem, too:
> Grrr... Because .zip is a valid TLD, it's impossible to know whether http://t.co/webB2l1Y9w should be a URL or a filename.
Twitter mangle your links to use t.co including the presented text, so that embedders have no way to determine that the text was supposed to be “example.zip” without following the link or the tweet link. There may have been some purpose to t.co quite a few years ago, but the reasons justifying it vanished completely a few years ago, leaving behind just something that is completely hostile to users and security common sense.
(This also reminds me of Cloudflare’s “email address protection” feature, which catches and mangles (in a you-need-to-run-our-JavaScript sort of way, so it doesn’t actually affect most people) various things that aren’t and can’t be email addresses, like package-name@1.2.3.)