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.
> 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.
> 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.
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.
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.
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.
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?
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:
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.
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
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."
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.
> 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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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
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.
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..
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.
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.
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!
> 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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
`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..." :-)
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.
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…
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.)
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
> 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.
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.
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?
>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).
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.
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.
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.
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?
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.
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.
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.
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).
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
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.
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.
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.
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.
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?
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
> - 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.
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...)
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.)
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.
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.)
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).
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].
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.
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.
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)
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.
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.
> 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.
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!
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.
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)
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.
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.
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
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.
> 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.
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)
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.
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
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.
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.
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?
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.
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.
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.
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.
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.`