Browser IDN display policy: opinions sought
gerv at mozilla.org
Mon Dec 12 17:54:27 CET 2011
On 12/12/11 15:23, Andrew Sullivan wrote:
> On Mon, Dec 12, 2011 at 11:15:55AM +0000, Gervase Markham wrote:
>> The publicsuffix.org list and the IDN TLD whitelist are two separate
>> entities and used for different purposes (although I happen to be
>> involved in them both). Let's not get them mixed up :-)
Hey, if the equivalent to the PSL info was published in DNS instead by
everyone, I'd be the first to applaud :-)
>> And ponies! ;-)
> Well, it's bound to sound that way if you don't take seriously the
> idea that there might be a way to figure these things out.
There was a winking smiley ;-)
> Suppose that zone operators (not just the root or TLDs, but any random
> zone you liked) had a mechanism by which you could look up their
> policies for, say, code point inclusion. That is, I'm RegyCo, and I
> run .example. I put an SRV or URI or something record at .example
> that points you to a policy document that tells you what code point
> ranges are permitted together in a single label in my zone, and also
> (for that matter) what code points I will register _at all_. Now you
> are in a position to decide whether you think my policy is sensible;
> and you are also in a position to decide whether any given label
> actually meets my own stated policies.
If I am to do such a check (and presumably to fail if the domain doesn't
meet it), what about when a policy changes to be more strict? How do you
deal with grandfathering?
What about performance? I would need to look up the rules for the zone
"foo.com" every time I accessed bar.foo.com, for lots of values of foo.
This doesn't sound like it would improve performance.
If there are going to be rules, by far the best place to enforce them is
once at domain registration time, not in real time in performance
critical code millions of times a day at access time.
Approaches like this were considered when we initially made the decision
to go with the solution we have. The bottom of
"The Moz/Opera anti-spoofing mechanism is the result of widespread
public analysis and discussion, and has the following advantages:
It is simple to code and deploy: about ten lines of code for the
It is the sole survivor of a large number of alternative proposals
that were considered and rejected. Unlike most of the other rejected
proposals, it does not need any modifications to the DNS protocol, or
distribution of "language" codes for labels, nor does it require
multiple DNS lookups, large character tables in the browser, or
real-time access to WHOIS information.
More information about the Idna-update