Users who misinterpret long domain names like _, thinking it says /security_department/, is a bigger problem. Users who click on such links are a bigger problem. Links where innocuous link text points to a brazenly malicious URL are a bigger problem. And within the landscape of security risks caused by text representations of domain names and the like, I argue that the attacks Unicode makes easier are medium to minor. But as the "PaypaI"/"Paypal" example shows, homograph attacks exist even within a single script. Unicode makes many things possible which were difficult before, including some homograph attacks. They have identical appearance, but have properties which affect text layout differently. Why? Because the first is a conventional space character, and the second is a non-breaking space. But they are distinct characters in many character sets, including Unicode, ISO 8859-1, and Windows CP-1252 "ANSI". In just about every reasonable font, they will have identical glyphs. In some fonts, digit "0" and uppercase letter "O" look darn similar. I can present you with a domain name "", which will look pretty similar to "", as long as I can choose a font where uppercase "I" looks identical to lower-case "l". Unicode's architecture has no say there.Ĭharacters that look similar, or homographs, are a problem even within character sets for a single writing system. I could choose three other fonts which made them look different. If you give me the three characters Latin capital letter A, and Cyrillic capital letter А, and Greek capital letter Α, I could choose three fonts to render them which made them look identical. So what defines how glyphs are rendered? Fonts, and the text layout engine, and their character-to-glyph mappings. (TUS, section 1.3 Characters and Glyphs, p. That is, the standard defines how characters are interpreted, not how glyphs are rendered. The Unicode Standard does not define glyph The mark made on screen or paper, called a glyph, is a visual representation of the character. The character identified by a Unicode code point is an abstract entity, such as “latin capital letter a” or “bengali digit five”. The difference between identifying a character and rendering it on screen or paper is crucial to understanding the Unicode Standard’s role in text processing. Notice that the concept of "glyph" does not appear in that list. … a character’s case, directionality, …alphabetic properties…, and other semantic values.…" (TUS, Chapter 1, p.1) The Unicode Standard specifies a numeric value (code point) and a name for each of its characters. It is a mistake to say "Unicode has …… with identical glyphs", because Unicode does not standardise glyphs. Glyphs, but are assigned to codepoints U+0041, U+0410, and U+0391, With identical glyphs nevertheless being assigned to separateĬodepoints (for instance, the Latin capital letter A, the CyrillicĬapital letter А, and the Greek capital letter Α all have identical Unicode has many, many instances of pairs or larger sets of characters A good place to start unpacking this question is chapter 1, Introduction, of The Unicode Standard (TUS). But like many questions about Unicode, a related answer is "plain text may be plain, but it's not simple". The short answer to this question is, "Unicode encodes characters, not glyphs".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |