From IUCG - Internet Users Contributing Group

To:

• John C Klensin <klensin@jck.com>,
• "Martin J. Dürst" <duerst@it.aoyama.ac.jp>,
• Gervase Markham <gerv@mozilla.org>,
• Patrik Fältström <patrik@frobbit.se>,
• Cary Karp <ck@nic.museum>

Subject:

Re: Browser IDN display policy: opinions sought

Cc:

• idna-update@alvestrand.no,
• iucg@ietf.org,
• "iab@iab.org IAB" <iab@iab.org>,
• IESG <iesg@ietf.org>

.

Contents 1 PREQUEL 1.1 At 12:12 09/12/2011, Gervase Markham wrote: 1.2 At 16:43 09/12/2011, Gervase Markham wrote: 1.3 At 18:25 09/12/2011, Gervase Markham wrote: 2 Text of the mail 2.1 At 17:35 10/12/2011, Patrik Fältström wrote: 2.2 At 17:48 10/12/2011, Cary Karp wrote: 2.3 At 16:28 10/12/2011, John C Klensin wrote: 2.4 At 03:06 11/12/2011, J-F C. Morfin wrote:

PREQUEL

This prequel was the initial part of the thread. It was no part of the quoted mail.

The 2011/12 post-IDNA2003/IDNA2008 state of the HTTP Internet Use Interface (browser) was docummented by contributions of Gervase Markham (Firefox) as follows :

At 12:12 09/12/2011, Gervase Markham 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-google-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.

Has anyone lobbied one browser manufacturer or another to change their policy? Is there another option that is not currently in use which would be better?

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

At 16:43 09/12/2011, Gervase Markham wrote:

On 09/12/11 15:34, Paul Hoffman wrote:

Without understanding both how a TLD gets on "a whitelist", and how "registry policy (is) used to prevent abuse", we cannot evaluate whether A or B would be better for Firefox. This information is critical to the analysis.

OK :-)

Mozilla's current policy on such things is listed here: http://www.mozilla.org/projects/security/tld-idn-policy-list.html

We try to avoid being prescriptive about what method registries should use to avoid homograph problems. The obvious ones are blocking and bundling, but some registries have come up with very creative solutions - one registry registering Cyrillic domains, for example, requires that every domain contain at least one Cyrillic letter which is not an ASCII-confusable.

There is a certain amount of judgement applied as to whether a registry's policies are adequate. While we try and be consistent and fair, that potentially can lead to accusations of unreasonable treatment.

On 09/12/11 15:34, Paul Hoffman wrote:

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

If Firefox (and Opera) were the only browsers that the site operator cared about, this would be good. However, I believe that is true for approximately 0% of the sites in the world. (The same would be true if there was a "D" that only applied to Chrome.)

Quite so. Which is why I suggested that Firefox having a Type B policy does not help so much in practice, because we were unable to convince other browsers that this was the best approach.

On 09/12/11 15:34, Paul Hoffman wrote:

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

That has been my feeling all along, although I stopped expressing it a while ago when it seemed like the Firefox team would never change. I'm glad to hear that the discussion is opening up.

Do you think my reservations about Type A policy are justified, or do you think I overstate the case? If you would, in an ideal world, prefer everyone to be Type B, would you be interested in a push to try and persuade other browser makers to change tack instead of Firefox?

On 09/12/11 15:34, Paul Hoffman wrote:

Absent anything convincing about how a TLD gets on "a whitelist", and how "registry policy (is) used to prevent abuse", I would hope that Firefox would join Chrome and IE with showing all single-script strings that it is believed that the user will understand.

My issue is that the method of determining "that it is believed a user will understand" is going to fail in an unknown but I would guess fairly high percentage of cases.

I wonder how we can get some statistics on that?

At 18:25 09/12/2011, Gervase Markham wrote:

On 09/12/11 16:46, Paul Hoffman wrote:

Thank you for that explanation. So, "if your IDN domain works in one copy of Firefox, it works in them all", but that might change over time if a TLD changes its policies. But we know that many TLDs very much want to change their policies with respect to bundling.

Without disputing your assertion, I'd be very interested in more information if you have it. Why do TLDs not like bundling?

On 09/12/11 16:46, Paul Hoffman wrote:

No; yes. :-) I think that if type A were not justified, there would have been many complaints about it over the years; I haven't heard any.

And you think that take-up and real-world use of IDNs on the consumer Internet has been broad enough that we would have heard them?

On 09/12/11 16:46, Paul Hoffman wrote:

If you would, in an ideal world, prefer everyone to be Type B, would you be interested in a push to try and persuade other browser makers to change tack instead of Firefox?

My ideal world is much closer to A than B. It is, in fact, one of the reasons that I switched to Chrome for my day-to-day work browsing that involves IDNs.

So do you add scripts for languages you don't speak to the Chrome preferences to get the IDNs to render?

On 09/12/11 16:46, Paul Hoffman wrote:

I wonder how we can get some statistics on that?

We can't. It is inherently impossible to measure because if some company wants to identify themselves with <somestring>.<theirtld> and that renders wrong in IE, they just won't register it.

But surely the point is that it may well render right in their IE, but wrong in the IE of their customers (e.g. if their customers are using US English Windows and IE)?

Text of the mail

At 17:35 10/12/2011, Patrik Fältström wrote:

Let me emphasize that what John writes here is extremely important. If you have the slightest opinion of what "confusing" implies, and what implications approval of "too similar" TLDs might have, specifically cross scripts, you should let ICANN know.

Now.

I do explicitly also sign this email as the chair of SSAC. That is not a mistake.

Patrik Fältström

Chair ICANN Security and Stability Committee

At 17:48 10/12/2011, Cary Karp wrote:

The advisory group for ICANN's Variant Issues Project will be holding its wrap-up meeting in Marina del Rey on Monday and Tuesday The issues report it is focusing on will finalized in short order thereafter. At least three of the people on the idna-update list will be in MdR so anything said on it can also be channeled into the VIP discussion.

The "now" that paf mentions really is NOW.

/Cary

At 16:28 10/12/2011, John C Klensin wrote:

As to how realistic that assumption is, you might consider:

(1) ICANN's Board apparently (minutes have not yet been posted) passed a resolution on Thursday exempting IDN variations on .EU from review for visual spoofing and other forms of confusability.

At 03:06 11/12/2011, J-F C. Morfin wrote:

Dear John,

ICANN has nothing to do with the Internet *technology* that the IETF is meant to positively influence (RFC 3935) and that Gervase has questions about on behalf of Firefox.

The IAB has.

ICANN claims benefits from a limited set of TLDs in class IN, outside of private networks, outside of IUsers interests, and outside of non-Internet digital technologies that want to use/already use the digital naming system and its root names (e.g.: .gsm, the Chinese TLDs and keywords, etc.). The area of use of browsers (and probable forked browsers, if open source ones become IUsers-foreign) is much larger.

IMHO, the last thing we need, hence my slowdown for more than one year, is an inadvertent browser war, or Internet use confusion, over IDNA. This is why, as IUsers, we certainly are interested in presentation-layer-related-services being offered by browser manufacturers, as long as they are RFC documented and we can turn them up/down at our own will.

The way I understand the problem is that the ball has been in your IAB field for more than one year after my appeal and the IESG/IAB have clarified that my area of concerns did affect, but did not belong to, the IETF scope. The IAB was (this is how I understood its road map) to decide how IDN/IDNA SHOULD be used in the Internet technology context. We did not move on this because I had hoped that we could maintain the IDNA2008 consensus and permit the IAB to move faster in not interfering. However, it turns out that I was wrong because the blocking reality questioned by you, me, Lisa, etc. remains: the IDNA2003/stringprep application-to-application architectural scheme does not scale to IDNA2008.

We all have also known for years that this issue is to be addressed prior to January 12, 2012.

The only viable architectural solution that I can figure out, but I could also be totally wrong, is subsidiarity at the IUI (intelligent use interface) on a fringe to fringe basis. The implications on many other diversity related items should have been discussed, over the course of the last two years, if some interests (IAB, IETF, ICANN, IGF, GAC, Unicode, Google, etc.) wanted to keep the transition under joint control. Since nothing has been discussed and, therefore, prepared and tested, we are heading towards an entirely new internet (IDv6 addressing, shared virtual unique root file, IDNgTLDs shambles, IANA revamp, etc.) without any idea of the way we want to manage it together, or even if we want to manage it together.

If the IAB wants to document its IAB chosen architecture for this new internet, it has exactly one month left to be clear about a framework. Then, practical experimentation will have to start prior to the first ICANN IDNgTLD being officially accepted. Otherwise, it will not be innovation towards a better internet for all. It will be a long-term costly competition (global fight) between an obsolete use, a commercial+ use and an emerging efficient use of the Internet.

I am going to document an IUse position that is to be I_Ded on January 10 if the IAB does not commit beforehand to a position that IUsers can consensually support. I have no objection to discussing my memo while I am preparing it (on the iucg@ietf.org mailing list: as you know, I cannot discuss it on the ietf@ietf.org mailing list).

However, please let seriously discuss only network architecture and stop cosmetic layer violation confusions.

At 02:02 11/12/2011, Paul Hoffman wrote:

[the response to the users] needs to come from a stable, trusted body. I question whether such a body who is willing to make a table exists.

Until now I thought that such a competent body was the IAB.

This "really NOW" I will know if I was right.

Best

jfc