Homoglyphs in URL tooltips

[j4james]

Windows Terminal version

1.18.1421.0

Windows build number

10.0.19045.2913

Other Software

No response

Steps to reproduce

1. Open a bash shell in Windows Terminal
2. Execute the following command:

printf "\n\e]8;;https://www.xn--fcbook-3nf5b.com/\e\\TOTALLY REAL FACEBOOK LINK. YOU CAN TRUST ME.\e]8;;\e\\ \n\n"

3. Hover over the resulting link text to see where the URL is going to take you.

Expected Behavior

There was a new feature advertised in the v1.18.1421.0 release notes that said "when you're hovering over a URL, we now display it in a partially-encoded form to help you avoid homoglyph attacks". So I expected there would be something in the tooltip indicating that this link was not exactly what it seemed.

Actual Behavior

The URL displayed in the tooltip gives the impression that it's linking to https://www.facebook.com/, which is very misleading.

Does PR #15095 perhaps rely on functionality that's only available in Windows 11?

[j4james]

I should add, I'm quite impressed that it decoded the punycode URL in the first place, and I think it's a good thing that we don't discriminate against non-Latin languages. However, there should at least be some indication when a URL contains characters that aren't ASCII.

[ianjoneill]

I can reproduce this in Windows 11 (10.0.22621.1702), so it doesn't seem to be Windows 10 specific.

(Edited to include version number)

[DHowett]

Ah, you know what? I was totally wrong about what we prevented. Great catch.

(The change actually prevents the display of URLs with an RTL/LTR override in them, which can be used to mask the destination.)

[lhecker]

For reference: https://chromium.googlesource.com/chromium/src/+/main/docs/idn.md
The relevant code is fairly complex and it doesn't seem like WinRT or Win32 implement a similar API already. As such the best move for us might be to disable IDNs for the tooltip in general.

[j4james]

As such the best move for us might be to disable IDNs for the tooltip in general.

If you mean we shouldn't convert the punycode version to Unicode, that wouldn't help, because it could just as easily have been Unicode to start with. I only used the punycode encoding in my example to make it obvious it was doing something dodgy.

A simple solution could be to check if the URL has anything other than ASCII, and if so, add a little warning in the tooltip saying exactly that (e.g. "Warning: this URL contains characters that aren't ASCII").

[lhecker]

Oh, I meant that we could actively encode any non-ASCII URL as punycode ourselves. It's what a hypothetical domain would actually be named anyways after all. IdnToAscii will return the input string if it's ASCII already.

Edit: Actually, we should probably show both: https://www.unicode.org/reports/tr36/#Punycode_Spoofs

[j4james]

OK, that makes sense. I thought you were saying there wasn't an API for that. I realise now you were talking about Chrome's IDN policy algorithm.

Actually, we should probably show both: https://www.unicode.org/reports/tr36/#Punycode_Spoofs

Yep. I was just going to recommend that.