3 ms·

> Assuming that every language Oof. Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" de

by hnfong 3y ago

> Assuming that every language Oof. Take for example, both 糉 and 糭 are valid characters in Chinese. One is a variant of the other. Which one is "canonical" depends on who (i.e. which authority, of which there are many) you ask. And FWIW the language and regional settings don't necessarily give an answer to the canonical representation. Those characters mean the same thing with or without the specks of dust. So, what's your solution here? To be fair, Unicode domains are inherently a huge mess. The thing is that we don't need more armchair experts dreaming up Euro-centric solutions.

necovek 3y ago
It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts. But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.
- hnfong 3y ago
  > while they might still fall for malicious URLs in their own language, they would not for other scripts. That's totally backwards. If the assumption is that users of language X will legitimately visit sites of language Y with sufficient frequency, then all that language-specific filtering makes no sense.
  - necovek 3y ago
    If a browser implements single language decode-punycode, they could also support user specifying multiple languages (like they do for Accept-Language). And seeing punycode in URL bar does not mean a site does not work, it's only a suboptimal experience.
  - matrss 3y ago
    Why wouldn't it make sense? If a chinese user e.g. specifies that they speak chinese and, say, french, all characters in those two language would show up as unicode and everything else as punycode. A malicious domain using e.g. cyrillic characters to create a domain that looks just like another french (or just plain-ASCII) one would show up as punycode. Sounds like a net improvement over what we have now.
matrss 3y ago
What you mention here does not contradict my assumption that there is a finite set of valid characters in every language, unless there is a rule in chinese that lets you assemble an infinite set of meaningful characters/symbols (unicode could still represent only a finite subset of those, though). Either one or both of the characters you mention are probably part of the script of the users language setting in chinese; if the character is then it should be rendered as unicode and if not as punycode. If the users language has this kind of ambiguity then they are the only ones to judge if the domain name is correct or not, but at least they are familiar with the language and do not see characters they might have never encountered before and/or need to deal with an ambiguity that they shouldn't even have to expect to begin with. The idea I proposed would still protect someone with a chinese language setting from being tricked by e.g. a cyrillic character in an otherwise ASCII domain name. I don't see how that is euro-centric (apart from ASCII being inherently english-centric), it is an overall improvement over the status quo no matter where you live and what language you speak.

by hnfong 3y ago

necovek 3y ago

It still sounds like an improvement: while they might still fall for malicious URLs in their own language, they would not for other scripts. But as someone said, tiny, valid differences are easy to miss anyway, and original URL attacks were replacing similar-looking ASCII graphemes (eg. l for 1), so this will all continue.

hnfong 3y ago
> while they might still fall for malicious URLs in their own language, they would not for other scripts. That's totally backwards. If the assumption is that users of language X will legitimately visit sites of language Y with sufficient frequency, then all that language-specific filtering makes no sense.
- necovek 3y ago
  If a browser implements single language decode-punycode, they could also support user specifying multiple languages (like they do for Accept-Language). And seeing punycode in URL bar does not mean a site does not work, it's only a suboptimal experience.
- matrss 3y ago
  Why wouldn't it make sense? If a chinese user e.g. specifies that they speak chinese and, say, french, all characters in those two language would show up as unicode and everything else as punycode. A malicious domain using e.g. cyrillic characters to create a domain that looks just like another french (or just plain-ASCII) one would show up as punycode. Sounds like a net improvement over what we have now.

matrss 3y ago

What you mention here does not contradict my assumption that there is a finite set of valid characters in every language, unless there is a rule in chinese that lets you assemble an infinite set of meaningful characters/symbols (unicode could still represent only a finite subset of those, though). Either one or both of the characters you mention are probably part of the script of the users language setting in chinese; if the character is then it should be rendered as unicode and if not as punycode. If the users language has this kind of ambiguity then they are the only ones to judge if the domain name is correct or not, but at least they are familiar with the language and do not see characters they might have never encountered before and/or need to deal with an ambiguity that they shouldn't even have to expect to begin with. The idea I proposed would still protect someone with a chinese language setting from being tricked by e.g. a cyrillic character in an otherwise ASCII domain name. I don't see how that is euro-centric (apart from ASCII being inherently english-centric), it is an overall improvement over the status quo no matter where you live and what language you speak.