We generally call World Wide Web clients “browsers.” This nearly ancient term – it’s more than 20 years old! – reflects a time when a web client’s main use was to present static information for personal consumption. Those days are long gone. 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.
Today those browsers are everywhere: on phones, in automobiles, on airplanes, in orbit and even in refrigerators. Their ubiquity reflects their importance and it is natural to wonder, for a tool that is so important to the Internet: how well do browsers support IDNs?
There are two crucial issues: display and retrieval.
Browsers must decide what to display to the user. Often the decision of what to display is based on the circumstances the browser finds itself in, rather than a hard-coded set of rules. For instance, the browser must decide whether to display the Unicode or the Punycode version of the IDN. Displaying the Punycode version of a URL destroys consumer confidence in IDNs because what is typed into the browser (or, clicked upon) is not reflected in the address bar. The user’s expectation that the IDN representation of the domain name would be preserved is effectively quashed.
Browsers also, in many circumstances face a dilemma when the device, for instance, a copying machine, is completely unable to display the characters in the IDN. Worse yet, if the browser does not have access to Unicode script there is no chance that the IDN will successfully display.
In 2016, our research finds that all major desktop/laptop browsers are built with APIs software libraries that support parsing of IDNs in URLs as well as doing conversions between Unicode and Punycode to support requests for DNS resolution. What each desktop browser does with the Unicode is inconsistent across these browsers: the rules for display of IDNs are different for different browsers. This has been consistently the situation since our early report in 2012 and is a result of each browser developer taking a different approach to security issues related to IDN display in the browser’s address bar.
Browsers in other contexts is a different situation. In 2016, we were able to test browsers embedded into other kinds of devices: cars, electrical appliances and televisions.
As we saw in 2015, there are two types of browsers being embedded into alternative, non-computing devices. First, we see versions or adaptations of desktop/laptop browsers converted for use in alternative settings. Second, we see custom-built browsers coded especially for the alternative environment. Versions of existing browsers, adapted for new uses, are especially present in large-scale environments such as digital televisions. When built on a code base of existing browsers, these web clients tend to have adequate support for IDNs. However, custom browsers are often being built for constrained environments such as automobiles or household appliances. Our research this year found no browser, custom built for a particular environment or purpose, able to correctly process or display IDNs. This was true of the browsers we tested built into cars and those built into consumer household appliances.
Today, approximately 15% of new vehicles have some sort of Internet connectivity and a few support shared Internet hotspots. This is likely to increase in the near future – 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 access to the Internet. This set of features will likely begin to migrate from higher-end, luxury models toward typical consumer models in the coming years. So far, the browsers built into the entertainments systems are custom-built and provide very poor, or no, support for IDNs.