Hi, On Tue, Feb 20, 2018 at 12:54:40AM -0800, Jim DeLaHunt wrote:
1. The underlying problem is that the registry (here, .com) permitted registration of a domain name which was confusable with another one. The right place to fight this kind of phishing with confusable characters is at the domain registry level.
I sort of agree with that, but I want to note some cautions. 1. It is not possible as a general matter to ensure that nothing "confusable" ever gets registered. We have no control over the fonts people are using, or the visual acuity of people, or the context in which the label is presented. All of those have a great deal to do with whether people get phished, quite apart from the content of the labels. 2. The "no-script-mixing" rules that many of us are arguing for are also drags on innovation, and in some locales there are good reasons to mix scripts. That tension won't go away just because we said so. 3. The distinction between identifiers and branding appears to be almost totally lost on people, with even the Unicode Technical Committee, who recommend against emojis in identifiers, saying that they're ok in domain names (contrary to the IDNA2008 specifications). I don't have any idea what to do about this, because most people don't understand how context-free and locale-free identifiers could possibly work reliably. (That includes me.) 4. There is no way to make rules for the entire DNS, because it is a distributed datbase with distributed authority. More generally, however, the position, "Use the A-label form" is in effect the position, "Don't use IDNA." For the most conspicuous fact about A-labels is that they're equivalently meaningless to everyone. That hardly seems like a usability win.
3. The people for whom A-labels instead of U-labels
There is nobody for whom A-labels are useful. A-labels are those things that have the prefix (xn--) and a punycode-encoded string in them. 'anvilwalrusden.com' has two labels, neither of which is an A-label, though they're both LDH-labels. This is covered in painful detail in RFC 5890, so I refer the gentle reader to that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com