Browser IDN display policy: opinions sought

Sun Dec 18 10:50:56 CET 2011

Dear All,

My name is Raed Al-Fayez I am from SaudiNIC (.sa & .السعودية    ccTLD Registry).

First of all I would like to thank Gervase Markham for opening such important issue; Also I thank everyone who have contributed in its discussion.

Please allow me to share with you our opinions and thoughts regarding "Browser IDN display policy":

IDNs should not be treated as second-class citizens on the Internet. They should be displayed in their native languages and not treated/displayed in their corresponding ASCII encodings. Users should not do anything to get their IDNs displayed correctly in their screens. IDNs should not be forced to be displayed in their ASCII format just – as some vendor claims: "The standard text encoding is used because it's possible for letters and symbols in some languages to be used to impersonate English language websites for phishing scams".  Please note that not ALL SCRIPTs can be used to "impersonate English language websites".

I would repeat here what Gervase Markham from Mozilla had – accurately - said in one of the ICANN meetings:
"They [IDNs] are going to be just as safe to use as ASCII domain names. You don't need extra alerts you don't need extra warnings, don't need extra training to use them. If they are less safe because characters are allowed which might confuse people, and therefore there is some danger, then we have failed in that goal ..".

At SaudiNIC, we have experiences with providing Arabic IDNs as we were the 1st ccTLD registry provided IDN registration in our region. We have observed that our local users lost their trust in the Arabic IDNs when IDN addresses appeared in ASCII encoding. Many of them were shocked not to see the Arabic IDNs but rather "garbage text" not in their native language. Furthermore, they had difficulties or did not know how to fix this within the operating systems or the browsers they were using.

Please note in our registry we provide a conservative and a complete IDN solution which include Variants managements at the Arabic Script level as well as we do not allow script mixing. Registration are based on a very well defined and limited language table. So the security issue is already taking care by the registry (us). Hence, users should have no security issue when they get Arabic IDNs and should be displayed in their native language automatically without the intervention by anyone including the users him/herself.

Here are some comments regarding Option A:

-          A language/country is added to the supported list but it is not associated with an IDN TLD. Hence, if a user add the Arabic language to the supported list this will always displays all the Arabic IDNs regardless wither the IDN TLD is trusted or not.

-          This treats IDNs as second criticizes of the Internet which leads to miss-trustiness from users in the IDNA as it always needs intervention from the user (which is not easy and not standard).

-          This option leads to different actions from the users to enable IDNs depending on operating system type/version and used applications (e.g., browsers). Therefore, it adds extra complexity to user acceptance and registry customer care.

-          In Airports or public internet hotspots IDNs would not work properly as user have no control in the application settings.

-          IDNA deals with domain labels at the script level, but "Option A" works at the language (and country) level which are incompatible behavior.

As IDNs are about making the Internet more global and accessible for everyone and many companies/communities are investing heavily in IDNs, it would not be fair to treat IDN domain names differently from their ASCII/English ones. IDNs should be used and displayed automatically without the intervention of users. This is very important so that these investments will not be jeopardized just because of these kind of treatments which will shun away the users from IDNs . Thus, IDNs should be treated as first-class citizens of Internet.

We have to be very careful as new gTLDs are coming in the market that will be used by almost all users around the world. It is not adequate and justifiable that new ASCII gTLDs are working from day one while new IDN gTLDs are handicapped by the applications and need some extra intervention and involvement from the user side to make them working probably.

In our judgment, the issue of " impersonate English language websites for phishing scams" is unjustly magnified based on bad example of a registry practice. For example, under ".com", IDN was supported with almost all possible Unicode characters without any restriction or variants managements. Hence, registries who provide clear language tables, policies, and variants handling mechanisms do not fall in these kind of problems but they have been penalize.

The problems cited as they are from IDNs can be addressed through mechanisms similar to the current practices to fight phishing scams and malware. Currently, web browsers and search engines have their own means to flag suspicious sites as a service provided from the application vendors to their users.

Hence, we recommend the following:

-       IDNs should be treated and handled similarly to ASCII domains. It should not require extra efforts from the users to make them work correctly. It should be transparent to the users, except for the suspicious sites (that can be handled via a black list).

-       Otherwise, if it is not possible to execute, we recommend to have a centralized authority (e.g., ICANN/IANA) that maintain a repository for each TLD registry that contains information about the registry's language tables, list of supported languages and it should be filled automatically (online) as part of the delegation process.

With best regards,

Raed I. Al-Fayez

------------------------------------------

Senior IT Projects Specialist, M.Sc, PMP

Saudi Network Information Center (SaudiNIC)

Communication and Information Technology Commission (CITC)

Tel: + 966-1-2639235   - Fax: + 966-1-2639393

http://www.nic.net.sa

-----Original Message-----
From: idna-update-bounces at alvestrand.no [mailto:idna-update-bounces at alvestrand.no] On Behalf Of Gervase Markham
Sent: Friday, December 09, 2011 2:12 PM
To: idna-update at alvestrand.no
Subject: Browser IDN display policy: opinions sought

Recently, Mozilla community member Jothan Frakes was kind enough to do some research about how different popular web browsers implement IDN, and when they display the real characters and when they display Punycode. This is in the context of a Mozilla review of our policy. I am interested in the opinions of people on this list (see below).

As it turns out, the behaviour of all popular browsers is summarised at the bottom a Chromium project document here:

http://www.chromium.org/developers/design-documents/idn-in-google-chrome

The policies fall into 3 approximate buckets:

A (IE, Chrome): Unicode if the (single) 'language' of the string is configured in the options, Punycode otherwise.

B (Firefox, Opera): Unicode if the TLD is in a whitelist, Punycode otherwise. Arbitrary script mixing permitted (registry policy used to prevent abuse).

C (Safari): Unicode if the script is in a whitelist (which by default does not include Cyrillic or Greek), Punycode otherwise. Not sure about script mixing.

Firefox has historically resisted adopting a Type A policy because we consider it seriously detrimental to IDN adoption and use. It seems to me that IDN can never be reliable for site owners, and therefore will not succceed, if a significant proportion of the world's browsers adopt Type A or Type C policies. This is because site owners can never know what proportion of their visitors will see gobbledegook in the URL bar rather than their nice domain name. Perhaps for sites whose visitors are all guaranteed to be from a particular country or language group, with properly-configured browsers and OSes which know that they speak a certain language or use a certain script, it might work - but I suggest that's a small subset of all sites. Many people in non-English-speaking countries still use English OSes and English browsers, with default settings.

Type C is particularly bad - Russian and Greek IDNs are broken by default, but even if you persuade your users to turn it on, they can then be mixed-script spoofed. You get to choose between functionality and security.

By contrast, with a Type B policy, if your IDN domain works in one copy of Firefox, it works in them all. If everyone had Type B policies, there would be no risk of a properly-registered domain coming up as gibberish.

It has been suggested that Firefox switch to a Type A policy. As it is, the mix of policies means that the goal of universal acceptability is not being met anyway. Firefox switching to Type A would also not meet that goal by itself, but one could argue that there's a bit more consistency to browser behaviour.

I would be interested in the opinion of people on this list as to:

- whether my analysis seems reasonable;

- whether they prefer type A, B or C; and

- whether they see any particular policy as more damaging to IDN

  adoption than another.

Has anyone lobbied one browser manufacturer or another to change their policy? Is there another option that is not currently in use which would be better?

(Note that "no restrictions" is not an option, given what happened in

2005 with payp-cyrillic-a-l.com, and I would rather not derail this debate by rehearsing those arguments again.)

Gerv

_______________________________________________

Idna-update mailing list

Idna-update at alvestrand.no<mailto:Idna-update at alvestrand.no>

http://www.alvestrand.no/mailman/listinfo/idna-update

-----------------------------------------------------------------------
تنويه:
هذه الرسالة و مرفقاتها (إن وجدت) تمثل وثيقة سرية قد تحتوي على معلومات تتمتع بحماية وحصانة قانونية. إذا لم تكن الشخص المعني بهذه الرسالة يجب عليك تنبيه المُرسل
بخطأ وصولها إليك، و حذف الرسالة و مرفقاتها (إن وجدت) من الحاسب الآلي الخاص بك. ولا يجوز لك نسخ هذه الرسالة أو مرفقاتها (إن وجدت) أو أي جزئ منها، أو
البوح بمحتوياتها لأي شخص أو استعمالها لأي غرض. علماً بأن الإفادات و الآراء التي تحويها هذه الرسالة تعبر فقط عن رأي المُرسل و ليس بالضرورة رأي هيئة الاتصالات و
تقنية المعلومات، ولا تتحمل الهيئة أي مسئولية عن الأضرار الناتجة عن هذ البريد.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20111218/f9ba1dc6/attachment-0001.html>