Sven Putteneers wrote: > If this patch would be widely used, we'd lose the all the advantages > associated with IDN. I think that was the point. IDN was not a very clever idea from the start -- it breaks the "don't allow the obvious to not be what it appears to be" (aka "don't surprise the user", etc, etc) rule which is one of the very most important rules of any kind of technology/human interface. When you do break that rule you get all kinds of "obvious" problems down the track, including very many that should have been obvious at the outset, to the designer of the system or functionality that did the breaking. Such stupid and eternally regrettable design decisions have often been strongly commercially motivated. > Maybe it's better to attack this problem on the browser side and have a Given IDN would seem to be here to stay, I'd say that will be the only place we can attack it... > configuration switch to enable or disable IDN. We could disable it as a > "reasonable default", but those who need it, could enable it. > Upon enabling the option, a warning dialog could pop up that warns the > user about the security problems associated with IDN ("don't enable this > unless you know what you're doing" stuff). > > That way the majority of the users would be safe from IDN attacks > (phishing comes to mind) and those who really want IDN would have to > click through a warning dialog telling them why enabling it may not be > such a good idea. Such warnings have far from sufficient efficacy. Much history shows that the folk who will most likely "stupidly ignore" such warnings are precisely the ones that would derive (most) benefit from the warnings _had they heeded them_ (i.e. the folk who really need this protection are the ones that will turn it off). The "let's pop up a warning message" approach to truly hard problems such as this is a commonly seen approach that shows the developer's total lack of understanding _and_ caring about the actual problem. Without having thought too hard about all this, a better browser-side solution may be to not allow domain names with a mixture of ASCII and IDN characters (I mean to the left of the unavoidably ASCII (??) top level country, .com, .mil, .org, .net, etc domain name components). If you have a Korean or Japanese or Mandarin or whatever domain name, then there should be no need for any ASCII characters in it. There may be problems with this idea with Central European names, where much of the ASCII character set is employed along with a few special characters, and with domain names that incorporate numerals. If IDN can be used to encode characters from the ASCII character set too then these problems are moot, but we end up back where we started in terms of mixed ASCII/IDN-only chars being the "problem". Of course, not allowing mixed ASCII/IDN does not entirely remove the problem of "IDN-spoofing" -- for most suitably long domain names (perhaps those with more than five _different_ caracters?) it is probably a safe bet that there will not be a suitable set of IDN homographs* possible to spoof your domain name, but for shorter ones... * Being the semi-pedant that I am, "homograph" was always the wrong term for these IDN spoofing tricks. A homograph is a pair of words (or presumably more) that are spelt the same but have different meanings. What we are talking about here are two (or more) words that are spelt differently but look the same -- perhaps "pseudograph", if not the right word, is certainly better.) -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3267092