Browser IDN display policy: opinions sought

[Paul Hoffman]

Not speaking for Andrew, just myself:

On Dec 12, 2011, at 8:54 AM, Gervase Markham wrote:

> 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?

The zone owner deals with grandfathering. They publish a policy that reflects all of the zones they control.

If you are asking "how does a browser deal with grandfathering when a policy changes?", I would say the same thing: assume that the zone owner has reasons for publishing that policy.

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

A sane browser would look up policies based on the browser's own policy update strategy, and would risk missing a policy update. Further, given that the policies would have TTLs on them, you don't even need to think about looking up a policy until the TTL expires. Further, the browser will know whether or not the zone had a policy before and base its lookup strategy on that.

Or was that meant to be another strawman objection?

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

Fully disagree. That restricts TLDs to never changing their policies. A browser vendor might want this convenience, but there are plenty of people who would like the browser vendors to be more responsive to changes than that so that IDNs can be more useful.

> Approaches like this were considered when we initially made the decision
> to go with the solution we have. The bottom of
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> says:
> 
> "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
> Mozilla implementation.
> ...
>    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.
> ...

Noted. So, if other browser vendors adopt a different approach, are you saying Mozilla won't? I thought the purpose of this thread was to revisit the question of what would be best for the users.

--Paul Hoffman