The .zip TLD sucks | Hacker News Reader

The .zip TLD sucks

financialstatement.zip

610 pointsme_again318 comments

Earlier discussion on Google's announcement: https://news.ycombinator.com/item?id=35917362

Not sure it matters that much.

Most non-technical people I know wouldn't have a clue what a .zip was. Windows has hidden file extensions by default now for decades. And having a phishing link in an email that says something.zip but links to somethingelse.com is a basic scammer 101 level technique. Why would it matter if the .zip was a real part of the URL or not.

Don't get me wrong, I dislike all of the generic TLDs, and the registration process behind them. But of all the points to argue on them, this seems like the weakest and least relevant.

I don't necessary agree with this argument. Normal people call some files by their extension pretty often -- pdfs, jpegs, gifs, zips, mp3s, etc.

While an OS may hide extensions, not everything does. Notably, gmail shows the file extension for attachments.

People call things by their common social usage and program association. If all mp3 files types got replaced with a random new standard like "fmp" overnight, id bet my life that most people would continue calling them mp3s for years.

See: people calling any animated image a gif, even though many are apng or webp

Which would then be the case for Zip too.

Yes, but my point is is has nothing to do with the extension. It could be a zip, rar, tar.gz, whatever. If they could all be opened in a default windows zip program, most people would call them all zip files.

> If all mp3 files types got replaced with a random

See also: “Why does the Save icon look like that?” Most computer users these days have never in their life seen a floppy drive, but they still recognize it as the save icon.

Technical people are the same. See for example SSL.

Yeah. It is embarrassing to learn this when a PCI auditor says, "wait you don't actually still use SSL do you?"

Yup. My generalization wasn't about non-technical users. I'm also including my friends (and myself!), some of which who are software engineers, in the category who call animated images gifs.

Not true. 4chan’s gif board is pretty famous for the… uh funny webms.

Why are people so confident in making generalizations about users?

I've seen my aging father change settings on a new computer to turn on showing file extensions on Windows, because he and a lot of older users were on the cutting edge of computing back when knowing the file extension was useful for choosing how to open it.

Sure, I'm acutely aware that there are stupid users out there; I've worked I.T. But there is also a whole spectrum of computer users with varying levels of computer proficiency out there, who us "computer people" don't see because they're not the ones who necessarily need help or cause problems. You can't necessarily extrapolate a visible minority of incompetent computer users to make statements about the entire population.

I don't necessarily have an opinion on whether that's enough justification to get rid of the .zip TLD. I'm just tired of the anti-user sentiment I'm hearing here.

> I've seen my aging father change settings on a new computer to turn on showing file extensions on Windows

Man, you're lucky. My aging father doesn't know how to change the inputs on his TV. And he doesn't understand why "our Internet is down" implies "the TV will not work" when the TV is clearly working, because it's telling him that it "can't connect."

i'm not super convinced by the argument, the only thing I could think of would be a youtube comment talking about an actual zip file automatically turning that mention into a link. youtube specifically seems very eager with its auto-linking. though realistically, that's more of a youtube problem than a .zip tld problem

Lots of mail clients and messaging apps detect domains and helpfully turn them into clickable links. None of the ones I use for work are doing this for .mov or .zip (yet), but I'm sure something will at some point and it will become a target for phishing.

> Windows has hidden file extensions by default now for decades.

Thankfully this is easy to turn off. I hate it, and it makes me mad for a few seconds each time I get a new machine/OS install.

Normal people don't know about TLDs and what that term means.

So the question is: is there another convincing reason for allowing this TLD on an internet level?

And what would you think about a .pdf or .docx TLD?

The question is why are these things even limited to a fixed predefined set and not allowed to be arbitrary of some max string length, given that the rest of the domain name already is.

Or why even require a fixed extension given that it's a recursive system anyway.

There's a number of complications with a wide open gTLD system.

1. Local DNS resolution. Bare (non-gTLD) DNS names are common in business networks, and although the expansion of the existing gTLD set complicates that, opening it wide can have unintended resolution impacts for these networks.

2. Browsers enforce security boundaries based on the origin of a site, and doing this is complex due to things like .co.uk. A naive implementation would grant all .co.uk domains into a single origin. The problem comes into play when looking at local DNS names. Without a known gTLD on the end of the DNS name, the browser assumes the root of the origin is the hostname itself. That is, given a locally resolvable http://bar and a locally resolvable http://foo.bar, both sites can communicate without restriction with respect to the Same Origin Policy. If we were to make gTLDs arbitrary, we'd have to break that behavior which could break a lot of intranet applications.

"Just enter 'Max-Miller-2023-05-13.your-receipt.pdf' into your browser's address bar and you'll see the receipt :)"

i suspect most people would fall for that even if it was a .com

What if someone legitimate writes "download assets.zip", and GMail (aka Google, aka the owner of the .zip tld) starts converting it to a URL like they do with .com?

It's worse than phishing, because it could be a legitimate email from someone you trust.

(Overall, I mostly agree that the issues are ultimately somewhat minimal... but this is a situation where there's absolutely no upside and only downside.)

By the way, Windows hiding file extensions by default must've contributed to people getting scammed more than anything. The classic technique of getting someone to download and open what looks like a benign file but is actually an .exe with that file type's icon would've not worked nearly as well if file extensions were shown by default.

computer people are used to rigid syntax rules because unambiguity, and they are willing to accept "line noise" syntax because they hate ambiguity even more.

as you point out, a .exe hiding behind a .zip is a problem caused by hiding extensions. and if we still lived in the 16bit DOS/Windows world, btw, MICROSOFT.COM would be a super problematic thing to click "especially-whether" the "extension" is shown or not (in 16 bit MSDOS, .COM is just as much a .EXE as .EXE is)

I'm just writing to extend your thought to the hiding of http:// and also www.

That's what introduces these problems, not a .ZIP tld, and I suspect/know it's the same people with this same type of thinking (whackamole problem solving) who think hiding http:// is a good idea (thereby causing the problem) and then suggest to fix any problems with more regulatory agencies to control what TLDs get created, what words we're allowed to use where, etc. (thereby causing new problems)

I'm not saying computer people "know better" and therefore invent systems that are tolerable to normies, I'm just saying I can't stand when normies are in charge of things that matter to me.

The whole .COM/.EXE thing is not limited to 16-bit DOS and Windows. For a very long time now, Windows simply treats both extensions as the equivalent of chmod +x, but the way the binary is loaded does not depend on the specific extension. That is, if a .COM file has a 64-bit PE header, it will happily execute on Win11.

Indeed, a bunch of system binaries are themselves like that for historical reasons - CHCP.COM, FORMAT.COM, MORE.COM etc - because they originally had such names long ago in DOS, and someone somewhere might have a batch file that includes the extension.

> they originally had such names long ago in DOS

And DOS got them from CP/M before it.

Btw, you can even run a executable file which has been renamed to any extension (.txt or .whatever) in command line. (See PATHEXT env) It just recognized by the explorer (and shellexecute api’ third parameter). So that’s mean all files have “executable” permission by default.

but it would have had to be named MICROSOF.COM

You'll get access codes for Building 7.

the one with the VIP lounge, right?

I haven't used Windows in a while, but doesn't the OS track "mark of the web" and alert users when they try to run something they downloaded? Not to say that most users won't click continue, but that feels like the bigger, more visible warning than a file extension.

Users have been trained on Windows to click OK, automatically, without reading, on any pop-up that appears.

Not just on Windows. Modern web pages are full of cookie banners, sign-up-for-newsletter banners and please-sign-in-with-facebook banners. It's become a sport to ignore what's in popups and quickly find the right place to click to get rid of them (an OK button, a little "x" in the upper right corner, ...)

Which is a bit ironic since there was a time where browsers would routinely open popups in new windows, upon which it was immediately misused by ads, upon which browsers implemented counter measures. We're just in the next iteration of this.

There is no visible "OK" button on a SmartScreen reputation warning.

The way Windows handles these things almost makes you think they want to handicap their users to make the transition to something else more difficult.

A responsible OS should help educate and empower their users. Windows just want them to stay where they are, use Office and only install programs from their official store.

There's a sweet spot of knowing just enough to be dangerous, in this case. If you know what a .zip and can be convinced you need it but are not aware of the TLD.

> Most non-technical people I know wouldn't have a clue what a .zip was

perhaps i am getting mussed up by the definition of "non-technical people" but i've worked directly with many, many non-technical people over many years who definitely knew what a zip file was and what it was for. they might not all have necessarily known how to _create_ a zip file, and sure i had to coach/train a few here and there who legitimately didn't have a clue, but i think if you're talking about anyone who has used a computer for a large-ish piece of their work (whether it is "technical" work or not) in the last 10 years or so, the chance of them having more than no clue about what a zip file is, is higher than you think it is.

i can think of multiple instances each of accountants, graphics/media/designer folks, scriptwriters, admin/executive assistants, chauffeurs, playwrights, stagehands, light/rope riggers, costume designers/tailors, HR folks, security guards, painters, writers etc who have had to deal with .zips.

would a 20-years-exp industrial lathe engineer/specialist know what to do with a zip? maybe? maybe not? depends if they like to mess around with computers after hours or does their company distribute work orders via email? if so, maybe they've dealt with a zip.

if a "non-technical person" is someone who doesn't use a computer very much, then yeah, i'm with you. i personally wouldn't consider a junior graphic designer to be "technical" but i'd bet you all the money in my wallet that 95/100 of junior graphic designers know what to do with a .zip file.

BTW everything else you said, i 100% agree.

My gut is that anybody who has used a smart phone more than a traditional desktop OS is less likely to know what a zip is

It's a shame to see our beautiful gardens all walled up

It's not so much (or just) walled gardens, its the hiding of the more fundamental layers of the system from the user.

A user doesn't navigate through the file system to a folder where they've saved a bunch of notes in discrete text files of some format or another, they start up a notekeeping app and use its interface to open their notes. Where are these notes saved? That is either hard to find in the bowels of the settings of the app, or entirely hidden and they're saved in a database accessible only to that specific app.

> saved in a database accessible only to that specific app

Or worse, on some disk “in the cloud" rented by the app maker, subject to subscription fees and the stability of the company.

It's more convenience actually. The same path that took us away from interacting with our computers purely via a terminal connected to a mainframe.

The cycle of grumpy old men will go on, gen Z will fondly remember the tech of their day and think that later gens are lazy/too trusting for letting AGI manage their lives.

Maybe. A phone will cause more hassle if they do get a zip file, so they might be more likely to remember that.

Junior graphic designer is most definitely a tech person… they are literally working on a computer every day all day long. I think sometimes people lose sight of just how much of a bubble they are in.

Those who are old enough to remember when files had extensions might know. Those who work with a file system daily know. In both cases we are talking about extreme minorities now.

To avoid a No True Scotsman impasse, who exactly are we talking about that doesn’t know what a zip file is? Someone who doesn’t use a laptop for their day job?

I'd wager that you're going to have low familiarity at best among people under 30[0] where computer use is ancillary to job at best, so all sorts of "technician" type jobs[1] plus warehouse work, transportation, and other public-facing roles like retail, police, fire...

I would make a weaker claim than "doesn't know what it is", there are probably a lot of people there who at one point have seen "files.zip" in gmail and then downloaded it and double clicked it to expand it or such, but I don't think any of them are going to be confused by URLs with .zip domains.

I'm actually curious about the intended distribution of this website - it's header is "If you clicked on this domain by mistake" but... I clicked on it very intentionally from an HN link, so didn't expect a file attachment at all; not sure what the scenario is where something could look like a file but actually be a link? E.g. if it's on a malicious website you could easily trick users with "Download stuff.zip" link text that actually points to "bobsmalware.com" or whatever, which works just as well for anyone loosely familiar with .zip files but not sophisticated enough to not trust the text vs the actual link pointer. Just like the original comment from `SimonPStevens says.

[0] grew up on mobile, not on desktop/laptop

[1] medical, physical therapy, landscaping, painting, mechanical, etc

Yes, there are still huge numbers of people who don't own a computer other than their smart phone.

Someone like my mom, she knows Spreadsheets as green files, and other than the color and that they open Excel, for her they're the same as any other file (Windows default hiding extensions doesn't help either)

Recently, she asked me to put a set of documents into a folder (She meant a compressed file) because some page required it

I have always found it fascinating, considering she has worked with Office products for the last ~20 years

It's wild to me some of the things I never knew, even though I've been using Windows or DOS for probably 35 years.

For example, I recently learned you can't name a file CON. Try it. Somehow over all those decades, I've never tried to do this until Tom Scott made a video about it:

https://www.youtube.com/watch?v=bC6tngl0PTI

Those are the most dangerous. They will happily open a file suffixed .zip.exe when windows hides the extension and it shows as .zip.

I genuinely believe this one change in the name of 'aesthetics' (or whatever justification was created for this) has caused real, material hurt for people.

Indeed https://en.wikipedia.org/wiki/ILOVEYOU

I think they mean people who are not good with computers - a subset of non-technical person.

Think of your 80 year old granny, or the guy down the road who’s never owned a computer.

Maybe you don’t have many in your circle but they are everywhere.

> would a 20-years-exp industrial lathe engineer/specialist know what to do with a zip?

Are you kidding? That guy has to convert his files to binary, put them on a USB drive, carry them to SunOS server, plug them in, and type something in a command line to send the binary over Serial to his CNC machine.

Industrial equipment isn't EOL at 30 years, it's "lightly used." You'd be floored at how much "ancient" tech knowledge is required to operate it.

And this is why https://www.floppydisk.com/ is still doing well.

Not to mention rs-232

RS232 has adjustable frequency whereas USB can't be configured this way, making it useless for GPS devices used for time synchronization and such.

> Most non-technical people I know wouldn't have a clue what a .zip was.

Most non-technical people in the 40+ age range that I know are well aware what .zip was and still is.

Please don't consider your circle of peers in their 20s as a representative sample of society.

Except you just did the same thing.

Zip files are probably the one extension a normie would understand at least anyone who has worked in an office.

I dunno. I think most non-technical people know that .zip indicates a zipfile, and know what a zipfile is.

> Windows has hidden file extensions by default now for decades.

It amazes me that they won't stop doing this. The security problems around it are enormous, not to mention that it causes a lot of confusion that isn't easily resolved by non-technical people.

I absolutely agree. If it were a ‘.html’ extension that opened a self extracting zip we would have an issue but I struggle to see the danger with this. If someone, technical or not, is already accepting the risk of opening a ‘.zip’ file from an unknown source the attack vector doesn’t grow by opening a webpage unexpectedly. Furthermore I can rename a malware.exe to malware.zip and send it out by email and the implications are obvious. Maybe the .zip TLD will dissuade technical users from accessing the domain but I hardly see it as a new danger that could be described as “evil” or “malicious” on googles part. I could be wrong and would love to hear a clever person think of a feasible attack but imo this does not warrant any panic.

The harm I see is that many chat applications will do inline previews of websites, even when simply pasting the domain name.

Though, I think the solution here is for apps to stop doing that.

That's assuming apps and libraries even start doing that for .zip (which is unlikely), and is not in any way unique to .zip.

I can confirm (as the owner of a domain which is a common filename), your comment is overly charitable (and it is indeed not unique to .zip).

Young people might not. But I do believe most older people who used desktop OS. Know that zip is a file that contains well other files. Which is mostly sufficient level of knowledge.

And hopefully they are told that they might be risky.

Hey mom, here's the photos from our last family get-together: familyphotos.zip

(go ahead, click it)

Depending on platform, this is even more fun with command lines with commands like: `open familyphotos.zip`

But the point is, unless you are technically skilled, you probably can't tell whether you're about to go to a trusted file or download something random.

Depending on the context you would probably expect to be taken to a local file on the disk, you would never think this would download something new unless you were already in a context to do so.

Note that Google is also doing this for .mov. Both are file formats which can execute code (zip and mov both have exploits).

These TLDs should at least be removed from the PSL.

Edit: Here's a PoC screenshot: https://twitter.com/mholt6/status/1657133439546695680

Wow this is scary. This really drives the point home, I wasn't sure with OP's article but this convinced me.

Opening a zip webpage url is probably harmless compared to opening a file archive…

I think the problem is that zip webpage URL http://familyphotos.zip is a download to a file archive that people will open.

And <a href="http: //perfectlynormalwebsite.com/familyphotos.zip">familyphotos.zip</a> isn't?

Am I missing something? What does the TLD add that wasn't possible before? Auto-vivified links in the 0.001% of users who only read text/plain? C'mon.

i love this example, having the domain automatically download a zip file that's the same name as the domain feels powerful.. (even though it could be used for malicious purposes). this could be a cool way for a musical artist to release an album, telling people to go to a zip domain and then it just downloads the album as a zip file.

> i love this example, having the domain automatically download a zip file that's the same name as the domain feels powerful

Did you and the GP just invent a new kind of phishing? Lmao. Go grab bitcoin-wallet.zip and start emailing people.

    Hi.  Here's the cold wallet with the $5 million you requested.  The password is 'password'.

Then 5 minutes later send a panicked looking email.

    Do NOT open the previous email.  It was sent to you by accident.  You are NOT authorized to view it.  DELETE IT NOW!

Haha.

It's worse than that. I'll send a legitimate email with an attachment named wallet.zip, and in the body say "download wallet.zip". Now the email client changes wallet.zip to a link. The email is not phishing. The <wallet.zip> site can be maliciously registered, knowing people will inadvertently mention "wallet.zip" in emails and may click the link.

Holy Carp! I didn't think about someone just registering all kinds of "normal" looking domain names: archive.zip, photos.zip, budget.zip, music.zip, etc.

Just register those domains and sit back and wait for people to come knocking on your door. It's a phishing dream!

This is why it's a stupid idea to automatically turn anything that doesn't start with a protocol specifier into a link.

> you probably can't tell whether you're about to go to a trusted file or download something random

Don't worry. Google will offer enhanced protection to keep your account from being phished and hijacked. How convenient.

I wonder how much more effective in practice that is than registering familyphotos.info for example.

> Depending on platform, this is even more fun with command lines with commands like: `open familyphotos.zip`

The `open` command on macOS doesn’t open websites if no schema is specified. At best (worst?) it makes a suggestion:

  $ open google.com
  The file /private/tmp/google.com does not exist.
  Perhaps you meant 'http://google.com'?

But it doesn’t even try it with the zip TLD:

  $ open familyphotos.zip
  The file /private/tmp/familyphotos.zip does not exist.

This is already an issue with a number of common(-ish) extensions a non-tech person might realistically encounter: .ai (Illustrator), .ps (Photoshop), .md, (Markdown), .mobi (E-books)

There's also some that are less commonly encountered by non-tech people, but still fairly common in the tech world (depending on the person of course): .sh, .rs, .cab, .java, .py, .org, .pl, .pm, .target, .pub

That's just from a quick check from what I recognized from memory; I didn't feel like writing the code to also print out the MIME type and description and there may be more. Here's a full list of conflicts I generated from my /usr/share/mime/globs and the TLD list from ICANN, 74 conflicts in total: https://gist.github.com/arp242/ca24b58eaf37184b03e626c8e4093...

Is .zip more common? No doubt, so it does become worse, but this confusion already exists, and will no doubt grow in the future with further proliferation of tlds and file extensions.

Basically, we should probably do something about this regardless, although I'm not entirely sure what.

IMO the correct solution is giving users adequate information. Instead of downloading files automatically, the browser should prompt. "You're about to download a file from the internet...".

Of course we all know what will really happen is Google will continue to use Chrome to obfuscate the way the internet works and all of the big tech companies will sell "solutions" to the problems they're causing. Most people will end up completely dependent on Google's Advanced Protection Program, Microsoft's SmartScreen Filter, etc..

Wasn't that default behaviour a while ago? I believe they changed it because most people saw the dialog twice and then got annoyed and deactivated it

For most people (i.e. those who use email via web) you're downloading a file from the internet either way. There isn't really a good way, in my opinion, to convince people to validate where the file downloaded from. Things like prompts are just as likely to become as ignored as the URL in the downloads status or the "this file is from the internet" warning. It's unrealistic to expect a person to check 999 times so on the 1,000th time they can catch the 1 time they were being tricked (or whatever numbers you want to use, point is it's just too rare compared to how often it does what they want and bugs them).

Adequate information is never stuff written in transient prompts.

Yes, the solution is giving users adequate information. That means telling them whether it's a link or a file, whether the file will execute, or what program will open it.

It's not at all clear to me this is really a major issue. I'm not exactly the "average user" and I'm guessing you're not either; so I can't really judge from my experience and preferences. I did spend 4 years as a tech in a local computer shop over ten years ago, and my experience is that people will click and do the oddest things regardless, but I'm not sure if that's really all that representative either because the more savvy users didn't really come to us with software problems.

I think this is a "further research needed". For starters, how often will these situations actually occur in the first place? This may be less often than feared. How many users will be confused? This may be less than one might assume. Is just downloading a .zip file actually a security risk or "merely" confusing? That would make a big difference. What design will help with that? This may be counter-intuitive.

> But the point is, unless you are technically skilled, you probably can't tell whether you're about to go to a trusted file or download something random.

Under what circumstances would a link you click on a website or an email _ever_ be a trusted file?

You can be on a legitimate, trusted web site or be reading a legit, trusted email from a contact and still have a link slip in there. Other commenters like xsmasher have described a benign example, I'll rephrase:

> I've attached familyphotos.zip -- here you go!

The email client will presumably have a link below called familyphotos.zip, but the email client ALSO link-ified the text familyphotos.zip to download the content at https://familyphotos.zip, which is untrusted but you don't realize it doesn't go to the same familyphotos.zip file.

Screenshot: https://twitter.com/mholt6/status/1657133439546695680

hxxps:[//]]familyphotos.zip (broke the link on purpose) is already registered, and it downloads the zip file. 4 days later, and unsurprisingly, it's already happened. I'll open the zip in a VM and see what happens, it's 0.58 KB...

Update: Turns out it just contains what_happened.txt, a copy of which is below. Thanks anonymous person!

```

"Hey, this isn't family pictures!"

You're right -- and that link you clicked wasn't a file attached to the email or message you received.

Thanks to Google[0][1], now it's impossible to discern the difference between a link to an attachment called "familyphotos.zip" and a link to this file... unless you are able to inspect the destination of a link before clicking it. Most software and apps don't allow that, and most people don't know how to tell the difference anyway.

Have fun in the Wild Wild Web!

[0]: https://www.blog.google/products/registry/8-new-top-level-do... [1]: https://twitter.com/Google/status/1653866291692728320

```

Or the attacker could've just sent you ... a link to familyphotos.zip. I'm not sure why you're bringing client-side auto-vivification (which yes, is a bad idea) into the picture when the attacker could equally send a link. I'm also not sure why you assume that clients will begin to auto-vivify .zip links just as a result of it existing, nor why you assume that's any worse than them auto-vivifying https://example.com/familyphotos.zip.

Yes, downloading file(even zip) is significantly more dangerous than opening zip domain. I would be worried about the opposite problem. Say zip becomes commonly used domain. And maybe in some website link is not very distinguishable from file and someone might end up downloading the file instead of opening a link.

> Hey mom, here's the photos from our last family get-together: familyphotos.zip

And most applications (even some browsers) will even helpfully strip out the "ugly https" in front too, and make it clickable. :)

On the flipside, familyphotos.com could be a windows executable.

Please name a platform where `open` will treat a non-link as a link? I just tested the ones I have access to and none did.

Well, there's also .com which was confusing for me as a 12 year old thinking it had something to do with a .COM executable, and nobody could explain what it meant.

I hereby want the .exe, .arj, and .rar TLD :-)

.jpg would make sense, if it's limited to domains only ever hosting a single image file, like goatse.jpg

That would be an hilarious restriction. And I’m sure it would also push clever devs to stretch the definition of what a single image file is. I now kinda want that to happen.

Domain names that are limited in their functionality by the TLD are really interesting to me. I know all of .dev is on the HSTS list, for example. I'm currently working on a subdomain registration service that only permits A/AAAA records in the private IP address ranges [1], but still supports certificate issuance over ACME DNS-01 via TXT rrecords.

For jpeg, that would be a terms of service agreement? Or would the TLD manage all hosting?

[1] https://www.getlocalcert.net/

I think at least my consumer router would block such DNS on grounds of DNS rebind protection.

Can you share which model? I think the better approach is to resolve the domain locally, using unbound or similar. That's extra setup that some people won't do, so I want to support multiple options.

Official OpenWRT builds do this by default (though you can turn that off in DNS settings), but many newer consumer routers that use OS based on OpenWRT might not have the option.

You also wouldn't be able to access it on grounds of the private IP address is not in the same private as your LAN.

Why stop at .jpg?

Imagine every file extension was a domain. Imagine all the public files of the world existing on the internet at their very own URL. It’s like the internet was just one massive directory of files.

Now wouldn’t that be amazing?

I hate read comments here, because they are always AIDS. People arguing about whether non technical people know what a zip file is for example. But this comment was a shiny diamond in a pile of turd, thank you.

We already have the .sh TLD [1]. So I don't see an .exe as a stretch

[1]: https://en.wikipedia.org/wiki/.sh

That is a ccTLD. ICANN is not allowed to take it back even if they want to.

gTLDs can and should be held to a higher standard.

The standard gTLD registry operator contract does not allow ICANN to unilaterally yank delegated TLDs.

While that is a good point, I am seeing a term of 10 years in Article 4 of the contract. Not sure whether ICANN has discretion to renew or not renew at the end of the term (IANAL), but if they stated now that they have no intention to renew, it could crater demand for domains using the TLD and make the venture costly for Google, should they pursue legal action.

https://newgtlds.icann.org/sites/default/files/agreements/ag...

This is just flat out not how ICANN actually operates, though.

I was disappointed to find exe.zip was already registered.

I hope someone does what https://omg.lol did. I would pay for a subdomain.

Notably, not a lot of computer users could explain what the COM in executables meant, either, even in MS-DOS times :) (A command [external to the CP/M command interpreter], IIUC.)

Wow - arj. Now that's been a while!

.app has also been a thing for quite some time

`command.com` is owned by 3M now to advertise its Command line of removable adhesive strips.

URL prefixes were supposed to resolve this ambiguity (file:// vs. http[s]://), but I guess people got tired of saying "aych-tee-tee-pee-colon-slash-slash..." :-)

This reminds me of being a kid in the 90s and installing the DOS version of Command & Conquer onto a parent’s laptop and then being asked to delete it. COMMAND.COM yep that must be it…

Haha, thanks for reminding me of .arj - good times!

> I hereby want the .exe, .arj, and .rar TLD :-)

.exe to host web-assembly content?

For those having a hard time fathoming it, here's a rather simple attack case:

someone types "product.zip" into the address bar thinking the browser will automatically google it because of course it's not a valid domain name

but it turns out product.zip is a valid domain name, and it masquerades either as the product's webpage or as a delivery vector for other payloads.

---

I've mistyped search terms with periods in them and seen the browser try to route me to an invalid domain, so this isn't beyond the realm of reason.

---

edit: xsmasher below came up with a much more obvious attack case that deserves a read.

ok, giving you props on coming up with a valid scenario here but in what world is someone trying to search for product.zip? Maybe my tech-illiterate boomer mom who would ask google to find a file on her desktop called product.zip but is that a case we want to optimize our TLDs for?

> Maybe my tech-illiterate boomer mom who would ask google to find a file on her desktop called product.zip but is that a case we want to optimize our TLDs for?

What percentage of the population is tech-illiterate?

maybe a single-digit percentage of HN, but the vast majority of the world even today can't find the control panel on Windows. And anecdata from school systems suggests that consumption-focused devices are regressing the next generation of users such that millenials and early gen-z are probably the peak of tech-literacy.

I don't search for zips, but searching like this is pretty good for finding pdfs.

If you were looking for a zip and knew with good chance it's on the internet, why not?

PDF is special for a dozen reasons.

Googling for "product.zip" makes no sense. Unless it's an actual website.

zip is special for a dozen other reasons.

It makes sense to me if you're looking for a portable deployment without an installer.

Can you give an example of where you would want to ask the internet for opaque zip files to execute instead of using official downloads?

E.g. why would you prefer "zoom.zip" over "install zoom" query?

Official downloads are generally opaque files. These aren't different things.

> why would you prefer "zoom.zip" over "install zoom" query?

Why shouldn't I? This isn't a question about figuring out the optimal search terms. But anyway. The mainline installer probably... installs it. In this scenario, I want a portable deployment, maybe because I lack permissions on this machine.

I get it, but I don't agree that the defense is having a smaller number of tldns. I think the problem is with an omnibar in the first place, because it has to heuristically guess what you want. I preferred having a separate search bar from address bar.

For a technical professional, I fight with the behavior of my web browser's address bar far more often than I really think I should. Maybe the average person would be far better served if the browser only assumed you meant a URL if you explicitly included a scheme, and otherwise just did a search.

Computers should serve humans, not vice versa.

The omnibar is a mixed bag from a usability standpoint. It favors the bold and confuses the meek. For some non-expert users, they eagerly mash in whatever they want, without understanding that the browser treats "hot women near me" differently from "amazon.com". For other non-expert users, they see domain names and big scary URLs in the omnibar and are scared to type anything into it that isn't an "official" web site address.

I'm pretty certain that's why my slightly dyslexic grandfather accidentally ordered two dozen hot grills from amazon.

Or similarly, the domain doesn't exist and the user sees an error page. They may assume their search engine is down.

I assume the attack case case was sending a mail that says "I have attached product.zip to this email" but product.zip becomes a link to the web because the email client is too smart.

What you think is an attachment from a trusted source is actually a link to the web.

Wow, I love/hate this attack case far more.

But can't you already hyperlink product.zip to any URL?

there's a certain plausibility to the idea that some folks were trained to hover over a link and see where it goes as part of anti-phishing training, but that a fraction of them may hover over the link, see product.zip anyway, and just click it because they don't have the context to understand why that would be a terrible link.

They can't understand that product.zip is a terrible link, but they can understand that perfectlysafewebsite.com/product.zip is a terrible link???

This is my primary gripe with this whole thread, in most cases where abc.zip would become a link, you could just as well hyperlink it to anything, like in an email, a web page, or a markdown document

The difference is the malicious actor and the email sender don't have to be the same person.

A malicious user can craft an email "this is [abc.zip](http://very-bad-website)". Ok nothing new here.

But a non-malicious, who's emailing their mom: "I've attached abc.zip" (and put a abc.zip as attachment).

Here the problem here is a malicious other user has registered abc.zip to download a virus, and the mom's email client highlight abc.zip, and she clicks on it instead of the abc.zip attachment.

Yes, auto-vivification of links is bad.

You're misunderstanding GP.

Your boss sends you this plaintext email:

  Hi!
  Please upload the photos as photos.zip to the company GDrive!
  Thanks,
  Boss

Your email client "helpfully" recognizes that "photos.zip" can be a TLD, so turns it automatically into a hyperlink. You click it because you think it's a link your boss intended to share with you, but you actually land on a site that pwns your browser with an exploit.

That isn't GP's example. That's a separate one.

There are 3 - yours, GP's, and GGP's.

None of the three seem like serious attack vectors to me.

I'm still having trouble coming up with a legitimate attack vector so I think there must not be one. I am ready to change my mind when I see one though.

> None of the three seem like serious attack vectors to me.

Why not?

I recognize that if the TLD doesn't exist in the first place then we aren't even asking the question, but if your email client auto-creates a confusing link isn't it the email client's fault?

A phishing strategy this enables: confusing the https:// URI scheme with the file:// pseudo-URI scheme.

For example, we receive a phishing email which reads "This is the bank with your financial statement attached. It's a password protected zip file encrypted with your online banking credentials for security." We click to download and end up at https://financialstatement.zip, where a JS prompt asks us for the decryption password. We think we're interacting with the file system and get owned.

Crucially, i) some browsers don't display the URI scheme in the address bar, and ii) people are used to the idea of a password-protected zip file, and iii) people are used to opening files with their browser.

The website can further strengthen the illusion of interacting with the FS by using HTML+CSS that imitates the browser's builtin file browser. It knows what it might look like by examining User-Agent and Accept-Language headers.

Anyone can do that now.

    <a href="https://anydomainname.com/">financialstatement.zip</a>

If it's a plain text email, attachments show up in a separate area.

If it's an HTML email, you could potentially fake the attachment area with or without a .zip TLD, just by adding a carefully constructed image.

That's not going to get through even the most rudimentary anti-phishing filters, and at least some email clients still hint to you what's going to happen when merely hovering over that link.

They occupy such different parts of my conceptual headspace that it never occurred to me that filename extensions could be confused with TLDs, or vice-versa.

But clearly, this is a problem!

Why is Google actually doing this? Presumably they have some motivation other than making a small profit on registration fees. What’s their angle here?

I once heard a story about a client who thought HTML was short for "hotmail".

They were almost right, the original HoTMaiL was stylized like that because the word was picked as having "mail" and "HTML" in it.

That's actually really clever.

Samba was named the same way:

>The name "Samba" was derived by running the Unix command grep through the system dictionary looking for words that contained the letters S, M, and B, in that order (i.e. grep -i '^s.*m.*b' /usr/share/dict/words).

Just imagine if they had gone with "sombrero", how much more fun networking would be. Or smörgåsbord!

Why S M and B?

https://en.m.wikipedia.org/wiki/Server_Message_Block

I think they were also one of the first web based e-mails. This was when majority people used email clients.

I would argue the majority of email users back in the 90's were actually using Unix clients like Pine. Some of the first major users of email in those times were college students, all universities setup email accounts for each student, hundreds of thousands of daily email users, which could be checked at dedicated terminals in libraries, etc. Those were usually Pine. Just think of those many thousands of users all knowing the Pine keyboard shortcuts to send an email -- I think I can still remember them, actually. There was no mouse.

This client was I think a novice web designer and assumed all web files were "hotmail files" as a result of this misunderstanding.

Pleasant memory here of being a naive kid and trying to register a domain by creating a file with extension COM.

I don't have a strong opinion on whether this TLD is a bad idea, but I just wanted to point out: Conflating TLDs and file extensions isn't even in the same universe of the most "obvious" mistakes many computer users can make. You might as well be surprised that a random person off the street might not know the difference between Vulgar Latin and Classical Latin.

This page is 90% an inflammatory rant again Google. Why does it matter who owns .zip? These domains can be abused no matter what. This page is almost actively harmful to the cause by making it seem like the entire motivation is just being anti-Google.

edit: I found Google's application to ICANN for the .zip gTLD. Abuse is mentioned a bunch but it seems pretty boiler plate. I don't yet see anything acknowledging the risk of .zip domains in particular: https://gtldresult.icann.org/applicationstatus/applicationde... (pointing out something lacking in Google's .zip gTLD application seems a stronger footing for getting ICANN to take action)

Yeah wow this is actually pretty bad. Right now I can go buy:

- wellsfargo.zip

- bankinfo.zip

- irs.zip

- email.zip

- taxreturns.zip

Which — in one sense it's great that there's some new domain names. On the other hand these 5 alone would be a total phishing nightmare for some unsuspecting people.

win.zip

What's the specific attack vector you're thinking of for something like wellsfargo.zip?

Some of these are more tortured, but I can personally imagine a scenario in which a less-technical friend or family member is told to open a ZIP archive locally by some (trusted!) website and types that into the omnibar instead, bringing them to a random website.

There's probably better ones, literally the first one I tried, but I'm imaging someone messaging me that telling me to download a recovery package for my Wells Fargo account and that it should open in the browser. Then have UI mimicking some kind of OS prompt and asking for your social security as a password to confirm identity, or something.

Is that substantially different from simply messaging someone and saying "download this file:" and linking to a malicious site with a .net TLD? Is the thought that the .zip tld conveys some kind of trustworthiness that a different TLD would not?

Really trying to understand this, I hope I don't come across as snarky or naïve.

Appreciate the clarification, no snark detected. And yeah, that is what I'm thinking people would or could expect. Obviously they're quite different but if someone is multitasking, not thinking clearly, or just not great with computers it seems like something that could (and probably will) happen.

I imagine the "conversion rate" of a .net TLD will be much lower for spammers than that of a .zip

WELLSFARGO ALERT: Suspicious activity detected in your account! Please see the attachment for more information [https://wellsfargo.zip]

So this is bad because .zip sounds vaguely like something related to attachments?

I dunno that doesn't sound much worse than wellsfargo.info to me.

Because technologically illiterate users will think it's a filename

I'm having a hard time imagining users who would be fooled by https://wellsfargo.zip but not fooled by https://wellsfargo.inc

Isn't that true of every generic-looking TLD?

With Chrome hiding the 'https://' a bankinfo.zip URL ends up looking a lot like a file or a attachment. So it could be used to trick people into assuming the file comes from a trusted domain instead of a third party one, as the user just see a filename without a domain part, not realizing what looks like a filename is the domain and they are no longer on their previous trusted site.

This is especially problematic as the 'https://' hiding also happens in the URL preview when you hover over a link (Edit: seems to happen only for longer URLs).

I'm guessing your hitrate is just as high if the URL is http://youareabouttogethacked.geocitiesorsomething.com/?shad....

As many other people have said, does anyone confuse C:\command.com and http://command.com? I doubt it.

How is this any different than 'There's an urgent update to your tax information. Download your documents from here: <a href="https://welsfargo.tax">https://wellsfargo.zip</a>'

Looks like it will take you to a zip file, but won't. hovering over the link looks legit enough. I just don't think it buys you that much. /shrug

> hovering over the link looks legit enough

You get a pretty different result if it's just "http" and not "https" though: The zip domain looks like just the file name instead of a URL.

Maybe have them click a .zip link that takes them to a web page which asks for an account password to open the "archive"?

I could see that getting under a few people's radars, but it's not much more menacing than existing fishing tricks with lookalike urls.

The problem is that we assume that it will forever be impossible for a browser to mimic the look and feel of opening a zip file attachment. I'm unsure if it's possible today but most definitely I don't think it's wise to assume it will never be possible in the future.

We are slowly chipping away at defense in depth all in the name of convenience.

winrar.zip

Unfortunately, .cm and .co are also rife for phishing scams.

(Apologies to the good folk of Cameroon.)

When I played around earlier I found e.g. document.zip, atachment.zip (proper spelling wasn't there), image.zip, and a few others like that, without looking very hard. Many were being sold on the registration site I looked at as "premium" presumably for common words or short domains.

Such names appear to be much more plausible attack vectors because they will trap people trying to open files. If I found a cheap common one I was going to buy it just to see what kind of traffic it got, but everything interesting was a few hundred dollars and up.

I was looking around for companies such as AWS and Contabo who sell domains without a markup fee. However i havent found any that support the .zip TLD.

that makes sense and is pretty good because otherwise people could very easily have bought out every decent domain.

For example, i have nabbed modpack.zip, ultimately however i dont see many scenarios where someone would make money from someone's technical inexperience being manipulated with this simple domain. But i feel slightly driven to keep it from the wrong hands. Plus that domain is really easy to remember which is great.

I’m not so sure …

If you expect a host name and you end up clicking a file instead, that seems dangerous.

But in this case, you expect to open a file and you visit a website instead? That sounds simply annoying…

Maybe this is for browsers to deal with - if there is a collision between TLD and (file extension on this system) throw up a warning?

You'd be throwing a warning on nearly every domain name, including this very site we're on right now. What would be the point? Domain names are different from file system paths, full stop.

I was interested in that, and apparently that has actually been used as an attack vector in the past! https://en.wikipedia.org/wiki/COM_file#Malicious_usage_of_th... TIL.

Do you think computer users always think that's the case? I tend to come down on the side of "no, probably not" but open to other arguments.

Exactly — and I think the danger is in website mimicking a file being opened. Which, browsers have already trained us to expect in many cases. Maybe some browser teams will implement a warning like this, that would make sense to me?

it could be worse, if the 'website' server automatically returned / downloaded something called YourTaxReturns.zip

Just to make sure I'm following, the scenario you're worrying about is someone sends an email containing a url to "YourTaxReturns.zip". Upon visiting the site, it automatically downloads a zip file named "YourTaxReturns.zip". And then what? How is this any worse than the user downloading the zip directly? They clearly wanted to download it, given they clicked on it after all.

How is this different from any other TLD?

Most TLDs are not the names of commonly used file transfer protocols, right? I think that's the primary difference that is concerning to the author of the post we are commenting on, and I it find convincing.

So surely there's some evidence from past TLDs like .app

When was the last time you used any file with .app?

.zip on the other hand is used more frequently across multiple operating systems.

Anyone that uses/used NeXTSTEP, OPENSTEP, Mac OS X, or GNUSTEP is very familiar with program names that end with .app

.app is the equivalent to .exe on MacOS, so for most MacOS users the answer is probably daily.

Not a Mac guy so this was a blank spot in my brain. thank you.

Zip isn't a file transfer protocol, it's a file compression format and popular file extension. Still, I don't understand a scenario in which this is going to be abused for exploitation.

Alice sends Bob an email containing the text resource.zip somewhere. Alice and Bob both trust each other. Bob's mail client converted the text into a link, Bob clicks the link and ends up on Mallory's website where the exploit is.

Also available: photoshop.zip and office.zip

For the Wells Fargo example at least, presumably Wells is registered with the TMCH (https://www.trademark-clearinghouse.com/) and this will raise a flag at the registrar level if someone tries to purchase it. At the very least the would-be registrant should see a warning about it.

https://newgtlds.icann.org/en/about/trademark-clearinghouse/...

This is google we're talking about... they'll run ads for people pretending to be the largest YouTuber and not even think twice.

I bought dkong.zip and galaga.zip, not sure what I should do with them though.

It's a dumb TLD for sure, but can someone explain what the security problem is? Is there a segment of users who'd be confused enough not to see the difference between a URL and a file name, but smart enough to be able to make that distinction if only the .zip TLD didn't exist?

IMHO the real problem was having domains go backwards in most-significant to least-significant.

    subdomain.domain.tld/root/to/sub/path

That goes inwards-out. If we had started with

    tld.domain.subdomain/root/to/sub/path

it all goes from top-level to bottom.

Therefore I propose we fix nothing until we deal with this.

Even with that fixed, people will argue why do other countries' have to have their country prefix? Shouldn't a US website be e.g. us.com.walmart to be fair? And what do you do with multi-nationals, de.com.mercedesbenz and us.com.mercedesbenz? com.mercedesbenz/de (and /us accordingly?). Or de.com.mercedesbenz/us (as well as /de) because it's a German company?

Face it, it's legacy, and just like QWERTY, it's never going to be fixed.

I see TV ads where the narrator just says "Search for $BRAND_NAME" expecting you to google it, AOL keywords all over again.

> The people who care are asleep at the wheel at best, some aren't with us anymore, and ICANN has failed all of us by allowing this to happen.

I think ICANN has increasingly become a failure, in several ways.

- Constant questionable TLD approvals (did the world really need more than the basic five? It's a scammer's dream!)

- IANA mismanaging IPv4 assignment, giving 16.7 million addresses to people who didn't need them at the beginning (like, Apple, who is comfortably sitting on every address starting with 17, or Ford, with every address starting with 19). Causing, of course, IPv4 address auctions...

- The whole .org domain sale fiasco to a private equity firm

- The contracts with VeriSign for .com management and price increases there for no particular reason

- Approving the .sucks domain, in what was widely criticized for having no public value other than to humiliate and extort corporations and individuals

- Giving the .amazon TLD to the company, instead of the Amazon Cooperation Treaty Organization (ACTO) which is comprised of countries involved in the actual Amazon rainforest after a years-long battle

And so forth...

> did the world really need more than the basic five?

Only because of domain squatters...

And, you know, the existence of countries, that speak different languages...

Fair point, in my attempt to throw shade at domain squatters I seemed to forget that countries and languages exist. (I really hate domain squatters...)

> - IANA mismanaging IPv4 assignment, giving 16.7 million addresses to people who didn't need them at the beginning

The US government could step in and demand that the big HODL'ers of not actively used IP space release it back to IANA. It's even worse than Nestle and others hogging onto extremely old water rights because Nestle at least makes something that people can drink...

Our governments are sitting and idling around while valuable resources - IP addresses, water, food, whatever - get ever more and more scarce as large chunks are held hostage by private companies.

By this (ridiculous) standard, DOS com executables make ".com" the worst offender. Or how about shell scripts and ".sh"?

Apple application bundles and .app, too

The worst would be a .js TLD; everyone looking for web frameworks like `angular.js` would end up on a website (that probably is not affiliated with that tool) instead of a search result page. Would make it incredibly easy to trick people into installing malicious dependencies.

That doesn’t seem to be that much a problem with the .net TLD and various .net products. (asp.net, quartz.net, yamldotnet, docker.dotnet, ssh.net, handlebars.net, etc. - from a quick search of these, asp.net is the only one where the asp.net website actually belongs to the product in question.)

What about an .htm or .html TLD?

Thankfully, a .js TLD is out of the question since you cannot create a 2-letter gTLD [0]. But who knows, maybe some private equity firm will try and bribe a nation to change names so they can get a new country code.

[0] https://newgtlds.icann.org/en/applicants/global-support/faqs...

This is more or less how I felt when typing `subprocess.run` into the omnibar and discovering that `.run` is now a valid gTLD.

At some point though we have to accept that the Internet's public namespaces can't be defined by whatever random-ass file extensions different operating systems use. I can understand pushing back on ".zip" as a special case (I don't think it's going to be that big of a deal, but we'll see), but the general principle shouldn't be that TLDs have to "avoid confusion" with file formats; it's the browser's job to avoid that confusion, right?

Oh, I don't necessarily disagree -- it was just surprising to think that I was Googling a Python API (for the 500th time!) and all of a sudden get a DNS lookup failure instead.

(It's not Google's or IANA's or whoever's responsibility to fix a namespacing problem here, but it's also maybe not ideal that less-technical users are funneled into a single "omnibar" interface for both searching and domain resolution.)

it's funny how the idea of googling docs already seems quaint to me coz of chatgpt but i still do it really often

I disagree after seeing what happened with .dev. I myself was concerned about it but it turned out to be fine. This will be the same.

Because .dev is such a common filename extension?

I'm not seeing the attack vector. The URL of this page certainly doesn't show it.

Probably because it's a reasonable TLD to use internally for testing

Why are you getting downvoted, that's literally what happened when it launched. A bunch of people were like shit I use .dev internally.

Nobody used .test, .example, or .home.arpa

Yup. It happened to me. After the .dev TLD was created, I switched all my internal dev hostnames over to .test because it's one of the reserved TLDs [1].

I also switched off of .local after learning that it's used for mDNS [2].

1: https://www.rfc-editor.org/rfc/rfc2606.html#page-2

2: https://en.wikipedia.org/wiki/.local

Except that it's not, and never was, because it was never expressly reserved for this purpose. And it was particularly unreasonable to use for testing since 2012 when multiple applications were submitted to ICANN to create it as a gTLD.

What was your concern with .dev?

A) Prior use - this is why I think zip won't be a big deal, people will adapt.

B) Being a good domain name for development - mysite.localhost turned out to be better.

mysite.localhost works fine for very simple development, but can easily fall down with containers, VMs, or multi-machine development. Technically, you can point it to a non-loopback IP, but I wouldn't do that. .localdomain is used some places as well, but I don't know how reliable it is.

.test is a bit more flexible, and what I use now. I'd prefer if .dev was reserved as well, but that ship has sailed.

It sure can because browsers resolve .localhost https://datatracker.ietf.org/doc/html/draft-west-let-localho...

Indeed the ship has sailed and you can use anything now. I'm in favor of .test becoming a gTLD so you might want to get off that.

.test will not become a gTLD. See RFC 2606.

As gTLDs increase in popularity they could amend that RFC.

Also it's not particularly clear and unchanging already. "TLDs for Testing, & Documentation Examples" includes .localhost. However, .localhost can be used for more than just testing and documentation. It's treated as a secure context in browsers and subdomains have different storage areas on browsers. (Shockingly, localhost:8000 and localhost:8080 aren't kept separate by browsers)

Those 4 reserved labels in that RFC are not going to be released, period.

I wasn't talking about the other ones, just .test.

Maybe as a Blockchain tld :) then it isn't DNS.

Currently new gTLD applications are paused and it's hard to remember how hot it was back when they were open or see how hot it's going to be when they're reopened.

Unless and until they are.

Don't underestimate the greed of the people making these decisions.

I work in this industry and know the people making these decisions and I'm not aware of anyone in favor of releasing the RFC 2606 reservations.

Would be done by someone asking for forgiveness instead of permission. :)

That's not remotely how ICANN works though. Everything always takes many years and has a million different discussions, processes, veto points, etc.

It would start off outside of ICANN, like Unstoppable Domains.

Edit: wow, ENS has .test domains: https://docs.ens.domains/contract-api-reference/testregistra...

Those are fake domain names. They don't resolve in the root DNS nameservers. This is one of the many reasons that "alternate roots" are terrible and will never be widely adopted.

I use my .dev domain as my email address. I've encountered a couple of systems that refuse to accept it, I'm assuming because it's what they use for internal testing (though it's also possible that their validation algorithms just assume a narrow range of TLDs).

That's on them. RFCs are free to view and download.

Oh, absolutely. But that doesn't mean it doesn't inconvenience me as well.

What's the legitimate reason we need a .zip TLD?

Namecheap says:

> Why choose a .ZIP domain?

> Build your brand fast with a .zip. The .zip top-level domain (TLD) is the perfect fit for organizations specializing in file sharing, storage, and download technology, or for anyone offering speedy and efficient online service.

> Is a .ZIP domain extension right for me?

> Use your .zip TLD to showcase your expertise in the field of file compression software or impress your clients with turbo-charged customer service.

Really?

https://www.namecheap.com/domains/registration/gtld/zip/

It's likely some LLM marketing garbage.

It's actually excellent for all the shady file sharing services. If the domain does become popular for this purpose, that makes building DNS blacklists very easy!

This is probably just another DNS money grab.

Erm, clearly this person is angry lol. I sense that they must be an older person because they think about files being shown as links/underlined texts and therefore people will mistake a domain name to a file. I think today's systems and software are more user-friendly and most of the time links and file names are displayed differently enough for people to know which one is which.

Also as others have commented, those not so tech savvy would probably not know what .zip or .mov files are anyway, and therefore their first instinct will be that they're links to sites rather than the other way around.

Kind of an inflammatory page, but the .zip TLD doesn't seem like a great idea.

I feel like the core message on this page is really weakened by including a broader critique of Google. It shouldn't matter who owns the TLD.

Even if Google wasn’t the .zip owner, or if you don’t believe they’re an insidiously corrupting force, you can still agree that .zip domains are overly confusing and ripe for abuse and attacks. This argument stands on its own, and focusing on the Google aspect just muddles the issue. (Though I agree with some of the sentiment)

Just today, I had a no-https warning from a .so site when I was trying to search for information about some linux library file.

libfooblah.so or something like that, i dare not post the actual name because of course it's gotta be something sketchy as a website.

Huh, I clicked on news.ycombinator.com the other day thinking I'd launch an MS-DOS application and ended up here. Have been stuck posting comments ever since.

What's next? We'll have a .exe TLD? Even if the OS will prioritize local files, there's no guarantee all the 3rd party apps old and new will use the same rule.

You know it's coming.

.exe is so s.exy

I get the concern at a high level, but it seems weird to not have any specific examples or a PoC.

Couldn't you already send someone an email or direct them to a webpage where the text "financialstatement.zip" is linked... anywhere?

Fun read about the usage of CORP as the default domain for Windows Active Directory domains and the chaos that might have come had Microsoft not ponied up for the domain: https://krebsonsecurity.com/2020/02/dangerous-domain-corp-co...

Wouldn't it be easy for cloudflare and other ~~WHOIS~~ DNS providers to just not propagate the .zip domain?

Isn't it time to leverage what's left of the decentralisation of the web rather than beg google?

I think you meant DNS, not WHOIS.

That's probably worse than the alternative: I don't think we want a world where the person in accounting can resolve hxxps://financialstatement.zip and the person triaging it in IT can't.

I did mean DNS, thanks, been a long week.

Why rely on third parties? Setting up your own recursive DoH server with the appropriate settings (PiHole etc) is super easy.

It's even free if you use the free forever VPS server Oracle will give you. The uplink being limited to 50mbps isn't an issue for DNS (and similar lightweight protocols).

I'd recommend putting the DNS behind a secret subdirectory though, because my server accidentally got added to a DNS server list and a small country started querying mine at about 30k per second

Publicly accessible DNS resolvers are an awful idea. Don't do it.

Why? As long as you don't allow UDP protocols so you don't become part of a DDoS botnet it's just a lookup service.

I agree. This is pretty terrible because it even circumvents what has so far been assumed to be "safe" methods of reading e-mail -- by stripping them down to plain text. Even avoiding <a href="actual">fake</a> attacks won't help by showing "actual" because that will be the attack vector itself. Ugh!!

Some of the ccTLD's have gone way up in price (especially the .ai domain, which was around $20 but I cancelled when I saw it would cost nearly $150 to renew). To some extent this has also affected the popular .io domains.

I've instead gone with .dev for my personal domain. It was a bit annoying updating my email everywhere, but I'm a lot happier with this.

Personally i see country-TLDs to be a great choice for personal domains/blogs.

Unless you're migrating soon, you are always going to be citizen of that country.

> Throughout the 2010s, Google has easily been one of the most insidiously corrupting forces on the internet, rivaled by none. Its takeover of the modern web through utter domination of the search engine market, chokehold over web standards, and near complete monopolization of web browsers has rendered much of the world beholden to it.

Preach!

I think I'd find this page much more convincing without the moralism and general anti-Google commentary. I'd be much more persuaded by a direct, simple explanation of the security hole here.

That might because I don't think Google is evil (I'm biased because I used to work there), but I think even if I did, a dispassionate description of the problem would be as or more persuasive.

Honestly it would be good to just patch browsers to keep interpreting .zip and other common file extensions as a search query (.com, .org, etc can stay)

You can argue that removing the .zip TLD is a better solution, but this one is immediately actionable (you control the browser)

This is the deliberate reason why this TLD exists.

ICANN sold out the internet.

> ICANN sold out the internet.

Breaking news from 2011.

Once we abandoned tlds as actual ways of organizing websites it was always going to be vanity.

There is an excellent explanation on proggit [1] that describes an attack vector for .zip TLDs. More specifically, it explains how a trusted source might inadvertently link to a malicious file.

[1] https://reddit.com/r/programming/comments/13fsvl5/the_zip_tl...

On windows you can have a .com file as an attachment too. Should we ban .com sites? Is the issue that you can fool people to open a website rather than a file? I'm not sure I follow how a TLD makes that easier. Even if you didn't have a top level TLD a non-experienced user isn't going to be able to tell because they don't look at file extensions anyway, just change the FAV icon and you're set.

If you've been using .foo in your tests or whatever, that's on you. You shouldn't have a license to work on software that touches a network if you haven't seen https://www.rfc-editor.org/rfc/rfc2606

They'd obviously hate me too! I've got directories called <name>.html which have an index.html in them which I use to have an equivalent to <name.pdf with all the image files and fonts included in them. But yes it does seem like troublemking to have a .zip directory that doesn't act like a zip file

The original mistake was tieing filename "extensions" to content.

A ".zip" is just four characters at the end of the filename. It conventionally means it's a ZIP compressed file, but it could contain anything.

Same with any other filename, .pdf, .doc, .wav, .jpg, etc. They are conventions but that's all they are.

I mean, that was a good rant, except I still don't understand why this is a problem

This reminds me of when eBay had '.dll' in their URL and our overzealous webfilter thought we were downloading a '.dll' versus trying to win the bid on that highly coveted Pokemon card.

When this TLD was announced, I was honestly shocked that someone suggested it and that it was approved - seems like such a daft idea to me to even entertain the idea of adding more confusion in this space.

Why is Google involved in something like this in the first place?

Because they haven't bought ARIN and ICANN yet? Sorry, that's a bit too cynical perhaps but it's the same reason Google spends perhaps hundreds of millions of dollars on Chromium that they give away: vertical integration. They want to own every component required for your online experience, from hardware, os, browser, and hidden infrastructure like DNS. It's a slow-moving battle with Microsoft and Apple, who have similar goals. (Not really sure what FB is doing - trying to do an end-run with Meta and Oculus I suppose. Which takes guts, but will probably fail.)

It's eye-opening to read about, for example, the stated geopolitical goals of the United States, who like every nation-state seeks total invulnerability, which in turn requires total dominance. Individuals aren't used to thinking in these terms - its extremely unsentimental and matter-of-fact game theory stuff that will curdle milk.

TBH I'm guessing. I don't really see how expansion of tlds helps Google with this goal - maybe they just want more namespace to control as a registar? That doesn't make sense. Hopefully I've nerd-sniped someone who knows more.

It's cheap to do. I think to apply for a TLD it's only like ~$185k and you get your $ back if your application is denied.

Probably something fresh and some PR for their Google Domains department or etc.

Standard PC executables end in .com, so we should probably get rid of that one too.

Maybe Poland should change its name so Perl programmers don't get confused.

Who cares anyway? Old people or young people, doesn't matter. Everyone WANTS to be scammed. Because they're scared too much, or they're greedy or they respect authorities too much.

Disable zip TLD and you left with like 100million ways how to scam people. What did you actually achieve?

I mean if you're old then there was a time when .com was the most common file extension at all.

It’s a weird tld given that zip files are a key malware and hacking vector.

Oh this is an awesome TLD. If I want to share a file with friends I should just share it as https://somefile.myname.zip

.com is also a valid file extension. Just learn to parse a URI.

Can't wait for the .exe extention or the null extension .

Ah well, .*\.zip$ added to pi-holes regex blacklist

Just like .info.

Probably the final aim from which this nerdy offer arise is to pollute the URL bar

Have we ever seen tld’s revoked or cease having registration possibility?

Nope. Not even .su which continues to exist more than three decades after the country it represents ceases to exist.

The time to comment on new gTLDs was a decade ago.

Many ccTLDs of no-longer-existing countries have been deleted: .cs, .cd, .yu, .tp.

There is only one correct solution to this. It's to completely remove any and all of these egregious filename extension TLDs with no questions asked, and punish the people who pushed for this.

I’m really curious to know what this person has in mind.

That is definitely not the solely correct solution and I’m really curious to know what kind of punishment you think is appropriate here.

The first paragraph was a quote from the website which I mistakenly didn’t indicate as a quote. My question was the same as the one you’re asking.

Same argument could be made for .com

Speaking of which, who owns command.com ?

3M.

.com isn't nearly as common as .zip today though

In fact it kind of preceded "widely adopted Internet" of 1997ish and died with MS-DOS

I don’t see what additional attacks this enables.

about as wise as having ".EXE" as a TLD

cosign. come on Google, this is obviously confusing and frustrating for everybody. the money cannot mean that much to you.

If you're looking for things to be OUTRAGED about then you'll find them.

Wait, isn't that the point of the ad-supported internet?

No ads on HN, and yet there's still rage-bait here on a daily basis.

HN is an ad for ycombinator. It's just that it's better than 99.9% of ads, but there's still the trap of needing eyeballs, which directed rage provides.

We've been trying to de-direct rage for 16+ years! it's fortunately part of whatever HN's business model is

Eh, not really. It's all a mistake how we *interpret* domain names.

From https://www.rfc-editor.org/rfc/rfc1034 3.6.1 , we see

----------------------

     For example, we might show the RRs carried in a message as:

     ISI.EDU.        MX      10 VENERA.ISI.EDU.
                     MX      10 VAXA.ISI.EDU.
     VENERA.ISI.EDU. A       128.9.0.32
                     A       10.1.0.52
     VAXA.ISI.EDU.   A       10.2.0.27
                     A       128.9.0.33

----------------------

Notice it's not ISI.EDU , but it's ISI.EDU. for an absolute fully-qualified domain name.

You can also notice weirdnesses here when you go to https://news.ycombinator.com. (copy and paste with period), like you're not logged in due to cookies not sharing.

But requiring absolute FQDN's would solve this https://financialstatement.zip -> https://financialstatement.zip. and remove the ambiguity.

That's pedantic. We're not going to teach the world to include the root '.'

Its absolutely not pedantic, when you consider that TLDs of any language can be a thing. Its really nice to see a foreign language TLD, and know how to separate them appropriately.

The "." at the end also serves another level of defense. When you provide a URL without a . at the end, I can append .someotherdomain.com. and redirect traffic. And I've seen that in the wild before.

And the difference between "pedantic" and "technically correct" is how you get hacked. But feel free to throw insults. I know one of us is right, and it aint you.

And the difference between "technically correct" and "how things actually work in practice" is what keeps the world turning in the face of slight mismatches. See for example the URI/URL naming war. "URL" is a valid term for URI-like identifiers, even if they aren't locators.

No one (within a rounding error of 0%) will change how they enter, use, or program systems to work with, URLs to use the FQDN. The incompatibility nightmare it would cause would be insurmountable.

I mean, you might be technically correct. I say might because I have no expertise on the matter so I can’t really comment on it. But literally the entire world is using domain names without the final .

So I don’t think pointing out the technicality of how a domain name is supposed to be represented really helps in this context.

Apologies if the term 'pedantic' felt like an insult. It was not intended as one.

But you're not even technically correct when you claim "Eh, not really. It's all a mistake how we interpret domain names."...

This document clearly says that the dotless form is perfectly acceptable and even expected.

Take for example this snippet:

    Relative names are either taken relative to a well known origin, or to a
    list of domains used as a search list.  Relative names appear mostly at
    the user interface, where their interpretation varies from
    implementation to implementation, and in master files, where they are
    relative to a single origin domain name.  The most common interpretation
    uses the root "." as either the single origin or as one of the members
    of the search list, so a multi-label relative name is often one where
    the trailing dot has been omitted to save typing.

Which says that relative names are meant to be used in user interface (ie by humans) and the most common interpretation of a dotless name is to be in the global/root namespace.

So yes, the dotless notation comes down to own we interpret domain names. However that interpretation is not a mistake, it is expected.

Can you clarify what system would allow "DOT evil DOT com" to be appended to "good DOT com" but not "evil DOT com" to be appended to "good DOT com DOT"? I'm not familiar with the latter.

Not the original poster, but I think they talked about DNS search suffix lists. Often seen in company networks where host foo.internal.example.org might be reachable via foo because internal.example.org is the search suffix. That will not happen with `foo.`

Granny ain't gonna know that

Putting a period at the end seems like a very ineffective way to disambiguate a name. How do you do this at the end of a sentence?

Reply on news.ycombinator.com