Add support for IDN (punycode) handles

[drash-course]

Currently, all @handle.tld are displayed in their ASCII form. This is fine for most domains, but some TLDs accept IDN domains and it'd be nice to support them fully. I found at least one other issue #6354 discussing this.

Of course, this opens the can of worms that are IDN homograph attacks.

I'm implementing a strategy similar to Firefox and Chrome : detect what "scripts" are being used in the IDN domain label and forbid mixing problematic scripts. In those cases, the punycode (ASCII) version of the label is shown instead. I've also added detection for the uppercase i, which can be mistaken for the lowercase l in many fonts. There are certainly more to add.

The security of this feature can't be taken lightly, and I hope this PR can create a discussion to progress this issue forward.

[mary-ext]

this is really cool, are you basing this off Chrome/Firefox's exact behavior or just the general idea of what they're doing? I wonder if they have test suites for this that we can copy over.

[drash-course]

this is really cool, are you basing this off Chrome/Firefox's exact behavior or just the general idea of what they're doing?

Just the general idea.
I've read https://bugzilla.mozilla.org/show_bug.cgi?id=1332714#c17 to understand the attack, and what Firefox considers their responsibility to filter.

Arguably it's the responsibility of Registrars to make sure people are not registering domains that are confusable. But in practice, those domains can be registered. So the status quo is that it's up to browsers and apps to carefully sanitize IDN domains and minimize the confusion potential with ad-hoc filters.

[surfdude29]

It might be a good idea to open up a discussion about this in the atproto repo:

https://github.com/bluesky-social/atproto/discussions

[drash-course]

It might be a good idea to open up a discussion about this in the atproto repo:

https://github.com/bluesky-social/atproto/discussions

I'm reading the AT Proto Handle spec and it seems they already took a position on IDN handles.

Internationalized Domain Names ("IDN", or "punycode") are not directly relevant to the low-level handle syntax. In their encoded form, IDNs are already valid hostnames, and thus valid handles. Such handles must be stored and transmitted in encoded ASCII form. Handles that "look like" IDNs, but do not parse as valid IDNs, are valid handles, just as they are valid hostnames. Applications may, optionally, parse and display IDN handles as Unicode.

@surfdude29 Do you think ATProto needs to standardize the filters apps should use to avoid IDN homograph attacks? Maybe ATProto can standardize what the security goals are. On the other hand, standardizing a specific implementation sounds unwise when you want to be able to react to novel attacks with new code / checks.

Edit: The ATProto discussion is at bluesky-social/atproto#3227

[surfdude29]

@drash-course I didn't know about that part of the ATProto handle spec tbh, so I may well have been over-cautious in suggesting it would be a good idea to discuss it over at the atproto repository as well.

However, I think you have raised some excellent points in your post there, and I hope that others who know a lot more about it than me (including Bluesky team members like @bnewbold) see it and are able to give feedback.

[drash-course]

I'm working on a more standard sanitization algo that follows https://wiki.mozilla.org/IDN_Display_Algorithm, and I'll add tests. I'll update this PR when it's ready, hopefully in a few days.