New TLDs: Not Bad

The fact that file extensions and TLD's were roughly the same length in the same format wasn't a big issue, when it's generally understood that ".com" and ".edu" are domains, while ".jpg" and ".mp4" are files. (And as the author states ".com" files are rarely seen by users anymore.)

But if the .zip TLD takes off, it's just adding a little bit more cognitive load. Sure, hopefully it's usually clear whether somebody's discussing a filename or a domain name from context. But not always, and that's annoying and anti-user. Conventions have value, and this decreases that value.

So really, it's just like... of all the possible TLD's, is there really any benefit to picking ones that are also common filename extensions? Is our economy really going to suffer if we say, hey let's not make things like .txt and .doc into domains as well? There are tons of other TLD's we can create instead.

Google bought these TLDs. Google also owns Chrome. When you type "something.zip" into the Chrome toolbar, it used to search for it. Now it takes you to a URL. Is that the most widespread vector for attack? Probably not. But at the very least, it's super annoying for people searching for a certain file.

I'm yet to see a single compelling reason why they should exist; the best defense has been "well yeah there's a ton of issues but _maybe_ it's not as bad as we think".

They couldn't add the email, they said the system was telling them it was an invalid email. Inaccurate email validation in the wild... I suspect the system has a list of known TLDs and that didn't exist when their system was created. Or even worse, they have some hardcoded list of known email providers...

I mean WHY?! Why the fuck do we need more tlds? And even if we needed new tlds, in the billions of possible choices, why would you choose something that confusing?!

Travel vetted each applicant, so you'd know that you were probably not visiting a scam site.

Tel was a little different, and more of a registry, but again...not malicious.

Us was more standard, only requiring that you be a US resident to register. But because it was a govt contract, any whisper of a domain being used maliciously was met with an audit that would shut it down if you couldn't provide a passport. It wasn't perfect, but better than nothing.

It would be nice if more TLDs audited registrants or restricted registrations in some way. A TLD that gains trust is more likely to gain adoption, IMO, even if it is a gTLD.

Instead, it seems to be a giant money grab from all parties involved, which has greatly hurt both trust and adoption.

Pedantically it shouldn't matter, but in practice it seems like a real headache. We can all think of common usage and edge cases where it could lead to real issues, from automatic link detection to malware spread.

At this point all we can do is shake our heads at the stupidity and prepare ourselves for the worst.

Search for file.zip and if it doesn't find a local copy, it will look for a similar result on the web.

If you clicked enter before looking (say, you had a typo but meant another file), Safari happily opens the page. I believe that if the page serves a zip, it downloads and unzips it in the background.

This TLD sounds like a terrible idea for Mac security, at the least.

mov and app is similar, but requires more configuration - and .app by default will not run when downloaded, and .mov is harder to exploit.

Interesting how Google and M$ added their own TLDs (and a fairly large amount of them).

(Edit: .meme and .dad are also google, so it's all forgiven)

If you have a file it's after a /. Usually it's after multiple /'s.

If you have to do file scanning in email or do any security/governance work at all, TLDs that collide with filenames look like a disaster. An example would be, given a string in a file draft.temp.zip, does it refer to a local filename or a domain? I'd even suggest muddying the namespace like this is a kind of subversion of the internet, which was effectively a social contract about consistency and end to end connectivity. Breaking internet namespaces like this separates the user and person from the network and makes them completely dependent on mediation in the OS for reasoning about basic endpoints. If there is no distinction between files on your machine and on platform company machines, you are in a walled garden.

Adding well known file extensions as TLDs will add a fundamental inconsistency that is just injecting chaos as a means to manage it. Yes, MSFT always had .com files and the internet survived, but that's an exception from a company that has never solved a problem they hadn't first caused.

Now "rarely", "mostly" and exotic situations" made me curious. Is there any chance at all to get a *.com file running on a any windows not older than two decades?

Where it indicates "scheme" - that is actually protocol to be used.

Nothing was stopping people from doing that before.

    hey, check out <a href="https://example.com">VacationPhotos.zip</a>

The main argument against domain confusion is basically that the author doesn't personally see it as an issue, underlined with a bunch of strawman arguments of things that could theoretically appear in urls but never do in practice.

But none of that matters, because thanks to forced HSTS, there will surely never ever be a malicious domain on those new TLDs. This is because, though the new domains may make security harder for users, forced HSTS makes security easier for certain other parties which are not users. So users just have to rely on the smooth operation of those theoretical other parties and everything will work out.