Message-Id: <6.1.2.0.2.20050224224107.027ee9d0@mail.jefsey.com>
Date: Thu, 24 Feb 2005 23:13:06 +0100
To: Erik van der Poel <erik@vanderpoel.org>,
	IETF idn working group <idn@ops.ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [idn] nameprep2 and the slash homograph issue
In-Reply-To: <421DEDFF.2000300@vanderpoel.org>
References: <421B8484.3070802@vanderpoel.org>
 <20050223072837.GA21463~@nicemice.net>
 <D872CCF059514053ECF8A198@scan.jck.com>
 <20050223105244.GE21463~@nicemice.net>
 <421CA114.9090302@vanderpoel.org>
 <20050224081721.GB12336~@nicemice.net>
 <421DEDFF.2000300@vanderpoel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Very, very good idea.

This could be a _standard_ way to print the domain name in the browser bar. 
A very simple way could just be to print every URL in the bar with a 
different color for each level. This does not change anything in any 
procedure and can be very easily tought and understood. If one standardizes 
the colors it may help customer support, advertizing, discussing, etc? 
permitting to speak of the "blue", "red", "green" part of a discussed URI. 
This would be far easier for lay people than to talk of first, second, etc. 
level - whatever the language.

I suggest you write a private Draft of this asap. Probably a single page 
enough. Mozilla could make it an immediate update if it would be an RFC on 
the standard track. This is would stop the developing campaign of concerns, 
with something which would be considered as positive.

Or, would this be for the W3C?
jfc

At 16:08 24/02/2005, Erik van der Poel wrote:
>Adam M. Costello wrote:
>>Erik van der Poel <erik@vanderpoel.org> 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
>
>