Perhaps a bit off-topic, but some folks might get support calls... http://وزارة-الأتصالات.مصر/ (that's Arabic for <Ministry of Communications>.<Egypt>) Regards, -drc
Great progress and interesting addition to the root, only issue is that after all the work with IDNs you land on a page written in english (web browser lang does not matter, name resolves to the same IP as the original URL). Hope they soon take advantage of the new name ... Cheers Jorge On Wed, May 5, 2010 at 11:34 AM, David Conrad <drc@virtualized.org> wrote:
Perhaps a bit off-topic, but some folks might get support calls...
(that's Arabic for <Ministry of Communications>.<Egypt>)
Regards, -drc
On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
On Wed, May 5, 2010 at 11:34 AM, David Conrad <drc@virtualized.org> wrote:
Perhaps a bit off-topic, but some folks might get support calls...
(that's Arabic for <Ministry of Communications>.<Egypt>)
Great progress and interesting addition to the root, only issue is that after all the work with IDNs you land on a page written in english (web browser lang does not matter, name resolves to the same IP as the original URL). Hope they soon take advantage of the new name
The page shows up in Arabic for me in all three of Safari (in which the URL bar also shows the Arabic name), Chrome and Firefox (in both of which the URL bar shows the encoded US-ASCII characters for the domain name). I tested using the Mac versions of these three browsers, and English is set as my preferred language. Arabic doesn't appear until much farther down on the list. The Safari experience looks nicer, but I suppose it leaves its users more susceptible to maliciously-constructed domain names that look similar to well-known ones. I wonder if they've addressed that issue in some way. I haven't been checking recently. - Geoff
Hi Geoff, yes, as I reported through other channels today the new IDN based URL started landing on the Arabic version of the page. Kudos for the folks in Egypt that are now taking advantage of the new ccTLD. I noticed testing with IE8, Chrome, FFox and Safari, that Safari is the only one that keeps showing the original URL in Arabic in the navigation toolbar, all the others switch to the ASCII encoded one. I guess there is more work/configuration to be done on the client side. Cheers Jorge On Thu, May 6, 2010 at 1:45 PM, Geoff Adams <gadams+nanog@avernus.com> wrote:
On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
On Wed, May 5, 2010 at 11:34 AM, David Conrad <drc@virtualized.org> wrote:
Perhaps a bit off-topic, but some folks might get support calls...
(that's Arabic for <Ministry of Communications>.<Egypt>)
Great progress and interesting addition to the root, only issue is that after all the work with IDNs you land on a page written in english (web browser lang does not matter, name resolves to the same IP as the original URL). Hope they soon take advantage of the new name
The page shows up in Arabic for me in all three of Safari (in which the URL bar also shows the Arabic name), Chrome and Firefox (in both of which the URL bar shows the encoded US-ASCII characters for the domain name). I tested using the Mac versions of these three browsers, and English is set as my preferred language. Arabic doesn't appear until much farther down on the list.
The Safari experience looks nicer, but I suppose it leaves its users more susceptible to maliciously-constructed domain names that look similar to well-known ones. I wonder if they've addressed that issue in some way. I haven't been checking recently.
- Geoff
Geoff Adams wrote:
On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
On Wed, May 5, 2010 at 11:34 AM, David Conrad <drc@virtualized.org> wrote:
Perhaps a bit off-topic, but some folks might get support calls...
(that's Arabic for <Ministry of Communications>.<Egypt>)
Great progress and interesting addition to the root, only issue is that after all the work with IDNs you land on a page written in english (web browser lang does not matter, name resolves to the same IP as the original URL). Hope they soon take advantage of the new name
The page shows up in Arabic for me in all three of Safari
When I first checked this site yesterday, I saw a page in English[1]. The same page is in Arabic today, in the same browsers that displayed English when I checked yesterday. I assume the server admin waited until the domain went live before implementing language display selection based on the URL used to reach the site, and now it's working correctly. [1] Such as I see when I use this URL instead: http://www.mcit.gov.eg/ jc
I'm getting three different behaviours from Firefox - I have the page open in a tab. The tab header is in Arabic script. (And the page itself renders fine in Arabic.) - When I go to that tab, the main Firefox window title shows boxes (i.e. "don't have the font for this.") - When I go to that tab, the Address Bar shows ugly punycode xn-format junk. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
I agree Safari experience looks much nicer and yes whole host of potential malice to arise. Firefox shows punycode http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ar/default.aspx Now if I understood arabic only and was travelling or happen to use Firefox which showed punycode how would I trust it? If it was directly translated to latin characters I could trust it with verification from someone I know who understands english. I would not trust puny code because an end user does not know what it means, I think there is potential for a lot of issues here. Zaid On 5/6/10 11:45 AM, "Geoff Adams" <gadams+nanog@avernus.com> wrote:
On 5 May 2010, at 2:16 PM, Jorge Amodio wrote:
On Wed, May 5, 2010 at 11:34 AM, David Conrad <drc@virtualized.org> wrote:
Perhaps a bit off-topic, but some folks might get support calls...
(that's Arabic for <Ministry of Communications>.<Egypt>)
Great progress and interesting addition to the root, only issue is that after all the work with IDNs you land on a page written in english (web browser lang does not matter, name resolves to the same IP as the original URL). Hope they soon take advantage of the new name
The page shows up in Arabic for me in all three of Safari (in which the URL bar also shows the Arabic name), Chrome and Firefox (in both of which the URL bar shows the encoded US-ASCII characters for the domain name). I tested using the Mac versions of these three browsers, and English is set as my preferred language. Arabic doesn't appear until much farther down on the list.
The Safari experience looks nicer, but I suppose it leaves its users more susceptible to maliciously-constructed domain names that look similar to well-known ones. I wonder if they've addressed that issue in some way. I haven't been checking recently.
- Geoff
On 2010-05-06, at 22:27, Zaid Ali wrote:
Now if I understood arabic only and was travelling or happen to use Firefox which showed punycode how would I trust it?
I agree, that seems like nonsense. The answer for non-Arabic-speakers who are concerned about whether an Arabic URL is a phishing site is presumably just not to follow any Arabic URLs. They're surely intended for people that don't have that problem. Joe
On 06/05/10 21:27, Zaid Ali wrote:
I agree Safari experience looks much nicer and yes whole host of potential malice to arise. Firefox shows punycode
http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ar/default.aspx
Now if I understood arabic only and was travelling or happen to use Firefox which showed punycode how would I trust it? If it was directly translated to latin characters I could trust it with verification from someone I know who understands english. I would not trust puny code because an end user does not know what it means, I think there is potential for a lot of issues here.
Zaid
This is indeed a security issue, and the behaviour in Firefox is currently that way by design. To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the Mozilla Foundation in order to inform the Foundation of their official IDN name allocation policy, so that the native-script URL display can then be switched on for their domain. See https://bugzilla.mozilla.org/show_bug.cgi?id=564213 and http://www.mozilla.org/projects/security/tld-idn-policy-list.html -- Neil
Neil Harris (neil) writes:
To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the Mozilla Foundation in order to inform the Foundation of their official IDN name allocation policy, so that the native-script URL display can then be switched on for their domain.
See https://bugzilla.mozilla.org/show_bug.cgi?id=564213 and http://www.mozilla.org/projects/security/tld-idn-policy-list.html
Wow, talk about layer violation. Is there a central place where various TLDs' IDN policies will be maintained ? I see a scalability issue if TLDs have to communicate to every single application maintainer out there what their policy is. Cheers, Phil
To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the Mozilla Foundation in order to inform the Foundation of their official IDN name allocation policy, so that the native-script URL display can then be switched on for their domain.
Wow, talk about layer violation.
Yeah, security can be like that. Things which technically are treated the same are often semantically very different.
Is there a central place where various TLDs' IDN policies will be maintained ?
Yes, of course. See http://www.iana.org/domains/idn-tables/ It doesn't have the new IDN TLDs yet, but that's not surprising since ICANN didn't bother to tell the registries in advance that would be making the TLDs active. See http://www.circleid.com/posts/by_the_way_your_idn_is_live/ R's, John
On 5/8/2010 07:36, Phil Regnauld wrote:
Neil Harris (neil) writes:
To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the Mozilla Foundation in order to inform the Foundation of their official IDN name allocation policy, so that the native-script URL display can then be switched on for their domain.
See https://bugzilla.mozilla.org/show_bug.cgi?id=564213 and http://www.mozilla.org/projects/security/tld-idn-policy-list.html
Wow, talk about layer violation.
Is there a central place where various TLDs' IDN policies will be maintained ? I see a scalability issue if TLDs have to communicate to every single application maintainer out there what their policy is.
Wait until the FCC, FTC, and IRS finish taking over the Internet. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
David Conrad wrote:
Perhaps a bit off-topic, but some folks might get support calls...
That actually looks quite handsome. :-) -- http://goldmark.org/jeff/stupid-disclaimers/
On Fri, 7 May 2010, Jeroen van Aart wrote:
David Conrad wrote:
Perhaps a bit off-topic, but some folks might get support calls...
That actually looks quite handsome. :-)
And this is what it looks like to DNS: http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ Hurrah for Punycode. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Fri, 7 May 2010, Jeroen van Aart wrote:
David Conrad wrote:
Perhaps a bit off-topic, but some folks might get support calls...
That actually looks quite handsome. :-)
And this is what it looks like to DNS:
http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/
Hurrah for Punycode. Yeah I was experimenting around with that yesterday. Imagine a zone file full of such domain names. Ack! "Did I accidentally hit x in
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/7/2010 22:53, Peter Beckman wrote: the middle of that name in VIM? Better run it through the converter to make sure." Yay yet another level of complexity in DNS management. Some of the names look as ugly as the contents of DNSSEC RRs. :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvluX8ACgkQ2fXFxl4S7sTghwCg8sh1ZrKpa3d/GlYaGYhAZKN+ /HEAmgPrKZaaHynHRQuTAYfe4xQAWIh1 =cO/L -----END PGP SIGNATURE-----
participants (14)
-
Bill Stewart -
David Conrad -
Geoff Adams -
JC Dill -
Jeroen van Aart -
Jim Burwell -
Joe Abley -
John Levine -
Jorge Amodio -
Larry Sheldon -
Neil Harris -
Peter Beckman -
Phil Regnauld -
Zaid Ali