Browser IDN display policy: opinions sought

[John C Klensin]

(Sorry... I've been necessarily offline for a couple of hours --
this note was started before I dropped out and is being finished
now, so some issues may have already been addressed by others.)

--On Monday, December 12, 2011 12:05 +0000 Gervase Markham
<gerv at mozilla.org> wrote:

> On 09/12/11 20:55, John C Klensin wrote:
>> 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".
> 
> Hi John,
> 
> Thank you :-)
> 
>> 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.
> 
> (Side point: I'd see universal font provision as something
> that's the OS's responsibility.)

I absolutely agree.  I also believe that being sure that domain
names are not confusing or otherwise intended for hostile
purposes is the job of ICANN (for TLD names, SLD policy, and
enforcement of both) and registries and, if necessary,
governments.  I believe that there are better ways to control
and fix the spam problem than recipient-end filters, no matter
how those filters are designed or how well they work.  I have
several similar beliefs that probably put me in an alternate
reality, if not over into "insane".  Understanding that those
beliefs aren't realistic today, I recognize and agree with your
desire to provide nearly-last-resort user protections (the last
resort is consistent user care and intelligence and even I'm not
sufficiently idealistic and unrealistic to believe in that).  

We, and certainly most others on this list, are painfully aware,
not only about the fundamental technical principle that it is
hard to display a script for which one has no fonts (however we
might feel about U-labels versus A-labels, either is clearly
better than "????" or its equivalent) and about how much
confusion can be added simply by the choice of type styles and
sizes one uses (e.g., I believe that the Firefox change in
recent versions to drop the typesize of the display of full URIs
when my mouse pointer moves over a link and to make the location
of that display less predictable to be security-lowering -- but
maybe that is just me). 

In this modern world, I'd like to see every operating system
support a good reference type style, with highly differentiated
characters, for all or most the the characters defined by
Unicode.  I'd like to have that type style able to be referenced
in a way that makes it accessible to applications even when the
user has chosen different defaults.  And I'd like to see
applications use it for display of security-sensitive objects
(not just domain names and IRIs, but, e.g., user and certificate
names and certificate contents), no matter how conventional
content is displayed.  That implies that I'd like to see XML,
HTML, etc., tags to identify such data.  

Of course, that implies that I'd like such a drastic increase in
the world supply of ponies that everyone who wanted one could
have one (and the means to keep it in comfort).
 
>> 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. 
> 
> You are. Mozilla is fine with that, in that we make many
> similar judgments for our users in lots of areas on a regular
> basis (the inclusion of certificate authorities being one
> obvious example).

Indeed.  And reasonable people can question those decisions too.
You and I do have a difference of opinion about whether users
should be able to override those decisions and how painful (or
obvious) it should be to do so if it is possible.   In my world,
not only should those options exist, but users should be able to
easily import security preference profiles that might be offered
by interested third parties (e.g., if I believe that Patrik and
I are about equally paranoid and about the same things, and he
wants to take the time to designate which certificate providers,
domains, etc., he is willing to trust, then, if I can persuade
him to share (either because he is nice or because I am willing
to pay for the privilege) he ought to be able to easily export
those settings and I ought to be easily import them.  And that
should be the case whether he and I are using the same browser
or different ones.  Again, I understand these are fantasies and
well out of IETF's scope, but I think it is all part advising
you (and ICANN, and W3C, and governments and other bodies who
think they care) about how Mozilla should proceed.

>> 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.  
> 
> You seem here to be suggesting a blacklist ("suspect trees")
> rather than a whitelist. Depending on how it was constructed,
> that might be somewhat controversial! :-)

No.  I think that, in the presence of sufficient authority and
consensus, there is no difference between a blacklist and a
whitelist.  Ultimately, if one maintains or uses a list, one has
to figure out what to do with the questionable cases.  To the
extent to which a policy amounts to "these are the known good
guys and we will reward everyone on that whitelist with "good"
name displays and punish everyone else with "bad" name displays,
you are basically running a blacklist whose membership is
determined by a simple set operation on the list of TLDs.   For
at least many of the folks who object to your particular version
of a "Type B" policy, that is the real source of the objection.

>> 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 opinion is that other forms of user warning are not going
> to be effective - if you want a user not to be fooled by a
> particular visual presentation, the only way is to not make
> that visual presentation.

A reasonable position, even if one doesn't agree with it.   I
again suggest that the language-based models are concerned about
that visual confusion model only as a secondary goal (whether
they realize that or not) because language-based (or even
script-based) models are almost completely ineffective at
avoiding confusion caused by a determined attacker.  Your
approach, based on a judgment --however crude-- about registry
policies and tolerance for confusing registrations is much
better in that regard, if only because you are asking the right
question.

>> 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.
> 
> Amen!
> 
>> 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.
> 
> It's deeply disappointing that solving this problem wasn't an
> obvious, basic goal of the process from the beginning!

I couldn't agree more.  But, ICANN, like every other body in
this strange activity we call the Internet, ultimately deals in
tradeoffs.  Independent of the history of how we got here --
interesting (and I could tell you a lot of stories), but largely
irrelevant going forward -- it is perfectly natural for someone
in the ICANN decision process to say "well, no one has
complained to _me_ about that, so it isn't really a problem".
I can assure you that lots of people are saying, loudly and
repeatedly and sometimes claiming to be speaking for the users
and/or us, that ICANN's goal should be to enable the selling of
as many names as possible, with as few restrictions as possible,
so the variation of "4000 people have told me that want no rules
and not a single one has told me that there is a problem that
ICANN needs to solve" is an even more plausible excuse.   I've
come to the conclusion --perhaps much later than I should have--
that it is time to eliminate at least that set of particular
excuses for inaction and not taking responsibility.  And the
only way that is possible is if lots of folks who are concerned
about the issues and understand why start making the issues
clear to ICANN.   ICANN also isn't the IETF: whether it should
be that way or not, a hundred loud voices often speak much more
persuasively than a single coherent technical (or even security)
argument.

best,
    john