6 September, 2017
Emoji, the pictorial symbols typically presented in a colourful cartoon form, are nowadays being widely used on smartphones, in chat, in email applications and in social media. Their increasing popularity has prompted the question of whether they could be used in domain names, just like other non-American Standard Code for Information Interchange (ASCII) letters (e.g. Han, Cyrillic and Arabic) used in internationalized domain names (IDNs). This regulatory ambiguity may be ended, however, by a recent advisory issued by the Internet Corporation for Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee (SSAC) strongly discouraging the idea.
While it is already possible to register domain names with emoji at the second level under the country code Top Level Domain (ccTLD) .WS (Samoa), ICANN has not yet expressed its formal position on this issue.
In its advisory of 25 May 2017 to the ICANN Board on the use of emoji in domain names, the SSAC recommends that the ICANN Board reject any TLD (root zone label) containing emoji and, more generally, strongly discourages the registration of any domain name that includes emoji in any of its labels. The SSAC also advises registrants of domain names with emoji that such domains may not function consistently or may not be universally accessible as expected.
In order to justify its recommendations, the SSAC first relies on the standard for Internationalized Domain Names in Applications (IDNA) which specifically excludes emoji from the characters accepted for use in domain names.
According to the SSAC, since the IDNA was designed to create a set of stable and secure identifiers for IDN registration and has been accepted by most applications, it seems reasonable, particularly from an architectural perspective, to follow the same approach by prohibiting the registration of domain names including emoji.
In the SSAC’s opinion, the ambiguity in the use of emoji constitutes the major obstacle to the generalisation of emoji domain names. The SSAC underlines that many emoji are visually similar and can be difficult to distinguish, especially when displayed in small fonts or by different applications, as no standard specifies exactly how they should be displayed. In other words, unlike natural languages, emoji are not required to be visually uniform (one code point displayed the same way in all circumstances) or visually distinguishable (different code points displayed in ways that permit them to be disambiguated regardless of context). These variations and ambiguities are perfectly acceptable in ordinary conversational exchanges, but will inevitably increase the risk of user confusion when they exist in domain names, which must be unambiguously resolved independent of any context.
For example, the happy face in emoji may have dozens of variations and it is generally difficult for people to figure out how to specify exactly what happy face they are trying to produce. As a result, the user is less likely to reach the intended resource and may instead be tricked by a phishing site or other intentional misrepresentation.
It should be noted that, further to the implementation of IDNs, such risk of confusion may result from the deliberate commingling of different scripts in the same IDN (e.g. <ɢoogle.com> where the first “ɢ” is typed in Cyrillic, although ICANN prohibits, in principle, the commingling of different scripts in the same IDN) and the adding of emoji to domain name labels will only make this problem worse and may further reduce acceptability of non-ASCII labels if they are perceived as being simply too confusing or dangerous.
Furthermore, the emoji modifiers, such as the special zero width joiner (ZWJ) code point allowing the user to “glue” together several individual emoji, or the Fitzpatrick Skin Tone modifier code point which makes it possible to apply different colours to emoji, are very likely to create additional confusability concerns when they are used in domain names. For instance, to a user, a single unmodified emoji might look exactly the same as its “glued together” counterpart or it may be quite difficult for a user to detect colour differences due to his or her colour vision deficiency.
Finally, as emoji are intrinsically visual constructs, there is no universal agreement upon the way to speak or enter an emoji, unlike natural language text. As a result, it is difficult to develop accessibility software helping visually impaired users to use emoji as internet identifiers. It is worth noting that, even for non visually impaired users, remembering and typing the exact emoji that the registrant intended could still be a real challenge.
Based on the above, the SSAC concludes that, due to their nature and particularities, emoji should not be used in domain names processed in the Domain Name System (DNS) as it is an exact-match lookup service and they will not be accepted or processed consistently. However the SSAC further underlines that this does not preclude or prohibit the use of emoji in other mechanisms that exist for the usage of strings that are not intended to be used as identifiers (e.g. clickable HTML anchor text or search terms typed into web search engines).
The SSAC Advisory on the use of Emoji in Domain Names is available here.
