Don't panic. Google offering scary .zip and .mov domains is not the end of the world In early May, Google Domains added support for eight new top-level domains, two of which – .zip, and .mov – raised the hackles of the security community. The reason, of course is, that .zip and .mov are both file extensions. So there's concern that a miscreant could employ these TLDs to confuse people by visiting a malicious …
I read some of the comments on Googles move as
"other people also have problematic TLD so Google creating more isn't that bad"
rather than the risk averse approach which problematic TLDs exist, let's not add to that while browsers might still be fooled.
Because the world is crying out to use .zip and .mov domains.....
...and why limit to 3 letters anyway? There's many, many TLDs out there more than 3 letters nowadays. .zip is a three letter word if your in the clothing or cable-tie business, but I don't see a need for .mov. That's not a word, it's an abbreviation for multiple words of vastly different meanings so won't have the same cachet with all all people.
"other people also have problematic TLD so Google creating more isn't that bad"
Yeah, the whataboutism is deafening.
.com dates back to a simpler, more naive time when not many people were using the internet, and now we're stuck with it.
.sh is potentially quite dangerous, but most people don't know what a shell file is to start with and hopefully (!) won't try and run it. It won't get you very far on Windows anyway.
.zip and .mov are extensions people know and recognise. They might even expect to receive legitimate emails with attached zip archives (or links to). The fact that .com and .sh exist are not good reasons for ICANN to allow other common file extensions as TLDs.
There are a bunch of active countermeasures out there... but it makes no sense to rely on active countermeasures to address a passive risk. That's poor security design.
.zip is confusing. "url.zip" does nothing that bit.ly doesn't already do. The world simply doesn't need them. They're just going to end up on arbitrary block lists with most of the other wanky gTLDs.
".sh is potentially quite dangerous, but most people don't know what a shell file is to start with and hopefully (!) won't try and run it. It won't get you very far on Windows anyway."
It won't get you far on Linux either unless you manually chmod it to give it execute permission. If the system automatically gives it execute permission because you downloaded and executable script, then the OS and browser are VERY badly misconfigured and you already have MUCH bigger problems :-)
Makes sense, as I don't think many were ever likely to be used legitimately regardless. It seems generally accepted that the main reason for these crap TLDs was to force owners of existing subdomains to buy more variants solely as a precaution to reduce the risk of cybersquatting.
these crap TLD's
Define 'crap'? I still find some systems which block my .cymru TLD, and web forms that refuse to accept it as a valid email address. In fact I even came across one which blocked any TLD with >4 characters but accepted anything else, even if it wasn't a valid TLD!
M.
"Bit like .xyz, pure spam sites"
I don't know about all that. I bought a .xyz domain for a friend of mine with his nickname. I won't post it, but it rolls right off the tongue and it's very easy to remember and type. He's a music producer and drummer that's worked for years with major touring acts and in the studio. He's shifting from being on the road all of the time to doing more work locally since he's been just about everywhere many times over and the glamour has completely rubbed off at this point. His girlfriend is also not keen on him being gone for months at a time either. A super easy domain name is always an asset.
I think you made a mistake there. In the immortal words of Elizabeth Montgomery, it's not about whether you're a witch but whether people think you are a witch* and people think .zyx is crap. Plus there is the fact that you can be screwed over at any time. I once had a .art domain which thankfully I didn't use for anything much. It was less than USD10 a year so why not? Except at some point those running the scam decided they wanted several hundred dollars per year. If I'd been using it seriously I would have been screwed.
*In a particularly crap episode of Bewitched that has stuck in my mind for that reason.
Isn't that like blocking a whole country just because some scammers are there? or taking it to the extreme, some spam comes from a .com domain so .com must mean spam? Clearly that last one is not true but it's only a matter of degree.
Someone should be able to buy and use a valid domain without being tarred by the scam/spam brush.
I don't do bans of large sets for exactly this reason. I wouldn't block an address just because it chose one of those TLDs. This is more about what I think when I see one. If I see a .com address, I'm thinking that it might be legitimate, if I see a .xyz domain I think there's a lower chance but it may be real, and if I see a .top or .buzz domain I assume it's a scam unless I have information that it's not. I'm sure some legitimate sites use those TLDs, but I don't think I've seen that many, which keeps me from using them either.
I have a pretty common name so a .com address is already long gone and the last time I checked, paid for the next 10 years. I looked at my name plus something else and those were gone too. The web address for my principal business is a .pro address as I could get my full name with that TLD. I also have several other .com's for various defunct or potential projects. They're cheap so why not? Somebody named John Smith may want there to be many TLD's so they have some sort of chance of getting Johnsmith.xxx or even johnsmithplumbing.xxx if they happen to be a plumber (or attorney).
I look for telltales like a famous brand name with a URL that isn't .com or an equivalent country TLD such as .co.uk. If I see that, I think 'scam'.
Phishing attacks already using the .zip TLD
Earlier this week, we investigated existing registrations using the .zip TLD and confirmed that there is already evidence of fraudulent activity.
At the time of writing, there are fewer than 5,000 registered domains using .zip. 2,253 of these have an A record, pointing to 838 distinct IP addresses. We have discovered phishing attacks on five of these domains so far, none of which are still live at the time of writing.
Someone should be able to buy and use a valid domain without being tarred by the scam/spam brush.
Sure. And someone else should decide that they aren't interested in any domains that participate in ICANN's gTLD money-grab.
There's far more content hosted on sites in domains in the original gTLDs and ccTLDs than I'll ever get to. I don't see any need to pay attention to anything sitting in any of the new TLDs.
At current numbers, assuming you aren't allowed on line unsupervised until the age of 10, and by the time you reach the age of 80 you longer care or are dead, you'd need to visit approximately 18,000 websites per hour to reach the end of the Internet in those 70 years :-)
Of course, there's more new sites coming online then dropping off each year, so it'd be a never ending, ever extending, task.
"There's far more content hosted on sites in domains in the original gTLDs and ccTLDs than I'll ever get to. I don't see any need to pay attention to anything sitting in any of the new TLDs."
My understanding was that the context was blocking emails, not talking about which web sites you choose to surf to.
I will admit that .xyz is one of the new TLDs that has a larger proportion of non-scam users. Unfortunately, that's not quite the same as saying that scammers aren't very common there.
It isn't a TLD I would choose for projects unless I really couldn't find a viable one in an older TLD, and in that case, I'd also be checking who was using the older variants of my domain on those TLDs for fear that a name collision would work to my detriment. I'm wondering why you or your friend chose the .xyz domain? If it was because the name was taken in all the more typical TLDs, did you find this less concerning than I would? Unless the suffix has some connection that makes an interesting pattern, I'm not sure why else you picked it.
This was monumentally stupid, and these pathetic "some other domain was already doing it!" excuses even moreso. Billions of Internet users were not even *alive* when MS-DOS was still in use (before being largely hidden by Windows95) and of the rest, how many remember that it was once an extension for an executable? (How many even knew that at the time? You never needed to actually type the extension to execute a program. And almost all software users actually used were (and still are) .exe files.)
.pl? .sh? .rs? Really? I'm sure I'm not the only one who has noticed that security scams often target the less-than-security-savvy, who are probably not going to think of any of those as file types at all. But everybody's downloaded a QuickTime movie or zip file at some point in their lives.
The domains should never been approved, but if they are going to be approved, fixing the URL display behavior would be a good start.
"Back in the day"..., .com was in use by CP/M (8 bit, 16 bit used .cmd), and earlier, when little Billy gates was still in short pants, DEC was using .com, long before MS and their version of DOS came along. It seems even tech journalists are getting younger these days, let alone the commentards :-)
Several reasons. The first reason is what I already said above: the part they think they're reading is login information because it's before the @ sign. Incidentally, paths can be anything as well, no need for those to be ASCII. Only the domain part of the address might have a restriction against Unicode, but it might not.
As for mixtures, nothing in any specification prevents someone from having a username with multiple kinds of Unicode characters. There are many languages where that is common, where Latin letters are used so they're using some bytes from ASCII's English area, but there are other letters, diacritics, or symbols which are found elsewhere in the Unicode codespace. If they tried to make a database of languages so they could ban sequences not associated with a language, it would be a lot of work that would likely just annoy people whose language hadn't been inserted yet. I'm allowed to have a path or username on my system consist of mixed alphabets, and if the browser couldn't support that, they're breaking the standards that implement Unicode support.
> Republic of Serbia shares its CC-TLD (.rs) with the Rust file extension.
Why? Why didn't Rust use .rust? [1]
Not only is there the potential conflict with URLs, but that .rs was already in use (and GIMP among others knows how to open those files).
Why did Ruby use .rb and not .ruby?
And why didn't The Community, this marvellous group of "lots of eyeballs", point this out to the originators and get it changed before the (in theses cases) languages became so widespread that it might be a problem to make the change?[2]
Pah [3]
[1] The only argument I've seen is "but Perl uses .pl, Python uses .py ..." - ignoring that not only do these at least at least sound like the language when you pronounce them but, oh yes, at the time these were introduced many (even *most* ?) systems COULD NOT DO ANY BETTER with file extensions! Maybe we should be glad that at least the file names weren't so limited in length - recall that Forth was called FORTH because the OS at the time could do neither uppercase nor more than 5 letters, so Chuck couldn't call it Fourth (as in, "fourth generation language" - waits for 4GLlers to start screaming).
[2] because renaming files and search/replace Makefiles is *such* a difficult problem </dripping_sarcasm_and_not_a_little_bile>
[3] Hah! You didn't the lawn sprinklers to be full of food dye, did you, ya punks! Now git!
I was relatively recently introduced to the terrifying fact that Windows file extensions have a 255-character limit on file extensions. The exact same limit as the entire filepath before the dot!
I don't think anyone is wanting to use novellas as file extensions, but you can certainly get a few decent limericks in there.
This post has been deleted by its author
I remember trying to send a DNS zone dump of a .com domain to a work colleague.
Text file, so I simply added it as an attachment (on Linux) and named it "example.com".
He never received it. After the third attempt I realized that the virus scanner on his mail system (he was on MS Outlook) thought a .com attachment must be an attempt to send an executable. The fact that the mime-type was "text/plain" mattered not one jot. Presumably MS looked at names, not actual information (standards - what are they?)
"The fact that the mime-type was "text/plain" mattered not one jot. Presumably MS looked at names, not actual information (standards - what are they?)"
Blanket bans may not be a great idea, but if you're going to have one, of course you'd use the file extension instead of the type. If the user saves the attachment and clicks on it, the OS is not going to crawl through the email database, check the type, and use that to open the file. It's going to look at the extension to do that. The type won't stay with the file, and Windows Explorer and many other GUI file managers have established years ago that they will use the extension for that purpose. Of course, your file wouldn't have executed, but people became worried after viruses, most famously Iloveyou, used a .vbs attachment and users who just blindly opened it, so they ended up using a big hammer to try to block anything that could execute just by clicking on a file.
The ship has sailed on that. Most filesystems don't have a place to embed that data, and it's not just Windows. I don't have fields for that in most Linux filesystems, and when that is available, the system doesn't use it.
I'm also having trouble figuring out why that's better; just like a file extension, it's a free format string that anyone can change. If that was used to identify file types, the ban would apply to that one instead. This also decreases the extensibility, since there is a defined list of authorized types. I've checked out IANA's list, and it's missing several types that people like to distinguish. I see a few types that name a specific script format, but for example both Python and Rust files don't have a type and would probably be labeled text/plain. We'd either have to constantly apply to add types to that list, make up new type designations and hope that everyone figures out to use them, or just ignore the type and use a different indicator.
My system identifies files by a signature string ("magic bytes" to some). Is this why I get complaints when I send a file without the "standard" "dot" followed by letters at the end?
Seriously, this is not a new invention. It would save many from inadvertently performing some unintended action.
The downside of "magic bytes" is that the shell has to read the actual file data (and how much of it?) to determine which action was required.
That means opening the file itself, rather than just the (likely cached) record in the mounted filesystem.
If the file is not in fact a real file but is instead a physical device, that could be exceedingly bad.
This is why mime types were invented, of course.
That introduces three problems. First, you have to open the file and read from it in order to know what can be done with it. You'd have to have a big database of magic byte sequences and an easy way of adding new ones. If anything did that automatically, you'd likely see performance dropping from extra reads, and that would get worse if there's a network link somewhere in the process.
The other problems are related, and they come because the user lacks information about what the file claims to be. The simpler problem is just inconvenience, since a user can generally understand what is contained in a file that uses a standard extension, but would have to read your file, hopefully with the same magic number database that you have, in order to figure that out using your method. The extension can also indicate something that your database probably doesn't, such as whether this file which your database correctly identifies as "plain ASCII text" is text, configuration, or source code, and if it's code, what language it's for. If you've sent a large collection of files, they may not really want to do that to every one of them to figure out which is which, and a good name that indicates the type makes that easier. The other side of the coin is worse: if the user recognizes an extension, they have a pretty good idea of what program will try to read the file if they open it. If I have a .zip file, I know my archive compressor of choice will try to open that. If somebody sent me a different kind of file with the .zip extension, the archive program will give me an error message. What can't happen is that the .zip file is an executable in disguise and will execute, since my software won't just execute a file without the correct extension set (admittedly, that extension is an empty string on my system, but it has to have a bit set so that evens it out a bit). The extension system is far from perfect, but I prefer that to guessing every file's contents and taking automatic action based on that guess.
> Has Google got the ability to invent new TLDs?
Just the money needed to get them into the database[1] and to provide the registrar service (the latter being mote than recouped by selling registrations to the gullible and the desperate)
[1] and to pay for all the plain brown envelopes holding same
That was my take-away of the original article. This is all enabled because Chome took the 'you're too stupid to make good decisions' route. All they had to do was pop up a warning like 'this link contains a username in plain text. Did you intend to log into something?' dialog.
It does that for self-signed certificates, and possibly some other use cases I can't bring to mind because I hate Chrome and would never touch it.
But instead, they think users are too stupid to understand the concept of usernames/passwords or the concept of authentication. In their patronizing hubris they decided that they should take the decision out of your poor dumb hands. And then the 'smart people' making decisions for you didn't realize they were creating a security problem themselves.
This is how you treat children too ignorant or immature to make good decisions. Glad to have one more arrow to shoot at Google - they make browsers intended for children, not adults.
No, it's required behavior from RFC 3986
The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource. The user information, if present, is followed by a
commercial at-sign ("@") that delimits it from the host.
Do you really feel it's more patronizing for them to follow specified behavior rather than send up warning screens for stuff that's explicitly specified and is in fact used in that way by several systems that accept HTTP authentication?
After reading all the "always knowledgeable" post of the commentards, I still don't know, other than gleaning money out of companies to prevent squatting, what the actual purpose to problem these TLD are intended to solve?
If the object is to open up domain names for more personal use, then why not something like .self?
I'm not sure they really have a purpose. When they started making them, the idea was that people wanted domains so badly that new TLDs would help, and a lot of people poured a lot of money into that idea. I'm not sure how well it's going, but I've seen some of the domains sold off and several shut down before launch, so maybe it's not as profitable as hoped. In that case, I don't know why Google decided to set up some new ones now that they've had a chance to see how well it worked before.
OP misses the point.
Not only is this invalid 'whataboutism' but also fails to recognize that context and the expertise level of the people you allow access to dangerous tools matters.
It's like saying that mining engineers use explosives all the time, so it's no big deal if we start peddling them to laymen.
Your gramma isn't going to know the difference between .pl and .com, nor be aware of their file association. But they will 'get' zip files, and that it's 'safe' or at least plausible that a URL they're clicking to download something would end in .zip.
If they saw one of these malicious links and it ended in .com, they'd maybe wonder why it was downloading something when they're just trying to link to a website in the common .com TLD. Sus.
Or if it ended in .pl they might wonder why the zip file wasn't a zip file, or ask for help on how to find the 'right' link because they don't know what to do with a .pl file - which would probably get the attention of someone who knew what Perl was, and that person would catch on to the fact that shenanigans were involved.
But ending in .zip? No red flags would be raised. Looks legit to granny.
One of these things is NOT like the other, and I reject the author's weak attempt at arguing equivalence.
I treat any TLD but .com, .net, .org and country suffixes as illegitimate.
So don't look for my business if your TLD is .biz etc.
Why? Just because spammers and scammers register those fucked up domains. What do we even need that confusion for? There are no limits to the numbers of domain names under existing TLDs. It's just so people can register (and/or squat on) alternate domain names if the new TLDs aren't taken. Registrars try to scam you into paying for these superfluous TLDs too, "Protect your business, register these today!" etc.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
