[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] IDNA section 3.1 requirement 3

At 6:34 AM +0000 3/17/05, Adam M. Costello wrote: 
Paul Hoffman <phoffman@imc.org> wrote:

 Question: when faced with an incomprehensible domain name with no
 visual indications, do you think that typical users will know what to
 do, or even what to be cautious of?


No, but they don't need to do anything special or use any more caution
than they would with any domain name that they didn't recognize.  As
long as they don't see "paypal" or whatever, they're at least not being
misled.

The example given at the start of your message was the homograph-slash. A spoof domain name that has that character and "paypal" will *still* display "paypal" in the Punycode. It will only truly work for names where the base script is not ASCII. It also relies heavily on browser makers ability to decide which mixed-script combinations are OK, and which are not, without giving them any guidance.

> Adam: could you think more about it and see how it would look if
thought visual assistance was an option? 

Suspicious characters could be shown in red, or highlighted, or with
squiggly underlines.  But the risk with any such scheme is that the
misleading text is still visible, so if the user doesn't take the
hint, they might still be misled.

Of course. That is weighed against the user not being able to read what was presented at all.

For example, if a browser erroneously decided that Chinese was undisplayable on the device (option "c"), the user would only see something that didn't look like what the originator had used and would not be able to decide whether to accept it or not. This would force browser makers to check which characters were displayable each time it launched. Similarly, if the logic in option "e" is wrong, the user would never be able to view the legitimate name.

  And these approaches would be
less effective or impossible on monochrome displays or in tty-based
applications.

Highlights and squiggly underlines show up fine in monochrome. TTY-based applications generally can't display IDNs faithfully anyway due to lack of sufficient pixels; developers on those systems need to make other design decisions anyhow.

Another option is to show the suspicious characters using the
replacement glyph (hollow rectangle), but then cut-and-paste might
break, unless it's really clever.

As you remember from a few years ago, cut-and-paste often doesn't work reliably with non-ASCII characters even under good conditions. This seems like a red herring.

I proposed the show-ACE approach because it's simpler to implement and
it's obviously effective regardless of the display technology.

It is effective at making some IDNs unreadable. That helps in the case of spoofed IDNs, and hurts in the case of legitimate IDNs.

John C Klensin <klensin@jck.com> wrote:

 Let's look at a few of the things we know about user behavior
 and reactions:

    * They do not like looking at punycode or similar "no
    obvious meaning" and/or "ugly" constructions.  If too much
    of it is displayed, they will be unhappy.


I agree.  If enough browsers implement the proposal, no one will have a
motive to use domain labels that would show as ACE, and therefore users
will see ACE very rarely.

That statement is predicated on browser makers across the world agreeing on how to implement option "e". That may be a tad optimistic. If you're wrong, it will cause IDNs in general to be useless due to their instability of viewing.

--Paul Hoffman, Director
--Internet Mail Consortium