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 2017, we note:
- significant progress in traditional browsers (for instance, browsers on desktops and laptops);
- slow to no progress in browsers in mobile devices and those in “alternative” environments;
- the failure to support IDNs on mobile 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
In 2017 we tested IDNs on seven browsers in “traditional” desktop settings:
- Internet Explorer
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.12 and Ubuntu 17.
The results of this testing in 2017 showed evolutionary improvement in “traditional” browsers. Unlike 2016, 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.
Testing this year indicates that, 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. We have found that this metric is highly 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 browser ‘furniture’ is less successful, although there has been progress since last year’s study. If a web page delivers a ‘title bar’ for the page that contains an IDN, all but two browsers will attempt to display the IDN. We also discovered some variation in how IDN bookmarks were stored and displayed. The goal is to display the IDN URL in bookmarks so that the user can easily read both the ‘text’ of the bookmark as well as recognise the URL. In three cases, browsers appear to 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 appears as Punycode.
For this test we examined Chrome, Firefox, Safari and Opera in Android and iOS-based devices.
There are significant problems for mobile devices and IDNs. First, there are large discrepancies between the abilities of the same browser on different platforms. Second, unlike desktops, mobile devices do not successfully retrieve web pages when presented with an IDN. Almost every mobile device and browser tested fails to correctly display the IDN – reverting to the Punycode in almost every instance. In 2017, only Chrome allows the correct entry, resolution, and display of IDNs.
The problem appears to be a decision by the browser designer to either use native operating system support for IDNs or build IDN support from scratch. Those vendors 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.
For 2017, 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 2017, 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, in the near future, 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 2017, 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.