An essential part of Universal Acceptance for IDNs (or ‘UA’) is the ability to use IDNs in browsers. A traditional view of browsers is that they are World Wide Web clients in desktops or laptops – indeed, that is their origin. Today, browsers appear in a huge variety of environments, for instance, mobile devices, car dashboards, refrigerators and community kiosks. Today, a human uses a piece of software to dynamically interact with services and content, and to act as a go-between between complex software, content and people. That we call such a tool a ‘browser’ is more of a nod to the history of the Internet than a reflection of what that tool actually does.

The browser has become, for some, the principal human interface to the Internet. As a result, IDN support in browsers is crucial.

In 2018, we note:

  • significant progress in traditional browsers (for instance, browsers on desktops and laptops);
  • improved progress in browsers in mobile devices and those in “alternative” environments; and,
  • the failure to support IDNs on “alternative” devices is a critical barrier to the further success of IDNs.

For this report, we note a relatively recent development in browsers. The URL box on a browser (where the current URL is displayed, or where a user can type a URL into the box) has been repurposed by many browsers as a search tool. For many browsers, the ability to type freeform text into the URL box means that the browser will send that text to a search engine of the user’s choice.  This has implications for IDNs. If the browser does not correctly parse a string as an IDN, it may simply hand the string to a search engine – thus failing the user’s expectations.

Desktop and Laptop Browsers

As in previous years, in 2018 we tested IDNs on seven browsers in “traditional” desktop settings:

  • Chrome
  • Edge
  • Firefox
  • Internet Explorer
  • Mozilla
  • Firefox
  • Safari

For each browser our methodology remains the same as in previous years:

  • Does the browser correctly resolve an IDN URL and display the appropriate page when the IDN is entered?
  • Does the browser correctly display an IDN URL in the location (URL) box once the page has been loaded – for instance, the Punycode version is not displayed?
  • Do internal links on the page display as IDNs and not Punycode?
  • Is it possible to enter IDNs into form fields when displayed by the browser?
  • Are IDNs rendered correctly in browser “furniture” – for instance, tabs, the browser status bar, bookmarks and other places where domain names appear under the control of the browser?

URLs and pages are tested in the following scripts: Arabic, Chinese, Korean, Japanese and Cyrillic.

Where possible, the browsers are tested using Windows 10, Mac OS 10.13 (High Sierra) and Ubuntu 18.04.

The results of this testing in 2018 showed evolutionary improvement in “traditional” browsers. Each browser tested, on all three platforms, is able to correctly resolve an IDN URL when it is typed, or pasted, into the location box. In each case, the browsers were also able to correctly display the IDN URL in the location (URL) box.

Display of the IDN is often dependent on support for the script in the operating system.  If operating system language support is available and if the IDN URL is passed as a UNICODE string (and not Punycode), each one of the browsers successfully displays the IDN URL as part of the content of the page. This metric is dependent on two things: 1] the configuration of the machine; and 2] the HTML being processed for display. As an example, in the case of Windows 10, if the machine has not been configured for language support, some browsers revert to displaying the Punycode rather than the UNICODE equivalent.  In addition, if a web page delivers internal links that are in Punycode, no browser was found that converted those back to their IDN equivalents for display.

IDN rendering in parts of the browser that are not the URL or location bar is not as routine.  If proper handling of the URL in the location bar has become a success story, so-called browser ‘furniture’ is less successful.  A browser has many places where it could display an IDN. For instance, if a web page delivers a ‘title bar’ for the page that contains an IDN, all but two of the tested browsers will attempt to display the IDN.

There is also some variation in how IDN bookmarks are stored and displayed. The goal is to display the IDN URL in bookmarks so that the user can easily read both the descriptive ‘text’ of the bookmark as well as recognise the URL. In several cases, browsers convert the IDN URL to Punycode before storing the bookmark. Subsequent display causes the descriptive text of the bookmark to appear correctly, but the IDN remains as Punycode – a situation that is possibly confusing to the user for the browser.

Mobile Browsers

For this test we examined Chrome, Firefox, Safari and Opera in Android and iOS-based devices.

In 2018, there is notable improvement in the major browsers built for mobile and portable devices.  It is likely that recent updates to the major mobile browsers have included incorporation of native operating system support for IDNs.  The result is that, in 2018, three of the four tested mobile browsers allow the correct entry, resolution, and display of IDNs.

Those vendors of mobile applications, including browsers, that appear to build IDN support into their browsers without using the underlying operating system clearly have more problems with the processing and display of IDNs.

In 2018, we were granted access to browsers installed in automobiles and on refrigerators. These are important examples of the future of browser technology.  However, in all the cases we were able to test in 2018, IDN support was absent even though the browsers were able to display content in scripts other than ASCII.

For ‘connected cars’, approximately 15% of new vehicles have some sort of Internet connectivity and a few support shared Internet hotspots. An informal survey of the automobile market shows this to be on the increase – both through consumer demand and through regulation. In many jurisdictions, there is a requirement that cars be able to make an automatic emergency call in the case of an accident.  Some new car models include, along with their entertainment systems, a set of browser-based applications and tethered access to the Internet. In 2018, we have seen this start to migrate from higher-end, luxury models toward typical consumer models. In the future, browsers in alternative environments – for instance, cars – will need to support IDNs just as we require it in desktops and mobiles.