Re: [Lucid] [[e-mail]: Re: Non-normalizable diacritics - new property]

[Shawn Steele <[e-mail]>]

Re: audio vs visual rendering…  I pronounce my droid “L3-G0” as “El Three Gee Oh”.  Which leads to problems as the last character is a zero.

This document makes a hard line between “homoglyphs” and “visually similar”.  Specifically calling out to (paraphrasing) just use a font that makes characters look different.  I’d assert that there isn’t a hard line between these concepts and that just picking the right font glosses over the difficulties in the problem.

The ʻokina is a decent case where it looks a lot like another character, and often fonts may even use the same glyph, however sometimes font designers choose to make a distinction.  It’s nearly impossible to tell a developer to “use the right font”.

Additionally it continues to treat these newly noticed characters as a special case without considering the many existing problems.

I’m also confused by the document’s attention to the need for unique identifiers at the beginning, but then looks at the existing IDNA problem.  I don’t consider IDNA able to provide “secure” (meaning unconfusable) identifiers.

I’m definitely in the 4.1 camp “Just another species of Confusables”.  However I disagree with the final paragraph.

IMO the cost of any mitigation (and implied cost of having a firedrill the next time one of these happens) outweighs any possibility of reducing the confusable space.  We’re spending hundreds of hours and thousands of dollars on this topic, but I’d be really surprised if an attacker even bothered with this code point.  If they did, it’d be 0.1% of the attacks, with 90% of the attacks using far less esoteric methods.

IMO the reason to solve the problem with this character would be as part of a solution to solve confusability attacks in IDNA in general.  Yet this solution addresses only a few characters of what are probably billions of ways to make confusable attacks.

-Shawn

http://L3-G0.com