Browser IDN display policy: opinions sought

[John C Klensin]

Gerv,

This is going to be long -- you asked for opinions and analysis
and I want to give you some, rather than just "I prefer X".

--On Friday, December 09, 2011 11:12 +0000 Gervase Markham
<gerv at mozilla.org> wrote:

> Recently, Mozilla community member Jothan Frakes was kind
> enough to do some research about how different popular web
> browsers implement IDN, and when they display the real
> characters and when they display Punycode. This is in the
> context of a Mozilla review of our policy. I am interested in
> the opinions of people on this list (see below).
> 
> As it turns out, the behaviour of all popular browsers is
> summarised at the bottom a Chromium project document here:
> http://www.chromium.org/developers/design-documents/idn-in-goo
> gle-chrome
> 
> The policies fall into 3 approximate buckets:
> 
> A (IE, Chrome): Unicode if the (single) 'language' of the
> string is configured in the options, Punycode otherwise.
> 
> B (Firefox, Opera): Unicode if the TLD is in a whitelist,
> Punycode otherwise. Arbitrary script mixing permitted
> (registry policy used to prevent abuse).
> 
> C (Safari): Unicode if the script is in a whitelist (which by
> default does not include Cyrillic or Greek), Punycode
> otherwise. Not sure about script mixing.
> 
> 
> Firefox has historically resisted adopting a Type A policy
> because we consider it seriously detrimental to IDN adoption
> and use. It seems to me that IDN can never be reliable for
> site owners, and therefore will not succceed, if a significant
> proportion of the world's browsers adopt Type A or Type C
> policies. This is because site owners can never know what
> proportion of their visitors will see gobbledegook in the URL
> bar rather than their nice domain name. Perhaps for sites
> whose visitors are all guaranteed to be from a particular
> country or language group, with properly-configured browsers
> and OSes which know that they speak a certain language or use
> a certain script, it might work - but I suggest that's a small
> subset of all sites. Many people in non-English-speaking
> countries still use English OSes and English browsers, with
> default settings.
> 
> Type C is particularly bad - Russian and Greek IDNs are broken
> by default, but even if you persuade your users to turn it on,
> they can then be mixed-script spoofed. You get to choose
> between functionality and security.
> 
> By contrast, with a Type B policy, if your IDN domain works in
> one copy of Firefox, it works in them all. If everyone had
> Type B policies, there would be no risk of a
> properly-registered domain coming up as gibberish.
> 
> It has been suggested that Firefox switch to a Type A policy.
> As it is, the mix of policies means that the goal of universal
> acceptability is not being met anyway. Firefox switching to
> Type A would also not meet that goal by itself, but one could
> argue that there's a bit more consistency to browser behaviour.
> 
> I would be interested in the opinion of people on this list as
> to:
> 
> - whether my analysis seems reasonable;
> - whether they prefer type A, B or C; and
> - whether they see any particular policy as more damaging to
> IDN   adoption than another.
>...
> (Note that "no restrictions" is not an option, given what
> happened in 2005 with payp-cyrillic-a-l.com, and I would
> rather not derail this debate by rehearsing those arguments
> again.)

Gerv, let me disagree, at least slightly, with Paul and Michel.
I've got a lot of sympathy for Type B even though I've never
been happy with at least one aspect of it.  I see a few --fairly
serious, IMO-- issues with Type A and a few with parts of your
analysis.

To start with, let me use my own patterns as an example.  I
really want the same character-display behavior on every device
I use.  It isn't good enough that I get the same behavior on
every device on which I'm running Firefox because I have devices
on which that isn't practical (you don't have a version for that
device, it doesn't behave well, my configuration of the device
has footprint/capacity problems and Firefox is getting
bloated,...).  In a typical week, I move among circa a
half-dozen machines with four to six different operating systems
(depending on how you feel about versions, and versions do make
a difference in this area). I may also sit down at a public
terminal or a friend's machine.  I'm probably worse than
average, but I'm not a tablet user: I've now got several
non-specialist friends who are carrying a smartphone, a Kindle
Fire, and an iPad, so this gets them too.  With Type A, these
machines need to be configured one at a time, using different
interfaces and conventions and sometimes going back to physical
media.  I wouldn't know how to configure my Android 2.2 phone to
display Greek or Han (which I prefer to be able to see, even
when I can't read the languages) while retaining Latin if I
wanted to...   We have no mechanisms for smoothly exporting
those settings among machines running the some OS, much less
across heterogeneous OSs.   That is a big pain, one requiring a
fair amount of technical smarts and time investment to get and
keep consistent, and impossible if one is using borrowed or
kiosk machines.

Worse, for several systems (Windows and FreeBSD included),
"configured in the options" doesn't mean "set a browser flag
that says it is ok to display Slobbovian script characters".
Instead, unless some of the bits are there already (which they
might be because, e.g., fonts and type styles are typically
installed in units of groups of scripts while configuration is
often done by language), it means "set operating system options
and load hundreds of megabytes of fonts for the relevant script
in every type style installed on the machine, printer driver
extensions, spelling dictionaries, keyboard layouts, and
sometimes phonetic tables for screen readers and other good
things".  For browser display of domain names or IRIs in scripts
I don't use routinely, a single reference type style would not
only be adequate, but I might be better off (less vunerable to
attack), but loading only one type style for scripts other than
those for my favorite language or two is not an option (or not
one that an unsophisticated user can figure out how to use). 

Because I (and others) may want to see the characters of scripts
that are associated with languages we can't read (e.g., I can
read Greek characters, but cannot usefully read the language),
Type A has the inherent problem of being language-based and, in
at least most cases, requiring that I essentially lie to the
operating system and tell it I can read and write languages for
which I have no capability.

Your "Type B" model, if used by other browsers and systems,
would get me that consistency of behavior, especially if browser
installation gives me that default "universal" reference font
too.  It is less useful if you and Opera are the only ones
supporting it, but "Type A" is less useful unless there are
really easy ways to export settings and to make fonts and
display for particular   scripts available without importing
large groups of scripts or all of the associated language
baggage.  Nothing else in this reality can give me that
consistency.  See below for a different reality, but I'm just
not convinced that we have it right with any of the three groups
of options.  Intentionally or not, I think they are even solving
different problems.

The big disadvantage of "Type B" is that it means I'm reliant on
your judgment about what TLDs are well-behaved (or worth the
risk) and which ones are not.  If I disagree, I lose -- either
because you are opposed to giving the user domain-by-domain
override capability or, if there is an override mechanism that
allows me to insert my own opinions, it would take me back to
the problem of keeping multiple machines consistent.   Even
overrides and your opinions might not be granular enough: It is
entirely possible that I would trust the registry and registrar
policies for the "frob" TLD for European scripts but not for
Asian ones (and vice versa) even if they permit registration
from those other scripts.  The current "Type B" doesn't even
have a vocabulary to talk about that.

In addition, if ICANN adds 500 new domains next year, many of
them with alternate actual orthography or renderings
("variants"), I can't imagine that the Type B approach is going
scale well enough to remain timely.   If the goal is to protect
users, with errors on the side of displaying A-labels considered
acceptable, then that may be ok, but it isn't a good story to
tell folks who are interested in using or marketing a new
domain.   Scaling for Type A and Type C depends on the number of
languages with which the user claims familiarity; for Type B, it
depends on the total number of TLDs.

All of that said, I think you (as a Type B) representative and
Microsoft (as a Type A one) one are, intentionally or not,
solving different problems.  Your concern --from the
explanations you gave years ago and reinforced by your use of
the bogus paypal example-- has been about protecting users from
intentionally-confusing or confuseable strings.    From that
perspective, displaying A-labels rather than U-labels is a way
to convey a particularly forceful message warning that the user
had better pay careful attention.  Microsoft's concern is, as
I've understood it, much closer to the belief that the user
doesn't want to deal with domain name labels in languages or
scripts she does not read or use.  That may have some useful
anti-phishing (and anti-fraud more generally) properties, but
(intentionally not, but I think intentionally) it is really much
more about an attractive user experience than it is about
protection against bad behaviors.   There is, I think, an
underlying dubious assumption that is that a domain name that
contains labels in some script implies content in a language
that uses that script, but so it goes.

The "different problems" suggests that, if you wanted to, you
could adopt Type A behavior but still identify domain names from
suspect trees (Type B behavior) in some way other than A-label
display.  Whether that would be a good strategy or not depends
on what you think about language-based models and your analysis
of the effectiveness of various forms of user warnings (my own
guess is that shifting to A-labels as a warning is going to be
effective if you don't do it very often but, if the network and
TLD behavior evolve in a direction that results in a lot of
users seeing A-labels most of the time, the shock value would
rapidly disappear (the same comment would apply to Type C
behavior with most scripts disabled by default).

To wrap this long analysis up, I think some analysis of what
problem you are trying to solve is in order.  Such an analysis
would go beyond my hypothesized difference between your concerns
and Microsoft's and would dig more deeply into your concerns.  I
think that what you are trying to do is ultimately a workaround
for a real solution.  Perhaps, almost nine years after work on
IDNA2003 completed and with the prospect of a huge upsurge of
IDN use in the relatively near future, the browser vendors and
the rest of us could band together to push for a solution to the
problem itself, not just workarounds that are not really very
good at user protection against skilled attackers.  

In principle, there is a much better answer than any of those
three models. It is for ICANN to get really serious about doing
properly what you are trying to approximate.  If ICANN had the
will to change its behavior and rules to stop the use of IDNs
(and, for that matter, domain names generally) for
mostly-untraceable deceptive behavior, the phishing piece of the
problem that all three of these approaches are trying to address
would stop for gTLDs.  If it did, it is likely that the natural,
domestic, pressures on and from governments to clean up the
ccTLD act would be immense.  For the countries that did not
conform, variations on your Type B model would be even more
attractive than they are today because they would represent real
consensus about indifferent behavior -- a sort of collective
Internet community shunning of those who were not interested in
conforming to community norms.   

It probably won't happen.  The communities that appear to have
the most influence in ICANN are far more interested in promoting
the sale of as many names as possible no matter who they are
sold to, under what conditions, for what purposes, etc.   Even
more sadly, the window on that approach probably closes forever
next month: while one can imagine transition plans based on
requiring registrant authentication at annual renewal now, once
ICANN starts signing long-term contracts with lots of "you pay
your money, you do what you like" gTLDs, I have no idea how the
community could go back even if that were considered a good idea.

At least in principle, ICANN is open enough that the situation
could be turned around.  Write your favorite ICANN SSAC member
asking that they review this situation and insist that it be
solved at the registration end, not leaving it to browser
vendors to perform heuristic or highly subjective tricks (note
that Patrik is now SSAC Chair).  Write your favorite ICANN GAC
member or government official who is concerned about Cybercrime
and suggest that this issue deserves attention.  If you are
involved with the ICANN at-large process, talk with your
representatives.  Or try notes to ICANN's CEO and/or Board
Chair.  These three types of browser filtering approaches each
have their strengths and weaknesses (which ones are best depend
on your assumptions), but the real solution to the user
protection part of the problem lies, at least IMO, at the other
end of the process.

regards,
     john