Browser IDN display policy: opinions sought

[Gervase Markham]

On 21/12/11 15:24, Paul Hoffman wrote:
>> And I have responded that this is not your problem; we are tackling
>> that sort of thing via other means (such as domain highlighting).
> 
> It is "our problem" in that you are introducing multiple ways to
> alert users about questionable domain names, 

The methods share a common approach - attempt to avoid showing the user
something which might confuse them into believing a falsehood. In one
case, it's greying-out non-critical bits of the domain name, in another,
it's changing the characters to not use potentially-confusing glyphs.

> The proposal people are making is that, if your motivation for
> showing Punycode is that there might be fraud, that you instead use
> the same alert technologies that you { are | will be } using for
> all-ASCII names that you believe are fraudulent.

The domain name highlighting approach doesn't make sense in this case of
potentially-confusing IDNs; in fact, the default behaviour makes the
problem worse. So I'm not sure how you are suggesting it could be used
as a mechanism for alerting the user to risk.

>> (For those not familiar: Firefox can use various data sources, but
>> by default uses the Google SafeBrowsing list, to put up warnings
>> whenever a site on the list is encountered.)
> 
> That seems quite reasonable to me.

Except that such mechanisms are always after-the-fact. The block list
data delta is downloaded once per day (live checking means that you send
your entire browser history to Google, something many people are not
comfortable with). The lifetime of individual phishing sites is usually
measured in hours.

I am not saying it is impossible that we will give up entirely and just
rely on "safe browsing" to protect Firefox users; but it would seem an
odd thing to do to say "yes, let people register domains of the
type/style of www.paypa-cyrillic_a-l.com; I'm sure eventually someone
will figure out it's a scam and add it to the blacklist". Such domains
seem to me to have no use but fooling people; the question is, how do
you distinguish them from other IDNs in a 0% false positive, 0% false
negative way? Is that even possible?

>>> If you want to get additional heuristics from TLDs about policies
>>> to help you decide when you should add a warning, the technical 
>>> community can talk about how to make that happen in a way that
>>> would be useful to application vendors. (So could ICANN, but I
>>> suspect that would be a waste of everyone's time.)
>> 
>> Could you expand on how that might happen?
> 
> Andrew already proposed maybe a new RRtype in which a zone can
> publish its script policy. That one attracts me most so far because
> it keeps DNS-related decisions in the DNS and uses clear TTL
> semantics for caching.

But the problem is not that the browser does not know the script policy
for a given TLD; the problem is that some TLDs do not have, or do not
have an acceptable, script policy. Even if we remove the notion of
"acceptable" entirely, then still, the only thing this would allow a
browser to check would be that a TLD is in conformance with its own
stated policy. That does not sound to me like a particularly useful
thing to check, as I would expect it to be true pretty much 100% of the
time. Why would they publish one policy and then accept registrations
under another?

Like the IANA registry of accepted scripts, this mechanism seems to
solve a problem that the browsers do not have.

Gerv