8 ms·

Yeah, IDNs should have never happened. Homograph attacks alone are reason enough for IDNs to be a terrible idea, and they cannot be fully prevented even with sp

by p-e-w 4y ago

Yeah, IDNs should have never happened. Homograph attacks alone are reason enough for IDNs to be a terrible idea, and they cannot be fully prevented even with special rules, because different fonts might render distinct characters similarly that are not normally considered "homographs". I feel IDNs are part of a larger trend of "Unicode should be everywhere", without any consideration for whether this is actually a good idea. Programming languages are guilty of this too, with many allowing almost any Unicode codepoint in identifiers. This has created an entirely new class of security vulnerabilities that are serious enough that VSCode now flags such codepoints by default if they look similar to certain ASCII characters. Basic ASCII Latin characters are the only characters that can be entered using almost any input device in existence without additional tools or configuration. This makes them a universal baseline, and software should carefully consider whether deviating from that baseline is really worth the security vulnerabilities and incompatibilities it may introduce, just so people can write their source code comments in Vedic Sanskrit, for a programming language where every keyword and almost every function name is in English.

smaudet 4y ago
I will probably write a character set checker for ascii tomorrow, I agree unicode is pretty much a security vulnerability anywhere but the frontend (for non copied display). Heck, it might even be a reasonable idea to bake anti-unicode into the system (kernel) and require elevated access to process it at all in a sandbox...
Kostic 4y ago
This is a very anglo-centric view. As someone who belongs to a small nation, I'm very happy and grateful that I'm able to use my language on the Internet as much as possible.
- p-e-w 4y ago
  I'm not against Unicode in general. Text content on the Internet most definitely should support the full range of Unicode characters. But that doesn't mean domain names should, or identifiers in programming languages. Those are critical, fairly low-level technologies, and allowing all of Unicode raises significant security concerns. I strongly believe those concerns outweigh the usefulness of non-Latin characters in those contexts. The accusation of anglocentrism is unwarranted here. Every mainstream programming language ever created has all of its keywords based on the English language, including languages like Ruby and Python whose creators aren't native English speakers. This isn't anglocentric, it's a best-effort attempt to make the language as universal as possible in the world we live in. Internationalization at this level of technology simply leads to fragmentation. Domain names and programming languages are very different from user-focused free-form web content.
  - Kostic 4y ago
    I'm not debating Unicode in programming languages but in domains. Also, I disagree that domain names aren't user focused. It's the first thing you learn as a regular web user (at least that used to be the case before, now it's usually the app name).
  - mongol 4y ago
    On the contrary, the accusation is warrranted. Domain names are printed on billboards, in newspapers, shown in TV ads and a myriad other examples outside the programming domain. I have not heard anyone from a non-English speaking country argue your viewpoint.
    - p-e-w 4y ago
      > I have not heard anyone from a non-English speaking country argue your viewpoint. Well, now you have. I'm not a native English speaker and I'm not from a country where English has any official status.
      - mongol 4y ago
        What characters are present in your native language, that is not in ASCII?
        numpad0 4y ago
        Tell me how many of top 100 websites in CJK use IDN...
        bananapub 4y ago
        > What characters are present in your native language, that is not in ASCII? is that a joke? or are you really under the impression that most languages use subsets of the Latin alphabet? even English uses letters that aren't in ASCII, much less literally every other one.
        saurik 4y ago
- citrin_ru 4y ago
  As much as possible can stop short of DNS names. My native langues doesn't use a Latin (or Latin based) script and think that it is very easy to learn to type and read (but not pronounce) names written in Latin script. It doesn't require learning English as a language. Also with a push from Google (and Firefox too) most users no longer type URLs - they enter a search query and go to a site from search result. I don't like this trend but site names become increasingly invisible for users.
- silon42 4y ago
  Personally, I have disabled IDN (enabled show-punycode)... If I there was a way to just whitelist the 3 extra characters in my language, I might allow it. Also, Firefox sadly has all individual countries TLDs enabled by default if I enable the whitelist. It should be the opposite.
- the_gipsy 4y ago
  Romans want to be able to dial a phone number without being forced to translate to Arabic numerals.
  - numpad0 4y ago
    I kind of agree to that and would hope to be able to revisit it, but no earlier than a century and half later. We are not there yet by at least that much.
- soraminazuki 4y ago
  On the contrary, this is going to make URLs hard to use and would drive it to irrelevance in some countries if IDN usage becomes more common. Take CJK languages for instance. There are just so many characters that you are required to use predictive typing for every piece of text. This means that it's impossible to type CJK URLs with deterministic keypresses as you're constantly choosing suggestions which gets reordered all the time. As for the homograph problem mentioned in the article, that's not an anglo-centric fluff. It's an actual major problem that affects speakers of all languages. It hinders the ability of people to reliably type or recognize domain names. That's going to cost some people their life savings. Overall, IDNs would cause more harm than good by making URLs unreliable. It would just serve to empower search engines.
zinekeller 4y ago
Sincere question: if Russians have first made the modern computer (and therefore the de facto language of computing is Russian and Cyrillic), are you okay with only using Cyrillic as the sole script?
- p-e-w 4y ago
  > if Russians have first made the modern computer (and therefore the de facto language of computing is Russian and Cyrillic) The first part of this sentence does not imply the second. The world's first programmable computer was in fact created by a German. That doesn't make German the language of computing. > are you okay with only using Cyrillic as the sole script No, because Russian/Cyrillic lacks the properties that make English/Latin so useful as a universal language/script: * Almost all languages have widely used, standardized transliteration systems into a Latin script. That's not true for Cyrillic. * English is far more widely spoken and read than any language written in Cyrillic. * The subset of the Latin script used by English is essentially the common denominator of all languages written in Latin. That's an extremely important property and immediately predisposes English for the role it has today. There are objective arguments for English as a universal language for computing. This isn't just "cultural imperialism" or something. English is not my first language, but if I try to imagine my first language being used in its place, I immediately see dozens of serious issues that would arise, all of which are non-issues with English.
  - vore 4y ago
    I think you are doing some backwards reasoning based on the prevalence of English in computing to justify why we would only need the English alphabet. > * Almost all languages have widely used, standardized transliteration systems into a Latin script. That's not true for Cyrillic. There may be standard transliteration systems for non-English alphabet languages, but there are often multiple standard transliteration systems (e.g. Russian, Arabic). Also, Chinese transliteration is pretty gobbledygook without diacritics that aren't present in the English alphabet (and kind of gobbledygook even with diacritics). > * English is far more widely spoken and read than any language written in Cyrillic. What if the de facto language of computing was Mandarin instead? > * The subset of the Latin script used by English is essentially the common denominator of all languages written in Latin. That's an extremely important property and immediately predisposes English for the role it has today. The Latin script used by English is exactly all the letters you need to write English. Many other languages written in Latin script either have more (e.g. Spanish, Norwegian), or fewer (e.g. Italian, Serbian), or have different rules for certain things (e.g. Turkish).
bawolff 4y ago
Personally i think the unicode code point in identifiers/source code drama is silly. The attack is someone you don't trust modifies your source code, using unicode to make the modifications more subtle. What type of threat model is that? There's tons of ways for a malicious party to sabotage source code. Most are probably more subtle than unicode hacks. It is like complaining about how the person you gave a key to your house to might rob you. I do think that in a code editor already doing syntax highlighting, individual tokens should be bidi isolated so you can't have RLO and friends affecting too much, but beyond that i really think this whole issue is way overhyped.
- josephcsible 4y ago
  > There's tons of ways for a malicious party to sabotage source code. If the malicious party has unfettered write access to your source code, then sure. But if all changes get reviewed by a maintainer before being merged, then there's way fewer ways, and Unicode attacks are a really large portion of them.
- TacticalCoder 4y ago
  > There's tons of ways for a malicious party to sabotage source code. Most are probably more subtle than unicode hacks. It is like complaining about how the person you gave a key to your house to might rob you. That's not at all how the open-source world works. Many unknown (to the project maintainer) people can create pull requests and try to sneak in a backdoor through, say, an homograph attack. if ( id == "root" && some_other_condition ) Pull requests comes in: if ( id == "rοοt" && some_other_condition && some_even_better_condition ) I totally vet that! Beautiful added security measure, that "some_even_better_condition" is the nuts, nothing can go wrong: it's an added protection! I merge that ASAP and release! Except your diff tool missed that on that same line "root" was changed to "rοοt" (and the attacker created an account named "rοοt" on your website). Game over. The point is not to bitch about my pseudo-code or how account creation do work: the point is that it's easy to miss an homograph attack during a review.
  - deleted 4y ago
    [deleted]
zamadatix 4y ago
Homograph attacks are still a problem without unicode. The entire concept of "it looks like the right text to the user" is just a horrible security concept out of the gate. You want warnings on nearly identical looking tokens regardless the reason, even if it's not security related. As far as input devices have you used an IME hands on before? Non-latin characters aren't really any more "additional tools or configuration" than when during install you select "English" as your language. Others may select something like "中文(中华人民共和国)" and now without additional tools or configuration they are entering via pinyin instead of qwerty even though it's the same physical keyboard symbols being pressed. These IMEs don't always have a 1:1 latin character to unicode character mapping you can rely on either e.g. for the prior example on modern Windows the same set of latin characters can result in different outputs in a similar way to how english autocompletion suggestions on a mobile device work.
- thaumasiotes 4y ago
  > Others may select something like "中文(中华人民共和国)" and now without additional tools or configuration they are entering via pinyin instead of qwerty even though it's the same physical keyboard symbols being pressed. That doesn't work; without additional configuration you'll just end up entering the same ascii that matches the keys you press. You have to enable the IME. (In the example you appear to be suggesting, you do that by hitting shift.) You can't be in Chinese input mode all the time, because that would make it impossible to type non-Chinese text.
  - zamadatix 4y ago
    Shift will switch modes but whether you need to shift to get out of latin or vice versa depends on the context. A legacy app will almost always default to "latin, shift to pinyin" while a modern app will almost always default to "pinyin, shift to latin" - exceptions for when the app is self-aware the other input makes more sense in the context. Examples of each respectively (on the current Windows 11 at least, not sure about others) is File Explorer and the Start Menu. Regardless I don't consider this additional configuration anyways in the same way I don't consider holding shift to get capitals changing your input configuration but maybe that's just me.
klabb3 4y ago
The problem is very real, and Unicode certainly made it worse, but you can have the same issue with ascii. Capital I and l looks the same in many fonts and ad-hoc mitigations have been made long before computers (eg license plates). And you’d be surprised how few non-techies know subdomain hierarchy rules (facebook.com.foo.bar). Add stress, dyslexia, poor eye sight etc on top of those and you can see how this becomes a real issue. Humans simply aren’t very good at string equality. As for mitigations, in ascii only you could color code lowercase/uppercase/numbers/symbols differently I guess, enforce font that renders glyphs different enough (probably monospace), highlight the domain name, etc. But even these solutions only go so far, and doesn’t naturally translate to all of Unicode or all situations where identifiers are needed.
lifthrasiir 4y ago
I actually have some firsthand experience with the IDN governance (long story short, I and other people opposed a certain kind of expansion in allowed Korean domain names [1]), and I was once told that IDN basically happened because the PRC government threatened that they will make their own DNS equivalent otherwise. I don't know how much of this is true---while who said this is supposed to know what's going on, I don't know if one actually knows that---but it did sound plausible given the haste nature of IDN and subsequent measures like LGRs. [1] https://no-hanja-domain.github.io/ https://no-hanja-domain.github.io/ (in Korean)
Avamander 4y ago
This is such an American(TM) view it's incredible. People have the right to have computers work in their native language and alphabet, your input method be damned.
- burnished 4y ago
  How do you reckon that’s a right? Seems more in the realm of “reasonable desire”. And if you want to work towards fulfilling that desire then great and more power to you, seems like it’s got some big challenges.
  - Avamander 4y ago
    Because people's computers belong to them, they have the right to use them in their own native language and character set. If we look at the problem from an even larger distance, it's people's right to their culture or self-expression. If these are not reasonable rights people should have then what? In the end the anglosphere should never be able to dictate the usable charset on the entire internet. That'd be utter nonsense.
    - burnished 4y ago
      I feel like your moral outrage has sort of blinded you, did you read TFA? Talking about it in terms of rights is silly because 1) even if we agreed that it was a right it’s not something that’s being withheld, it is instead a problem no one has yet been able to solve and 2) in terms of rights everyone is already free to program in any language they want, though their choice of encoding may make interoperability with existing systems difficult
      - Symbiote 4y ago
        I think this thread isn't discussing the article, but the borderline-flamebait comment by p-e-w that "IDNs should have never happened". I find that suggestion outrageous.
1vuio0pswjnm7 4y ago
I disable Unicode at every opportunity I get to do so, because I honestly do not need it. Unicode as a "feature", especially one that adds complexity and potentially security risks, should be optional, not mandatory. IMHO. FWIW, I agree with this viewpoint 100%. Thanks for stating it so clearly.
wasmitnetzen 4y ago
I remember a radio ad (before IDN, obviously), where a company having an "ö" in their name had to repeatedly tell their customers that their domain is written "oe" instead. I'm sure this issue has cost them some real money. Domain names are nothing like programming languages.
- mongol 4y ago
  Yes it used to happen all the time and it was butchering words right and left. For someone that has no affection to their language, that may feel ok, but to me the advantages of IDN outweighs the complexity without doubt.
phendrenad2 4y ago
We don't need to throw the baby out with the bathwater here. We can have non-English domain names without the security risks. We just need to do a better job of indicating to the user that a domain name is written using, say, kanji and not ascii. Full unicode support, I.E. allowing mixed character sets in a domain name, should be disallowed, however, as displaying to the user "the first character is kanji, the rest is ascii" is too cumbersome.
- cryptonector 4y ago
  Disallowing mixed scripts in labels is not necessarily workable. Consider that in South Korea it is common to use the English "ing" gerund ending in otherwise Hangul text. That said, that would be the a very good step towards ameliorating the confusables issue in IDNs.
cryptonector 4y ago
The biggest problem with IDN is that it allows mixed script labels, but even that it kinda has to (e.g., in South Korea it's common to use the English "ing" gerund ending to alter Korean words spelled in Hangul).

by p-e-w 4y ago

smaudet 4y ago

I will probably write a character set checker for ascii tomorrow, I agree unicode is pretty much a security vulnerability anywhere but the frontend (for non copied display). Heck, it might even be a reasonable idea to bake anti-unicode into the system (kernel) and require elevated access to process it at all in a sandbox...

Kostic 4y ago

This is a very anglo-centric view. As someone who belongs to a small nation, I'm very happy and grateful that I'm able to use my language on the Internet as much as possible.

p-e-w 4y ago
I'm not against Unicode in general. Text content on the Internet most definitely should support the full range of Unicode characters. But that doesn't mean domain names should, or identifiers in programming languages. Those are critical, fairly low-level technologies, and allowing all of Unicode raises significant security concerns. I strongly believe those concerns outweigh the usefulness of non-Latin characters in those contexts. The accusation of anglocentrism is unwarranted here. Every mainstream programming language ever created has all of its keywords based on the English language, including languages like Ruby and Python whose creators aren't native English speakers. This isn't anglocentric, it's a best-effort attempt to make the language as universal as possible in the world we live in. Internationalization at this level of technology simply leads to fragmentation. Domain names and programming languages are very different from user-focused free-form web content.
- Kostic 4y ago
  I'm not debating Unicode in programming languages but in domains. Also, I disagree that domain names aren't user focused. It's the first thing you learn as a regular web user (at least that used to be the case before, now it's usually the app name).
- mongol 4y ago
  On the contrary, the accusation is warrranted. Domain names are printed on billboards, in newspapers, shown in TV ads and a myriad other examples outside the programming domain. I have not heard anyone from a non-English speaking country argue your viewpoint.
  - p-e-w 4y ago
    > I have not heard anyone from a non-English speaking country argue your viewpoint. Well, now you have. I'm not a native English speaker and I'm not from a country where English has any official status.
    - mongol 4y ago
      What characters are present in your native language, that is not in ASCII?
      - numpad0 4y ago
        Tell me how many of top 100 websites in CJK use IDN...
      - bananapub 4y ago
        > What characters are present in your native language, that is not in ASCII? is that a joke? or are you really under the impression that most languages use subsets of the Latin alphabet? even English uses letters that aren't in ASCII, much less literally every other one.
        saurik 4y ago
citrin_ru 4y ago
As much as possible can stop short of DNS names. My native langues doesn't use a Latin (or Latin based) script and think that it is very easy to learn to type and read (but not pronounce) names written in Latin script. It doesn't require learning English as a language. Also with a push from Google (and Firefox too) most users no longer type URLs - they enter a search query and go to a site from search result. I don't like this trend but site names become increasingly invisible for users.
silon42 4y ago
Personally, I have disabled IDN (enabled show-punycode)... If I there was a way to just whitelist the 3 extra characters in my language, I might allow it. Also, Firefox sadly has all individual countries TLDs enabled by default if I enable the whitelist. It should be the opposite.
the_gipsy 4y ago
Romans want to be able to dial a phone number without being forced to translate to Arabic numerals.
- numpad0 4y ago
  I kind of agree to that and would hope to be able to revisit it, but no earlier than a century and half later. We are not there yet by at least that much.
soraminazuki 4y ago
On the contrary, this is going to make URLs hard to use and would drive it to irrelevance in some countries if IDN usage becomes more common. Take CJK languages for instance. There are just so many characters that you are required to use predictive typing for every piece of text. This means that it's impossible to type CJK URLs with deterministic keypresses as you're constantly choosing suggestions which gets reordered all the time. As for the homograph problem mentioned in the article, that's not an anglo-centric fluff. It's an actual major problem that affects speakers of all languages. It hinders the ability of people to reliably type or recognize domain names. That's going to cost some people their life savings. Overall, IDNs would cause more harm than good by making URLs unreliable. It would just serve to empower search engines.

zinekeller 4y ago

Sincere question: if Russians have first made the modern computer (and therefore the de facto language of computing is Russian and Cyrillic), are you okay with only using Cyrillic as the sole script?

p-e-w 4y ago
> if Russians have first made the modern computer (and therefore the de facto language of computing is Russian and Cyrillic) The first part of this sentence does not imply the second. The world's first programmable computer was in fact created by a German. That doesn't make German the language of computing. > are you okay with only using Cyrillic as the sole script No, because Russian/Cyrillic lacks the properties that make English/Latin so useful as a universal language/script: * Almost all languages have widely used, standardized transliteration systems into a Latin script. That's not true for Cyrillic. * English is far more widely spoken and read than any language written in Cyrillic. * The subset of the Latin script used by English is essentially the common denominator of all languages written in Latin. That's an extremely important property and immediately predisposes English for the role it has today. There are objective arguments for English as a universal language for computing. This isn't just "cultural imperialism" or something. English is not my first language, but if I try to imagine my first language being used in its place, I immediately see dozens of serious issues that would arise, all of which are non-issues with English.
- vore 4y ago
  I think you are doing some backwards reasoning based on the prevalence of English in computing to justify why we would only need the English alphabet. > * Almost all languages have widely used, standardized transliteration systems into a Latin script. That's not true for Cyrillic. There may be standard transliteration systems for non-English alphabet languages, but there are often multiple standard transliteration systems (e.g. Russian, Arabic). Also, Chinese transliteration is pretty gobbledygook without diacritics that aren't present in the English alphabet (and kind of gobbledygook even with diacritics). > * English is far more widely spoken and read than any language written in Cyrillic. What if the de facto language of computing was Mandarin instead? > * The subset of the Latin script used by English is essentially the common denominator of all languages written in Latin. That's an extremely important property and immediately predisposes English for the role it has today. The Latin script used by English is exactly all the letters you need to write English. Many other languages written in Latin script either have more (e.g. Spanish, Norwegian), or fewer (e.g. Italian, Serbian), or have different rules for certain things (e.g. Turkish).

bawolff 4y ago

Personally i think the unicode code point in identifiers/source code drama is silly. The attack is someone you don't trust modifies your source code, using unicode to make the modifications more subtle. What type of threat model is that? There's tons of ways for a malicious party to sabotage source code. Most are probably more subtle than unicode hacks. It is like complaining about how the person you gave a key to your house to might rob you. I do think that in a code editor already doing syntax highlighting, individual tokens should be bidi isolated so you can't have RLO and friends affecting too much, but beyond that i really think this whole issue is way overhyped.

josephcsible 4y ago
> There's tons of ways for a malicious party to sabotage source code. If the malicious party has unfettered write access to your source code, then sure. But if all changes get reviewed by a maintainer before being merged, then there's way fewer ways, and Unicode attacks are a really large portion of them.
TacticalCoder 4y ago
> There's tons of ways for a malicious party to sabotage source code. Most are probably more subtle than unicode hacks. It is like complaining about how the person you gave a key to your house to might rob you. That's not at all how the open-source world works. Many unknown (to the project maintainer) people can create pull requests and try to sneak in a backdoor through, say, an homograph attack. if ( id == "root" && some_other_condition ) Pull requests comes in: if ( id == "rοοt" && some_other_condition && some_even_better_condition ) I totally vet that! Beautiful added security measure, that "some_even_better_condition" is the nuts, nothing can go wrong: it's an added protection! I merge that ASAP and release! Except your diff tool missed that on that same line "root" was changed to "rοοt" (and the attacker created an account named "rοοt" on your website). Game over. The point is not to bitch about my pseudo-code or how account creation do work: the point is that it's easy to miss an homograph attack during a review.
- deleted 4y ago
  [deleted]

zamadatix 4y ago

Homograph attacks are still a problem without unicode. The entire concept of "it looks like the right text to the user" is just a horrible security concept out of the gate. You want warnings on nearly identical looking tokens regardless the reason, even if it's not security related. As far as input devices have you used an IME hands on before? Non-latin characters aren't really any more "additional tools or configuration" than when during install you select "English" as your language. Others may select something like "中文(中华人民共和国)" and now without additional tools or configuration they are entering via pinyin instead of qwerty even though it's the same physical keyboard symbols being pressed. These IMEs don't always have a 1:1 latin character to unicode character mapping you can rely on either e.g. for the prior example on modern Windows the same set of latin characters can result in different outputs in a similar way to how english autocompletion suggestions on a mobile device work.

thaumasiotes 4y ago
> Others may select something like "中文(中华人民共和国)" and now without additional tools or configuration they are entering via pinyin instead of qwerty even though it's the same physical keyboard symbols being pressed. That doesn't work; without additional configuration you'll just end up entering the same ascii that matches the keys you press. You have to enable the IME. (In the example you appear to be suggesting, you do that by hitting shift.) You can't be in Chinese input mode all the time, because that would make it impossible to type non-Chinese text.
- zamadatix 4y ago
  Shift will switch modes but whether you need to shift to get out of latin or vice versa depends on the context. A legacy app will almost always default to "latin, shift to pinyin" while a modern app will almost always default to "pinyin, shift to latin" - exceptions for when the app is self-aware the other input makes more sense in the context. Examples of each respectively (on the current Windows 11 at least, not sure about others) is File Explorer and the Start Menu. Regardless I don't consider this additional configuration anyways in the same way I don't consider holding shift to get capitals changing your input configuration but maybe that's just me.

klabb3 4y ago

The problem is very real, and Unicode certainly made it worse, but you can have the same issue with ascii. Capital I and l looks the same in many fonts and ad-hoc mitigations have been made long before computers (eg license plates). And you’d be surprised how few non-techies know subdomain hierarchy rules (facebook.com.foo.bar). Add stress, dyslexia, poor eye sight etc on top of those and you can see how this becomes a real issue. Humans simply aren’t very good at string equality. As for mitigations, in ascii only you could color code lowercase/uppercase/numbers/symbols differently I guess, enforce font that renders glyphs different enough (probably monospace), highlight the domain name, etc. But even these solutions only go so far, and doesn’t naturally translate to all of Unicode or all situations where identifiers are needed.

lifthrasiir 4y ago

I actually have some firsthand experience with the IDN governance (long story short, I and other people opposed a certain kind of expansion in allowed Korean domain names [1]), and I was once told that IDN basically happened because the PRC government threatened that they will make their own DNS equivalent otherwise. I don't know how much of this is true---while who said this is supposed to know what's going on, I don't know if one actually knows that---but it did sound plausible given the haste nature of IDN and subsequent measures like LGRs. [1] https://no-hanja-domain.github.io/ https://no-hanja-domain.github.io/ (in Korean)

Avamander 4y ago

This is such an American(TM) view it's incredible. People have the right to have computers work in their native language and alphabet, your input method be damned.

burnished 4y ago
How do you reckon that’s a right? Seems more in the realm of “reasonable desire”. And if you want to work towards fulfilling that desire then great and more power to you, seems like it’s got some big challenges.
- Avamander 4y ago
  Because people's computers belong to them, they have the right to use them in their own native language and character set. If we look at the problem from an even larger distance, it's people's right to their culture or self-expression. If these are not reasonable rights people should have then what? In the end the anglosphere should never be able to dictate the usable charset on the entire internet. That'd be utter nonsense.
  - burnished 4y ago
    I feel like your moral outrage has sort of blinded you, did you read TFA? Talking about it in terms of rights is silly because 1) even if we agreed that it was a right it’s not something that’s being withheld, it is instead a problem no one has yet been able to solve and 2) in terms of rights everyone is already free to program in any language they want, though their choice of encoding may make interoperability with existing systems difficult
    - Symbiote 4y ago
      I think this thread isn't discussing the article, but the borderline-flamebait comment by p-e-w that "IDNs should have never happened". I find that suggestion outrageous.

1vuio0pswjnm7 4y ago

I disable Unicode at every opportunity I get to do so, because I honestly do not need it. Unicode as a "feature", especially one that adds complexity and potentially security risks, should be optional, not mandatory. IMHO. FWIW, I agree with this viewpoint 100%. Thanks for stating it so clearly.

wasmitnetzen 4y ago

I remember a radio ad (before IDN, obviously), where a company having an "ö" in their name had to repeatedly tell their customers that their domain is written "oe" instead. I'm sure this issue has cost them some real money. Domain names are nothing like programming languages.

mongol 4y ago
Yes it used to happen all the time and it was butchering words right and left. For someone that has no affection to their language, that may feel ok, but to me the advantages of IDN outweighs the complexity without doubt.

phendrenad2 4y ago

We don't need to throw the baby out with the bathwater here. We can have non-English domain names without the security risks. We just need to do a better job of indicating to the user that a domain name is written using, say, kanji and not ascii. Full unicode support, I.E. allowing mixed character sets in a domain name, should be disallowed, however, as displaying to the user "the first character is kanji, the rest is ascii" is too cumbersome.

cryptonector 4y ago
Disallowing mixed scripts in labels is not necessarily workable. Consider that in South Korea it is common to use the English "ing" gerund ending in otherwise Hangul text. That said, that would be the a very good step towards ameliorating the confusables issue in IDNs.

cryptonector 4y ago

The biggest problem with IDN is that it allows mixed script labels, but even that it kinda has to (e.g., in South Korea it's common to use the English "ing" gerund ending to alter Korean words spelled in Hangul).