4 ms·
This problem was largely "solved" years ago, when browsers, email clients, and major social networking platforms started showing the punycode representation of
by envy2 10y ago
This problem was largely "solved" years ago, when browsers, email clients, and major social networking platforms started showing the punycode representation of IDNs.
- arm 10y agoWhile that is the case for many programs, it’s absolutely not the case for modern web browsers. For example, navigating to はじめよう.みんな¹ in Safari 9² and Firefox 46³ does show the IDN as it’s supposed to look to the end user in the address bar. (Of course, internally, it’s still represented as an ASCII string (using Punycode⁴)). ―――――― ¹ — http://はじめよう.みんな/ http://はじめよう.みんな/ ² — http://i.imgur.com/KX5i9aW.png http://i.imgur.com/KX5i9aW.png ³ — http://i.imgur.com/7WVeypl.png http://i.imgur.com/7WVeypl.png ⁴ — https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode
- sdkmvx 10y agoI always set network.IDN_show_punycode to true in Firefox to force it to show me ASCII. Perhaps I'd feel differently if I spoke another language, but as it is, the risk of lookalike characters is too great to allow them to display.
- deleted 10y ago[deleted]
- bandrami 10y agoI haven't particularly studied punycode, but since I first heard of it I keep thinking that it at least seems like it mitigates one set of collisions by allowing a different set of collisions. I mean, it seems unlikely someone would want the domain Mnchen-3ya.com, but wouldn't the city of München still be able to impersonate that person?
- arm 10y agoWould that be a collision though? xn--mnchen-3ya.com and mnchen-3ya.com look pretty different.