[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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