For example https://почивнидни.com is shown as https://xn--b1aekbb1acci5f.com in Safari. There is no problem in Firefox, Google Chrome and Microsoft Edge.

Also https://детскиградини.бг is shown properly in Safari.

Is there any way to show https://почивнидни.com properly in Safari?

  • 1
    Whois lookup returns “Domain Name: XN--B1AEKBB1ACCI5F.COM” for the first and “DOMAIN NAME: детскиградини.бг (xn--80afcccsdam9a3aim.xn--90ae)” for the second. Commented Apr 1 at 5:41

1 Answer 1


Mixing characters from different scripts in an IDN homograph attack is a common attack vector for phishing scams. Some browsers therefore show the Punycode-encoded IDN name instead of the decoded one to make users aware they are visiting a website which mixes characters from different scripts.

For example, you may think you are visiting apple.stackexchange.com, but you are actually visiting аpple.stackexchange.com. Can you spot the difference? The second one uses U+0430 Cyrillic small letter a (а), instead of U+0061 Latin small letter a (a), which is why it is encoded as xn--pple-43d.stackexchange.com.

This security advisory and the corresponding bug fix in the public WebKit bugtracker seem to imply that Safari uses a case-by-case analysis of individual characters / glyphs, including their surrounding context, in order to decide whether to render the characters as decoded IDN or raw encoded Punycode. Changelog from the patch:

Punycode encode U+15AF when not in context of other Canadian aboriginal code points

So, it appears that, according to some unknown heuristic inside of Safari (WebKit), почивнидни.com is considered "dangerous", while детскиградини.бг is not. As you can see from the above-mentioned patch, what is or isn't considered "dangerous" can change from patch version to patch version, so there is no guarantee that what is shown one way today will be shown the same way tomorrow.

There used to be some basic information available from Apple [archived version of https://support.apple.com/kb/TA22996 from the Wayback Machine], but it is not very informative.

Note that there is nothing wrong about this. In fact, почивнидни.com is not a legal domain name in the Domain Name System, since DNS labels can only contain ASCII characters az, 09, and -. The actual DNS domain name that is registered with the .com DNS zone really is xn--b1aekbb1acci5f.com, and the TLS certificate really is issued to xn--b1aekbb1acci5f.com as well.

In general, a false positive (showing the Punycode when there is no danger of confusion) is fine, since it is only a minor inconvenience. A false negative (showing the IDN when it can be confused with a real, trustworthy domain) can be catastrophic. Therefore, it makes sense to err on the side of caution and rather show one too many domains in its Punycode form than one too few.

  • 1
    I don't think think that it is the reason why it chooses to show https://детскиградини.бг properly. For example Safari doesn't show https://ελλ.ελ properly too.
    – ilhan
    Commented Apr 3 at 10:03
  • 1
    This article seems to indicate that Safari might make the decision based on individual characters, not just whole scripts: sensorstechforum.com/cve-2018-4277-apple-idn-homograph-attack So, it's possible that some security researcher at Apple decided that one combination of characters is dangerous and another isn't. Commented Apr 3 at 11:23
  • 1
    Here's another security vulnerability that also involves just one specific character: ssd-disclosure.com/ssd-advisory-apple-safari-idn-url-spoofing Commented Apr 3 at 11:25
  • 1
    @ilhan: As explained in my answer, and as you can see from the linked patch, Safari considers every single character separately, in its surrounding context. Unicode currently has 149813 characters and 161 scripts, that's 24119893 different combinations. So, the answer to every one of your examples is either "someone, somewhere, sometime at Apple wrote a specific piece of code that specially treats this specific combination of character and script" or "until now, nobody at Apple wrote a specific piece of code that specially treats this specific combination of character and script". Commented Apr 4 at 8:21
  • 1
    Also, your example is not correct. ASCII is not a script, it is a character set and a character encoding. a, e, i, g, l, n, r, t, and ü are all characters from the Latin script, or more precisely, u is from the Latin script and ü is an accented version of u. Commented Apr 4 at 8:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .