IDN Display Algorithm: Difference between revisions

Jump to navigation Jump to search
no edit summary
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
are single-script, or one of a limited and defined number of allowable combinations.
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 "scope.tld"). However, so do the
(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.
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Navigation menu