42
UTS #39: Unicode Security Mechanismsunicode.org
rnicrosoft.com sure didn't need unicode tricks to fool people lol
The reality is that unless your in the US or "most" of Europe, you're going to WANT Unicode domain names - people in china are mostly fine with http://www.china.cn but they're going to really want to use their own language https://xn--fiq8ituh5mn9d1qbc28lu5dusc.xn--fiqs8s or https://xn--mgbeiue0iwb.xn--ngbc5azd - https://xn--wgv71a119e.jp
Demanding that everyone use our alphabet because we're too dumb to recognize the difference between google.com and xn--ggle-55da.com is the worst kind of "security through superior firepower"
(the fact that HN shows these correctly in the EDIT window but have to dump to punycode in display is sad, tbh)
Not even "most" of Europe - almost all European languages use diacritics to some extent or another. In the context of domain names, some words are comprehensible with the diacritics stripped, but there's some loss of precision. (For instance, an "ñ" is critical if you're trying to say "happy new year" in Spanish...)
UCS-2 (i.e. Javascript, 16-bit character space) has enough codepoints for every language still spoken except Chinese (even after undoing Han Unification, which was dumb).
Unicode is China forcing variable-length character encodings on the rest of the world.
─ 8 more ─
this might be the dumbest thing I've read on HN in 2026
─ 6 more ─
It's the facts, man.
If you want to say that the facts are dumb, well, you can do that.
─ 5 more ─
No, it's not. UTF-16 supports the same characters as UTF-32 and UTF-8 (all three support all of Unicode). UTF-16 does that by having... variable width characters, in the form of 2-UTF16 code units for some chars.
UTF-16 wastes a bunch of space (when you don't need 16 bits to mark a character), and doesn't avoid variable-width encoding. UTF-8 tries to optimize space (but is ASCII skewed) with more variance (but once you can't infer length from bytes, what's the difference?) UTF-32 is a space hog at the benefit of predictable length encoding (a full Int32 to represent the null char, or a carriage return)
─ 3 more ─
Congratulations, you've discovered why UTF-16 is stupid. You pay the space penalty of two-byte characters and the complexity penalty of variable-length characters.
It's the worst of both worlds!
Seriously nobody advocates UTF-16. The smart people advocate UCS-2.
─ 2 more ─
You can either have Javascript uses UTF16 because UCS2 is dead. Or you can have variable width is stupid. JavaScript supports UTF16 (otherwise; no emoji). UCS2 is also a Unicode standard - just an old one, in their own words:
>In particular, for the purposes of data exchange, UCS-2 and UTF-16 are identical formats.
https://web.archive.org/web/20030818043641/http://www.unicod...
Ok. lol. THAT's the dumbest thing I've read on HN.
The insistence that Javascript means UCS-2 not UTF-16 involves selectively reading a version of the standards document that's more than a decade obsolete.
If you don't like facts that is dumb.
If you really must blame anyone, Japan bears significantly more blame. (Tongue-out Smiley Face Emoji). Plus the original Unicode Consortium for being insufficiently sensitive to requirements for Asian scripts in the first place.
A summary of a fascinating rabbit hole. Here are the scripts that are included in the UTF Supplementary Multilingual Plane, which cannot be encoded in UCS-2, excluding scripts of primarily historical and archeological interest. Obviously, they can all be encoded in UTF-16.
Deseret - The Mormon Alphabet, designed by Joseph Smith to remove corruption in English when written in the Latin alphabet. Used briefly in the 19th century, but no longer actively used, except by a small community of hobbyists and scholars.
Shavian - A phonetic alphabet for English, whose development was funded by George Bernard Shaw. Currently only used by hobbyists.
Osmanya - One of several competing alphabets for the Somali language. Officially superseded by the Somali Latin alphabet in 1972. "Material written in the script is 'almost non-existent'" -- Wikipedia
Adlam - Use to write the Fuldani language. Spoken by about 36m people. The Adlam script is currently taught in Fuldani schools, and is used widely.
Hanifi Rohingya - One of three scripts currently actively used to write Rohingya, the others being Rohingya Arabic, and Rohingya Latin. Rohingya is spoken by 1.5m people. There are at least two newspapers published in Hanifi Rohingya. It is often used in the Rohingya diaspora, and widely taught in Rohingya refugee camps.
Osage - Currently, the official alphabet of the Osage language. Invented in 2006. Osage is spoken by about 50,000 people, and children are taught to use the Osage alphabet in schools.
Medefaidrin - a constructed script and language created as a Christian sacred language by an Ibibio congregation in 1930s Nigeria. It has its roots in glossolalia ('speaking in tongues').
What is the alternative? ASCII isn't it because there isn't only English out there. All the different encodings we had before weren't it either.
Having only ASCII in urls is incredible US centric. Yes it brings problems, yes they are solvable. It takes work to not have US and it's writing system to be the center of everything.
A single language per file
─ 4 more ─
... might sound like a reasonable solution until you start trying to write about languages. It is unreasonable for a sentence like "In Japanese, the word for 'hello' is こんにちは; in Korean, it's 안녕하세요." to be unrepresentable.
─ 1 more ─
Then language change tags which draw a box around the different language.
We tried that in the 1980s with MS/PC/DR-DOS and code pages. We also had BBS networks where people shared such files around the world. One language per file turned out to be a bad idea.
─ 1 more ─
To be fair, that was actually one language per computer.
UCS-2. What Javascript uses.
─ 1 more ─
Javascript uses UTF-16, not UCS-2. An tragic historical mistake. I imagine they would use UTF-8 if they got a chance to do it all over again.
Unicode is complex because human language is complex. If you want someone to blame, blame God:
>Go to, let us go down, and there confound their language, that they may not understand one another's speech. So the LORD scattered them abroad from thence upon the face of all the earth: and they left off to build the city. Therefore is the name of it called Babel; because the LORD did there confound the language of all the earth: and from thence did the LORD scatter them abroad upon the face of all the earth.
Perhaps attempting to build one character set for all languages is just another Babel-like act of hubris, and the security vulnerabilities are God's judgment upon us for not sticking with the mess of incompatible local encodings that preceded it.
I mostly just blame ancient Shang diviners... were it not for them, there would be no need to expand beyond a 16 bit fix width character set.
Pitching a solution to a problem they created. Yes, Unicode has become a racket.
Banning the "limited use" category by default in the "General Security Profile" is interesting given it overrepresents indigenous scripts.
For example, Canadian Aboriginal Syllabics is the writing system of Inuktitut, the primary language of the Canadian territory of Nunavut spoken by 63.1% of the population. It seems like they're being disenfranchised by this proposal.
I compiled an overview who uses it, and who should: https://github.com/rurban/libu8ident/blob/master/doc/c11.md
Honestly that is just sad. Extremely sad.
Bruce Schneier wrote about it more than two decades ago:
"Unicode is too complex to ever be secure".
Systems created by people who have zero understanding of security and who cannot realize that complex systems cannot possibly ever be secure is already bad.
But to then see the same people implement "security mechanisms" for the mess they created for in the first place is just sad.
FWIW I love Unicode, where it belongs: in translation / properties files.
I've got hooks verifying that all source code files are ASCII-only.
I've got rules for my LLMs to only ever emit ASCII in source code.
I've got firewall rules blocking any domain using punnycode (aka Unicode domain names). A bit tricky to do that one.
I've got my editor configured so that any single non-visible ASCII char (except space and enter) and every single Unicode character appears in bold fluo magenta on a dark background. All zero-width chars are forced to have a width.
I wonder how people who disagree with those who believe that Unicode is too complex to ever be secure reconcile with the fact that we have something titled:
"Unicode® Technical Standard #39 Unicode Security Mechanisms"
The question is: how the heck did we end up here?
What mindset led to this clusterfuck?
Who, in his right mind, decided that it was a good thing to have Unicode chars in URLs? Certainly not security experts.
The homoglyph attacks were predicted by Bruce Schneier (and others) decades ago. Countless people got tricked and lost their live savings because URLs allow an 'a' to not be an 'a'. It's sad.
And it's of course not the only attack using Unicode: there are plenty.
It's really just all a sad joke and many of us saw it coming from day one.