Browser IDN display policy: opinions sought

Mark Davis ☕ mark at macchiato.com
Tue Dec 13 22:40:11 CET 2011


Martin,

According to all of the information I have from our security people:

IDNA spoofing is *far* down on the list of importance compared to other
ways to spoof. Average people are more swayed by the appearance of the page
they land on than on the appearance of the url in the address bar. The
average person doesn't distinguish:

https://www.bankofamerica.com/deposits/index.action?body=check_overview&state=CA//
a valid target
https://www.bankofamerica.com.deposits.index-action.me?body=check_overview&state=CA//
bogus site

The warnings that really grab people's attention are where (for example) a
warning screen comes up before the contents appears, telling people that
the content page is dangerous, and asking if they want to continue. Simply
changing the appearance in the address bar is often overlooked.


That says to me that much it would be better to always show the Unicode
characters (thus giving a uniform UI across browsers), but then provide a
more obvious UI signal to users that the page is suspect (and for what
reason). So from your example, the user should see
http://www.viagénie.com<http://www.xn--viagnie-eya.com/>
 and http://биатлон.рф <http://xn--80abvnkf0a.xn--p1ai/> in all of the
browsers.

The Unicode vs Punycode UI is a blunt tool anyway; a separate UI signal out
from that for gradations in the levels of warnings given to users. Thus the
following could get different levels of warnings (depending on the user's
language settings)—some being of the "you can't go farther without
confirmation" sort:

   - ѕех.рф (the 'sex' are all Cyrillic characters)
   - ѕех.com <http://xn--e1a6a7b.com> (the 'sex' are all Cyrillic
   characters)
   - pаypal.com (with just one Cyrillic а).
   - &c.

User's could also get settings to turn off classes of errors, if they find
that those get in the way based on their environment.

On determining which pages are suspect because of their URL: If we were in
a world where we could depend on registries to police domain name labels,
that would be simple for browsers and other clients. Such a Kumbaya planet
bears little resemblance to our reality, though. And as far as I know,
ICANN neither has the authority to require that every domain name label (at
every level, such as the label 'foobar' in foobar.blogspot.co.uk) meets
some particular set of requirements, nor would it would be willing to
certify (subject to legal damage claims?) that such is the case, even for
those domain name labels that it can control.

That says to me that whatever level of signaling that is required is
largely up to the browsers; depending on the registries is just wishful
thinking. Given that, I think some refinements of A look promising. There
are a variety of different possibilities; it would probably be useful for
interested parties to brainstorm on the most effective ones in practice.

   - warn on mixed-script labels (allowing certain exceptions, essentially
   where there are no confusable characters between the scripts, like Latin +
   Hangul)
   - warn on mixed-script domain names.
   - warn on confusable characters outside of my languages
   - &c.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20111213/85dd8c9e/attachment-0001.html>


More information about the Idna-update mailing list