What rules have been used for the current list of codepoints?

Martin Duerst duerst at it.aoyama.ac.jp
Tue Dec 26 07:55:02 CET 2006


[Most of this post was written a while ago, but I found
out it wasn't sent when cleaning up.]

At 19:06 06/12/15, Gervase Markham wrote:

>The way to avoid spoofs is, instead, to cut down the set of characters
>as far as is reasonably possible and then to require registries to have
>policies which do not issue two confusable domain names to different
>entities. There are several technical and logistical ways of achieving
>this. I see no reason why a registry would object to having a policy
>which prevents some of its customers defrauding other of its customers.

I agree.

>This is the policy that Firefox adopts; we currently display IDN domain
>names for around 30 TLDs, the registries for all of which have
>anti-spoofing policies. Any registry with such a policy is welcome to
>ask to be included in the list, and we will ship the list change in our
>next security update.

I don't like this, because it's technology policing policy, and
it could be misused in all kinds of ways. It may put a heavy
burden on browser makers: Is 'any policy' good enough? Checking
the policy takes work. Where do you draw the line between good
policies and 'not good enough' policies? Do you check not only
for the existence of a policy, but also for actual implementation/
enforcement? If yes, how? If not, why not? What if a registry
has a very good policy, but doesn't make every detail of it
public? Why do you think you know, better than others, what the
right policy is? Do you reserve the right to retract a TLD from the
list even if their policy doesn't change, but you find out that
it left some loophole open? And how long does it take to get a
security update out, and how does the need for a security update
negatively affect the deployment of IDNs?

These are just too many questions for me to think this is a good
idea that browser creators make judgements about registration
policies.

>> Japanese domain names would not be shown to most American users, and
>> that's OK because they can't read them anyway!
>
>That's rather a naive and sweeping statement. Are there no Japanese
>Americans? Are there no Japanese visiting America and using Internet
>cafes? Are there no Americans learning Japanese? Must all of these
>people reconfigure every browser and other IDNA-aware client they use to
>tell it all the languages they can read? And, in the case of a client
>they are using temporarily, configure it back afterwards to avoid
>putting others at risk?

I totally agree. I'm glad to hear that the IE7 implementation is
a bit more flexible than what Erik originally described.

>> And most Americans are not interested in doing business with a paypal
>> that has one of the letters in Cyrillic, so you just don't show them
>> the spoofed name. You show them a warning instead.
>
>This is the mixed-script question, not the unfamiliar character
>question. But, to use your example, if payp<cyrillic-a>l.com gets issued
>to someone other than the owner of paypal.com, then that is squarely the
>responsibility of the .com registrar, and they should be taken to task
>for it.

They have been 'taken to task' for it, and taken that offending
URI off quickly. And I'm pretty sure they won't make the same
mistake again.

>It should not need to be the user's responsibility to avoid
>being taken in.

Well, yes, but ultimately, users have to learn that there are
some dangers on the Internet, the same way visitors to the US
(and most other countries) have to learn that there are some
places you better don't go to.

Regards,     Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp     



More information about the Idna-update mailing list