Browser IDN display policy: opinions sought

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Tue Dec 13 11:19:14 CET 2011


On 2011/12/12 21:04, Gervase Markham wrote:
> On 12/12/11 06:54, "Martin J. Dürst" wrote:
>> 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.
>
> Perhaps if we are throwing blame around,

Sorry about that.


> a little could be reserved for
> registries which said "this is not our problem, guvnor, it's intended to
> work this way"?

Please rest assured that I didn't want to single out the browser side, 
nor Firefox in particular. I have plenty of blame left for the 
above-mentioned registries, and will not hesitate to throw it their way 
as much as they deserve.


> I deny the charge that we over-reacted.

To take some very simple examples, why do I have to look at 
http://www.xn--viagnie-eya.com/ in Firefox when I can see 
http://www.viagénie.com in Chrome? The other way round, why do I have to 
look at http://xn--80abvnkf0a.xn--p1ai in Chome when I can see 
http://биатлон.рф in Firefox? (and why can I see both of these in Opera 
and in Safari?)

There is absolutely *nothing* wrong with displaying either of these 
domain names. Otherwise, the other browsers displaying them, and their 
users, would be in deep trouble, wouldn't they? That's the reason I say 
that browsers overreacted.


> The list of reasons for our
> policy at the bottom of this page:
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> was compelling then and is still pretty compelling today IMO.

Others have poked holes at that already. I personally don't think it was 
such a bad idea to try and get the registries to do their job by some 
more or less gentle pressure. And I don't think that the criteria you 
have are overall unreasonable. And it might even have worked quite a bit 
better if all the browsers had collaborated.

But if I were in the position of a registry, I'm not sure I'd taken the 
time to submit bug reports. One browser might be okay, but what if all 
browsers were doing this? And what if their criteria were all slightly 
different? The number of browsers is another dimension over which this 
approach doesn't scale. (For those people who think that there are only 
four or five browsers around: That's totally wrong. There are four or 
five major browsers, but there are many, many others.)

Another potentially very important aspect is 'who is in charge'. I have 
absolutely zero insider knowledge, and am just speculating, but it might 
be possible that Verisign simply doesn't think they should in any way 
obey instructions of a browser maker as to what they can and can't 
register, or what they should and shouldn't document, or that they have 
to submit a bug report (rather than the browser maker doing the legwork 
if they choose to use their own criteria).

If something like the above speculation is true, then the whole thing 
may have ended up as a power struggle between registries and browsers, 
fought on the backs of users (both those registering IDNs and those 
simply wanting to browse them).

Anyway, I don't necessarily want Firefox to abandon policy B. Definitely 
not if that meant switching to A, which has just about the same number 
of problems, just different ones. As you already are thinking about 
changing policies (which would mean implementing them), why not 
implement another policy and then OR the results together. That way, the 
huge number of current false positives gets reduced quite a bit.

Regards,    Martin.


More information about the Idna-update mailing list