At 9:52 PM +0100 2/9/02, Lars Marius Garshol wrote:
>It seems to me that this problem really needs some other fix than the >merging of all similar-looking characters in all character sets. I >just can't see that working. > That's your suggestion, not mine. I have never proposed merging all the similar looking characters. If I misspoke or something I wrote was misinterpreted as indicating that, I apologize. But that is not now nor ever was my position. However, I do continue to maintain that character confusion is a real security risk that will have real impact on users, and that needs to be considered in any system that uses Unicode. In some domains the problem might be severe enough to eliminate Unicode from consideration in favor of less extensive character sets like Latin-1. That would be a shame, but until the Unicode consortium addresses at a root level the real security implications of their work, security conscious developers will look elsewhere. (I notice the Unicode 3.0 book does not even have the word "security" in its index.) Many more developers who are at best tangentially conscious of security issues will go ahead and develop insecure systems because they don't realize the security implications of adopting Unicode. There might be other solutions. I have proposed forbidding mixed block domain names; e.g. allowing Cyrillic names and Latin names but not mixed Cyrillic-Latin names. To me, that seems a reasonable trade-off. Vastly improved spoof-resistance (though still not perfect) while still allowing the registration of most desired localized names. Another possibility is a super-normalization that does combine similar looking Unicode characters; e.g. in the domain name system we might decide that microsoft.com with Latin o's or Cyrillic o's or Greek o's is to resolve to the same address. No separate registration would be necessary or possible. This would require detailed analysis of the tens of thousands of Unicode characters allowed in domain names by fluent speakers of various languages; not easy, not cheap, but perhaps necessary. Besides, the security improvements, this proposal would also improve the system's usability. Aren't sure whether that URL on the bus used an o or an omicron? Doesn't matter, type either one. >Similarly, the "security problems" caused by using Unicode encoding >tricks to hide or mangle text in, say, contracts, is no different from >using HTML or CSS (or whatever) tricks to achieve the same effect, and >yet nobody is talking about security problems with HTML or CSS. See >[1] for one way of dealing with it that is now being worked on. > Actually, people have been talking about the security problems with HTML for years. Search engines have gone to some effort to eliminate spamdexers that use these techniques. The log in HTML's eye does not, however, negate the existence of the log in Unicode's eye. >So while I accept that there is a problem it does not seem to me that >Unicode is the problem. To me the problem seems to be the complexity >of the relationship between the bytes sent to the user and what the >user actually sees and reacts to. That complexity is not going to >disappear, and aspects of the same "problem" exist with just about any >information representation, so clearly the solution must be something >other than changing all of these syntaxes/formats/encodings. > >In the specific case you cite, for example, a better solution might be >for the user's email client to keep track of all the user's contacts >and for it to indicate in some clearly visible way whether the current >email comes from one of them or not. Whether it uses string matching >of email addresses or digital signatures to do that doesn't really >matter; it solves the problem in your example either way. > If the internationalized domain name system comes into being without any resistance to spoofing, I will certainly recommend that people upgrade their client software to prevent this, just as I recommend today that people avoid Outlook Express, Microsoft Office, and other products that provide fertile soil for worms. I expect such efforts to be about equally effective; i.e. some wiser users will protect themselves. Many other users will be protected by accident. And many more users will not be protected at all. -- +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +-----------------------+------------------------+-------------------+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ | +----------------------------------+---------------------------------+
