Firefox: open about:config, set network.IDN_show_punycode to true. Next time you open the page, the address bar will show <a href="https://www.xn--80ak6aa92e.com/" rel="nofollow">https://www.xn--80ak6aa92e.com/</a> instead of <a href="https://www.apple.com/" rel="nofollow">https://www.apple.com/</a>. Better yet, always type in or bookmark pages where you might enter sensitive information.<p>I was surprised this was still an issue, as I heard about IDN homograph attacks years ago.
What if you just don't click on any links in email? Particularly if they are really important sites. Just accomplish the proposed task another way. For example, if you get an email from Paypal, stating that you need to update a credit card or something, don't click their link, instead open a browser and enter "<a href="https://www.paypal.com"" rel="nofollow">https://www.paypal.com"</a> yourself, and go into your account information and look for your saved payment methods.<p>edit: typos
Which is why I look for the organization's name in the browser bar when I'm logging in to a high-value website (Google, Apple my bank, etc). For those who don't know the UI for extended verification certificates see the difference in the screenshot: <a href="http://imgur.com/a/ycVwA" rel="nofollow">http://imgur.com/a/ycVwA</a>.
Amusingly, Facebook seems to block this link from being posted publicly (The site reports "There was a problem updating your status. Please try again in a few minutes" - private messages work fine however).<p>I wonder what Facebook's heuristic there is, since they don't seem to block all punycode URLs. Maybe something about character distribution (all latin-like characters -> probably phishing)?<p>Edit: Actually, it might not be a block at all. I think it might just be a bug in Facebook's URL parser, since when pasted into messages the automatic hyperlink is set to <a href="http://invalid.invalid" rel="nofollow">http://invalid.invalid</a>.
The latest version of Chrome renders the URL in the original punycode, not as apple.com. The browser vendors all use their own algorithm for deciding when to render as punycode vs unicode:<p><a href="https://www.chromium.org/developers/design-documents/idn-in-google-chrome" rel="nofollow">https://www.chromium.org/developers/design-documents/idn-in-...</a>
If you use a password manager, it most likely won't auto-fill apple.com's passwords on <a href="https://www.xn--80ak6aa92e.com/" rel="nofollow">https://www.xn--80ak6aa92e.com/</a>
I really hope things like this do not lead us to a mentality that anything that isn't the Latin alphabet is malware or spam. There are people in the world using non-Latin alphabets and allowing them to have domain names in their native alphabets is a good thing, we just haven't worked out how to do it securely yet.<p>Disabling the rendering of punycode is actually not helpful in cases where you wanted to visit a domain using the Cyrillic alphabet which you want to be sure of, and someone registered some similar looking domain which looks equally like a bunch of gibberish to the one you're looking for.<p>Some suggestions, maybe good, maybe bad:<p>* It may be as simple as adding a character set into the address bar<p>* Flag a warning if the domain name alphabet doesn't match the page content (as would be the case in this example) or maybe something else
>This affects the current version of Chrome browser, which is version 57.0.2987 and the current version of Firefox, which is version 52.0.2.<p>Firefox 52.0.2 & linux here, and the "L" in the URL looks like a capital i with serifs - quite noticeable. Perhaps different on windows/osx though.
Text-only browser shows the IDN, not the phished domain.<p></sarcasm>I guess I need to "upgrade to a modern browser" for websites to work correctly?</sarcasm><p>As an aside, I still do not understand how "modern" browsers evolved to hiding portions of the URL or using a phony address bar i.e. "omnibox" to the right of the real address bar.<p>In the first case, it seems to offer no benefit other than to hide important details.<p>In the second case, it seems so overtly deceptive for newcomers to the www that I am surprised they could pull it off.<p>Maybe these things have changed recently as these monster programs are constantly changing. If so, pardon my ignorance.<p>Is it not true that users who do not understand the basics of www usage e.g., what is a domain, a URL, etc. are always going to be at risk of manipulation?
As much as I like Firefox, I don't really agree with their reason for not considering this to be a bug: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1332714" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1332714</a><p>> Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected<p>> programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are<p>> buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the<p>> responsibility of domain owners to check for whole-script homographs and register them.<p>> We can't go blacklisting standard Cyrillic letters.
I wanted to share the fake Apple URL with my team, and Slack expanded it to <a href="https://www.xn--pple-43d.com" rel="nofollow">https://www.xn--pple-43d.com</a> when I hit send.
Even though Safari is behind the curve for many web tech features, I've been pretty happy using it as my main browser for the last few months. On a MacBook Pro, none of the browsers even come close to competing with Safari when it comes to battery life. I still keep Chromium and Firefox installed, and Chromium is my go-to option for web development. But I'm happy to find that Safari has sane defaults when it comes to displaying URLs.
Verified by: Let's Encrypt<p>Somehow i was expecting that comodo was the one culprit for the valid cert but i forgot how easy is to ask for certs like this. Sometimes i think that lets encrypt is hurting more than doing good.
I thought about normalising homographs then I tried out an implementation.<p><a href="https://github.com/nalply/homoglyph_normalize" rel="nofollow">https://github.com/nalply/homoglyph_normalize</a><p>The idea is: get confusables.txt from Unicode and generate from that a JavaScript object which does the mapping.<p>It's not guaranteed to work, I didn't even test it, but it's perhaps a starting point for whatever you want to do with it.
The good news is, it's hard to find characters that actually look like latin characters. This uses the Cyrillic characters, but there are no characters resembling g or d, so most websites are safe from this. Though, it is incredibly infuriating that it doesn't show the punycode unless you try to find it.
Would a possible solution be to check if a url contains 'ambiguous' letters, and if so, transform all these letters to the more common versions and then check if that domain already exists? If it does, give the user a warning.
The bug report in Chromium.<p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=683314" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=683314</a>