Comment by repiret | Hacker News Reader

Comment by repiret | Hacker News Reader

Several years ago I read [1] a proposal for internationalized domain names from DJ Bernstein from before puny-code took hold. The key observation was that there's nothing stopping you from just using UTF-8 in the existing DNS protocols, but it included a discussion of how to treat visually indistinguishable unicode characters to prevent fraud, which is why I bring it up now:

The proposal was that the TLD administrators should whitelist in non-ASCII characters and generally require that domains are either entirely ASCII or entirely in a subset of Unicode that made sense for their native languages - .ru could allow all-ASCII or all-Cyrillic, .gr could require all-ASCII or all-Greek, .de could allow ASCII plus eszett and the umlauts, and could further require normalized encoding (ü must be FC and not CC 88 75) and consider ö.de and oe.de to be collisions [2], and so on. Weird varieties of spaces, dashes, non-printing characters, accents that are only needed to type Klingon, and so on would never get whitelisted in.

I've always thought that was a great idea, and its a general principal App stores could use too. (Although I realize that app stores don't have as strong a concept of a native language as most TLDs do, which makes it a bit harder)

[1]: Its possible it was https://cr.yp.to/djbdns/idn.html, but I'm not convinced. Maybe it was an earlier revision.

[2]: In German, you spell "ö" as "oe" if you don't have an ö key. German speakers wouldn't necessarily need "ö" and "o" to be collisions.

This is an awful idea that conflates country and language and adds another place where governments can marginalise minorities. Should administrators of north African tlds be empowered to forbid Tifinagh characters?

Which character sets should be permitted in the .US tld?

The general principal of all ascii or all something else is not bad though. It would prevent certain homograph spoofs.

I'm not sure it would help that much. For example pop.ru and рор.ru look identical to my eyes in my current font.

Yes it's not bad but not great either. It would only help in certain situations (hello vs Ꮒello). It also becomes tricky if you permit Turkish, as you would have to allow mixing of ascii and the dotted vs dotless i.

There are also good reasons to mix language in a name. US state abbreviations might be used to distinguish (e.g.) a diaspora community in Texas from their equivalent in Alaska.

Dotted and dotless i is a different issue, related to capitalization. Those are still Latin letters. Of course to support most European languages you have to be able to use ASCII and non-ASCII Latin letters together. That's not unique to Turkish.

Think of the Spanish word "cañon", for example. It's not four English letters and one Spanish letter, it's just five Latin letters (four of which are in ASCII).

There is a difference between ı and i in both cases. I don't know what you mean by 'related to capitalisation'

The reason I raise Turkish specifically is that the similarity between the characters presents a potential homograph for a phishing attack in non-Turkish domains. (e.g. mıcrosoft.com). Characters with apparent diacritics are less vulnerable (e.g. öracle.com).

There was an example where еріс.com (whose domain is in the Ukrainian Cyrillic alphabet, and I think would be pronounced like "eris dot com") once got a security certificate that would be visually indistinguishable from one for epic.com. This was, thankfully, intended by its creator to demonstrate the vulnerability.

The certificate has expired now, and additionally, browsers now show it as https://www.xn--e1awd7f.com/ . Even HN rewrites it if I type it as a full URL in Unicode, actually.

same thing with google.com and google.com

I would say yes, otherwise we're stuck with enumerating and testing innumerable edge cases.

Uh, you can just do two things. Prohibit mixing of character blocks. That is sane and would prevent many incidents.

Edit: As for homoglyph bundles, you just have to do it like EURid and create tables.

But the main protective layer would be the user interface, similar to how HTTPS is handled, either descriptively, with warning colors or both.

This is what happens today with international domains.

Different TLDs whitelist different code pages/codepoints as allowed under their domains. See e.g. https://www.verisign.com/en_IN/channel-resources/domain-regi... or https://eurid.eu/en/register-a-eu-domain/domain-names-with-s... and the linked https://eurid.eu/media/filer_public/8d/18/8d18473b-ed9b-4fba...

Yes. I don't recall the details but I think it's required by ICANN. We (Google Registry) support extended Latin and Japanese codebases, and since the registry software that we've written is Free Software, you can see our implementation, e.g. here's extended Latin: https://github.com/google/nomulus/blob/master/java/google/re...

Would that really help when .com is the most popular gTLD, followed by .org? Being international I'm not sure how you could restrict the charset here.

This is a horrendous idea.

What's to say, 0 and o can be mixed up and ban that too? How would you handle gray areas? Determining what's fishy and what's not is not a matter of black and white. What if you have a German name and want to set up a site in India with ö.in? This idea creates more problems than it solves.

Policing/banning is never a good idea. Internet freedom is way more important than phishing attemps.

Let's ban everything because anything can be phished if you're smart enough.

It is certainly not a horrendous idea; it is commonly used for serial numbers in engineering. For example a part number would have a serial number that is a subset of A-Z, skipping the easily ambiguous O,I and similar.

Say, for example, the base 58 character set used by bitcoin.

Related: https://pypi.python.org/pypi/idgen/0.0.1

That's one way to ensure safety of domain names, at the cost of mnemonics ;)

Respectfully, I disagree with the absolutist view that policing and banning is /never/ a good idea. Phishing is rightfully unlawful, and its wholly appropriate for the mechanisms of society to fight against it.

There is a balance to be made for sure, but in the case of both domain and app names, I'd argue that the harms from fishing outweigh the freedom of expression conferred by being able to register "Αpple.com". While the names of things do carry some expression, things have names primarily so you can tell them apart. Its a well settled moral principal that we should have rules to preserve the utility of names as monikers, and that its entirely possible to construct rules for that purpose that have a negligible effect on freedom of expression. If you disagree, then show me the developed country that decided it didn't need a trademark law.

Your hypothetical German expat in India is welcome to try to convince the Indian authorities that the ability to register können.in outweighs the value in preventing amazön.in from being registered. Maybe there are more Germans in India than I know, or maybe phishing causes less economic harm in India than it does in the US.

App store names are harder, because you don't have TLDs giving you a hint to what language(s) most of your users speak. But you can still disallow mixing of Latin, Green and Cyrillic alphabets; you can still say that if you are going to use the crazy accents used in Vietnamese, that you can't also use umlauts; you can still whitelist unicode characters as needed, so that you don't have a dozen different spaces and dashes for no reason; you can still use other signals to give language hints. And as it turns out, most people running app stores have a large pile of money they can use to curate and maintain good automated rules, and hire people to manually audit names when the automated heuristics think its fishy but not fishy enough to automatically disallow, or in response to complaints.

The explosion of TLD s shows they don't care about us. I cannot in good faith put trust in them. I don't know what a solution is but this is not it.

Explosion of TLD was such a lucrative move, they couldn’t resist!

See, this is another problem. Once you have a phishing blacklist, some entity with big enough pockets will just start influencing the DNS system. It would be a slippery slope going straight to dystopia.

Thanks for a detailed response but I still think it’s a bad idea on principle as you’re bestowing authority to some organization that needs to be funded, organized, maintained and skilled to keep track of these rules.

Soon, it will become a giant mess and regulation will impede regular companies/people that would question “Who put these rules together? Our domain doesn’t happen to be fishy”.

Furthermore, how important of a name does it have to be for adding it to these automated rules? How do you quantify that?

Even in an ideal perfect world, I wouldn’t want to sacrifice internet freedom for phishing attempts. DNS is a huge part of the internet whereas phishing costs are neglible.

Every time someone brings an idea about regulating the internet, I just get a repulsive feeling. Stop trying to fuck with the internet. The EFF is not enough.

Isn’t Google Chrome and other browsers already doing this? Phishy websites get tagged and there is a big red screen that shows up - most importantly - allowing users to bypass it if needed. There are times when legit but old websites get banned by these Phishing blockers. I think the solution needs to be more “local” than something on a grand global scale.

Reply on news.ycombinator.com