Browser IDN display policy: opinions sought
James Seng
james.seng at gmail.com
Mon Dec 19 01:19:01 CET 2011
+1
Sent from my iPhone
On 18 Dec, 2011, at 6:02 PM, Raed Al-Fayez <rfayez at citc.gov.sa> wrote:
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 1
st 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
http://www.alvestrand.no/mailman/listinfo/idna-update
-----------------------------------------------------------------------
تنويه:
هذه الرسالة و مرفقاتها (إن وجدت) تمثل وثيقة سرية قد تحتوي على معلومات تتمتع
بحماية وحصانة قانونية. إذا لم تكن الشخص المعني بهذه الرسالة يجب عليك تنبيه
المُرسل
بخطأ وصولها إليك، و حذف الرسالة و مرفقاتها (إن وجدت) من الحاسب الآلي الخاص
بك. ولا يجوز لك نسخ هذه الرسالة أو مرفقاتها (إن وجدت) أو أي جزئ منها، أو
البوح بمحتوياتها لأي شخص أو استعمالها لأي غرض. علماً بأن الإفادات و الآراء
التي تحويها هذه الرسالة تعبر فقط عن رأي المُرسل و ليس بالضرورة رأي هيئة
الاتصالات و
تقنية المعلومات، ولا تتحمل الهيئة أي مسئولية عن الأضرار الناتجة عن هذ
البريد.
_______________________________________________
Idna-update mailing list
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/20111219/34a40ce9/attachment-0001.html>
More information about the Idna-update
mailing list