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