6 ms·

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 ther

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 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.

fermienrico 9y ago
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.
- ta8374477 9y ago
  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.
  - tonyhb 9y ago
    Say, for example, the base 58 character set used by bitcoin.
  - asher 9y ago
    Related: https://pypi.python.org/pypi/idgen/0.0.1 https://pypi.python.org/pypi/idgen/0.0.1 That's one way to ensure safety of domain names, at the cost of mnemonics ;)
- repiret 9y ago
  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.
  - mcny 9y ago
    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.
    - fermienrico 9y ago
      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.
daurnimator 9y ago
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-registry-products/idn/idn-policy/registration-rules/index.xhtml https://www.verisign.com/en_IN/channel-resources/domain-regi... or https://eurid.eu/en/register-a-eu-domain/domain-names-with-special-characters-idns/ 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-abe7-947d235f25b1/idna2008and_homoglyph_bundling_tables.pdf https://eurid.eu/media/filer_public/8d/18/8d18473b-ed9b-4fba...
- CydeWeys 9y ago
  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/registry/idn/Latin-IDN.txt https://github.com/google/nomulus/blob/master/java/google/re...
frobozz 9y ago
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.
- vostok 9y ago
  I'm not sure it would help that much. For example pop.ru and рор.ru look identical to my eyes in my current font.
  - baby 9y ago
    same thing with google.com and google.com
  - frobozz 9y ago
    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.
    - rspeer 9y ago
      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).
      - frobozz 9y ago
        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).
simias 9y ago
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.

fermienrico 9y ago

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.

ta8374477 9y ago
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.
- tonyhb 9y ago
  Say, for example, the base 58 character set used by bitcoin.
- asher 9y ago
  Related: https://pypi.python.org/pypi/idgen/0.0.1 https://pypi.python.org/pypi/idgen/0.0.1 That's one way to ensure safety of domain names, at the cost of mnemonics ;)
repiret 9y ago
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.
- mcny 9y ago
  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.
  - fermienrico 9y ago
    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.

daurnimator 9y ago

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-registry-products/idn/idn-policy/registration-rules/index.xhtml https://www.verisign.com/en_IN/channel-resources/domain-regi... or https://eurid.eu/en/register-a-eu-domain/domain-names-with-special-characters-idns/ 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-abe7-947d235f25b1/idna2008and_homoglyph_bundling_tables.pdf https://eurid.eu/media/filer_public/8d/18/8d18473b-ed9b-4fba...

CydeWeys 9y ago
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/registry/idn/Latin-IDN.txt https://github.com/google/nomulus/blob/master/java/google/re...

frobozz 9y ago

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.

vostok 9y ago
I'm not sure it would help that much. For example pop.ru and рор.ru look identical to my eyes in my current font.
- baby 9y ago
  same thing with google.com and google.com
- frobozz 9y ago
  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.
  - rspeer 9y ago
    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).
    - frobozz 9y ago
      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).

simias 9y ago

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.