Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
No edit summary |
No edit summary |
||
Line 22: | Line 22: | ||
has not applied for inclusion, or because we do not think they have sufficiently | has not applied for inclusion, or because we do not think they have sufficiently | ||
strong protections in place. In addition, ICANN is about to open | strong protections in place. In addition, ICANN is about to open | ||
a large number of new TLDs. So either maintaining a whitelist is going to become | a [http://newgtlds.icann.org/ large number of new TLDs]. So either maintaining a whitelist is going to become | ||
burdensome, or the list will become wildly out of date and we will not | burdensome, or the list will become wildly out of date and we will not | ||
be serving our users. | be serving our users. | ||
Line 29: | Line 29: | ||
The Chromium IDN page has a [http://www.chromium.org/developers/design-documents/idn-in-google-chrome good summary] | The Chromium IDN page has a [http://www.chromium.org/developers/design-documents/idn-in-google-chrome good summary] | ||
of the policies of Chrome/Chromium and the other browsers. | of the policies of Chrome/Chromium and the other browsers. Unfortunately, no consensus has emerged on how to do | ||
this. Those other mechanisms were considered, but many of them depend on the configuration of the user's | |||
computer (e.g. installed languages), and this does not give site owners any confidence that their IDN domain | |||
name will be correctly displayed for all their visitors (and no way of telling if it's not). | |||
==Proposal== | ==Proposal== | ||
The plan is to augment our whitelist with something based on ascertaining whether all the characters in a label | The plan is to augment our whitelist with something based on ascertaining whether all the characters in a label | ||
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. | |||
[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], | ||
which is about Unicode and security, defines a "Moderately Restrictive" profile which we could use. | which is about Unicode and security, defines a "Moderately Restrictive" profile which we could use. It says | ||
the following (with edits for clarity): | |||
It says the following (with edits for clarity): | |||
<blockquote> | <blockquote> | ||
Line 84: | Line 87: | ||
This system would permit whole-script confusables | This system would permit whole-script confusables | ||
(All-Latin "scope.tld" vs all-Cyrillic " | (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 | solutions of the other browsers, and it has not proved to be a | ||
problem so far. If there is a problem, everyone is equally affected. | significant problem so far. If there is a problem, everyone is equally affected. | ||
If problems arose in the future (e.g. with homographs between a particular | |||
script and Latin), we would need to quickly issue a robust response | |||
making the point that it is up to registries to make sure that their customers | |||
cannot rip each other off. Browsers can put some technical restrictions in place, | |||
but we are not in a position to do this job for them while still maintaining | |||
a level playing field for non-Latin scripts on the web. | |||
===Transition=== | |||
If we decide to adopt this plan, in between adopting it and shipping a Firefox with | |||
the restrictions implemented, we would admit into the whitelist any | |||
TLD whose anti-spoofing policies at registration time were at least as strong as | |||
those outlined above. |