On 11-02-25 02:35 PM, Igor Bukanov wrote:
With most fonts it is not possible to see that the following ES
fragment should alert 1, not 2. I guess such problems are not
considered high on the list of language designs.
javascript:var a = 1; а = 2; alert(a);
It's certainly relevant! The NFKC pass is supposed to defend against ..
*some* of this sort of ambiguity; but there is a limit, and as you say,
it's font-dependent. FWIW, the emacs buffer I pasted it in to inspect
showed the difference plenty well (0x0061 LATIN SMALL LETTER A vs.
0x0430 CYRILLIC SMALL LETTER A). But I think that's because it had to do
a multi-font patchwork job. A well done full-range font would probably
have collided, visually.
I pointed out the risk of homographic "attacks" like this to the fellow
who raised the complaint initially, and .. I still agree it's a risk.
It's even a risk in IDNA, where they don't (I believe) squeeze this
ambiguity out even in their nameprep profile.
It's just one that I've changed my feeling on the risk/reward ratio of,
I guess. It's substantially *less* of a risk here than in URLs, too; it
seems really unlikely that anyone's going to use systems-language source
code for phishing attacks (goodness, I hope not).
In any case, if it worries you in production code I suspect it'll be a
small matter of adding a pragma (once the compiler plug-in interface is
sufficiently non-vapourware) to clamp your project's source to a
particular unicode range.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
