3 ms·
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 sai
by 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 agoIf 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 agoWhy 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.