Re: [idn] nameprep2 and the slash homograph issue

[Erik van der Poel <[e-mail]>]

Adam M. Costello wrote:
> Erik van der Poel <[e-mail]> wrote:
>>The IETF generally only specifies the "wire" protocol, not UI
>>behavior.  The IETF does not specify how apps interface with users;
> 
> Generally, that's true, but IDNA is an exception.  It state four
> requirements (RFC 3490 section 3.1), and one of those four has rather
> little to do with wire protocols, and quite a lot to do with UI
> behavior:
> 
>    3) ACE labels obtained from domain name slots SHOULD be hidden from
>       users when it is known that the environment can handle the non-ACE
>       form, except when the ACE form is explicitly requested.  When it
>       is not known whether or not the environment can handle the non-ACE
>       form, the application MAY use the non-ACE form (which might fail,
>       such as by not being displayed properly), or it MAY use the ACE
>       form (which will look unintelligible to the user).

I don't think IDNA is an exception. Note that the part you quote above 
uses words like SHOULD and MAY. I would say that those words were chosen 
for *exactly* the reasons I mentioned (i.e. IETF *specifies* wire 
protocols, not UI behavior). See section 6 of:

http://ietf.org/rfc/rfc2119.txt

This RFC focusses on "interoperability" (but also mentions "harm") so I 
would say that the wire protocol is the main concern.

> I think this discussion is headed toward an update to IDNA that would
> add a second exception to that requirement, for protecting the user
> against phishing.  What we need to figure out is how to describe that
> exception, and how specific or deliberately vague that description
> should be.

Here I agree with you. I'm not going to try to come up with the wording 
for that, but this morning I started to think that the right-to-left DNS 
and IDN spoofing problems *could* be addressed at the UI level by 
providing a *tool* that security-conscious users could *choose* to use.

I'm thinking of a tool that might be implemented as an extension for 
Mozilla, for example. It would offer to display domain names in the safe 
order, i.e. left-to-right for users whose main language is 
left-to-right. I have not heard of any UIs that offer top-to-bottom in 
their menus, dialogs, etc, so I would guess that this would be omitted 
in the extension too, though right-to-left might be offered for 
right-to-left users (many of which are in the Middle East -- Hebrew and 
Arabic).

In addition, such a tool would offer to display domain names in a clear 
font, unlike the sans-serif that is commonly used today. This would make 
the distinction between lowercase l and digit 1 clearer. And it would 
separate the domain name from its context, e.g. using color.

Finally, this tool would offer to display characters outside the user's 
language(s) in a special way, to make them stand out and catch the 
user's attention. I believe we need to focus on the user here, because 
we are talking about how things *look* to the user.

For example, people in the Far East are used to spotting small 
differences between complicated characters because they were taught as 
children to read and write the thousands of complex "Han" characters 
that differ in small ways.

Americans, on the other hand, are only used to seeing a small number of 
characters, and would not even be able to *read* Han characters, let 
alone spot differences between them. This is why I believe that a tool 
that focusses on the user might be a good idea.

You may claim that nobody would ever want to read domain names 
left-to-right, to which I would counter that some people are willing to 
try Dvorak keyboards, which are totally different from QWERTY. I.e. it's 
the user's choice. Internet security education may eventually lead 
*some* users to make this choice.

Erik