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.
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.
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
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).
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.
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.
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.
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?
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.)
`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…
> 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
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.
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.
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).
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.
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.
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 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.
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.
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.
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.
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?
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)
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.)
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 genuinely believe this one change in the name of 'aesthetics' (or whatever justification was created for this) has caused real, material hurt for people.
> 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.
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.
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.
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.
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?
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.
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.`
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.
330 comments
[ 1.5 ms ] story [ 337 ms ] threadBut 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).
- 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.
Really trying to understand this, I hope I don't come across as snarky or naïve.
I imagine the "conversion rate" of a .net TLD will be much lower for spammers than that of a .zip
I dunno that doesn't sound much worse than wellsfargo.info to me.
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).
As many other people have said, does anyone confuse C:\command.com and http://command.com? I doubt it.
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
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.
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.
We are slowly chipping away at defense in depth all in the name of convenience.
(Apologies to the good folk of Cameroon.)
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.
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.
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?
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.
.zip on the other hand is used more frequently across multiple operating systems.
https://newgtlds.icann.org/en/about/trademark-clearinghouse/...
Isn't it time to leverage what's left of the decentralisation of the web rather than beg google?
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.
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
ICANN sold out the internet.
Breaking news from 2011.
I hereby want the .exe, .arj, and .rar TLD :-)
For jpeg, that would be a terms of service agreement? Or would the TLD manage all hosting?
[1] https://www.getlocalcert.net/
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?
[1]: https://en.wikipedia.org/wiki/.sh
gTLDs can and should be held to a higher standard.
https://newgtlds.icann.org/sites/default/files/agreements/ag...
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..." :-)
.exe to host web-assembly content?
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...
Only because of domain squatters...
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.
Nobody used .test, .example, or .home.arpa
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
B) Being a good domain name for development - mysite.localhost turned out to be better.
.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.
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.
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)
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.
Don't underestimate the greed of the people making these decisions.
Edit: wow, ENS has .test domains: https://docs.ens.domains/contract-api-reference/testregistra...
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.
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.
If you were looking for a zip and knew with good chance it's on the internet, why not?
Googling for "product.zip" makes no sense. Unless it's an actual website.
It makes sense to me if you're looking for a portable deployment without an installer.
E.g. why would you prefer "zoom.zip" over "install zoom" query?
> 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.
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.
What you think is an attachment from a trusted source is actually a link to the web.
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.
Your boss sends you this plaintext email:
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.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.
Why not?
You can argue that removing the .zip TLD is a better solution, but this one is immediately actionable (you control the browser)
(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.)
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.
While an OS may hide extensions, not everything does. Notably, gmail shows the file extension for attachments.
See: people calling any animated image a gif, even though many are apng or webp
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.
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.
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."
> 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.
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?
Or why even require a fixed extension given that it's a recursive system anyway.
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.
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.)
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.
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.
And DOS got them from CP/M before it.
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.
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.
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.
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.
Or worse, on some disk “in the cloud" rented by the app maker, subject to subscription fees and the stability of the company.
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.
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.
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
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
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
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.
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.
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.
> 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.
Though, I think the solution here is for apps to stop doing that.
And hopefully they are told that they might be risky.
Couldn't you already send someone an email or direct them to a webpage where the text "financialstatement.zip" is linked... anywhere?
[0] https://newgtlds.icann.org/en/applicants/global-support/faqs...
From https://www.rfc-editor.org/rfc/rfc1034 3.6.1 , we see
----------------------
----------------------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.
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.
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.
So I don’t think pointing out the technicality of how a domain name is supposed to be represented really helps in this context.
This document clearly says that the dotless form is perfectly acceptable and even expected.
Take for example this snippet:
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.
.exe is so s.exy