Browser IDN display policy: opinions sought

[Paul Hoffman]

On Dec 12, 2011, at 9:33 AM, Gervase Markham wrote:

> On 12/12/11 17:24, Paul Hoffman wrote:
>> 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.
> 
> So published policies can only ever been loosened, not tightened?
> 
> (If they were tightened, existing domains might fail the new policy,
> which would result in them being blocked. This is what I mean by the
> grandfathering problem.)

Published policies can be tightened. No one so far has talked about *blocking* domains: we have been talking about when to display names in one form or another. Note that "loosening" might be the same as "tightening": it can change the way a domain appears in the location bar.

>> 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.
> 
> So just block the domains, then?

Why would you want to block a domain instead of just showing the Punycode-encoded name?

>>> 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.
> 
> Except if it's the first time the user has visited the site, or the user
> has cleared their browsing history, or is using private browsing, or
> their cache has been cleared due to memory pressure on their mobile
> device, or...

When a user visits www.example.com and the browser only knows the policy for .com, the browser might look up the policy for example.com. Or, it might not: a browser that cares about display speed might have a list of single-script terminal labels that don't need looking up, such as "www".

You can code your browser however you want, of course. To me, a sane browser would not clear the Punycode display history when the browser clears its browsing history or goes into private browsing. The display of domain names (or anything!) in the location bar is unrelated to the content of the page. 

>> Or was that meant to be another strawman objection?
> 
> Oh, no.
> 
> Historically, the idea that a browser will burden the Internet and its
> own speed characteristics with millions or billions of additional
> requests per day, (and making them blocking - so don't render the site
> until it returns) for a purpose such as this has been met with
> incredulity and barely-suppressed laughter from our performance and
> networking teams.

That's fine: this isn't such a proposal. I'm not sure why you are treating it as one.

>>> 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.
> 
> Surely the opposite? If a TLD enforces a policy at registration time, it
> can change that policy and start accepting registrations under the new
> one, without consulting anyone.

Have you forgotten that TLDs are registered with the root? Or are you making an exception for them in the "once at domain registration time" rule above?

>> 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.
> 
> I'm not saying that. But no other browser vendor has adopted an approach
> which requires extra network requests for each new site visited, and
> periodically thereafter. And I don't expect them to.


Noted. You also expected them to adopt the Mozilla IDN policy, but that didn't happen either. We all surprise each other, often to good effect.

--Paul Hoffman