Browser IDN display policy: opinions sought
gerv at mozilla.org
Tue Dec 13 11:26:52 CET 2011
On 12/12/11 18:18, Paul Hoffman wrote:
>> (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
OK, yes. I was typing faster than thinking. For "blocking", read "start
displaying the name as Punycode".
I guess what I'm saying is that with this browser-enforced mechanism,
someone can register a name, verify that it renders fine in all
browsers, start using it, build a business, and then a change of
registry policy leads to their name starting to appear as gobbledegook
That doesn't sound awesome.
>> 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".
This part of the idea sounds like it would need something like, er, the
Public Suffix List to make sure it worked correctly. ;-)
> 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.
A user who clears their history wants, or is sufficiently likely to
want, the browser to entirely forget that he has visited the sites he
has visited - in such a way that someone examining his computer cannot
tell he has been there. Therefore, any browser record of domain names
(whether it's HSTS pin information, domain name letter display policy,
or anything like that) also has to be cleared.
>> 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.
Are you saying that these lookups would be non-blocking?
Or are you saying that implementing it in a browser used by 450 million
people wouldn't lead to billions of additional requests per day?
>>> Fully disagree. That restricts TLDs to never changing their
>> 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?
I'm sorry, I've failed to follow this subthread of the discussion. Can
you restate your point for me?
More information about the Idna-update