5 ms·

Until we can figure out something that doesn't suck, yes. Look, I'm sympathetic with a huge chunk of the world's population having to deal with a (potentially)

Until we can figure out something that doesn't suck, yes. Look, I'm sympathetic with a huge chunk of the world's population having to deal with a (potentially) unfamiliar character set, but what can you do about it? There has to be some standard that everyone can agree to which doesn't compromise the integrity of the net.

jawns 13y ago
This might at first sound like a xenophobic, anglocentric position, but it actually makes quite a bit of sense. There are a number of instances in which it is advantageous / critical to adopt a lingua franca -- that is, a single language that everyone in the world agrees to use for a particular purpose. In the case of domain names, Patrick is right: If we allow characters that appear to be one thing but are actually another, it opens up a whole bunch of evil possibilities.
- mtrimpe 13y ago
  There is some middle ground between opening up all of UniCode and just Latin characters. It seems that generally a subset of sufficiently distinct characters should mostly suffice. I don't think e.g. Latin, Hebrew and Chinese have much visual overlap.
  - b3n 13y ago
    This is already a solved problem in every major browser. They will show mixed script domains as punycode instead of their unicode equivalent[1][2]. ICANN does not even allow all unicode characters[3]. There's so much FUD going around. [1] http://www.chromium.org/developers/design-documents/idn-in-google-chrome http://www.chromium.org/developers/design-documents/idn-in-g... [2] http://www.mozilla.org/en-US/about/governance/policies/security-group/tld-idn/ http://www.mozilla.org/en-US/about/governance/policies/secur... [3] https://tools.ietf.org/html/rfc5892 https://tools.ietf.org/html/rfc5892
    - Patrick_Devine 13y ago
      Great links. I'm not sure I'd go so far as to say it's a "solved problem" when there are four different behaviours from four separate browsers, but I'm glad each browser is taking homograph attacks seriously. In the first link, I compared Chrome and Firefox and they do work differently.
- jessedhillon 13y ago
  Couldn't this also be mitigated by making all domains mandatorily delegated from a national ccTLD? Eliminate/redirect apple.com to apple.com.us, then make sure it conforms to the rules for US domains (Latin character set only, etc) whereas apple.com.ru comes under the rules of the Russian registrar?
  - VMG 13y ago
    I prefer an unfractioned internet
    - mjolk 13y ago
      That's not fractioned. Are you being flippant?
  - mjolk 13y ago
    I like this solution. However, ICANN already made profit on .us/.ru domains, when I really think that they should have come as 'free' suffixes to registrations. e.g. I buy 'apple.com' and while if I want to leave it as this, fine. However, I should also have 'apple.com.us' and 'apple.com.ru' so that I can handle these appropriately. It's not perfect, but it at least gives my users a chance to say "hey, I probably prefer (english|russian), so please give me that page." Of course, this is also a bit lazy and somewhat of a non-solution, as this only addresses the issue for English speakers. A russian speaker using the .ru namespace is already willing to "play by the ascii rules." People going to 'apple.com' really expect to go to the webpage of the American electronics company. One could assume this by the TLD. Users sending a request to 'apple.рф' would be doing something somewhat strange (user sends english base label, followed by a cyrillic tld). This isn't that absurd though, as english company names become loanwords (at least in russian -- see "xerox" or even ask a russian if he owns a 'yabloko makkniga pro' or an 'apple macbook pro' for example). Should the presence of a non-unicode TLD trigger country-specific mode in browsers for the sake of security? How do we handle loanwords (spoiler to above: russians say 'apple' when referring to the brand, even though it shadows the actual Russian word for apple) with non-ascii TLDs?
    - 13y ago
mjolk 13y ago
> I'm sympathetic with a huge chunk of the world's population having to deal with a (potentially) unfamiliar character set, but what can you do about it? Well, seeing as that "huge chunk" is a large majority, then the solution isn't "learn english because I'm used to typing URLs _this_ way." I understand that English is the current lingua franca, but it's aggressive to expect everyone to deal with it just to use the internet. Why not use our country tlds? It might mean that ICANN has to actually do some work, but I think that the uppermost tld for countries should actually be reserved for suffixes. e.g. apple.us #should have never been sold apple.com.us #there, none of that scary unicode apple.com.ru #same unicode problem abound (but at least it addresses the first issue)
- lukehorvat 13y ago
  Who says you have to learn English?
nettletea 13y ago
Punycode.

jawns 13y ago

This might at first sound like a xenophobic, anglocentric position, but it actually makes quite a bit of sense. There are a number of instances in which it is advantageous / critical to adopt a lingua franca -- that is, a single language that everyone in the world agrees to use for a particular purpose. In the case of domain names, Patrick is right: If we allow characters that appear to be one thing but are actually another, it opens up a whole bunch of evil possibilities.

mtrimpe 13y ago
There is some middle ground between opening up all of UniCode and just Latin characters. It seems that generally a subset of sufficiently distinct characters should mostly suffice. I don't think e.g. Latin, Hebrew and Chinese have much visual overlap.
- b3n 13y ago
  This is already a solved problem in every major browser. They will show mixed script domains as punycode instead of their unicode equivalent[1][2]. ICANN does not even allow all unicode characters[3]. There's so much FUD going around. [1] http://www.chromium.org/developers/design-documents/idn-in-google-chrome http://www.chromium.org/developers/design-documents/idn-in-g... [2] http://www.mozilla.org/en-US/about/governance/policies/security-group/tld-idn/ http://www.mozilla.org/en-US/about/governance/policies/secur... [3] https://tools.ietf.org/html/rfc5892 https://tools.ietf.org/html/rfc5892
  - Patrick_Devine 13y ago
    Great links. I'm not sure I'd go so far as to say it's a "solved problem" when there are four different behaviours from four separate browsers, but I'm glad each browser is taking homograph attacks seriously. In the first link, I compared Chrome and Firefox and they do work differently.
jessedhillon 13y ago
Couldn't this also be mitigated by making all domains mandatorily delegated from a national ccTLD? Eliminate/redirect apple.com to apple.com.us, then make sure it conforms to the rules for US domains (Latin character set only, etc) whereas apple.com.ru comes under the rules of the Russian registrar?
- VMG 13y ago
  I prefer an unfractioned internet
  - mjolk 13y ago
    That's not fractioned. Are you being flippant?
- mjolk 13y ago
  I like this solution. However, ICANN already made profit on .us/.ru domains, when I really think that they should have come as 'free' suffixes to registrations. e.g. I buy 'apple.com' and while if I want to leave it as this, fine. However, I should also have 'apple.com.us' and 'apple.com.ru' so that I can handle these appropriately. It's not perfect, but it at least gives my users a chance to say "hey, I probably prefer (english|russian), so please give me that page." Of course, this is also a bit lazy and somewhat of a non-solution, as this only addresses the issue for English speakers. A russian speaker using the .ru namespace is already willing to "play by the ascii rules." People going to 'apple.com' really expect to go to the webpage of the American electronics company. One could assume this by the TLD. Users sending a request to 'apple.рф' would be doing something somewhat strange (user sends english base label, followed by a cyrillic tld). This isn't that absurd though, as english company names become loanwords (at least in russian -- see "xerox" or even ask a russian if he owns a 'yabloko makkniga pro' or an 'apple macbook pro' for example). Should the presence of a non-unicode TLD trigger country-specific mode in browsers for the sake of security? How do we handle loanwords (spoiler to above: russians say 'apple' when referring to the brand, even though it shadows the actual Russian word for apple) with non-ascii TLDs?
  - 13y ago

mjolk 13y ago

> I'm sympathetic with a huge chunk of the world's population having to deal with a (potentially) unfamiliar character set, but what can you do about it? Well, seeing as that "huge chunk" is a large majority, then the solution isn't "learn english because I'm used to typing URLs _this_ way." I understand that English is the current lingua franca, but it's aggressive to expect everyone to deal with it just to use the internet. Why not use our country tlds? It might mean that ICANN has to actually do some work, but I think that the uppermost tld for countries should actually be reserved for suffixes. e.g. apple.us #should have never been sold apple.com.us #there, none of that scary unicode apple.com.ru #same unicode problem abound (but at least it addresses the first issue)

lukehorvat 13y ago
Who says you have to learn English?

nettletea 13y ago

Punycode.