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.
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...!
> 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.
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.
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.
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, but I don’t see the need to normalise the identifier when it’s used.
There have been some additions since 2018 when this article was
written; here is the current list, from what I can tell:
㎝ 00339D SQUARE CM CM Cameroon
㏌ 0033CC SQUARE IN IN The Republic of India
㏄ 0033C4 SQUARE CC CC Cocos (Keeling) Islands
01F190 SQUARE DJ DJ Djibouti
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
℠ 002120 SERVICE MARK SM San Marino
㎺ 0033BA SQUARE PW PW Palau
㎊ 00338A SQUARE PF PF French Polynesia
№ 002116 NUMERO SIGN NO The Kingdom of Norway
㍷ 003377 SQUARE DM DM Dominica
㏿ 0033FF SQUARE GAL GAL Galicia, Spain
㎜ 00339C SQUARE MM MM Myanmar
Ⅵ 002165 ROMAN NUMERAL SIX VI Virgin Islands, U.S.
ⅵ 002175 SMALL ROMAN NUMERAL SIX VI Virgin Islands, U.S.
㏛ 0033DB SQUARE SR SR Suriname
㎏ 00338F SQUARE KG KG Kyrgyzstan
℡ 002121 TELEPHONE SIGN TEL Contact data
㎈ 003388 SQUARE CAL CAL Google
㎰ 0033B0 SQUARE PS PS Palestinian Territory, Occupied
㏕ 0033D5 SQUARE MIL MIL United States Military
01F14D SQUARED SS SS South Sudan
㎞ 00339E SQUARE KM KM Comoros
㏎ 0033CE SQUARE KM CAPITAL KM Comoros
㏜ 0033DC SQUARE SV SV El Salvador
㎀ 003380 SQUARE PA AMPS PA Panama
㎩ 0033A9 SQUARE PA PA Panama
₨ 0020A8 RUPEE SIGN RS Serbia
㎁ 003381 SQUARE NA NA Namibia
㏅ 0033C5 SQUARE CD CD The Democratic Republic of the Congo
01F12D CIRCLED CD CD The Democratic Republic of the Congo
st 00FB06 LATIN SMALL LIGATURE ST ST Sao Tome and Principe
㏚ 0033DA SQUARE PR PR Puerto Rico (U.S.)
01F14C SQUARED SD SD Sudan
㎽ 0033BD SQUARE MW MW Malawi
㎿ 0033BF SQUARE MW MEGA MW Malawi
01F16B RAISED MD SIGN MD The Republic of Moldova
㍳ 003373 SQUARE AU AU Australia
㎙ 003399 SQUARE FM FM Federated States of Micronesia
㎇ 003387 SQUARE GB GB United Kingdom
㎷ 0033B7 SQUARE MV MV Maldives
㎹ 0033B9 SQUARE MV MEGA MV Maldives
01F14B SQUARED MV MV Maldives
㋏ 0032CF LIMITED LIABILITY SIGN LTD Binky Moon, LLC
01F16A RAISED MC SIGN MC Monaco
fi 00FB01 LATIN SMALL LIGATURE FI FI The Republic of Finland
01F16C RAISED MR SIGN MR Mauritania
㎃ 003383 SQUARE MA MA Morocco
㎾ 0033BE SQUARE KW KW Kuwait
㏉ 0033C9 SQUARE GY GY Guyana
㎎ 00338E SQUARE MG MG Madagascar
㏗ 0033D7 SQUARE PH PH The Republic of the Philippines
㎳ 0033B3 SQUARE MS MS Montserrat
㎋ 00338B SQUARE NF NF Norfolk Island
™ 002122 TRADE MARK SIGN TM Turkmenistan
㌽ 00333D SQUARE POINTO XN--ECKVDTC9D Amazon Registry Services, Inc.
㍴ 003374 SQUARE BAR BAR Bar, Punto 2012 Sociedad Anonima Promotora de Inversion de Capital Variable
33 comments
[ 5.0 ms ] story [ 45.3 ms ] threadhttps://shkspr.mobi/blog/2018/11/domain-hacks-with-unusual-u...
HN seems to encode it as punycode when it shouldn’t; it skipped normalization.
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.
There was a story about Jon Postel (pre-ICANN) and fuck.com, this might be it:
https://www.links.net/webpub/fuck.com.html
[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.
I had it for a while until they started charging a lot for it (it was Turkmenistan).
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
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.
what are grandmothers even doing on the internet, theres dangerous viruses and worms on there!
Also, some programming languages treat it as a valid identifier.
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.
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.
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.
aHR0cHM6Ly/wn4WC8J2WjfCdkKTigpvhtZbwnZKTLuKTnPCdlaDwnZKD8J2Tsi/wn4aG8J+Gg/CfhbU=
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
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, but I don’t see the need to normalise the identifier when it’s used.