Subject: Re: [I18nrp] Confusion among characters and strings

From: Larry Masinter <[email-masked]>
Date: Thu, 11 Oct 2018 23:04:50 -0700

This 

An experiment:
Given a string, convert the string to an image, OCR the image, and see
you get back the same string, code-point by code-point.
Vary the font to cover repertoire on common platforms (Android, iOS, windows mac).

Note this secion contains lots of puns

G00GLE.com OCRs to GOOGLE.com consistently.
Larrч turns into Larry and Зcom into 3com.
Toys-Я-Us.com turns into Toys-A-Us.com, even when language is Russian.

I was using open office to turn text into image
soffice --convert-to jpg test.txt
and https://ocr.space/compare-ocr-software for ocr.

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Oct 2018 03:11:58 -0400

Larry,

Asmus can almost certainly speak to this with greater authority
and better examples than I can, but it seems to me that there
are several different subcategories of confusion.  For the
purpose of looking at character grapheme relationships (OCR-like
methods included), the first two on the list below have tended
to dominate discussions but I think we do the Internet a real
disservice by focusing only on them:

(1) Within Latin script, e.g., the g00g1e examples.
(2) Between Latin script and other scripts (especially Greek
and/or Cyrillic), whether with mixed-script strings or complete
substitutions.
(3) Within non-Latin (and non-Greek and Cyrillic) scripts.
(4) Within and among non-Latin scripts, especially ones with
rich traditions of type style design and/or calligraphy as a
design art.

Your suggestion risks falling into a trap we seem to fall into
regularly, which is looking at the first category or two (if
only because it is easy to incorporate examples that almost
everyone on IETF lists will understand) and assuming whatever
observations one makes apply to other than Greek-Latin-Cyrillic
scripts.  

best,
  john

--On Thursday, October 11, 2018 23:04 -0700 Larry Masinter
<[email-masked]> wrote:

> This 
> 
> An experiment:
> Given a string, convert the string to an image, OCR the image,
> and see you get back the same string, code-point by code-point.

---

From: Sarmad Hussain <[email-masked]>
Date: Fri, 12 Oct 2018 19:16:45 +0000

Dear all,

>> G00GLE.com OCRs to GOOGLE.com consistently

Though I am not familiar with the algorithms behind these specific OCRs, generally OCRs perform a language modelling task after the image classification/recognition task to formulate the final output (this can be seen as a corrective measure).  It could mean that "G00GLE" may actually be recognized as either "G00GLE" or "GOOGLE", and former even with possibly higher likelihood values.  However, the subsequent language model will score "GOOGLE" as much more likely than "G00GLE", ensuring that the cumulative probability scores are higher for "GOOGLE", giving it as the eventual output.  Though effective for OCRs, such language based corrective analysis makes OCRs a less effective tool for gauging string confusion.  

If one turns off the language model in an OCR, then the results would be "closer" to a string confusion task - though there are other problems with a simple image classification task.  In some recent work on Arabic script, native readers were found to weigh certain strokes (those which form a character) more than others (those which join the characters) in character recognition tasks - a purely perceptual preference for this cursive script, something a pure image classification/recognition task does not consider (as it would give each stroke an equal weight).

Regards,
Sarmad

-----Original Message-----
From: i18nRP <[email-masked]> On Behalf Of Larry Masinter
Sent: Friday, October 12, 2018 11:05 AM
To: 'John C Klensin' <[email-masked]>; [email-masked]
Subject: [Ext] Re: [I18nrp] Confusion among characters and strings

This 

An experiment:
Given a string, convert the string to an image, OCR the image, and see you get back the same string, code-point by code-point.
Vary the font to cover repertoire on common platforms (Android, iOS, windows mac).

I was using open office to turn text into image soffice --convert-to jpg test.txt and https://urldefense.proofpoint.com/v2/url?u=https-3A__ocr.space_compare-2Docr-2Dsoftware&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=xeCsPHV_i7VGdkJqjbKMJ_i59E5tHFqpjD6AEoYEwzA&s=ab1teI6TRTtvos10YRG08zadQpOKRMNzkHG1vBbIZhw&e= for ocr.

_______________________________________________
i18nRP mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i18nrp&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=xeCsPHV_i7VGdkJqjbKMJ_i59E5tHFqpjD6AEoYEwzA&s=Mw-p2pdByp7TjeXzbfmXpgrdM7soyU2jjc7Ombp5i2U&e=

---

From: Asmus Freytag <[email-masked]>
Date: Mon, 15 Oct 2018 04:36:19 -0700

> An experiment:

This isn't a useful experiment given how poorly OCS performs. (?)

Try it with Chinese characters and each string would have a huge "halo" 
of OCR-confusables.

That said, I see nothing wrong with making letter o and zero (and some 
other examples) either outright blocked variants or something that's 
flagged as potentially malicious. For the Root Zone we don't have 
digits, so I didn't have to investigate them, of course.

All comes down to whether there's a will on the side of registries to 
police things, and whether, for those that do, we can define either 
minimal standards or best practices (perhaps on a per-script basis).

A./

> https://www.ietf.org/mailman/listinfo/i18nrp

---

From: John C Klensin <[email-masked]>
Date: Tue, 16 Oct 2018 22:14:30 -0400

--On Monday, October 15, 2018 04:36 -0700 Asmus Freytag
<[email-masked]> wrote:

> That said, I see nothing wrong with making letter o and zero
> (and some other examples) either outright blocked variants or
> something that's flagged as potentially malicious. For the
> Root Zone we don't have digits, so I didn't have to
> investigate them, of course.

> All comes down to whether there's a will on the side of
> registries to police things, and whether, for those that do,
> we can define either minimal standards or best practices
> (perhaps on a per-script basis)

Just to be clear, this is a point about which Asmus and I are
100% in agreement.  

Another is that, given variations in human languages and writing
systems, no set of rules are likely to be 100% effective, at
least unless they are so restrictive as to guarantee pushback
and, for any registry that doesn't believe in them, probably
non-conformance.  As an extreme example of the latter, consider
the original, vintage RFC 1591 and earlier, rules about new gTLD
names, which were, in essence:

 (i) To get one, you are going to need to demonstrate (to
	a very skeptical review process) that you have a real
	need, that the requirement or application had a very
	broad scope and value to the global Internet, that the
	need cannot be satisfied by use of hierarchy within an
	existing TLD, and that the management of first-level
	subdomains (i.e., SLDs) was going to be responsible and
	was not going to turn into controversy or a problem for
	IANA.
 (ii) If you got past (i), the domain was going to be
	represented by a mnemonic label of exactly three ASCII
	characters in length.
 (iii) Those three letters were going to be letters -- no
	punctuation or digits. 
 (iv) There are actually advantages to the Internet to
	keeping the number of TLDs small and having the list
	change very slowly.  

Noting that ICANN almost immediately dropped the first two
criteria, the three in combination and especially the third,
which remains (note Asums's comment about not having to deal
with digits in the root), are very effective in avoiding the
risk of confusion.  The fourth, which was dropped when the
current new gTLD program was introduced, provided an additional
measure of protection as well as reinforcing the level of proof
of benefits required by the first.

There was a clear understanding that application of those rules
to domains below the root would be impractical and, more
important, inappropriate.  It is key to the above that pre-ICANN
IANA was able (and believed to be certain) to enforce its own
rules.

In today's world, as Asmus has explained from a different
perspective, the only realistic approach is to create a series
of layers of protocol rules and guidelines, getting increasingly
specific and localized as one progresses through the layers.
Specifically, we have

* The DNS and restrictions imposed by its structure as laid out
in RFC 1034 and 1035 and their successors.
* For ASCII strings, the "preferred syntax" of 1034/1035; for
labels containing non-ASCII characters, IDNA2008 and its rules
about allowable characters.  If one were to summarize IDNA2008
from a high conceptual level, it requires the same
letter-digit-hyphen restrictions, with extended interpretations
of "letter" and "digit" and some additional restrictions
required by combining characters, case-comparison relationships,
and characters that seem important but that clearly posed
problems is used in an unrestricted way.

Those two layers are inherently global.  If they are not, many
things stop working or don't work and have the same
interpretations in an interoperable way.   Then we start
restricting the repertoire of names for a particular zone
further...

* General guidelines that may not apply to some specific cases.
"Don't mix scripts in a label", "avoid leading and trailing
digits if possible", and "avoid strings that are trivially
confused with or spelling variations on well-known string or
names" are examples of such guidelines.

* Rules or guidelines that restrict the characters, or character
sequences (actually quite a different matter) that can be used
in a particular script.  The rules either preclude mixed-script
labels or require additional explanation.

* Rules or guidelines that impose further restrictions because
of the way specific languages use particular scripts.  As a
trivial Latin script example, one might ban letters with more
than one diacritical mark from the DNS, but there are a few
languages that would make unusable. 

* Guidelines that affect entire FQDNs, rather than individual
labels.  Some of these are obvious, e.g., a zone dedicated to a
single language or function might want to be sure that all of
its subdomains conform to that language or function.  Others are
not.

... and probably other examples.  I don't see those as really
layering neatly, but you get the idea and it probably does not
make much difference whether they do or not.

As is often the case in other areas, if one wants safety
(including security and lack of even benign confusion), one
gives something up.   In the DNS case, that might be flexibility
of naming [1], low complexity, and ease of testing compliance
[2].

Where Asmus and I _may_ differ is a layering and boundary
question.  As we discussed when assembling
draft-klensin-idna-rfc5891bis, sooner or later there is a
necessity for registries to understand what they are doing and
be responsible, to use good sense, and to be accountable for
whatever is done.  At the level of an individual registry, that
is, almost by definition, the last rule in the chain.   The
question is how many sets of rules it is worth injecting between
IDNA2008 and "the registry needs to be responsible and
preferably accoutable".

If the registry is not motivated to act responsibly -- whether
because it is too much trouble, there is financial incentive to
not do so, there are no penalties or costs, or for other
reasons-- then it is unlikely that the intermediate guidelines
will help (and possible that there won't even be IDNA2008
conformance, as we have seen with registries selling emoji
domain names).  Sadly, we have a good deal of empirical evidence
for that.  The other problem source, for which there is also
empirical evidence, is that there are registries out there whose
strategy is to identify some set of rules and then make the
claim that, if they follow those rules, they are not responsible
for anything that goes wrong: the fault lies with the
rule-specifier.  And the more specific the rules or guidance
gets to whatever the registry wants to do, the easier it seems
to be for a registry to take that "we followed the rules, so not
our fault" position.

So, where I think we differ is how much beyond IDNA2008 it is
worth going with guidelines of various sorts.   I wouldn't say
"zero", but, for the reasons above, I wouldn't go very far.  I
think Asmus would go much further and, if I were considering
this only on technical and linguistic grounds, I would probably
agree with him.

   john

[1] At the time the DNS was designed and early policies laid
out, there were very strong (and generally accepted) attitudes,
left over from the name assignments that ultimately comprised
the host table, that there were certain conventions and
decisions, and one might as well just get used to them because
there were no other options.  No more... and completely
incompatible with the idea that people should be able to choose
their own names in/from their own languages.

[2] Even for the root, compare the above four rules with the LGR
process and evaluation rules, with or without RFC 7940 and 8228.

---

From: Asmus Freytag <[email-masked]>
Date: Tue, 16 Oct 2018 19:48:12 -0700

> this only on technical and linguistic grounds, I would probably

My take is based on the understanding that almost nobody is able to
understand the writing system issues (or issues at the intersection of
writing system and encoding) for *all* or even *most* modern scripts.

The root zone LGR project required about 10-40 people per script and
has taken about 8 years today, if you count the precursor phase.

Some ccTLDs may be able to muster such resources, but ordinary gTLD
operators trying to offer broad support of IDNs are in a tough position
and could benefit from either "minimal standard or best practices".

The former should be very focused and are perhaps what you were
thinking of above. The latter should be styled along the lines of:
"if you allow X, the consequence is that neither users nor rendering
systems for that script will be able to process it." and similar statements
of documented facts and suggested decisions (with supporting rationale).

We are very big on insisting on a documented rationale for all elements
of a root zone LGR; if any of these were to be expanded into "best practice"
documents, I would expect that feature to continue.

The world of writing systems is pretty complex; this complexity is
also "irreducible". There is no Gordian knot solution to "make it all
simple".

That said, applying certain limits on repertoire can often dramatically
simplify issues for a given script. Take disallowing combining marks
for Arabic. Turns out they are not essential for mnemonics in that
script (unlike, say, support for arbitrary types of text) and leaving
them out sidesteps a number of other issues.

A./

A./