But it does show you the url in the tweet. But if you use opengraph the image for your link is more prominent so I bet not as many people look at the domain for it.
But that's intentional malicious linking. Auto-hyperlinking "VacationPhotos.zip" or even just "photos.zip" can mean clicking into a malvertising page, or in some worse-designed cases, your email program prefetching a malvertising page.
The concern here is that someone could say write something like "look in assets.zip for our marketing assets." in an email, repository, etc and a parser automatically turns that into a link. The reader, trusting the source and seeing the link reasonably assumes it's a link to said assets, and clicks it. All a malicious actor needs to do is register assets.zip and wait for people to make this (I'd argue soon to be common) mistake.
The malicious actor doesn't need to be in the loop at all. Similar to typosquatting.
I have my (sadly inactive) blog on app.rodeo only because I bought this domain a decade ago, and sunk cost fallacy dictates I have to use it for something after so many years of paying fees.
If a rich Texan rodeo entrepreneur showed up in my email inbox wanting to buy this unique domain, I wouldn’t say no. But I’d ask for a pony.
“Normal humans” may not type these for personal use, but I do for work all the time and it is a frequent source of confusion, even if not an attack. It’s not just .zip and .mov, but .txt, .js, more.
I shipped an international package with USPS today and there was an option to add an email. I used my email address with a .family TLD.
They couldn't add the email, they said the system was telling them it was an invalid email. Inaccurate email validation in the wild... I suspect the system has a list of known TLDs and that didn't exist when their system was created. Or even worse, they have some hardcoded list of known email providers...
You'd be surprised. Especially if you are building B2B and users want to use their company emails. Blocking any non-standard TLDs will create a customer service pain for any reasonably large business.
I’ve been exclusively using email address(es) at my .info domain for over twelve years now. To my recollection, I’ve had issues due to the domain name exactly once, about two years ago; in that case it was a website with a bad email validation regex, and, being a web developer, I was able to bypass it, and the backend accepted it.
Now I do recall noticing things that would baulk at five-character TLDs once or twice more. (Actually-deployed stuff, this is—if I counted example email address validation regular expressions I’ve seen from Stack Overflow and similar and “see how good/bad/otherwise this LLM is”, it’d be quite a few more.)
Judging by the amount of problems I had with an email address on a subdomain (@students.univerity.tld), it seem about 5% of all registration forms use a regex similar to .*@[a-z0-9]\.[a-z]{2,4}
I wonder what the success-rate with unicode domains looks like
When I was in charge to implement the email validation at my previous employer, the only thing I did was checking for "." and "@" in the correct order.
The sales-focused part of the company complained that they would still receive invalid email-addresses for their newsletter.
Turns out what they really wanted was an email address where they could send stuff to. So we implemented a MX-check for the host part of the email address. However, that check was mostly a warning, in the sense of "Hey, are you sure the email you entered is correct?".
The discover bank doesn't even accept an email at indian tld like hello@example.in The reason given by support was that .in email will work only in India & discover operates only in USA. I tried to reason that people move from India to USA all the time & keep the same email accounts.
Also, if some system accepts such a domain it sill likely it gives it a red flag.
I'm using .email domain for a long time, in many cases it's not accepted on registration. When it's accepted and it's an e-commerce website then half the time I get an automated email that the sale was either declined, or they require additional proofs. Or, in some cases, the order just gets ignored, and when you physically call them they can't even find the email in their system, so my guess some anti-spam system just blocks it.
I own a .co domain. Frequently when entering my email address the validator tries to correct me - “Did you mean .com?”. No, I meant the thing I entered.
The real problem is when I give my email address to someone else and then they get corrected by their email client. For some reason, people place implicit trust in these validators. This results in emails getting sent to the wrong TLD.
.co was released in 1991, and it’s easier than ever to launch a TLD. Email validators need to stop validating TLDs. It doesn’t help anyone.
I just think it's annoying that if I see a reference to "foo.zip" or "foo.mov" it's not immediately clear anymore whether it's a file or a domain.
The fact that file extensions and TLD's were roughly the same length in the same format wasn't a big issue, when it's generally understood that ".com" and ".edu" are domains, while ".jpg" and ".mp4" are files. (And as the author states ".com" files are rarely seen by users anymore.)
But if the .zip TLD takes off, it's just adding a little bit more cognitive load. Sure, hopefully it's usually clear whether somebody's discussing a filename or a domain name from context. But not always, and that's annoying and anti-user. Conventions have value, and this decreases that value.
So really, it's just like... of all the possible TLD's, is there really any benefit to picking ones that are also common filename extensions? Is our economy really going to suffer if we say, hey let's not make things like .txt and .doc into domains as well? There are tons of other TLD's we can create instead.
Yeah I think there is potential for confusion given users have been warned for years not to download zipped files as they could harbor malicious payloads, now they have to think is it a link to a file or a tld?
So if it's a domain, you should fully qualify it: https://foo.zip.
Over time, this can become a convention. Part of the price you pay in using a .zip domain will be that software doesn't auto-linkify it unless you prefix it with http(s)://.
And with chrome leading it (IIRC) and other browsers following, end users don't even see http or https:// prefixes in their browser bar anymore. Further adding to confusion.
I don't see a reason for adding these new TLDs other than a cash grab.
Right but if you're not hosting Web content then you wouldn't want it linkified in a Web context. If you're using it for something else, e.g. SMTP, then you'd represent the domain name differently as username@your.domain
Why wouldn't someone follow the standard of prefixing it with an appropriate subdomain? E.g., `smtp` or `imap` if it's something they're going to be discussing publicly?
Furthermore, why not use port numbers as a suffix? That's how we can have umpteen services across different protocols on a single domain.
This solution only works if you believe no filename extensions will ever be created (or popularized) from here on out.
So, instead of hoping for that, why not search for solutions that actually will stand the test of time and aren't as fragile as "freeze the filename extensions!"
Also one of the really funny parts of this entire debate is the focus on filenames when most average people aren't even aware of their existence. Windows and Mac have hidden them by default for years now. It's only an image if it shows the image thumbnail, it's only a folder if it shows the folder icon, and so on. I bring this up because it shows how fragile this solution is. You can't get people to adhere to the rule of looking out for ".zip" if they don't even know it exists!
> This solution only works if you believe no filename extensions will ever be created (or popularized) from here on out.
It works if you just don't believe a filename extension like .com or .net will be popular in the future. Personally I don't think they will, as people rightly find it annoying if the clash with TLDs.
In fact, if something like a .net file does become popular, it just shows that people don't care as much as I assumed, and so the problem has solved itself.
I'm sure that bagder (https://twitter.com/bagder) tweeted about this, but I cannot find the tweet (either I'm losing it, bagder deleted it, or twitter's search is broken)
At any rate, `.com` is a (windows) file extension and we've not been too fussed about that as a TLD for the last 40 years.
And .sh (shell script or Saint Helena), and .rs (Rust source file or Republic of Serbia). The latter in particular is quite popular for Rust-related websites.
Or Moldova's .md, Anguila's .ai, Cocos Islands' .cc, Palestine's .ps, Paraguay's .py, Somalia's .so... The list goes on. Filename extensions have always been confusable with TLDs. And yet we've somehow coped for decades.
These, as well as the ones cited in the next comment down, are all file extensions only developers or perhaps power users would know. But .zip is a very mainstream file extension, perhaps one of the most mainstream ones besides the media ones (mp3, mp4, jpg, png, gif) and .exe.
Completely agreed. It might not be an immediate disaster, but it adds cognitive load. And for what benefit exactly? What's the use in having these TLDs?
If "not bad, actually" is the best praise we can give these new TLDs, then it still feels like the downsides far outweigh the potential issues.
Google bought these TLDs. Google also owns Chrome. When you type "something.zip" into the Chrome toolbar, it used to search for it. Now it takes you to a URL. Is that the most widespread vector for attack? Probably not. But at the very least, it's super annoying for people searching for a certain file.
I'm yet to see a single compelling reason why they should exist; the best defense has been "well yeah there's a ton of issues but _maybe_ it's not as bad as we think".
> Is that the most widespread vector for attack? Probably not.
Yeah one big issue I had with the article was the assertion that telling people to open a file like VacationPhotos.zip isn't something humans do. Is it common? Probably not, but there are a LOT of humans. Even 1% of them doing something makes for a huge attack surface. The vacation photos example is also probably not a very good one. How many README.md files are there out there telling someone to look in assets.zip for the webserver assets, or docs.zip for documentation? Someone seeing this is a link would likely reasonably assume it's a link to the file in the repository, and I'm sure someone more creative than me could get up to all sorts of interesting shenanigans with that (incorrect) assumption.
Guess which is older, Moldova's .md TLD or markdown? Just because we aren't going to go retroactively revoking TLDs doesn't mean we should actively make the problem worse.
For the same reason we probably shouldn't start using the COM file extension for something again.
You never should have been able to type "something.zip" and go to a zip. That was chrome being unnecessarily "ambitious" in creating a shortcut when you should have always had to specify "file:///" like every other browser.
You just can't trust '.' separators to always mean something is a file. I think most people have known that since the dotcom era. It's annoying that Google owns them, but there's no shortage of power inequalities in the domain registrar field. It sounds to me like a minor roadbump that is exacerbated by common misconceptions around FQDNs and MIME types.
I recall comments on new gTLDs being overwhelmingly negative when criticism was directed mainly at ICANN. I wonder why more people are willing to defending it now.
It may not be that terrible security-wise, but it’s just plain stupid to add .zip and .mov as tlds.
I mean WHY?! Why the fuck do we need more tlds? And even if we needed new tlds, in the billions of possible choices, why would you choose something that confusing?!
Right. Network Solutions keeps gifting me with unwanted domains in strange TLDs. Then they add "privacy protection" and other unwanted services for which they try to bill. I have to transfer those domains to another registrar to stop that.
The arguments in that blog feel very much like a Google press release.
The main argument against domain confusion is basically that the author doesn't personally see it as an issue, underlined with a bunch of strawman arguments of things that could theoretically appear in urls but never do in practice.
But none of that matters, because thanks to forced HSTS, there will surely never ever be a malicious domain on those new TLDs. This is because, though the new domains may make security harder for users, forced HSTS makes security easier for certain other parties which are not users. So users just have to rely on the smooth operation of those theoretical other parties and everything will work out.
This only strengthens the argument against overmatching autolinkers. The URL RFCs recommend using less-than and greater-than characters to denote URLs in text, like so: <https://www.example.com/>. I welcome a return to this practice.
I wish more TLDs did what travel, tel, and US did(or tried to do, in the latter's case).
Travel vetted each applicant, so you'd know that you were probably not visiting a scam site.
Tel was a little different, and more of a registry, but again...not malicious.
Us was more standard, only requiring that you be a US resident to register. But because it was a govt contract, any whisper of a domain being used maliciously was met with an audit that would shut it down if you couldn't provide a passport. It wasn't perfect, but better than nothing.
It would be nice if more TLDs audited registrants or restricted registrations in some way. A TLD that gains trust is more likely to gain adoption, IMO, even if it is a gTLD.
Instead, it seems to be a giant money grab from all parties involved, which has greatly hurt both trust and adoption.
The horse is already out of the barn on this one, but .zip really is a moronic TLD and I'm surprised it was inflicted on us.
Pedantically it shouldn't matter, but in practice it seems like a real headache. We can all think of common usage and edge cases where it could lead to real issues, from automatic link detection to malware spread.
At this point all we can do is shake our heads at the stupidity and prepare ourselves for the worst.
The internet was designed around a very specific human readable taxonomy of distinct objects, namely hosts, files, and users. We technically could cause the host and file namespaces to collide on purpose, but other than creating a market for products and services that unknot the mess this makes, what makes it a good idea? I think it's probably time to abandon the platform dominated internet for new cryptographic protocols, as the beneficiaries of this inconsistency are the intermediaries who will charge you to manage the chaos and inconsistency they have themselves created.
If you have to do file scanning in email or do any security/governance work at all, TLDs that collide with filenames look like a disaster. An example would be, given a string in a file draft.temp.zip, does it refer to a local filename or a domain? I'd even suggest muddying the namespace like this is a kind of subversion of the internet, which was effectively a social contract about consistency and end to end connectivity. Breaking internet namespaces like this separates the user and person from the network and makes them completely dependent on mediation in the OS for reasoning about basic endpoints. If there is no distinction between files on your machine and on platform company machines, you are in a walled garden.
Adding well known file extensions as TLDs will add a fundamental inconsistency that is just injecting chaos as a means to manage it. Yes, MSFT always had .com files and the internet survived, but that's an exception from a company that has never solved a problem they hadn't first caused.
"but it is fair to say that .com files are rarely seen by users any more; on Windows, .com has mostly been supplanted by .exe except in some exotic situations."
Now "rarely", "mostly" and exotic situations" made me curious. Is there any chance at all to get a *.com file running on a any windows not older than two decades?
out of curiosity i checked my relatively recent windows 10 installation. i see 102 files ending in .com; 13 if filtered to unique files names. 12 in the windows folder, and 1 in a game folder. most of the windows folder ones are in System32m WinSXS, and SysWow64 subdirs, as well as some windows update subfolders. so it looks like mostly for win32 compatibility. i tried running system32/tree.com in powershell and it works fine
http is insecure and should not be used. Not always using https would defeat the entire purpose of the added security, not least because a MitM attacker could block only the https packets and then force a silent downgrade to insecure http. It needs to always be https, never anything else.
I know this is good for the internet, but not all HTTP is the internet.
I have to upload TLS certificates to a printer. A printer!
The printer doesn’t even have a sensible tls algorithms, because its firmware was written at least a decade ago. And the likelihood of someone, anyone, MITMing my printer is 0
Now you're talking about something completely different though. Connecting to a printer over LAN is not at all the same as a Web browser talking to a third party webserver over WAN.
Split horizon DNS just how DNS works. Its weird that HSTS preload lists has made security decisions assuming all domains under these TLDs exclusively point to the internet, when that's not how DNS works
Just use another TLD is nice when everything is from scratch, but when it isn't it means migrating an intranet to another TLD and managing hostname changes for every instance under the domain...
When I link to http (because I want to share public information that never will need encryption), your browser rewrites that to https and then the user gets an error.
No, this is ridicoulus. The browser does not execute a jpeg. It displays it.
The reason malwares worked was insecure automatic execution in IE. You do NOT need https for the browser to type check and securely sandbox downloaded data.
MITM is not the problem, because if I can send a malware from my https server you still have the problem, all https does is waste a ton of electricity for your job (in)security.
If your browser requests a jpeg an my https server returns a exe that the browser saves and the user is foolish enough to execute it, that is not a http problem.
Me neither, but it seems they are used somewhere, or at least have domains: 153 for .google, 37 for .apple, 2 for .android, 85 for .microsoft, etc. For many non-tech brands they don't seem to have any domains though.
Apple finder mixes web results with local results.
Search for file.zip and if it doesn't find a local copy, it will look for a similar result on the web.
If you clicked enter before looking (say, you had a typo but meant another file), Safari happily opens the page. I believe that if the page serves a zip, it downloads and unzips it in the background.
This TLD sounds like a terrible idea for Mac security, at the least.
mov and app is similar, but requires more configuration - and .app by default will not run when downloaded, and .mov is harder to exploit.
123 comments
[ 3.0 ms ] story [ 166 ms ] threadNothing was stopping people from doing that before.
The malicious actor doesn't need to be in the loop at all. Similar to typosquatting.
If a rich Texan rodeo entrepreneur showed up in my email inbox wanting to buy this unique domain, I wouldn’t say no. But I’d ask for a pony.
They couldn't add the email, they said the system was telling them it was an invalid email. Inaccurate email validation in the wild... I suspect the system has a list of known TLDs and that didn't exist when their system was created. Or even worse, they have some hardcoded list of known email providers...
Or, seriously, not supporting .info won't stop a lot of people from adopting and keeping a system, not a lot of developers from doing things this way.
Now I do recall noticing things that would baulk at five-character TLDs once or twice more. (Actually-deployed stuff, this is—if I counted example email address validation regular expressions I’ve seen from Stack Overflow and similar and “see how good/bad/otherwise this LLM is”, it’d be quite a few more.)
I wonder what the success-rate with unicode domains looks like
That matches @0.ab, but not mail@example.com.
I think you mean: .+@[a-z0-9]+\.[a-z]{2,4}
The sales-focused part of the company complained that they would still receive invalid email-addresses for their newsletter.
Turns out what they really wanted was an email address where they could send stuff to. So we implemented a MX-check for the host part of the email address. However, that check was mostly a warning, in the sense of "Hey, are you sure the email you entered is correct?".
I'm using .email domain for a long time, in many cases it's not accepted on registration. When it's accepted and it's an e-commerce website then half the time I get an automated email that the sale was either declined, or they require additional proofs. Or, in some cases, the order just gets ignored, and when you physically call them they can't even find the email in their system, so my guess some anti-spam system just blocks it.
The real problem is when I give my email address to someone else and then they get corrected by their email client. For some reason, people place implicit trust in these validators. This results in emails getting sent to the wrong TLD.
.co was released in 1991, and it’s easier than ever to launch a TLD. Email validators need to stop validating TLDs. It doesn’t help anyone.
I still remember humblebundle rejecting my mailbox.org email as invalid, I'm guessing because of that. They fixed it at some point, fortunately.
The fact that file extensions and TLD's were roughly the same length in the same format wasn't a big issue, when it's generally understood that ".com" and ".edu" are domains, while ".jpg" and ".mp4" are files. (And as the author states ".com" files are rarely seen by users anymore.)
But if the .zip TLD takes off, it's just adding a little bit more cognitive load. Sure, hopefully it's usually clear whether somebody's discussing a filename or a domain name from context. But not always, and that's annoying and anti-user. Conventions have value, and this decreases that value.
So really, it's just like... of all the possible TLD's, is there really any benefit to picking ones that are also common filename extensions? Is our economy really going to suffer if we say, hey let's not make things like .txt and .doc into domains as well? There are tons of other TLD's we can create instead.
Over time, this can become a convention. Part of the price you pay in using a .zip domain will be that software doesn't auto-linkify it unless you prefix it with http(s)://.
I don't see a reason for adding these new TLDs other than a cash grab.
Furthermore, why not use port numbers as a suffix? That's how we can have umpteen services across different protocols on a single domain.
So, instead of hoping for that, why not search for solutions that actually will stand the test of time and aren't as fragile as "freeze the filename extensions!"
Also one of the really funny parts of this entire debate is the focus on filenames when most average people aren't even aware of their existence. Windows and Mac have hidden them by default for years now. It's only an image if it shows the image thumbnail, it's only a folder if it shows the folder icon, and so on. I bring this up because it shows how fragile this solution is. You can't get people to adhere to the rule of looking out for ".zip" if they don't even know it exists!
It works if you just don't believe a filename extension like .com or .net will be popular in the future. Personally I don't think they will, as people rightly find it annoying if the clash with TLDs.
So no, COM files aren't relevant at all in this discussion.
At any rate, `.com` is a (windows) file extension and we've not been too fussed about that as a TLD for the last 40 years.
www.example.com would be the primary, and example.com redirects to www.example.com
It’s my simple approach to overcome the cognitive overload issue.
.com is also a file extension. It describes an executable format that predates the web.
Better yet, why not just suffix it with a `/` if you're lazy?
Google bought these TLDs. Google also owns Chrome. When you type "something.zip" into the Chrome toolbar, it used to search for it. Now it takes you to a URL. Is that the most widespread vector for attack? Probably not. But at the very least, it's super annoying for people searching for a certain file.
I'm yet to see a single compelling reason why they should exist; the best defense has been "well yeah there's a ton of issues but _maybe_ it's not as bad as we think".
Yeah one big issue I had with the article was the assertion that telling people to open a file like VacationPhotos.zip isn't something humans do. Is it common? Probably not, but there are a LOT of humans. Even 1% of them doing something makes for a huge attack surface. The vacation photos example is also probably not a very good one. How many README.md files are there out there telling someone to look in assets.zip for the webserver assets, or docs.zip for documentation? Someone seeing this is a link would likely reasonably assume it's a link to the file in the repository, and I'm sure someone more creative than me could get up to all sorts of interesting shenanigans with that (incorrect) assumption.
For the same reason we probably shouldn't start using the COM file extension for something again.
I mean WHY?! Why the fuck do we need more tlds? And even if we needed new tlds, in the billions of possible choices, why would you choose something that confusing?!
The main argument against domain confusion is basically that the author doesn't personally see it as an issue, underlined with a bunch of strawman arguments of things that could theoretically appear in urls but never do in practice.
But none of that matters, because thanks to forced HSTS, there will surely never ever be a malicious domain on those new TLDs. This is because, though the new domains may make security harder for users, forced HSTS makes security easier for certain other parties which are not users. So users just have to rely on the smooth operation of those theoretical other parties and everything will work out.
But sorry, I did think the author was a Googler, but apparently he works at Microsoft instead.
Travel vetted each applicant, so you'd know that you were probably not visiting a scam site.
Tel was a little different, and more of a registry, but again...not malicious.
Us was more standard, only requiring that you be a US resident to register. But because it was a govt contract, any whisper of a domain being used maliciously was met with an audit that would shut it down if you couldn't provide a passport. It wasn't perfect, but better than nothing.
It would be nice if more TLDs audited registrants or restricted registrations in some way. A TLD that gains trust is more likely to gain adoption, IMO, even if it is a gTLD.
Instead, it seems to be a giant money grab from all parties involved, which has greatly hurt both trust and adoption.
Pedantically it shouldn't matter, but in practice it seems like a real headache. We can all think of common usage and edge cases where it could lead to real issues, from automatic link detection to malware spread.
At this point all we can do is shake our heads at the stupidity and prepare ourselves for the worst.
If you have to do file scanning in email or do any security/governance work at all, TLDs that collide with filenames look like a disaster. An example would be, given a string in a file draft.temp.zip, does it refer to a local filename or a domain? I'd even suggest muddying the namespace like this is a kind of subversion of the internet, which was effectively a social contract about consistency and end to end connectivity. Breaking internet namespaces like this separates the user and person from the network and makes them completely dependent on mediation in the OS for reasoning about basic endpoints. If there is no distinction between files on your machine and on platform company machines, you are in a walled garden.
Adding well known file extensions as TLDs will add a fundamental inconsistency that is just injecting chaos as a means to manage it. Yes, MSFT always had .com files and the internet survived, but that's an exception from a company that has never solved a problem they hadn't first caused.
Now "rarely", "mostly" and exotic situations" made me curious. Is there any chance at all to get a *.com file running on a any windows not older than two decades?
If you have a file it's after a /. Usually it's after multiple /'s.
Interesting how Google and M$ added their own TLDs (and a fairly large amount of them).
(Edit: .meme and .dad are also google, so it's all forgiven)
https://security.googleblog.com/2017/09/broadening-hsts-to-s...
Also zip does not execute.
I have to upload TLS certificates to a printer. A printer!
The printer doesn’t even have a sensible tls algorithms, because its firmware was written at least a decade ago. And the likelihood of someone, anyone, MITMing my printer is 0
Ie if you have a .dev domain that resolves to your intranet - you will still need HTTPS on example.dev, the browser won’t let you off?
Also, if this is really a problem, use a different TLD?
Split horizon DNS just how DNS works. Its weird that HSTS preload lists has made security decisions assuming all domains under these TLDs exclusively point to the internet, when that's not how DNS works
Just use another TLD is nice when everything is from scratch, but when it isn't it means migrating an intranet to another TLD and managing hostname changes for every instance under the domain...
http://n-gate.com/software/2017/07/12/0/
The reason malwares worked was insecure automatic execution in IE. You do NOT need https for the browser to type check and securely sandbox downloaded data.
MITM is not the problem, because if I can send a malware from my https server you still have the problem, all https does is waste a ton of electricity for your job (in)security.
If your browser requests a jpeg an my https server returns a exe that the browser saves and the user is foolish enough to execute it, that is not a http problem.
Stop using your monopoly to force waste.
https://www.microsoft and https://www.hotmail seem to work.
https://ntldstats.com/tld has some statistics.
Search for file.zip and if it doesn't find a local copy, it will look for a similar result on the web.
If you clicked enter before looking (say, you had a typo but meant another file), Safari happily opens the page. I believe that if the page serves a zip, it downloads and unzips it in the background.
This TLD sounds like a terrible idea for Mac security, at the least.
mov and app is similar, but requires more configuration - and .app by default will not run when downloaded, and .mov is harder to exploit.
Where it indicates "scheme" - that is actually protocol to be used.
https://www.rfc-editor.org/rfc/rfc1738