The impact on TWiki is roughly as follows:

• TWiki's use of domain names within external links - probably the biggest impact, but various links already work fine (see below)
• TWiki server hostname: TWiki doesn't do much with the hostname, so may just work.
• TWiki's use of domain names within %INCLUDE% URLs - could be an issue

Here are some examples taken from a W3C presentation - give them a try in your browser:

• http://räksmörgås.josefsson.org (encoded in ISO-8859-1 in page, maps to http://xn--rksmrgs-5wao1o.josefsson.org)
• http://納豆.w3.mag.keio.ac.jp (encodeded using Unicode NCRs in page, maps to http://xn--99zt52a.w3.mag.keio.ac.jp)

Some tests using IDNs in TWiki external links are shown below.

• Swedish test site about räksmörgås, domain part written with ISO-8859-1
• Japanese test site, domain part written with NCRs - 納豆

IDNs not in the site's character set (set in TWiki.cfg in the $siteLocale variable, displayed using %CHARSET%) will need to be written as Unicode NCRs (NumericCharacterReferences? ), e.g. &&#32013; to generate 納, but that is the same constraint on any Unicode text using in a TWiki site that does not use Unicode as its site character set. Note that Unicode support is still under development - see ProposedUTF8SupportForI18N for details.

It would also be necessary to modify the URL parsing code to handle embedded http:// URLs.

Browsers seem to take care of converting domain names that include ISO-8859-1 characters and Unicode NumericCharacterReferences? (NCRs) into the correct ASCII-safe Unicode ('punycode') required by the IDN standards, rather like the way that they convert such characters in the non-domain part of a URL into UTF-8 URLs.

Browser support is improving - IDNs are already supported by Mozilla Firebird/Firefox 0.7, Netscape 7.1, Opera 7.20, Konqueror 3.2 and Safari 1.2 (MacOS X 10.3), but not by IE 5.0/5.5/6.0 (although IDNs do work with a Verisign plugin).

This Netscape 7.1 article provides a good overview of the state of IDN globally.

IDNs are already available in Sweden, Japan, Germany (big influx of IDN registrations recently) and Poland, according to this Mozillazine story.

-- RichardDonkin - 10 Mar 2004

IDN support in various non-IE browsers is vulnerable to a homograph attack - phishing sites can use IDN to appear exactly like the real site. There's more discussion of homograph attacks in this paper.

IE is also vulnerable if using an IDN plugin. In Firefox 1.0, only examining the certificate in detail for a secure site revealed the use of IDN.

This is not a TWikiSecurity issue, but a phishing hole on the browser side.

UPDATE: MozillaZine article on this vulnerability, including link to Secunia listing and possible Firefox workarounds (disabling IDN, not clear if this works well though).

UPDATE: More useful discussion at Mozillazine including possible solutions. Firefox 1.0.1 will ship with IDNs set to display Punycode by default (e.g. http://räksmörgås.josefsson.org will be displayed in URL bar as http://xn--rksmrgs-5wao1o.josefsson.org).

-- RichardDonkin - 24 Feb 2005

The Unicode Consortium has published a paper on security issues with Unicode, covering visual spoofing of URLs through IDN amongst other issues.

-- RichardDonkin - 12 Aug 2005