Re: [idn] IDNA section 3.1 requirement 3

["Mark Davis" <mark.davis@jtcsv.com>]

I agree. See also http://www.unicode.org/reports/tr36/draft/, where there
was already something along those lines.

âMark

----- Original Message ----- 
From: "John C Klensin" <klensin@jck.com>
To: "Mark Davis" <mark.davis@jtcsv.com>; "IETF idn working group"
<idn@ops.ietf.org>
Sent: Thursday, March 17, 2005 11:22
Subject: Re: [idn] IDNA section 3.1 requirement 3


>
>
> --On Thursday, 17 March, 2005 07:37 -0800 Mark Davis
> <mark.davis@jtcsv.com> wrote:
>
> > I agree with John. Use of the raw punycode in place of the
> > represented characters will cause more user confusion, not
> > less. User sees:
> >
> > xn--tlralit-byabbe.fr versus xn--tlralit-byabb390f.fr
> >
> > Presented with a collection of apparently random letters, eyes
> > quickly glaze over, and people really can't distinguish
> > between two names in any sensible fashion. Users are not going
> > to memorize which gobbledygook is the one they want. And this
> > is, over course, vastly magnified once you are outside of
> > Latin script IDNs.
> >
> > While I agree on the need to present some mechanism for
> > distinguishing cases (see tr36), raw punycode is not a good
> > choice. It would even be better to present raw IP addresses
> > (not that I am really suggesting that).
>
> I'm glad you are not, because it would cause harm and would be
> unlikely to help much.  Even getting an address and
> reverse-mapping wouldn't help a lot: the phishers would have
> more difficulty getting hold of an appropriate reverse-mapping
> delegation than the forward one, but probably not much more
> difficulty.
>
> It is probably worth noting that, in a UI context, the
> punctuation problem (especially the "/" homograph version) may
> not as severe as it appears.  Remembering that I don't believe
> there are "solutions" to these problems, but only ways to chip
> away at them, suppose that browsers and other applications that
> process and present URIs (or IRIs) started parsing and coloring
> them according to the parse.  No tricks about analysis of the
> IDN -- just do it for everything.  And maybe color isn't the
> right answer: perhaps we should borrow a note from publication
> Algol and use a bold type.  So, for http://ops.ietf.org/idn, the
> use would see "http://";, and the "/" after "org", in bold and
> the domain name and tail as normal text.  Once a user got used
> to looking at that style of presentation, a homograph-"/" spoof
> would stand out as highly unusual at best.  That certainly is
> not a magic bullet.  It requires that users be reasonably alert
> to the unusual, but that is the critical first line of defense
> against phishing and similar attacks anyway.  It doesn't involve
> warning messages or overwhelming the user with gibberish where
> names are expected.  And maybe it is a little more in the
> direction of the sort of things we should be thinking about.
>
> best,
>    john
>
>
>