Except it’s not something that most people actually use - even in the 90s .com was basically a relic, and more to the point even among those folk that recognize a .com as a file type, it would be considered risky.
You can’t just fixate on things in isolation - it’s not just “is this an extension” it’s “is this a thing people are used to being a file extension and is it benign in such a case”. By the time urls were a thing that non-technical folk were interacting with, “.com” was not something they would be using, even on windows. In fact on windows and dos you would generally not even be typing it, as the platform adds the extension automatically.
Even with the correct url, its a tag, so it would be possible to rebind it to a new malicious commit, if the repo gets a malicious actor
Even with all of this, then there is Smart Screen telling you “Hey, don’t run random unsigned executables and be careful with stuff you downloaded”
When is it okay? .rs can be malicious, .com can be malicious, etc. “but .com isn’t common” so its a matter of popularity? What would the change be that would make one okay with .zip existing as a TLD
These are two completely different classes of attack though. One is “the people you’re downloading and running arbitrary code from are evil”. The other is “the people you think you’re downloading and running arbitrary code from are good, but the URL is deceiving, so you’re actually downloading code from an unrelated attacker”.
My hot take is that domain names were a mistake. Phone numbers existed, saying “you use this number to access X” and have your own address book. Bank website not in address book? Well that’s weird isn’t it!
Granted, there’s obviously a lot of things to be done to improve security for browsing, just all this chasing down of unicode lookalikes seems like an interminably hard problem to resolve in a universal way.
This feels like a failure of web browsers more than top level domains that match common file extensions. Personal opinions ahead:
Disregarding user info when resolving and following urls is bad. It shouldn’t have been included in the spec in the first place but because it does exist, silently dropping it is the worst of all possible methods of handling it.
Treating Unicode forward slashes as alternate characters from ASCII forward slashes is bad. Colons and periods should also be combined in this way as well. They are the foundational punctuation of URLs and protecting them is more important.
Separately from browser failures, rendering html in emails is bad. I don’t need to qualify this, I’m preaching to the choir here.
The username is very useful in some circumstances, mostly unrelated to web browsing. SSH URLs, for instance.
I agree, but it’s a slippery slope. There are many, many Unicode characters that resemble ASCII characters.
Uh, strongly disagree. I’ve never understood why rich text & hypermedia is great in one app but supposedly terrible in another. In any case this issue has nothing to do with HTML; it’s about URLs appearing in raw form.
The decision to support full HTML in e-mails is fraught with problems:
Folks abuse markup by saying silly shit like “my response in pink”, and the next time they reply “my reply in green” instead of using the proper indented quoting mechanism. This is a lost cause by now…
Due to developers thinking they have to support both text-only clients and HTML-capable clients, often a completely botched text-only representation is shipped. There are so many companies out there that either send the raw HTML source code of the e-mail as a secondary text/plain copy, or an unreadable mess of text (presumably automatically-translated version from HTML), or a useless empty message or “your e-mail client is unable to read this”. I get confronted with this almost daily. In these cases it would be better if they sent just the HTML, so that my client can pipe it through lynx. I doubt there are any clients that can’t handle HTML at all nowadays.
Click tracking is rampant and not blatantly obvious when the URL is hidden behind clickable text or pictures. This happens a lot less on the web (because tracking happens there via JS).
Clients have either crippled HTML renderers or include a full browser engine with all the related bloat and security issues that brings. To add insult to injury, after many years of just using Internet Explorer as a rendering engine (with all the associated problems that had), Microsoft actually started shipping Outlook 2007 with an even worse HTML view: the HTML renderer from Word. This means we can’t even have the nice things from HTML - we’re stuck with table layouts etc if we want to make sure people can actually view the mails as intended.
If you want to do HTML in a web-based e-mail viewer, you suddenly have a built-in XSS vector and have to work hard to sanitize it. But not too hard, because that could break complex layouts.
Weird as it sounds, Microsoft’s RTF (rich text format) would’ve been a much better standard to settle on for e-mail. Microsoft and Apple both support it and it’s not the most insane file format ever. It would solve all the issues above except the first.
I’m old enough to remember seeing sigs with that one, and also jaded enough to believe it’s utterly pointless. Non-technical users have no idea what ASCII even is, or how to make their mailclient use it. And developers typically don’t get a vote - marketeers want their e-mails to look flashy. There’s no going back.
Mail is the universal communication format. It was inevitable that people would want richer formatting than plain text, and I bet you’ll find mailing lists arguments saying HTML is preferable to RTF for any number of reasons.
Anyway, you can send everyone in a company an email with a link saying “DON’T CLICK” in huge red letters that will in fact steal all their passwords, and a number of people will click it. That’s why there’s all manner of band aids like warning the sender is outside the organization, sending every link through some central “checking service”, etc. etc. HTML email just slightly lowers the bar.
I don’t agree that the problems you list are worth condemning HTML email, but I agree that RTF email worked well. These days Markdown email would be even better, since it’s a simpler format and you can get away without having to provide a text/plain equivalent.
Is http auth, which is how site login worked for decades.
Right. Browsers could instead display a simple generated form with the username and password pre-populated before loading the page. That would solve this better than silently dropping them, imo.
It’s not surprising that a US-centric definition of esquire was selected, but when you dive into the protocols of the British usage, things get even more complicated.
Hopefully a decentralised alternative to DNS soon. I think it’s the one place blockchain (or some other kind of proof-of-something system) would actually be useful.
MUA’s should have no issue since they are supposed to correctly parse html. Other applications, like word processors, especially the ones who immediately turn anything.abc into a URL will have a hard time.
Imagine .com, a perfectly valid extension in Windows.
Except it’s not something that most people actually use - even in the 90s .com was basically a relic, and more to the point even among those folk that recognize a .com as a file type, it would be considered risky.
You can’t just fixate on things in isolation - it’s not just “is this an extension” it’s “is this a thing people are used to being a file extension and is it benign in such a case”. By the time urls were a thing that non-technical folk were interacting with, “.com” was not something they would be using, even on windows. In fact on windows and dos you would generally not even be typing it, as the platform adds the extension automatically.
I tried kafka.esq, but was of course too late.
Waking one morning from uneasy sleep, Gregor Samsa discovered he had been transformed into a gigantic lawyer.
I am not surprised if these get generally blocked by most of the sysadmins. It is too much risk to allow .zip and similar as valid extensions.
I got my partner a .ninja domain and a surprising number of web forms still reject it as an invalid email address, years after it was added as a TLD.
I mean, likewise, can you quickly tell on mobile which is good and which is bad?
(The joke is both are bad)
Even with the correct url, its a tag, so it would be possible to rebind it to a new malicious commit, if the repo gets a malicious actor
Even with all of this, then there is Smart Screen telling you “Hey, don’t run random unsigned executables and be careful with stuff you downloaded”
When is it okay? .rs can be malicious, .com can be malicious, etc. “but .com isn’t common” so its a matter of popularity? What would the change be that would make one okay with .zip existing as a TLD
These are two completely different classes of attack though. One is “the people you’re downloading and running arbitrary code from are evil”. The other is “the people you think you’re downloading and running arbitrary code from are good, but the URL is deceiving, so you’re actually downloading code from an unrelated attacker”.
Both links are deceptive, the first one links to kubarnetes org, a person could go and take that org right now.
Correction: seemingly someone now has taken the org
Tags can be deleted and re created with the same name. Just a nitpick :)
Who has torment.nexus ?
https://torment.nexus/@brandon/110341821575284522
You just know that’s why they added it
It’s a Fedi instance! https://torment.nexus/about
Will the innovations at Google never cease?
Common file name extensions are going to bite someone as tlds. .zip, .mov, …
I’m waiting for
.exe.My hot take is that domain names were a mistake. Phone numbers existed, saying “you use this number to access X” and have your own address book. Bank website not in address book? Well that’s weird isn’t it!
Granted, there’s obviously a lot of things to be done to improve security for browsing, just all this chasing down of unicode lookalikes seems like an interminably hard problem to resolve in a universal way.
Trust is hard enough as it is!
Sounds a lot like compuserve used to be.
I managed to snag doo.dad during the preregistration period. Not sure what I’m going to do with it yet.
Wait and sell it for millions :^}
Willing to cut you a deal for $500,000
This feels like a failure of web browsers more than top level domains that match common file extensions. Personal opinions ahead:
Disregarding user info when resolving and following urls is bad. It shouldn’t have been included in the spec in the first place but because it does exist, silently dropping it is the worst of all possible methods of handling it.
Treating Unicode forward slashes as alternate characters from ASCII forward slashes is bad. Colons and periods should also be combined in this way as well. They are the foundational punctuation of URLs and protecting them is more important.
Separately from browser failures, rendering html in emails is bad. I don’t need to qualify this, I’m preaching to the choir here.
The decision to support full HTML in e-mails is fraught with problems:
text/plaincopy, or an unreadable mess of text (presumably automatically-translated version from HTML), or a useless empty message or “your e-mail client is unable to read this”. I get confronted with this almost daily. In these cases it would be better if they sent just the HTML, so that my client can pipe it through lynx. I doubt there are any clients that can’t handle HTML at all nowadays.Weird as it sounds, Microsoft’s RTF (rich text format) would’ve been a much better standard to settle on for e-mail. Microsoft and Apple both support it and it’s not the most insane file format ever. It would solve all the issues above except the first.
In one month, the campaign against HTML email will be 25 years old: https://en.wikipedia.org/wiki/ASCII_ribbon_campaign
I’m old enough to remember seeing sigs with that one, and also jaded enough to believe it’s utterly pointless. Non-technical users have no idea what ASCII even is, or how to make their mailclient use it. And developers typically don’t get a vote - marketeers want their e-mails to look flashy. There’s no going back.
Mail is the universal communication format. It was inevitable that people would want richer formatting than plain text, and I bet you’ll find mailing lists arguments saying HTML is preferable to RTF for any number of reasons.
Anyway, you can send everyone in a company an email with a link saying “DON’T CLICK” in huge red letters that will in fact steal all their passwords, and a number of people will click it. That’s why there’s all manner of band aids like warning the sender is outside the organization, sending every link through some central “checking service”, etc. etc. HTML email just slightly lowers the bar.
I don’t agree that the problems you list are worth condemning HTML email, but I agree that RTF email worked well. These days Markdown email would be even better, since it’s a simpler format and you can get away without having to provide a text/plain equivalent.
Is http auth, which is how site login worked for decades.
This is a separate and unrelated issue to TLDs. Plenty of similar issues exist anywhere there’s a visually similar character in multiple languages.
Plenty of emails are better and reasonable with fonts. But more to the point even plain text emails get (and benefit from) linkification of urls.
Right. Browsers could instead display a simple generated form with the username and password pre-populated before loading the page. That would solve this better than silently dropping them, imo.
The AOL Kewordification of the Internet continues.
https://mistakes.computer/gtlds
this might be more convincing with some reasoning attached
Yeah, weird. Is the page supposed to be blank aside from the heading?
It’s not surprising that a US-centric definition of esquire was selected, but when you dive into the protocols of the British usage, things get even more complicated.
Hopefully a decentralised alternative to DNS soon. I think it’s the one place blockchain (or some other kind of proof-of-something system) would actually be useful.
Facepalm
Hm?
MUA’s should have no issue since they are supposed to correctly parse html. Other applications, like word processors, especially the ones who immediately turn anything.abc into a URL will have a hard time.