Tangentially related - 20+ years ago I managed to register a π domain under one of the primary TLDs.
As in, the registration form was accepted and the fee was charged.
Then, few days after they emailed to say that "due to technical difficulties" the registration can be registered and they have no choice but to unregister it.
My brother had a friend who tried to register fuck.com in the early days of the Internet, around 1994, and the registrar was confused and wanted to know why he wanted to register it. This was when the Internet was mostly universities and a .com cost $100 to register.
1994 they were definitely still free[1]. I had so many good ones, but when they switched to the paid model[0] I was a broke college student and let them all go.
[0] IIRC, it was Unilever who caused it -- they mailed in something like 19,000 domain registration applications, one for each of their current trademarks.
[1] OK, I looked it up, September 1995 was when the charging started.
Unilever later bought the domain substance.com from my friend. Remarkably, they apparently later let it lapse and someone else registered it. I'd assumed they were going to have a database of chemical substances that were used as ingredients, or something.
Maybe. That sounds like the story he told me. But now I'm wondering if I'm misremembering the friend part. Maybe he read the story when he was posted in 1997 and told me about it.
I managed to register a one letter domain below a CC-tld, despite that country having a rule against it. Their signup form had two stages and the check was only on the first page... so all it took was changing a hidden form field.
I had it for a while until they started charging a lot for it (it was Turkmenistan).
I managed to grab a lot of really good[0] emoji domains by bouncing between registrars until you find one that has some poor (good?) coding that lets them slip through.
Then you get stuck a year later when they've upgraded their system and now nothing you do will let you renew it or transfer it...!
I did the same. Namecheap was the worst. They'd let me register one then refund me a few days to a week later when someone caught it. That was way worse than just saying no.
Not sure why so many things use the compatibility form of normalisation.
Some older RFCs even recommended using it for passwords, which needlessly reduces entropy (yes we need to normalise passwords because of combining characters, but we don’t need to collapse symbols that a user can choose from, like ſ and s).
In my opinion, the compatibility form makes mostly sense for searching text, and even then it’s sometimes annoying (I want to search exactly for ss and not ß, browser). If you know of other good use cases let me know.
It also OK to disallow registering two identifiers with the same compatibility normalisation form (edit: this does not prevent all homoglyph attacks BTW, that is another can of worms), but I don’t see the need to normalise the identifier when it’s used.
> For example, U+200B ZERO WIDTH SPACE was originally classified as a space character (General_Category=Zs), but it was reclassified as a Format character (General_Category=Cf) to clearly distinguish it from space characters in its function as a format control for line breaking.
Braille Pattern Blank "⠀" (U+2800) is another one of my favourites, since it's also not considered whitespace, but it looks like it. It can actually be fairly helpful for forms that won't let you leave any field blank, since it bypasses most whitespace checks.
> It was found that many publications that use Unicode Braille characters use U+2800 with a marking glyph. A
marking space is not without precedent, consider U+1680 OGHAM SPACE MARK. However, in some cases,
U+2800 is clearly used as a symbol, to indicate the presence of a space when describing a Braille sequence
corresponding to a symbol or punctuation, similar to the use of ␣ (U+2423 OPEN BOX) to indicate the
presence of a space. Especially in cases where it is used in a trailing position, as in the [UNE13] example, it is
clear that it would be inappropriate for this symbol to disappear.
> Considering this usage as a marking symbol, together with concerns about changing the relatively stable—and
often hardcoded—White_Space property (a property of only 25 code points, last changed in Unicode 6.3, when
U+180E MONGOLIAN VOWEL SEPARATOR ceased to be a space), the PAG preferred a more targeted
change.
I use it for sites like Facebook where I want to type :) without it changing to the terrible `U+1F642 SLIGHTLY SMILING FACE` [1]. I wouldn't really mind if it were the `U+1F60A SMILING FACE WITH SMILING EYES` [2], but the first one is so laughably terrible, as if I'd really want to send an emoji to communicate a disingenuous, pained smile as a default. Some platforms let you backslash-escape sequences so they don't get turned to emoji, like \:), but for Facebook and the like, putting a ZWS in between the letters stops the conversion.
Though if your emoji is at the end of a line, it'll potentially break your emoji between the two lines. since That's what a ZWS is for, after all.
> My favorite unicode character is zero width space. One of its funniest properties is that it's not a whitespace.
My editor is configured to never show any character (except the one and proper newline) at less than the full-width of a regular character (in the monospace font I'm using ofc).
And if it's not a visible ASCII char, not only it's always shown at least at full-width, it's also shown as bold magenta on a black background. As the non visibe zero-width is empty, it shows as full-width on a black background.
Note that, in addition to normalizing domain components, the process also maps U+3002 IDEOGRAPHIC FULL STOP (。) to U+002E FULL STOP (.) for use as a separator, a nice touch for domain names encoded in blackboard bold.
Also, the author's one-liner, updated for Python 3:
Doesn't work for me in Chrome either; it transforms the URL from the top comment into https://sp.m. I believe this is the result of browser-level defenses against IDN homograph attacks, some of which postdate this article.
There have been some additions since 2018 when this article was written; here is the current list, from what I can tell:
㍳ │ 003373 │ SQUARE AU │ AU │ Australia
㍴ │ 003374 │ SQUARE BAR │ BAR │ Bar, Punto 2012 Sociedad Anonima Promotora de Inversion de Capital Variable
㎈ │ 003388 │ SQUARE CAL │ CAL │ Google
㏄ │ 0033C4 │ SQUARE CC │ CC │ Cocos (Keeling) Islands
㏅ │ 0033C5 │ SQUARE CD │ CD │ The Democratic Republic of the Congo
� │ 01F12D │ CIRCLED CD │ CD │ The Democratic Republic of the Congo
㎝ │ 00339D │ SQUARE CM │ CM │ Cameroon
� │ 01F190 │ SQUARE DJ │ DJ │ Djibouti
㍷ │ 003377 │ SQUARE DM │ DM │ Dominica
DZ │ 0001F1 │ LATIN CAPITAL LETTER DZ │ DZ │ Algeria
Dz │ 0001F2 │ LATIN CAPITAL LETTER D WITH SMALL LETTER Z │ DZ │ Algeria
dz │ 0001F3 │ LATIN SMALL LETTER DZ │ DZ │ Algeria
fi │ 00FB01 │ LATIN SMALL LIGATURE FI │ FI │ The Republic of Finland
㎙ │ 003399 │ SQUARE FM │ FM │ Federated States of Micronesia
㏿ │ 0033FF │ SQUARE GAL │ GAL │ Galicia, Spain
㎇ │ 003387 │ SQUARE GB │ GB │ United Kingdom
㏉ │ 0033C9 │ SQUARE GY │ GY │ Guyana
㏌ │ 0033CC │ SQUARE IN │ IN │ The Republic of India
㎏ │ 00338F │ SQUARE KG │ KG │ Kyrgyzstan
㎞ │ 00339E │ SQUARE KM │ KM │ Comoros
㏎ │ 0033CE │ SQUARE KM │ KM │ Comoros
㎾ │ 0033BE │ SQUARE KW │ KW │ Kuwait
㋏ │ 0032CF │ LIMITED LIABILITY SIGN │ LTD │ Binky Moon, LLC
㎃ │ 003383 │ SQUARE MA │ MA │ Morocco
� │ 01F16A │ RAISED MC SIGN │ MC │ Monaco
� │ 01F16B │ RAISED MD SIGN │ MD │ The Republic of Moldova
㎎ │ 00338E │ SQUARE MG │ MG │ Madagascar
㏕ │ 0033D5 │ SQUARE MIL │ MIL │ United States Military
㎜ │ 00339C │ SQUARE MM │ MM │ Myanmar
� │ 01F16C │ RAISED MR SIGN │ MR │ Mauritania
㎳ │ 0033B3 │ SQUARE MS │ MS │ Montserrat
㎷ │ 0033B7 │ SQUARE MV │ MV │ Maldives
㎹ │ 0033B9 │ SQUARE MV MEGA │ MV │ Maldives
� │ 01F14B │ SQUARED MV │ MV │ Maldives
㎽ │ 0033BD │ SQUARE MW │ MW │ Malawi
㎿ │ 0033BF │ SQUARE MW MEGA │ MW │ Malawi
㎁ │ 003381 │ SQUARE NA │ NA │ Namibia
㎋ │ 00338B │ SQUARE NF │ NF │ Norfolk Island
№ │ 002116 │ NUMERO SIGN │ NO │ The Kingdom of Norway
㎀ │ 003380 │ SQUARE PA AMPS │ PA │ Panama
㎩ │ 0033A9 │ SQUARE PA │ PA │ Panama
㎊ │ 00338A │ SQUARE PF │ PF │ French Polynesia
㏗ │ 0033D7 │ SQUARE PH │ PH │ The Republic of the Philippines
㏚ │ 0033DA │ SQUARE PR │ PR │ Puerto Rico (U.S.)
㎰ │ 0033B0 │ SQUARE PS │ PS │ Palestinian Territory, Occupied
㎺ │ 0033BA │ SQUARE PW │ PW │ Palau
₨ │ 0020A8 │ RUPEE SIGN │ RS │ Serbia
� │ 01F14C │ SQUARED SD │ SD │ Sudan
℠ │ 002120 │ SERVICE MARK │ SM │ San Marino
㏛ │ 0033DB │ SQUARE SR │ SR │ Suriname
� │ 01F14D │ SQUARED │ SS │ SS │ South Sudan
st │ 00FB06 │ LATIN SMALL LIGATURE ST │ ST │ Sao Tome and Principe
㏜ │ 0033DC │ SQUARE SV │ SV │ El Salvador
℡ │ 002121 │ TELEPHONE SIGN │ TEL │ Contact data
™ │ 002122 │ TRADE MARK SIGN │ TM │ Turkmenistan
Ⅵ │ 002165 │ ROMAN NUMERAL SIX │ VI │ Virgin Islands, U.S.
ⅵ │ 002175 │ SMALL ROMAN NUMERAL SIX │ VI │ Virgin Islands, U.S.
㌽ │ 00333D │ SQUARE POINTO │ ポイント │ Amazon Registry Services, Inc.
Lowercasing is not guaranteed to be stable between Unicode versions. If you're looking for stable string matching, use "case folding" instead. Instead of:
lower(a) == lower(b) // or,
lower(needle) in lower(haystack)
Use:
casefold(a) == casefold(b) // or,
casefold(needle) in casefold(haystack)
It's equivalent to lowercasing in almost all cases, but with a stability constraint between across Unicode editions. As per the Unicode stability policy [1]:
> Case folding is not the same as lowercasing, and a case-folded string is not necessarily lowercase. In particular, as of Unicode 8.0, Cherokee has become a bicameral script with the introduction of lowercase Cherokee letters, but Cherokee text case folds to the existing uppercase letters. This case folding behavior for Cherokee text is precisely to guarantee continued case folding stability.
Casing in Unicode can be tricky. The case mapping FAQ [2] is a good place to start. If you need more information, start scanning through the Core Spec and following the case-related links [3].
Oh, it can. In fact there's an entire official tome of documentation describing how to carefully do Unicode-in-URLs to reduce the risk[0]. Browsers also have some mitigations to avoid the most common issues like homoglyph attacks where they show the domain in punycode if it doesn't match some local heuristic (like if you're in en-US, it's unlikely you're actually trying to visit a site with Cyrillic letter "a" instead of ASCII "a").
It's implemented because we have thousands of writing systems and we decided, for better or worse, we want to reflect those in URLs. Solving the subsequent security issues is likely easier than getting everyone to agree to read and write the same language.
As to me I'm running my own DNS resolver (I use unbound) and everything goes through port 53 UDP (and AIUI technically 53 TCP should be allowed, but nothing will happen if you just block it), unencrypted. What then unbound does on the Internet, that's up to you: you can encrypt those requests...
The nice thing with everything being in the clear, is that you can null route / NX DOMAIN every single domain that uses Unicode (punnycode) characters and you can even do that at the firewall level, by inspecting UDP packets.
Of course you gotta be sure to really block DoH / DoT internally but it's all doable.
I set that up years ago and I've been running like that since then without any issue.
Just as entire countries's IP blocks do not exist in my world, domains using Unicode characters do not exist. And I really don't care about your feelings about it: I'm just explaining that technically it can be done to block them all and that the Internet keeps working just fine.
Unicode really is just too complex to ever be secure. And those who don't understand that are part of the problem.
Looks like HN broke the URL after submitting. Let's try again:
Here is the backup link:https://shkspr.mobi/blog/2018/11/domain-hacks-with-unusual-u...
That shows up as ₛᵖ.ⓜ, so a bunch of characters are missing.
HN seems to encode it as punycode when it shouldn’t; it skipped normalization.
Python 3 encodes the domain to xn--hkr-zdyy2ssn00g.mobi.
Not that that works.
Consider that a good thing; it seems HN is immune to Unicode confusion attacks.
Tangentially related - 20+ years ago I managed to register a π domain under one of the primary TLDs.
As in, the registration form was accepted and the fee was charged.
Then, few days after they emailed to say that "due to technical difficulties" the registration can be registered and they have no choice but to unregister it.
I was so close, damn amateurs.
My brother had a friend who tried to register fuck.com in the early days of the Internet, around 1994, and the registrar was confused and wanted to know why he wanted to register it. This was when the Internet was mostly universities and a .com cost $100 to register.
1994 they were definitely still free[1]. I had so many good ones, but when they switched to the paid model[0] I was a broke college student and let them all go.
[0] IIRC, it was Unilever who caused it -- they mailed in something like 19,000 domain registration applications, one for each of their current trademarks.
[1] OK, I looked it up, September 1995 was when the charging started.
Unilever later bought the domain substance.com from my friend. Remarkably, they apparently later let it lapse and someone else registered it. I'd assumed they were going to have a database of chemical substances that were used as ingredients, or something.
Was that friend Justin Hall of Wired?
There was a story about Jon Postel (pre-ICANN) and fuck.com, this might be it:
https://www.links.net/webpub/fuck.com.html
Maybe. That sounds like the story he told me. But now I'm wondering if I'm misremembering the friend part. Maybe he read the story when he was posted in 1997 and told me about it.
What was his response? Did they refuse to allow it?
I managed to register a one letter domain below a CC-tld, despite that country having a rule against it. Their signup form had two stages and the check was only on the first page... so all it took was changing a hidden form field.
I had it for a while until they started charging a lot for it (it was Turkmenistan).
I managed to grab a lot of really good[0] emoji domains by bouncing between registrars until you find one that has some poor (good?) coding that lets them slip through.
Then you get stuck a year later when they've upgraded their system and now nothing you do will let you renew it or transfer it...!
[0] "good" is subjective in this context
I did the same. Namecheap was the worst. They'd let me register one then refund me a few days to a week later when someone caught it. That was way worse than just saying no.
Not sure why so many things use the compatibility form of normalisation.
Some older RFCs even recommended using it for passwords, which needlessly reduces entropy (yes we need to normalise passwords because of combining characters, but we don’t need to collapse symbols that a user can choose from, like ſ and s).
In my opinion, the compatibility form makes mostly sense for searching text, and even then it’s sometimes annoying (I want to search exactly for ss and not ß, browser). If you know of other good use cases let me know.
It also OK to disallow registering two identifiers with the same compatibility normalisation form (edit: this does not prevent all homoglyph attacks BTW, that is another can of worms), but I don’t see the need to normalise the identifier when it’s used.
My favorite unicode character is zero width space. One of its funniest properties is that it's not a whitespace.
Also, some programming languages treat it as a valid identifier.
That's new
> For example, U+200B ZERO WIDTH SPACE was originally classified as a space character (General_Category=Zs), but it was reclassified as a Format character (General_Category=Cf) to clearly distinguish it from space characters in its function as a format control for line breaking.
Ha! Yes I discovered that this is true in C as part of my IOCCC entry:
https://github.com/ioccc-src/winner/blob/master/2025/ncw3/pr...
Braille Pattern Blank "⠀" (U+2800) is another one of my favourites, since it's also not considered whitespace, but it looks like it. It can actually be fairly helpful for forms that won't let you leave any field blank, since it bypasses most whitespace checks.
Indeed, the ossification of this old absurdity can be helpful, also for visual alignment within names.
This prompted me to finally dig a bit and find the official reference why they didn't fix the bug despite a plea from some Braille council
https://www.unicode.org/L2/L2025/25183-utc184-properties-rec...
> It was found that many publications that use Unicode Braille characters use U+2800 with a marking glyph. A marking space is not without precedent, consider U+1680 OGHAM SPACE MARK. However, in some cases, U+2800 is clearly used as a symbol, to indicate the presence of a space when describing a Braille sequence corresponding to a symbol or punctuation, similar to the use of ␣ (U+2423 OPEN BOX) to indicate the presence of a space. Especially in cases where it is used in a trailing position, as in the [UNE13] example, it is clear that it would be inappropriate for this symbol to disappear.
> Considering this usage as a marking symbol, together with concerns about changing the relatively stable—and often hardcoded—White_Space property (a property of only 25 code points, last changed in Unicode 6.3, when U+180E MONGOLIAN VOWEL SEPARATOR ceased to be a space), the PAG preferred a more targeted change.
This doesn't seem that unreasonable.
I use it for sites like Facebook where I want to type :) without it changing to the terrible `U+1F642 SLIGHTLY SMILING FACE` [1]. I wouldn't really mind if it were the `U+1F60A SMILING FACE WITH SMILING EYES` [2], but the first one is so laughably terrible, as if I'd really want to send an emoji to communicate a disingenuous, pained smile as a default. Some platforms let you backslash-escape sequences so they don't get turned to emoji, like \:), but for Facebook and the like, putting a ZWS in between the letters stops the conversion.
Though if your emoji is at the end of a line, it'll potentially break your emoji between the two lines. since That's what a ZWS is for, after all.
1. https://util.unicode.org/UnicodeJsps/character.jsp?a=%F0%9F%...
2. https://util.unicode.org/UnicodeJsps/character.jsp?a=1F60A&B...
I look like U+1F642 when I smile genuinely
My favorite use for it is putting it into mandatory surname fields, which sometimes works.
Try using the zero-width non-joiner instead (U+200C).
> My favorite unicode character is zero width space. One of its funniest properties is that it's not a whitespace.
My editor is configured to never show any character (except the one and proper newline) at less than the full-width of a regular character (in the monospace font I'm using ofc).
And if it's not a visible ASCII char, not only it's always shown at least at full-width, it's also shown as bold magenta on a black background. As the non visibe zero-width is empty, it shows as full-width on a black background.
Sticks out like a sore thumb.
Would you mind sharing your editor and magic recipe?
Note that, in addition to normalizing domain components, the process also maps U+3002 IDEOGRAPHIC FULL STOP (。) to U+002E FULL STOP (.) for use as a separator, a nice touch for domain names encoded in blackboard bold.
Also, the author's one-liner, updated for Python 3:
Firefox doesn't even let me open the link, wow.
Doesn't work for me in Chrome either; it transforms the URL from the top comment into https://sp.m. I believe this is the result of browser-level defenses against IDN homograph attacks, some of which postdate this article.
The URL from the top comment has been mangled by HN's "no fancy text" policy. You'll have to use the URL given in the post itself.
Same here on Firefox mobile, link is not clickable.
Same, can't open on Firefox
On Firefox, hover-over of the link doesn't show the URL in the bottom left of the browser.
I click on the link on Android Firefox and nothing happens.
Here is the URL encoded in base64 so HN does not break it:
aHR0cHM6Ly/wn4WC8J2WjfCdkKTigpvhtZbwnZKTLuKTnPCdlaDwnZKD8J2Tsi/wn4aG8J+Gg/CfhbU=
This has given me a lot of trouble with emails.
I have a domain that contains Nordic characters and it is a crapshoot if the email client will accept and send.
Meanwhile I have not encountered problems with http access.
There have been some additions since 2018 when this article was written; here is the current list, from what I can tell:
Interesting, thanks. How did you generate this list? And do you know if the lowercasing rules have ever changed between Unicode version?
Lowercasing is not guaranteed to be stable between Unicode versions. If you're looking for stable string matching, use "case folding" instead. Instead of:
Use: It's equivalent to lowercasing in almost all cases, but with a stability constraint between across Unicode editions. As per the Unicode stability policy [1]:> Case folding is not the same as lowercasing, and a case-folded string is not necessarily lowercase. In particular, as of Unicode 8.0, Cherokee has become a bicameral script with the introduction of lowercase Cherokee letters, but Cherokee text case folds to the existing uppercase letters. This case folding behavior for Cherokee text is precisely to guarantee continued case folding stability.
Casing in Unicode can be tricky. The case mapping FAQ [2] is a good place to start. If you need more information, start scanning through the Core Spec and following the case-related links [3].
1. https://www.unicode.org/policies/stability_policy.html#:~:te...
2. https://www.unicode.org/faq/casemap_charprop.html#casemap
3. https://www.unicode.org/versions/Unicode17.0.0/core-spec/cha...
I will reach out to the author of RFC 5895 to ask if they are aware if this.
You may be interested in Unicode Technical Standard #46: Unicode IDNA Compatibility Processing:
https://unicode.org/reports/tr46/
Thanks
Via <https://data.iana.org/TLD/tlds-alpha-by-domain.txt>, <https://www.unicode.org/Public/UNIDATA/UnicodeData.txt>, some Python and some regexps.
(I don’t know anything about Unicode case conversions.)
Oh, some good spots there. Thanks!
Looks like that it could be exploited by some means for nefarious purpose. I wonder why it's even implemented in the first place.
Oh, it can. In fact there's an entire official tome of documentation describing how to carefully do Unicode-in-URLs to reduce the risk[0]. Browsers also have some mitigations to avoid the most common issues like homoglyph attacks where they show the domain in punycode if it doesn't match some local heuristic (like if you're in en-US, it's unlikely you're actually trying to visit a site with Cyrillic letter "a" instead of ASCII "a").
It's implemented because we have thousands of writing systems and we decided, for better or worse, we want to reflect those in URLs. Solving the subsequent security issues is likely easier than getting everyone to agree to read and write the same language.
[0]: https://www.unicode.org/reports/tr36/tr36-10.html
> Is this useful?
No, it is not, IMHO. When you create an "alias" you are adding "yet-another-confusion-opportunity" and "yet-another-failure-opportunity".
For no actual reason.
I for one would aim at lowering the complexity, not at making stuff more fancy.
Is it too late to say most Unicode characters should not be permitted in domains?
Yes, but also wrong. Normalization like the one mentioned in the post is the mistake, not Unicode characters
My browser refuses to open this link. It couldn’t find the server.
I know it's not inclusive, but DNS should be ASCII only.
Which of course Bruce Schneier predicted in 2000:
https://www.schneier.com/crypto-gram/archives/2000/0715.html...
"Unicode is just too complex to eve be secure"
As to me I'm running my own DNS resolver (I use unbound) and everything goes through port 53 UDP (and AIUI technically 53 TCP should be allowed, but nothing will happen if you just block it), unencrypted. What then unbound does on the Internet, that's up to you: you can encrypt those requests...
The nice thing with everything being in the clear, is that you can null route / NX DOMAIN every single domain that uses Unicode (punnycode) characters and you can even do that at the firewall level, by inspecting UDP packets.
Of course you gotta be sure to really block DoH / DoT internally but it's all doable.
I set that up years ago and I've been running like that since then without any issue.
Just as entire countries's IP blocks do not exist in my world, domains using Unicode characters do not exist. And I really don't care about your feelings about it: I'm just explaining that technically it can be done to block them all and that the Internet keeps working just fine.
Unicode really is just too complex to ever be secure. And those who don't understand that are part of the problem.
Does this also allow you to work with DNS in a fully private/anonymized way?
Now, please present a list of these to your grandmother, and ask her which ones are phishing, and which are legitimately from the government.
Now, present the same list to an I.T. professional with the same questions. Perhaps make sure they are not carrying any weapons before you try.
This is just one reason why visual inspection of URLs and "hover over this link" haven't been useful defenses for a long time.
The author of the article isn't advocating for using these domains for trusted services.