The new .zip TLD is going to cause some problems
shkspr.mobi
shkspr.mobi
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.)
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...
Yeah, it just doesn't work anymore.
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.
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.
Hell yeah!
There are many file extension collisions with TLDs and the sky didn't fall yet
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.
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!
"I should know better."
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.
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.
https://news.ycombinator.com/item?id=35920336 ("The .zip TLD sucks", >290 comments)
Side note: Outlook automatically converting addresses into Bing Maps links is quite frustrating when you copy+paste dozens of addresses a day for work.
The same exact security issues that are present here with .zip are also possible with unintended links.
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.
This was probably for two reasons. Bandwidth was precious. Searching file systems was slow.
Maybe business ethics played a role as well.
Maybe not.
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.
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.
I’d really like to use my last name as a TLD so I can do firstname.lastname.