Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
Update to show this is now what we do
This page explains the plan for changing the mechanism by which how Firefox decides whether to display a given IDN label (a domain name is made up of one or more labels, separated by dots) in its Unicode or Punycode form.
Implementing this plan is was covered by {{bug|722299}}.
==Background==
If we just display any possible IDN label, we open ourselves up to [http://en.wikipedia.org/wiki/IDN_homograph_attack IDN homograph attacks], where one identical-looking domain can spoof another. So we have to have some mechanism to decide which ones to display and which ones to not display, which does not involve comparing the domain in question against every other single domain which exists (which is impossible).
===Current Previous Algorithm===
Our current previous algorithm is was to display as Unicode all IDN labels within TLDs on our [http://www.mozilla.org/projects/security/tld-idn-policy-list.html whitelist], and display as Punycode otherwise. We check checked the anti-spoofing policies of a registry before adding their TLD to the whitelist. The TLD operator must had to apply directly (they cannot be nominated by another person), and on several occasions we have required policy updates or implementation as a condition of getting in.
We also have had a character blacklist - characters we will never display under any circumstances. This includes those which could be used to spoof the separators "/" and ".", and invisible characters. This still exists.
===Need For ChangeWhy We Changed===
be serving our users.
===Other Browsers=The New Idea==
all come from the same script, or are from one of a limited and defined number of allowable combinations. The
hope is that any intra-script near-homographs will be recognisable to people who understand that script.
We will retain the whitelist as well, because a) removing it might break
some domains which worked previously, and b) if a registry submits a
good policy, we have the ability to give them more freedom than the default restrictions do.
So an IDN would be is shown as Unicode if the TLD was on the whitelist or, if not, if it
met the criteria above.
==Algorithm==
If a TLD is in the whitelist, we will unconditionally display Unicode. If it is not, the followingalgorithm will applyapplies.
[http://www.unicode.org/reports/tr39/#Restriction_Level_Detection Unicode Technical Report 39]
===Possible Issues and Open Questions===
The following issues are still open, but should were not considered important enough to block initial implementation.
Further suggestions from TR #39:
===Downsides===
This system would permit permits whole-script confusables
(All-Latin "scope.tld" vs all-Cyrillic "ѕсоре.tld"). However, so do the
solutions of the other browsers, and it has not proved to be a
significant problem so far. If there is a problem, every browser is equally affected.
to make sure that their customers
cannot rip each other off. Browsers can put some technical restrictions in place,
only people in a position to implement the proper checking here. For our part,
we want to make sure we don't treat non-Latin scripts as second-class citizens.
