[chii]

> A domain using only Cyrillic characters that happen to spell a Latin word (like “аpple” in all-Cyrillic) may still render in the address bar’s font and look identical.

that is very interesting.

I imagine the browser could take some context clues and switch rendering to puny code if the locale of the user is nowhere near a cyrillic region. But that is only going to patch some edge cases and miss others.

Ideally, the solution is password managers everywhere, which don't have this vulnerability, instead of using human eyes to visually recognize web urls and thus is vulnerable.

[bojan]

> I imagine the browser could take some context clues and switch rendering to puny code if the locale of the user is nowhere near a cyrillic region.

Anyone reading this - please, please, please do not make any assumptions based on the end-user's geography.

Signed, someone who can cross 3 national and 4 language borders within a few hours of driving.

[jdranczewski]

The article mentions this only briefly, but browsers already do this kind of heuristic protection! See https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending... or https://chromium.googlesource.com/chromium/src/+/main/docs/i... for a Chrome-specific blog post.

I think the lack of exploration of the context around the problem and current mitigations is an issue with the article - it spends a lot of time talking about the possible threat, but very little time on whether the attack is actually practical with modern mitigations.

[olsondv]

Not to mention it would only apply to clicking spoofed links. Unless the keyboard mapping was compromised, those letters won’t be typed.

[alterom]

>> A domain using only Cyrillic characters that happen to spell a Latin word (like “аpple” in all-Cyrillic) may still render in the address bar’s font and look identical

Here you go:

https:// аррlе.соm

(using English "l" and "m" here, Russian м looks differently)