Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
no edit summary
This page explains the plan for changing the mechanism by which 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 covered by {{bug|722299}}.
==Background==
Our current algorithm is 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 the anti-spoofing policies of a registry before adding their TLD to the whitelist. The TLD operator must 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 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. (XXX Do we need to update this to remove some of those, like ZWJ/ZWNJ, for IDNA2008?)
===Need For Change===
[http://www.unicode.org/reports/tr36/proposed.html#Security_Levels_and_Alerts Unicode Technical Report 36],
defines a "Moderately Restrictive" profile. It says the following (with edits for clarity, after discussion with the author):
<blockquote>
characters are permitted without restriction.
Additional checks, as suggested by TR #39 section 5:
* Display as Punycode labels which use more than one numbering system (we would need a list of numbering systems in Unicode)* Display as Punycode labels which contain both simplified-only and traditional-only Chinese characters, using the Unihan data in the Unicode Character Database (should be < 16k of data for a simple binary test)* Display as Punycode labels which have sequences of the same nonspacing mark (we would need a list of, or the name of a class containing, all such marks)
===Possible Issues and Open Questions===
The following issues are open, but should not block initial implementation.
* Check to see that all the characters are in the sets of exemplar characters for at least one language in the Unicode Common Locale Data Repository. [XXX What does this mean? -- Gerv]
Also:
* Should we document our character hard-blacklist as part of this exercise? It's already visible in the prefs. Are any characters in it legal in IDNA2008 anyway?We should review it to make sure we aren't disallowing characters now allowed by IDNA 2008.
* Do we want to allow the user to choose between multiple "restriction levels", or have a hidden pref? There are significant downsides to allowing this...
* Do we ever want to display errors other than just by using Punycode? I suggest not...
