Re: IDNA section 3.1 requirement 3

At 6:34 AM +0000 3/17/05, Adam M. Costello wrote:
>Paul Hoffman <[email protected]> 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 <[email protected]> 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