4 ms·

I fully support national languages, ASCII is not suitable for a huge part of mankind. But it's obvious that Unicode as it is is not suitable for security critic

I fully support national languages, ASCII is not suitable for a huge part of mankind. But it's obvious that Unicode as it is is not suitable for security critical applications. Myself, speaking several European languages, I need less than 10 Unicode characters (each of them actually still 8 bit ISO 8859-15 codes). Well, need and need, most of the sites don't even register a punycode domain, but some uglified ASCII version of their name. As a practical step browsers should ask the user whether they want to allow URLs in a certain language the first time a non-ASCII character is entered. With just one or a couple of languages allowed, the attack surface would be drastically reduced for most users.

noirscape 3y ago
Agreed on ASCII not being suitable for a huge chunk of mankind for messaging. That said, in lieu of a better defined set of characters, it is a reliable set of characters that largely don't overlap when it comes to homograph attacks on human readable identifiers. The only single character ones in ASCII with noticable issues are 0/O and I/l/1 (this is also why on latin alphabet gift cards, you'll often see these characters omitted entirely). The other homograph attacks on ASCII are mostly font kerning dependent (and even the two I mentioned can still be made distinct from each other in fonts). I'm not dunking on Unicode here to be clear, Unicode is awesome. That said, bolting Unicode into unique identifiers humans are meant to read is a bad idea because of the homographs. Again; just look at how non-latin alphabet countries generally (don't) work with Unicode in things like usernames. > As a practical step browsers should ask the user whether they want to allow URLs in a certain language the first time a non-ASCII character is entered. This would probably help on top of the usual algorithmic blocklists that Firefox and Chrome already use (which largely rely on trying to match what sets of Unicode are used in a domain name to pick between Unicode and punycode rendering).
bell-cot 3y ago
> As a practical step browsers should ask the user whether... No, humans are far too well-trained in "just say yes and forget it". The browser should loudly flag any non-ASCII name (maybe there's a buried-deep option somewhere, to less-loudly flag it), or else it should do a bit of OCR and pop up a "DANGER - Look-Alike Domain Name..." warning.
- necovek 3y ago
  This case is a clear case of "letter k with a cedilla below": this is encoded in Unicode as a composed character that can be decomposed. No OCR needed. For all of these accented cases where no mixing of scripts occurs, browsers could simply decompose to Unicode Canonical (Decomposed) Normal Form, and flag any accented letters (eg. render them in red in the URL bar).

noirscape 3y ago

Agreed on ASCII not being suitable for a huge chunk of mankind for messaging. That said, in lieu of a better defined set of characters, it is a reliable set of characters that largely don't overlap when it comes to homograph attacks on human readable identifiers. The only single character ones in ASCII with noticable issues are 0/O and I/l/1 (this is also why on latin alphabet gift cards, you'll often see these characters omitted entirely). The other homograph attacks on ASCII are mostly font kerning dependent (and even the two I mentioned can still be made distinct from each other in fonts). I'm not dunking on Unicode here to be clear, Unicode is awesome. That said, bolting Unicode into unique identifiers humans are meant to read is a bad idea because of the homographs. Again; just look at how non-latin alphabet countries generally (don't) work with Unicode in things like usernames. > As a practical step browsers should ask the user whether they want to allow URLs in a certain language the first time a non-ASCII character is entered. This would probably help on top of the usual algorithmic blocklists that Firefox and Chrome already use (which largely rely on trying to match what sets of Unicode are used in a domain name to pick between Unicode and punycode rendering).

bell-cot 3y ago

> As a practical step browsers should ask the user whether... No, humans are far too well-trained in "just say yes and forget it". The browser should loudly flag any non-ASCII name (maybe there's a buried-deep option somewhere, to less-loudly flag it), or else it should do a bit of OCR and pop up a "DANGER - Look-Alike Domain Name..." warning.

necovek 3y ago
This case is a clear case of "letter k with a cedilla below": this is encoded in Unicode as a composed character that can be decomposed. No OCR needed. For all of these accented cases where no mixing of scripts occurs, browsers could simply decompose to Unicode Canonical (Decomposed) Normal Form, and flag any accented letters (eg. render them in red in the URL bar).