dready blog v2.0

What do you do on a long weekend? Code, code…. and more code!

That’s all I’ve been doing the whole US labor day weekend, working on various projects. One of the projects that i’ve been burning my weekends on is IDNSearch.net. The idea is to have a showcase of IDN’s as they are being used today. It serves as a central searchable directory of IDN’s that is community-driven.

Finally, after many burnt weekends and missed lunches, the site is ready for public consumption.

Features

• searching - this is an essential feature by definition
• voting - yay or nay? Have your say
• commenting - discuss with each other
• tagging - organize them by category
• trackback - ping an IDN to have it link to your blog
• RSS feed - stay tuned to the latest additions

I’ve spent most of today scouring the web for interesting IDN’s and manually adding it to the site. As of now, there is a total of 38 IDN’s spread across 11 TLD’s and 10 languages, and already you can see the potential for it (well, at least I can.) So, if you’re reading this, please explore the site and send me your feedback. If you have a little more time, help by either submitting an IDN or casting some votes! Tell your friends about it. Thank you and God bless!

URL: IDNSearch.NET

Just released version 1.1 of EchIDNA which includes confusable characters detection and bulk punycode conversion tool. It has been 16 months since the last release in April 2005, and I’m glad I finally managed to dedicate some time on it. Head over to http://idn.isc.org/ to download it.

Here’s a shot of it in action:

This is a proposal to the major browser producers supporting IDNA to advertise their IDN capabilities. One way of doing it is to include a token in the User-Agent HTTP request header. According to RFC2616, the User-Agent header is used for

“statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations.”

This will serve at least 2 purposes:

1. Allows web sites to encode anchor URLs in the native page encoding or HTML entities (&#xXXXX;) for clients that advertises IDNA support. For other clients, punycode can be used for baseline compatibility.

2. Provides IDN versioning information. There have been sprouts of discussions over the next version of Nameprep profile (or even a new IDNA, maybe even a new IDN solution). This would be a good preparation for things to come, regardless of which direction the future takes us.

Below are some examples of popular browser User-Agent strings I pulled from my logs (and my proposed addition):

Firefox: *
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 IDN/RFC3490

Googlebot (which I believe is IDNA compliant):
Mozilla/5.0 (compatible; Googlebot/2.1;+http://www.google.com/bot.html) IDN/RFC3490

Internet Explorer 6:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) IDN/RFC3490

Opera:
Mozilla/4.0 (compatible; MSIE 5.0; Windows ME) Opera 5.11 [en] IDN/RFC3490

Safari:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/312.8 (KHTML, like Gecko) Safari/312.6 IDN/RFC3490

Other possibilities for advertising this capability exists, such as a custom header X-IDN-Version. The same information could possibly be exported to Javascript via the navigator.userAgent field, or some other custom Javascript API (this is more an example of what should NOT be done rather than a recommendation.)

* To achieve the result in Firefox, type this into the URL bar (in a single line):

javascript:Components.classes["@mozilla.org/preferences-service;1"].getService()
.QueryInterface(Components.interfaces.nsIPrefBranch)
.setCharPref(”general.useragent.extra.idna”,”IDNA/RFC3490″);


This should take effect immediately. Go to http://www.wannabrowser.com/ and verify that “IDNA/RFC3490” is displayed in the “HTTP User Agent” box.

The .NET RFP evaluation report by Telcordia is disappointing because:

IDN was not given the weight that it deserves; it was lumped together under the general heading of “Ability to support current feature functionality of .NET”.

Sure, IDN is a current feature of .NET, but it is a poorly implemented one. Currently, anyone on the Internet can register all sorts of mambo-jumbo IDN in .NET using randomly-picked Unicode characters. What’s more worrying is that you can spoof legitimate domain names using look-alike Unicode characters ¹. The cause of this in .COM/NET is inadequate policy on Verisign’s part.

Of the five proposals, Sentan’s is the only one that had a decent game plan for rectifying the situation. Their proposed plan of action is: grandfather existing names, remove controversial tables, add mature tables, then allow registrations only in languages for which language tables exist. NeuLevel has adopted tables from various currently deployed languages in their respective countries, and have consulted with those registries and language communities. The languages proposed were: Chinese, Japanese, Korean, French, German, Icelandic, Swedish, Norwegian, Danish, Polish, Thai. Each of these languages have been deployed in one or more registries, and the language tables are publicly available either on the IANA language table registry or on the registry sites. Specifically, advice was sought on the deployment of said language tables in a gTLD context, the security implications and how best to be conservative without crippling legitimate use.

I believe that this approach, though conservative, echoes many of the concerns raised by the community in the recent IDN list discussions. Sentan should be applauded for putting cultural respect, compliance and the stability of the Internet over profit.

Apparently, the evaluators missed the point.

At first glance, Verisign does comply with ICANN’s IDN guidelines but, really, it is taking advantage of the fact that the guidelines (deliberately or not) omitted many details. They did not violate the clauses of the guidelines, but have in every sense violated its spirit and purpose. Not only did Verisign show no plan to improve the situation in their proposal, they were proud to claim to be the only registry to support all languages and code points.

This message was also posted to ICANN’s net-rfp-general forum.

Disclaimer: Though I have worked as a consultant for NeuLevel providing expertise in the area of IDN’s, I am no longer affiliated any of the RFP bidders.

¹ This is referred to as the IDN Homograph Attack. When the IDN standards were developed, it was decided that protocols should be kept simple, leave the policy making to the registries and other relevant organizations. As a result, the number of Unicode characters banned at protocol level were only restricted to spacing and control characters, private use blocks and other “non-characters”.

Returned from the my first ICANN meeting in Cape Town, where I gave a presentation on James Seng’s brainchild—IDN-OSS, in which I am taking a technical role to develop an open source plug-in to enable IDN functionality in Internet Explorer. Presentation slides are available here.

I was also lucky enough to present on behalf of Darin Fisher (netwerk God at Mozilla) the status of Mozilla’s IDN support.

Also on the same panel was Michel Suignard from Microsoft, who talked about the challenges of implementing IDN in Internet Explorer from a security perspective. From what I gathered, don’t expect IDN support in IE for at least a year from now.

We just released the new IDN-OSS plugin for IE (still alpha), featuring a taskbar icon (wheeee!) and on-the-fly enable/disable. Head over to http://idn.isc.org/ to get it!

I’ve been working on IDN-OSS for a few months now. Although we have yet to produce a usable product suitable for the general audience, we have just released an alpha-quality plugin for Internet Explorer 6 on Windows 2000/XP. There is also a simple IDN conversion tool for Windows.

There is still a lot of work to be done, so I will continue to work on the client for the next couple of weeks to bring it to the masses. Stay tuned!