PunyGuard Blocks Every Internationalized Domain After Chrome 154 Renders Cyrillic apple.com Lookalike

A developer has published a Chrome extension that blocks every internationalized domain name, in response to a demonstration that Chrome 154 renders an all-Cyrillic fake of apple.com exactly like the genuine site. According to a post on dev.to by the extension's author, the address bar displays аррӏө.com — five Cyrillic letters — as-is, with no visible sign of the substitution. The post cites a Gizmodo article as the origin of the demonstration.

How the lookalike slipped past Chrome

Chrome has a long-standing defense against these homograph tricks: when a domain contains characters judged confusable with another script, the browser displays it in Punycode, the ASCII encoding used on the wire. Instead of аррӏө.com looking like apple.com, the user would see xn--80a6aa68c8d.com.

The catch is the word "judged". Chrome's decision rests on a list of lookalike characters, and as the author explains, the Cyrillic letter ө (U+04E9) was not on it. With that single omission, all five Cyrillic letters rendered in full, looking exactly like the real domain.

The author argues this is less a mistake than a structural limit of the method: the number of characters is enormous, their appearance changes with the font, and any list of confusables is permanently incomplete. Human eyes fare no better, since a one-character difference defeats careful visual inspection. PunyGuard's answer is to stop judging by appearance altogether.

One rule, zero judgment

The extension checks a single property: whether any label (dot-separated piece) of the hostname begins with xn--, the prefix every internationalized domain carries on the wire regardless of how it is displayed. It is implemented as one Chrome declarativeNetRequest rule whose condition is this regex:

^https?://(?:[^/?#]*[.@])?xn--

Because Chrome itself enforces declarativeNetRequest rules, the extension never needs to inspect the pages a user visits. Details from the post: the rule also catches IDN top-level domains such as example.xn--q9jyb4c, but ignores xn-- appearing in the middle of a label or in the path and query. It applies to top-level navigations and embedded iframes, not to subresources like images and scripts. And since Chrome converts the hostname to Punycode before matching, it does not matter whether the IDN arrives as Unicode typed into the address bar, a clicked link, a server-side redirect, or a URL handed over from another application.

Deliberate collateral damage

The design decisions are documented in an architecture decision record. Script-based filtering — allowing kanji and kana while blocking Cyrillic — was rejected because confusable characters exist within allowed scripts too, which merely relocates the problem. Visual-similarity matching was rejected as the same approach that just failed inside Chrome.

There is no allowlist and no "proceed just this once" button, because phishing ultimately depends on persuading people to click through warnings. The cost is explicit: legitimate domains such as 日本語.jp get blocked as well. The author is blunt that this is acceptable to them personally, stating a dislike of Japanese-language domains and describing the tool as built first for themselves, with that caveat placed near the top of the README.

One further tradeoff sits in the blocking mechanism. Chrome's declarativeNetRequest offers a plain block, which would leave users staring at an unexplained ERR_BLOCKED_BY_CLIENT error, or a redirect. The author chose a redirect to a warning page bundled with the extension, so the reason for the block is always clear. That choice requires the broad permission, which the extension offsets by doing nothing else: no content scripts, no external requests, no stored data.

The code is available on GitHub, and the post also points to a complementary technique using the Unbound DNS resolver, described in Japanese by riorist, which works regardless of browser and is arguably the more secure option according to the author.

Why it matters

This is a small tool, but it frames a real gap. Browser IDN protections are heuristic: they depend on curated lists of confusable characters, and one missing entry was enough for a five-letter fake to perfectly impersonate apple.com in a current Chrome release. PunyGuard demonstrates the opposite extreme — a deterministic rule keyed to the wire format rather than the rendering, enforced by the browser's own network layer with a single regex and no page visibility. For users whose legitimate destinations are all ASCII, the false-positive cost is near zero and an entire class of homograph phishing disappears. For everyone else, it at least makes the tradeoff explicit: convenience versus an attack that no amount of careful looking reliably catches.