Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
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. | 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== | ==Background== | ||
Line 11: | Line 13: | ||
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. | 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. | 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. | ||
===Need For Change=== | ===Need For Change=== | ||
Line 49: | Line 51: | ||
[http://www.unicode.org/reports/tr36/proposed.html#Security_Levels_and_Alerts Unicode Technical Report 36], | [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): | defines a "Moderately Restrictive" profile. It says the following (with edits for clarity, after discussion with the author): | ||
<blockquote> | <blockquote> | ||
Line 73: | Line 75: | ||
characters are permitted without restriction. | characters are permitted without restriction. | ||
Additional checks: | Additional checks, as suggested by TR #39 section 5: | ||
* Display as Punycode labels which use more than one numbering system | * Display as Punycode labels which use more than one numbering system | ||
* Display as Punycode labels which contain both simplified-only and traditional-only Chinese characters | * Display as Punycode labels which contain both simplified-only and traditional-only Chinese characters | ||
* Display as Punycode labels which have sequences of the same nonspacing mark | * Display as Punycode labels which have sequences of the same nonspacing mark | ||
===Possible Issues and Open Questions=== | ===Possible Issues and Open Questions=== | ||
Line 83: | Line 85: | ||
The following issues are open, but should not block initial implementation. | The following issues are open, but should not block initial implementation. | ||
Further suggestions from TR #39: | |||
* 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] | * 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] | ||
Line 89: | Line 91: | ||
Also: | 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? | * 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 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... | * Do we ever want to display errors other than just by using Punycode? I suggest not... |