IE7 will prevent IDN spoofing

[madcamel]

Great news to all IDNers:

http://www.pcworld.com/news/article/0,aid,124056,00.asp

IE 7 will put restrictions on the scripts allowed to be displayed in the address bar based on the user's browser language settings. If a domain name has characters that aren't in the user's chosen languages, the address will be shown in punycode, he wrote.

 

[touchring]

Great news to all IDNers:

http://www.pcworld.com/news/article/0,aid,124056,00.asp

This is great news for East Asian IDNs, where people use local language PCs.

 

[Rubber Duck]

This is great news for East Asian IDNs, where people use local language PCs.

But the real benefit will be that IDN prevent same script spoofing that aims to confuse people over the various different ways that the local characters can be transliterated.

Best Regards
Dave Wrixon

 

[QuantumBeam]

well..............nice

 

[Sarcle]

But the real benefit will be that IDN prevent same script spoofing that aims to confuse people over the various different ways that the local characters can be transliterated.

Best Regards
Dave Wrixon

Yeah, now that's addressed I wonder what the naysayers will say next to try to kill down talk on idn's. Oh, I see all ready, "script change."

 

[Rubber Duck]

Yeah, now that's addressed I wonder what the naysayers will say next to try to kill down talk on idn's. Oh, I see all ready, "script change."

Yes, well that is b*ll*cks. Yes having the dot com always in Latin is not ideal, but it is a damned sight more convenient than having to use Latin characters for the Keywords in the second level. Anyway, the road map for IDN.IDN will be established in January 2006 I believe. Changing script? Everyone is already changing script every time they visit the address bar. Where do these jokers come from?

Best Regards
Dave Wrixon

 

[Domagon]

The IE 7 restrictions are also great news for domainers with legacy domains ...

It will for one thing enforce the notion that particular IDNs are of limited usefulness outside their intended region / language ...

And from a technical aspect, with such restrictions, many users will often encounter IDNs that dropback to punycode...

A user of a legacy non-IDN domain will never experience such a dropback effect - the domain shown is what it is ... that certainty is important in some applications; IDNs rely on more of a best guess model which goes against an important tenet of DNS, which is that domain resolution is to be exact ... IE7 restrictions will help maintain the spirit of that tenet for IDNs.

In a nutshell, based on what I've read so far, IE7's security restrictions appear quite reasonable overall ... they will benefit users, registrants of IDNs, and those with legacy domains.

Ron

 

[Rubber Duck]

... that certainty is important in some applications; IDNs rely on more of a best guess model which goes against an important tenet of DNS, which is that domain resolution is to be exact ...

Ron

Please confirm what you mean here. There is no best guess about the resolution of punycode and to my knowledge there are no issues regarding the translation of Unicode into Punycode by any of the recognised browsers that support IDN.

I hope these comments are not just your "best guess"!

Best Regards
Dave Wrixon

 

[Domagon]

Please confirm what you mean here. There is no best guess about the resolution of punycode and to my knowledge there are no issues regarding the translation of Unicode into Punycode by any of the recognised browsers that support IDN.

Punycode resolution itself is exact ... no debate there.

However, the unicode translation part is a "guess" to some extent ...

To quote the article "Internet Explorer 7 will use application programming interfaces (APIs) to convert domain names to punycode"

Note the phrase "application programming interfaces" which implies the translation to punycode is upto the programmers of such APIs; we all know how good MS is coding APIs LOL!

A related issue is will every browser, and every other type of software that does IDN resolution for that matter, use exactly the same APIs / implementation ... if not, an IDN that works in one browser, etc may not work in another, or far worse resolve to two different resources.

But even assuming the all the APIs work bugfree, which is unlikely ... they still, in practical, real-world terms, will in part rely on heuristics that are not 100% precise for some translations; "best guess" so to speak.

Below I've quoted a portion of RFC 3743 ... this is where "best guess" really comes into play ... a related issue is that IDNs are somewhat fluid ... what's a valid IDN today may not be tomorrow and vice-versa.

"6. Security Considerations

As discussed in the Introduction, substantially-unrestricted use of
international (non-ASCII) characters in domain name labels may cause
user confusion and invite various types of attacks. In particular,
in the case of CJK languages, an attacker has an opportunity to
divert or confuse users as a result of different characters (or, more
specifically, assigned code points) with identical or similar
semantics. These Guidelines provide a partial remedy for those risks by supplying a framework for prohibiting inappropriate characters
from being registered at all and for permitting "variant" characters
to be grouped together and reserved, so that they can only be
registered in the DNS by the same owner. However, the system it
suggests is no better or worse than the per-zone and per-language
tables whose format and use this document specifies. Specific
tables, and any additional local processing, will reflect per-zone
decisions about the balance between risk and flexibility of
registrations. And, of course, errors in construction of those
tables may significantly reduce the quality of protection provided."

Ron

 

[touchring]

Punycode API based on Verisign's sample code is available in open source format and can be downloaded all over the web.

I dun see how this can be rocket science.

Either the programmer in charged of the idn stuff is only trying to make himself look good, or he is preparing to avoid responsibility by pushing all future faults to Verisign's API.

 

[Rubber Duck]

There is some fuzzy thinking going on here.

The stuff quoted here about tables relates to registration not resolution.

Once the domain has been purchased, then there should be no issues.

The encodement alogorithms are well understood and have been agreed by ICANN. The existing browsers and the Verisign Pluggin for IE 6.0 have been working for 2 years without any issues.

What you are infact doing is suggesting that Microsoft are totally incapable of incorporating a simple piece of code into their new browser, when in fact this was already up and running last summer to my knowledge.

To me this just smacks of further IDN smearing.

Dave Wrixon

 

[touchring]

I hope these comments are not just your "best guess"!

:cheeky:

I guess this "best guess" will happen when a hacker installs some virus onto the PC, and cause the wrong stuff to be entered into the url section, e.g. some macedonian characters that look like latin.

 

[Domagon]

There is some fuzzy thinking going on here.

The stuff quoted here about tables relates to registration not resolution.

Speaking of fuzzy, such tables aren't set in stone and are subject to change - there can and likely will be situations, in fact the RFC even suggests what should happen to current registrations, if the table(s) change ... point is that what is a valid IDN today may not be one tomorrow and vice-versa ...

Once the domain has been purchased, then there should be no issues.

The operative word there is "should" ... no guarantees an IDN will function properly; possibly even, in extreme situations, be "taken back" / blocked completely.

The encodement alogorithms are well understood and have been agreed by ICANN.

The algorithms may be agreed upon, but they are only as good as the situations they take into account (there are numerous permutations of possibilities that likely are not accounted for), and more to the point are only good as the tables, etc they rely on.

The existing browsers and the Verisign Pluggin for IE 6.0 have been working for 2 years without any issues.

Without issues? I seriously doubt that LOL! IE 6 has so many security problems, including some still unfixed, as it is ... to say "without any issues" is overly optimistic ...

And anyways, even assuming MS gets it 100% right, that doesn't mean every other software program will ... it's very likely that APIs, despite there being a set standard, will vary in quality and implementation ...

Heck, even APIs for resolving legacy domain names vary and don't handle all situations the same ... IDN resolution is lightyears more complex so it's definitely enevitable that IDN resolution will be something less than exact.

What you are infact doing is suggesting that Microsoft are totally incapable of incorporating a simple piece of code into their new browser, when in fact this was already up and running last summer to my knowledge.

Yes, that's exactly what I'm saying ... MS has a long history of fudging up even simple things ... heck, don't you remember all the problems MS have had handling unicode for standard ascii characters in IE / NT server ... unicode translation for IDNs is much more complex so it's likely to be buggy; less than exact.

To me this just smacks of further IDN smearing.

You present IDNs as being all rosy and totally trouble-free ... the truth is somewhere in between - yes, there is a need for IDNs, IDNs generally work well, etc ... but IDN resolution is relies on various somewhat subjective factors, such as tables that are subject to change, numerous programmed APIs, differing implentations, etc - in effect ultimately makes IDN resolution "best guess".

Ron

 

[touchring]

Well, you got it right, IE is insecure, so let's all switch to Firefox, which is secure and has IDN support - which is happening in Germany right now.

And there will be no need to argue over whether IE should introduce IDN.

:cheeky: :cheeky: :cheeky:

 

[Rubber Duck]

Speaking of fuzzy, such tables aren't set in stone and are subject to change - there can and likely will be situations, in fact the RFC even suggests what should happen to current registrations, if the table(s) change ... point is that what is a valid IDN today may not be one tomorrow and vice-versa ...

None of this means that a meaningful term is going to be invalidated. Table changes that relate to commonly used characters are possible, but the Unicode point will not change nor will meaning of the character that it represents. There may be some short-term hitches in search or even browser conversion during updates, but essentially nothing changes. The fact that there is a procedure in place indicates that this has all been thoroughly thought through!

The operative word there is "should" ... no guarantees an IDN will function properly; possibly even, in extreme situations, be "taken back" / blocked completely.

Don't accept this. The only IDNs that are likely to be scratched are ones that have no real function value apart from fraud.

The algorithms may be agreed upon, but they are only as good as the situations they take into account (there are numerous permutations of possibilities that likely are not accounted for), and more to the point are only good as the tables, etc they rely on.

The algorithms have now been in use for two years and are deemed to be be successful. Not once in all the recent ICANN workshops has this issued been raised.

Without issues? I seriously doubt that LOL! IE 6 has so many security problems, including some still unfixed, as it is ... to say "without any issues" is overly optimistic ...

And anyways, even assuming MS gets it 100% right, that doesn't mean every other software program will ... it's very likely that APIs, despite there being a set standard, will vary in quality and implementation ...

Heck, even APIs for resolving legacy domain names vary and don't handle all situations the same ... IDN resolution is lightyears more complex so it's definitely enevitable that IDN resolution will be something less than exact.

Every other software programme of any significance has already implemented this. There are no issues. If Microsoft cannot match the worst of the rest then they really are in trouble and will soon become irrelevant. Hey, I would be very happy if everyone was already on Firefox. Its time for Microsoft to put up or shut up! Somehow, I think they already now this. I would expect the release sooner rather than later. I think someone pulled the plug over December release as they feared the conseqences or releasing just as everyone was going home for Christmas.

Yes, that's exactly what I'm saying ... MS has a long history of fudging up even simple things ... heck, don't you remember all the problems MS have had handling unicode for standard ascii characters in IE / NT server ... unicode translation for IDNs is much more complex so it's likely to be buggy; less than exact.

It is not buggy. Keyboard driver generates Unicode Point. Algorythym flawless converts to Punycode, which is ASCII. DNS resolves. End of story.

You present IDNs as being all rosy and totally trouble-free ... the truth is somewhere in between - yes, there is a need for IDNs, IDNs generally work well, etc ... but IDN resolution is relies on various somewhat subjective factors, such as tables that are subject to change, numerous programmed APIs, differing implentations, etc - in effect ultimately makes IDN resolution "best guess".

I think you are forgetting all this is already up and running. Domainers are getting traffic and click through. The volume of such traffic will drastically increase with the release of IE 7.0 and the realisation by firms in Asia they cannot get search ranking without IDN. As domainers frankly, we are not interested in all these symantics, but are instead looking forward to the day in the near future when the pay cheques become meaningful.

Best Regards
Dave Wrixon

 

[Netego]

1/ The Chinese characters have been used for a few thousand years. They are being used in mainland China, Taiwan, Hong Kong, Singapore, Japan, Korea and everywhere in the world. It certainly will take some time for Icann to come up with character tables acceptable to all Chinese IDN users, a very small part of the character set still need to be discussed and studied, but I don't see how this can be a "problem" for us to start using Chinese IDN now, because internet itself has never been perfect, we keep improving it.

2/ No matter what method you use when searching the character tables, heuristics (best guess) or brute-force, the result has to be exact.Touchring stated it well, "I dun see how this can be rocket science."

Many large corporations already registered their Chinese IDNs:

Google 咕果.com (xn--9trs65b.com)
Domain Name: xn--9trs65b.com

Registrant:
Google Inc. (DOM-1434602)
1600 Amphitheatre Parkway
Mountain View CA 94043 US

Administrative Contact:
DNS Admin (NIC-1467103) Google Inc.
1600 Amphitheatre Parkway
Mountain View CA 94043 US
[email protected]
+1.6502530000
Fax- +1.6506188571

Created on..............: 2005-Nov-22.
Expires on..............: 2006-Nov-22.
Record last updated on..: 2005-Nov-22 07:25:20.

Domain servers in listed order:
NS1.GOOGLE.COM
NS2.GOOGLE.COM
NS3.GOOGLE.COM
NS4.GOOGLE.COM

------------
The PinYin of 咕果.com = guguo.com
Domain Name: guguo.com

Registrant:
Google Inc.(DOM-1424091)
1600 Amphitheatre Parkway
Mountain View
CA 94042 US

Administrative Contact:
DNS Admin(NIC-14407163)
Google Inc.
1600 Amphitheatre Parkway
Mountain View
CA 94042 US
[email protected]
+1.6503300100
Fax- +1.6506181434

Created on..............: 2002-Aug-05.
Expires on..............: 2007-Aug-05.
Record last updated on..: 2005-Oct-25 13:56:53.

Domain servers in listed order:

NS1.GOOGLE.COM
NS2.GOOGLE.COM
NS3.GOOGLE.COM
NS4.GOOGLE.COM

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

Bank of America 美國銀行.com (xn--9csr65g40fr2k.com)

Domain Name ..................... xn--9csr65g40fr2k.com
Name Server ..................... dns7.hichina.com
dns8.hichina.com
Registrant ID ................... hc246215652-cn
Registrant Name ................. HongZhang
Registrant Organization ......... BANK OF AMERICA CORPORATION
Registrant Address .............. 100 NORTH TRYON STREET, CHARLOTTE, NORTH CAROLINA
Registrant City ................. CHARLOTTE
Registrant Province/State ....... NORTH CAROLINA
Registrant Postal Code .......... 100044
Registrant Country Code ......... CN
Registrant Phone Number ......... +86.01068001882 -
Registrant Fax .................. +86.01068001884 -
Registrant Email ................ [email protected]

 

[Sarcle]

I'll add another one. Many more own their trademarks, too lazy to look them up again.

メッセンジャー.jp
Yahoo. Site is already set up.

メッセンジャー.com
(messenger, japanese)

Registrant:
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
US

Domain name: XN--YCKFX3JNA8GXC.COM

Administrative Contact:
Administrator, Domain
One Microsoft Way
Redmond, WA 98052
US
+1.4258828080
Technical Contact:
Hostmaster, MSN
One Microsoft Way
Redmond, WA 98052
US
+1.4258828080


Registration Service Provider:
DBMS VeriSign,
800-579-2848 x4
Please contact DBMS VeriSign for domain updates, DNS/Nameserver
changes, and general domain support questions.


Registrar of Record: TUCOWS, INC.
Record last updated on 22-Nov-2004.
Record expires on 08-Sep-2006.
Record created on 08-Sep-2004.

 

[mole]

IDN spoofing will not affect the asian characters as much as the ASCII character set, I think IDN deception nightmare will come when surfers see something like càfe, and thought there was a speck of fly sh*t on their screen.

 

[Rubber Duck]

IDN spoofing will not affect the asian characters as much as the ASCII character set, I think IDN deception nightmare will come when surfers see something like càfe, and thought there was a speck of fly sh*t on their screen.

No it will not sigficantly affect Asia, but without IDN the use of Latin transliterations was a train crash waiting to happen.

Best Regards
Dave Wrixon

 

[none]

IDN spoofing will not affect the asian characters as much as the ASCII character set, I think IDN deception nightmare will come when surfers see something like càfe, and thought there was a speck of fly sh*t on their screen.

Happens to me all the time. I've got to stop eating and talking while on my laptop!