Changes

Jump to: navigation, search

IDN Display Algorithm

1,250 bytes added, 17:34, 20 January 2012
no edit summary
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
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
be serving our users.
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. Unfortunately, no consensus has emerged on how to dothis. 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 domainname will be correctly displayed for all their visitors (and no way of telling if it's not).
==Proposal==
The plan is to augment our whitelist with something based on ascertaining whether all the characters in a label
are single-all come from the same script, or are from one of a limited and defined number of allowable combinations. Thehope 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],
which is about Unicode and security, defines a "Moderately Restrictive" profile which we could use. It says the following (with edits for clarity):
<blockquote>
This system would permit whole-script confusables
(All-Latin "scope.tld" vs all-Cyrillic "scopeѕсоре.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, everyone is equally affected. If problems arose in the future (e.g. with homographs between a particularscript and Latin), we would need to quickly issue a robust responsemaking the point that it is up to registries to make sure that their customerscannot 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 maintaininga 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 withthe restrictions implemented, we would admit into the whitelist anyTLD whose anti-spoofing policies at registration time were at least as strong as those outlined above.
Accountapprovers, antispam, confirm, emeritus
4,925
edits

Navigation menu