Browser IDN display policy: opinions sought
phoffman at imc.org
Tue Dec 13 16:37:58 CET 2011
On Dec 13, 2011, at 2:26 AM, Gervase Markham wrote:
> 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
> everywhere simultaneously.
> That doesn't sound awesome.
A zone *always* has the right to change information for sub-domains in the zone; many of those changes will affect the story you gave above. The policy for name display is one of the least-offensive of these changes.
As others have said, if you want permanent perfection, don't look for it in the DNS.
>>> 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".
Correct. If you haven't cached .com's name display policy when you get that, go ahead and display it.
> This part of the idea sounds like it would need something like, er, the
> Public Suffix List to make sure it worked correctly. ;-)
It sounds like you are fishing for reasons to support it; have a party with that.
>> 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.
You are possibly mixing up levels again. If a user goes to www.nastypr0nsite.com and hides that by clearing everything in his browser, that action does not clear the DNS cache at the same time.
>>> 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?
The latter. Repeating myself: the first time a user goes to www.somenewsite.com, if the policy for .com is already in the user's DNS cache, there is no additional lookup.
>>>> 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?
One level up, you said "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". I disagreed because TLDs are registered in the root, and I do not want ICANN enforcing a policy on TLDs that the TLDs cannot change over time.
More information about the Idna-update