Recently, the Shmoo Group discovered that Firefox is vulnerable to precisely the exploit that i predicted in my 2002 paper—Ping
➡

Where have you seen this response? Over on the crypto + security at mozilla groups there has been quite a bit of chit chat on the problem, although I grant that nobody who claims to be a member of a security team has said anything yet.—Ian

I admit that my characterization of the response comes from various blog entries about the vulnerability, not the Mozilla newsgroups. So perhaps it is not fair for me to say that there is no response. Rumour has it that Opera is claiming there is nothing wrong with their implementation, which, if true, is quite depressing.

I am very disappointed that the implementors of IDNs in Firefox did not anticipate this problem. The problem is well known and well documented. See <icann.org> or <cs.technion.ac.il> for instance. RFC 3454 (Stringprep) specifically points out:

The Unicode and ISO/IEC 10646 repertoires have many characters that look similar. In many cases, users of security protocols might do visual matching, such as when comparing the names of trusted third parties. Because it is impossible to map similar-looking characters without a great deal of context such as knowing the fonts used, stringprep does nothing to map similar-looking characters together nor to prohibit some characters because they look like others. User applications can help disambiguate some similar-looking characters by showing the user when a string changes between scripts.

Even if no one on the Firefox team read this paragraph, even 0.5 second of thought on the topic of security and usability should have been sufficient to realize that the use of Unicode in the location bar would yield a security-damaging source of ambiguity.—Ping