Browser IDN display policy: opinions sought
patrik at frobbit.se
Sat Dec 10 17:35:50 CET 2011
Let me emphasize that what John writes here is extremely important. If you have the slightest opinion of what "confusing" implies, and what implications approval of "too similar" TLDs might have, specifically cross scripts, you should let ICANN know.
I do explicitly also sign this email as the chair of SSAC. That is not a mistake.
Chair ICANN Security and Stability Committee
On 10 dec 2011, at 16:28, John C Klensin wrote:
> --On Saturday, December 10, 2011 21:51 +0900 "\"Martin J.
> Dürst\"" <duerst at it.aoyama.ac.jp> wrote:
>> Also, now that we have non-ASCII TLDs, that gives us some new
>> ideas. We should be able to assume that ICANN wouldn't be open
>> to visual spoofing at the TLD level, such as e.g. not allowing
>> whole-script confusables in Cyrillic or Greek. That should
>> mean that cyrillic.cyrillic and equivalents are safe to
>> display. And these are incidentally the domains where IDNs are
>> really at their best, and where the growth should go.
> Having suggested yesterday that we should try to get ICANN to
> fix a large fraction of the underlying problem, and maybe could
> succeed, and had my sanity questioned (in good humor; no offense
> taken), a comment on the above...
> I note that you say "should be able to assume". It seems to me
> that is correct. It also keeps you out of this wagon I'm riding
> to the nut house :-)
> As to how realistic that assumption is, you might consider:
> (1) ICANN's Board apparently (minutes have not yet been posted)
> passed a resolution on Thursday exempting IDN variations on .EU
> from review for visual spoofing and other forms of
> confusability. An optimist would assume that is a special
> case, never to be repeated, and that EU itself will be careful
> to avoid potentially-confusing strings even if doing so results
> in unnatural translations. A pessimist would assume that anyone
> with sufficient power and leverage can get such an exemption and
> that one should be careful about what protections one assumes
> will come from that direction.
> (2) The rules about what will or will not be accepted are
> contained in the "Applicant Guidebook", which I strongly
> recommend as recreational reading for anyone who is trying to
> figure out what one should expect from ICANN in this area.
> As a guide to relevant material in this 352+ page document
> (maybe much longer-- the pre-assembled version seems to have
> some sections omitted), see Section 220.127.116.11 on "String
> Contention". Those of you who took statistics courses may find
> it particularly interesting to contemplate what a definition
> actually means that is based on whether the combination of two
> things "create[s] a probability of user confusion".
> If you have any strong opinions about either that document or
> exemptions from confusability reviews, remember that this list
> is not the right place for the discussion. The members of
> ICANN's current Board of Directors, including the CEO, are
> listed at http://www.icann.org/en/general/board.html should you
> want to express your support (or offer other opinions).
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update