The Register on IDNs

Posted on by

<sigh> Kieren McCarthy, whose work I normally appreciate, has sounded off on the IDN issue in The Register without doing any research. The following is the letter I sent him, which I’m reproducing here in case anyone else is under any of the same misapprehensions.

FWIW, the three documents his article mentions, which were released by the registrar community, are also ill-informed in thinking we’ve disabled IDNs. This points to a communications failure that we should try and do something about. More on this when I’ve caught up on the 200-odd mails I have in my Inbox on the subject. (Irony noted.)

Sorry, Kieren, but much as I generally admire your work, 0 marks out of 10 for doing your research on this one. We haven’t disabled IDNs, as the follow-up post in my blog (or, heaven forbid, actually downloading the code and trying it) would have told you. All IDN domains in Firefox 1.0.1 and Mozilla 1.8b1 display in their punycode form. Given the timescales we had for releasing the 1.0.1 security update, this was the best solution we could come up with which dealt with the problem, but as we’ve made quite clear, it’s a temporary one only.

Paul Hoffmann, your “knowledgeable expert” you deployed to patronize us by proxy, may be an expert on IDNs, but he’s not an expert on browser or security UI design. Neither am I, but I know enough to tell him that his idea wouldn’t fly, and I did. The other two documents you link to are in fact guidelines for registries to implement to protect users – in fact, some of the very “ICANN guidelines” I mentioned. So, quoting them as an “everyone else disagrees” measure would rather suggest you hadn’t actually read them.

As for mozilla.org being parochial, it seems that I spend half my time answering well-meaning people who put forward ridiculous suggestions about how IDN domains can be “flagged” or “warned against” (Mr Hoffman included) when in fact our goal is to make them first-class domain names in the browser, alongside and equal with traditional domains. This thinking is laid out in my paper “A Plan For Scams” which I also wrote and blogged about recently.

So, just to set everything straight:

  • We haven’t disabled IDNs, just made them ugly in the short term.
  • We are getting together with the other browser and plugin manufacturers, the registry groups, some registrars, the IDN people and the Unicode people to sort something out that’ll work in the long term. Don’t worry – when we have, you’ll be the first to know :-)

Gerv

Update 9.42am: Don’t write emails quickly when in need of sleep. While most of the content above is right (having fixed some typos), as a kind friend has pointed out, the tone is not. I apologise to Kieren for sending him something so ill-considered.

Also, I didn’t mean to count Mr Hoffmann’s remarks among the “ridiculous” ones I’ve seen, only among those which recommended warning against IDNs in some way. So apologies to him, too.

Update 11.54am: and I can’t even spell his name right. Thanks to Smylers for spotting this one.

11 thoughts on “The Register on IDNs”

  4. Imagine you are a Chinaman who likes secure websites with Han URLS.

    Now, with Firefox punycoding all URLS in the address bar, xn-1 and xn-l both look rather similar given English is only your fifth language.

    You are now very susceptible to being phished.

    This measure (OK, I recognize it as being temporary) makes browsing international domain names far far safer for those who understand English.

    It makes browsing international domain names far far less safe for those who do not understand English well.

    Appearance is almost always an excusable thing to drop for security. However, it seems security is only for those who speak English.

    Once again I say: you are being Anglocentric.

  5. Typos fixed – thanks, guys.

    Unicoder: which is more common on today’s Internet – people surfing to potentially-spoofable .com domains, or people using secure IDN URLs?

    Find me a single content-filled secure website with a IDN URL which doesn’t just redirect to a non-IDN URL and I’ll at least admit that you’ve pointed out a minor drawback. But there’s no way that this scenario is more common than the problem we are protecting against by making the change.

    What would you have done, given the short timescale we had available?

  7. Gerv, your claimed respect for Kieren would look a little more plausible if you spelt his name correctly!

  8. I would like to know whether this is the temporary solution or you think this should be the permanent solution. Please try キヤノン.jp and notice it would not redirect, even though it is the same site of canon.jp. If Canon did not register キャノン.jp at the same time, it could be used for some tricky purpose.

  9. Sorry Gervase, but there’s nothing to apology to. Kieren McCarthy article was rubbish, he treated Mozilla’s developpers as “small-minded” based on wrong assumptions, and worse, he spreaded lies and didn’t even checked his “facts”.

    His article was an insult to journalism.

  10. ditto what Ced said, the register’s cool, but it occasionally confuses irrereverence and satire with being nasty to people about things you don’t understand.

  11. Unicoder has a point (although he should put more emphasis on the fact that this solution is known to be temporary).

    This measure definitely increases security all-round, simply because there aren’t many secure IDN domain names.

    However, you are discriminating against the class of international domain names, something you said you would try not to do. There is no incentive at the moment for a site to have a secure IDN.

    Your solution decreases the spoofing surface for users familiar with the Roman alphabet, and increases the spoofing surface for users unfamiliar with Roman alphabet. This is very unfortunate. That said, your patch was absolutely correct, simply because of the numbers of sites of each type. However, in a future with IDN all over the place, this solution would certainly be discriminatory. From the thought you’ve put in I’m sure you’re aware of this, so I think Unicoder is being a bit unfair.

    Maybe you should allow IDN by default for characters in languages the user has specified in the languages options, and punycode all others?
    That would probably be more elegant, although it increases the spoofing surface… Up to you to crunch the numbers and see, I guess.