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

[Andrew Sullivan <[e-mail]>]

On Wed, Mar 11, 2015 at 09:58:26PM +0000, Shawn Steele wrote:
> 
> 
> It says "there's a spectrum", but then "We use the term "homoglyph" strictly:..."  That seems like an attempt at a hard line, though it does say "normally"
> 

As I said in an exchange off-list, the point here is to situate
"homoglyph" in a spectrum of different cases, all of which are more or
less confusable.  rn and m are plainly not homoglyphs, because if you
set them in even moderately large type with serifs you can immediately
see the difference.  Latin A and Cyrillic A are just homoglyphs: no
reasonable font even tries to differentiate them, partly because as a
matter of history they evolved from the same form and therefore it's
not surprising that they look the same now.  They're different
abstract characters because they are in different writing systems, but
they look identical.

> > ʻokina
> 
> 
> 
> Hmm, I'd thought I'd seen it different, but maybe not, sorry if that was a bad example.

It wasn't a bad example.  It was a good example, but of something
different than what you intended. :) The point is precisely that these
fine details are going to matter in this discussion, so we need to
attend to them.
 
> 
> Although I think it's fair for an RFC to indicate that some fonts can exacerbate the problem, I'm not sure that it's fair to state that parts of the problem could be "solved" by a font.  For example, sometimes the font choice may be under the control of the attacker.
> 

I think the draft says "mitigate", not "solve".
 
> ?? 2.2.2 explicitly emphasizes the Arabic Hamza Above case, though it does go on to mention that there are other characters.

There's a _whole appendix_ that attempts to illustrate the range of
the issue, and the text goes out of its way to point the reader at
that and to avoid talking about specific characters except to explain
the history, because we're trying to attend to the general problem.

> For example, this focuses on the examples illuminated by a very esoteric Arabic code point.  I’m digressing, but I never see any discussion of 拔 vs 拨 or  暖 vs 暧 (depending on font, YMMV)

In fact there is a (different) Han character in the appendix.

> > IDNA is supposed to be providing unique identifiers.

> At what level?

At every level.  DNS names are exact-match.  Each identifier is
unique.

In the DNS, color.tld and colour.tld are not the same identifier.
Conceptually they are confusing for Canadians (and spelled wrong for
USians and English respectively), but they're different.  We want that
to be as reliable as possible, and we seem to have stumbled on a class
of cases for which we cannot make derivative-property rules.  I think
that might be a problem, which is why I wanted to get a discussion
going in order to understand.

> Can they provide a unique FQDN that maps to a single server?  Sure, but they could do that if we’d just left it at “all of Unicode”.
> 

No, we would not have.  Are you quite sure you understand how the
matching rules work?  It was _never_ "all of Unicode", because that doesn't even catch the normalization cases.

> At the human level, it most certainly does not.

That's sort of the point, here, though.  But I think your description
of how this would work (elided) presents a false dichotomy: either
everyone can get this with 100% accuracy or it's not a unique
identifier.  By similar reasoning, if you cannot eliminate all crime
then you should have no laws.

> B)     We want a human safe unique identifier.

It seems to me that, more mildly, we could just say that we want one
as safe as possible, or whose "safety" we understand.  Remember, this
is a BoF and the point of the I-D was to get people to understand and
articulate problems.

> b.      I’m not sure this is achievable.  It’ll be hard for sure.

Yes.

> c.      IMO such an identifier could not also be perfectly linguistic.

Existing identifiers of all sorts are already not linguistic.  I
observe that "anvilwalrusden" is not, to my knowledge, a word in any
language.  Certainly "dyn" (my employer) is not -- the name is a
constant source of fun around the office, since virtually everybody
pronounces it "wrong" (i.e. correctly according to the
locally-prevailing norms of pronunciation).

>                                                    ii.     Eg: map Latin, Greek & Cyrillic as appropriate.
> 

This might actually not be a bad idea.

> d.      This isn’t IDNA

This BoF is not only about IDNA.

> 
> Clearly some people think that the class of the problem here is a real problem, and presumably that it is worth the effort to attempt to solve the perceived problem.

I would be satisfied if, in Dallas, we came away with a clear
delineation of the problem, or even a clear idea of how we might
delineate the problem.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]