Browser IDN display policy: opinions sought

John C Klensin klensin at jck.com
Sun Dec 11 21:12:52 CET 2011



--On Sunday, December 11, 2011 14:20 -0500 Andrew Sullivan
<ajs at anvilwalrusden.com> wrote:

> On Sat, Dec 10, 2011 at 06:48:20PM +0100, Patrik Fältström
> wrote:
>> 
>> On 10 dec 2011, at 18:26, Paul Hoffman wrote:
>> 
>> > D: Unicode if the label is a single script that is
>> > displayable by the browser, Punycode otherwise.
>> 
>> +1
>> 
>> With the exceptions for combinations of various scripts and
>> script COMMON.
> 
> But this boils down to, "We should do that, unless we can't
> and it makes sense to do something else."  Which is
> practically equivalent to "we should follow this rule except
> when we don't."
> 
> Note that even LDH is not in one script.

It also raises a very complex problem from which none of these
strategies are immune (unless they are completely focused on
user experience without even a hint of protecting people from
harm).  What we know already is that script-mixing tests aren't
much good.  Yes, preventing them (preferably as a registration
norm) unless they are actually necessary, is a good thing to do.
But, if someone is actually planning an attack, there are more
than enough "all in one script but confusable with another"
examples to provide ample opportunities.

If we tell, or appear to tell, the poor lusers that we are
protecting them against a particular variety of attack --such as
confusing names-- and end up doing that often enough to be
persuasive that we are accomplishing something while remaining
open to slightly-more-clever attacks, we actually decrease
effective security by encouraging the user to become less wary.
Repeated observations from many parts of the world that adding
traffic signals to interactions that were known to be dangerous
often increases the accident rate come to mind here.

So let's be a little careful about our assumptions about who we
are helping and with what.

   john




More information about the Idna-update mailing list