Browser IDN display policy: opinions sought

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Mon Dec 12 07:54:54 CET 2011


On 2011/12/12 5:12, John C Klensin wrote:

> 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.

Yes indeed. The browser vendors overreacted on issues such as 
script-mixing, stuff that the user isn't able to read, and so on, 
because overreacting was easier than a more careful reaction, and they 
were able to say that they did something.

But they didn't do much for in-script attacks, because that's much more 
difficult. (Not that I'm advocating a browser that shows MlCR0S0FT.com 
with punycode.)

> 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.

With regards to wrong messages, I'm not so concerned about the typical 
"luser", but about the people between the end users and the hard-core 
tech experts. I'm not so much concerned about the actual loss of money. 
People who are stupid enough to click before thinking will click before 
thinking, whatever the circumstances. The APWG and others will be busy 
to take down phishers as fast as they can independent of what we may or 
may not tell people. But I'm concerned about the wasted effort on 
implementations and the damage from suboptimal implementations (e.g. 
showing only a small part of what could be shown without any direct spam 
potential).

Regards,    Martin.


More information about the Idna-update mailing list