[UA-discuss] Another difficulty to overcome ...

Jim DeLaHunt jfrom.uasg at jdlh.com
Fri Feb 23 00:35:35 UTC 2018


Roberto:

Thank you for this reply.  You have experience and a perspective which I 
lack. I've never tried to run a domain name registry or act as 
registrar. This discussion is an education for me.

 > it is not fair to leave it to individual registries to take their own 
choices on what is “confusingly similar" and what is not, with the 
result that some SLD could be registered in some TLD but not in others.…

I see this point. On the other hand, aren't there already differences in 
what second-level domain names may be registered, at least for 
country-code top-level domains?  For instance, won't the .jp top-level 
domain forbid names in Thai script, and the .ht top-level domain forbid 
names in Japanese?  But I can see confusion if .com permits registering 
a name which .biz forbids, and so on.

 > Also, according to the current scheme of the market, the interface 
with the registrant is the registrar, not the registry. The deletion of 
a registration of - or the denial to register - a domain name would 
create substantial contractual litigation unless the RRA 
(Registry-Registrar Agreement) is changed adding specific clauses.…
 > ICANN has been violently reluctant to establish some standards of 
this type for fear of appearing even more as a regulator….

A difficult situation indeed!

 > We have already had long, tiresome, time wasting discussions about 
the supposed responsibility of registries about detecting domain names 
“confusingly similar” to brands or marks in order to protect 
intellectual property, please do not open another front that has the 
same technical and contractual problems.

It wouldn't be me or UASG advocates who open that front. It would be the 
fraudsters, and the users who perceive confusable domain names as being 
a threat.

The fraudsters will attack any weak point they can find to commit their 
fraud.  If the RRA, or the historical stance of ICANN, or exhaustion of 
people who have survived other fights about domain names, lead to an 
inability to combat the fraudsters, then the fraudsters will take 
advantage of that. And the users will react based on their perception of 
threats, which may differ from the reality. That reaction may make 
Universal Acceptance harder to promote, whether we like it or not.

In making the case for Universal Acceptance, I think we need to come up 
with a credible argument for how to balance these competing forces.
       —Jim DeLaHunt


On 2018-02-22 05:15, Roberto Gaetano wrote:
> Jim,
> I share your overall rebuttal and am in favour of regular IDN labels, 
> but have different opinions on the three items you mention.
> We fully agree on 3., adding also that if we want to have a standard 
> way to present urls it can only be  showing what the user expects to 
> see not the translation via an algorithm that will generally not be 
> understood. The only advantage of having punycode would be to detect 
> potential scams but at the price of making the result unreadable.
> About 2., although the observation is correct, I fail to see its value 
> as an argument about the choice of label type - but that may well be 
> my lack of understanding rather than the value of the argument itself.
> However, I am in complete disagreement with 1. As a disclosure, I have 
> to state that I am chairing the Board of Public Interest Registry, so 
> it is clear that, while I am supposed to have some experience about 
> the registry business, I have also a vested interest in the matter.
> My point is that, while in theory the registries can exert control on 
> the domain names registrations, in practice we have a few quite 
> substantial problems, both technical and contractual. For instance, I 
> don’t see the possibility of developing an algorithm to detect all the 
> possible cases while it is not fair to leave it to individual 
> registries to take their own choices on what is “confusingly similar" 
> and what is not, with the result that some SLD could be registered in 
> some TLD but not in others. Also, according to the current scheme of 
> the market, the interface with the registrant is the registrar, not 
> the registry. The deletion of a registration of - or the denial to 
> register - a domain name would create substantial contractual 
> litigation unless the RRA (Registry-Registrar Agreement) is changed 
> adding specific clauses.
> Talking by experience, ICANN has been violently reluctant to establish 
> some standards of this type for fear of appearing even more as a 
> regulator - or maybe also for other reasons - and the ball cannot be 
> punted to the registries with the risk of having different behaviour 
> and therefore confusion in the market.
> We have already had long, tiresome, time wasting discussions about the 
> supposed responsibility of registries about detecting domain names 
> “confusingly similar” to brands or marks in order to protect 
> intellectual property, please do not open another front that has the 
> same technical and contractual problems.
> Cheers,
> Roberto
>
>> On 20.02.2018, at 09:54, Jim DeLaHunt <jfrom.uasg at jdlh.com 
>> <mailto:jfrom.uasg at jdlh.com>> wrote:
>>
>> Multiple people have made the argument that having a browser show 
>> A-labels ("punycode") instead of U-labels ("regular IDN") is 
>> desirable as a way of fighting phishing.
>>
>> My rebuttal has three parts:
>>
>>  1. The underlying problem is that the registry (here, .com)
>>     permitted registration of a domain name which was confusable with
>>     another one. The right place to fight this kind of phishing with
>>     confusable characters is at the domain registry level.
>>  2. Even if you could magically prevent all confusable 2nd-level
>>     domain name registrations, phishing would still be a problem.
>>     Fraudsters have many tools, confusable 2nd-level names is only
>>     one of them. There are also confusable names at the 4th or 5th
>>     levels (e.g. microsoft.com.innocuous.deceptive.com
>>     <http://microsoft.com.innocuous.deceptive.com>), and misleading
>>     links in message bodies, and so on.
>>  3. The people for whom A-labels instead of U-labels are a privileged
>>     set of latin-script reading Internet users. The second billion
>>     internet users will predominantly be people who read a different
>>     script than latin. U-labels are a requirement for them to have
>>     legible domain names for legitimate sites. A-labels mean they
>>     don't get domain names which they can read. And they deserve to
>>     be able to read their domain names and email addresses.
>>
>> This is an excellent audience for me to test my rebuttal. Is it 
>> solid?  Can I improve it?
>>
>> Cheers,
>>      —Jim DeLaHunt, Vancouver, Canada
>>
>> On 2018-02-19 23:36, Ronald Geens wrote:
>>> All,
>>>
>>>    I am aware of the good work going on in the UASG to get IDN at 
>>> all levels natively supported in web-adresses and email and I fully 
>>> support that.
>>>
>>> On the other hand there is darker side of the web that people want 
>>> to be protected from.
>>> I just read this blog about some people that may actually find it 
>>> better to see puny-code in stead of regular IDN in order to detect 
>>> spam and phishing.
>>> https://ma.ttias.be/show-idn-punycode-firefox-avoid-phishing-urls/ which 
>>> is an opposite view of what UASG is trying to achieve.
>>>
>>>    Does/Will the UASG have a standpoint in this matter ? Is this in 
>>> scope of UASG or will we rely on the anti-virus industry or even 
>>> registrars/registries to protect the world from abuses like this ?
>>>
>>> Best regards,
>>>
>>> Ron Geens
>>> DNS Belgium
>>
>> -- 
>>      --Jim DeLaHunt,jdlh at jdlh.com      http://blog.jdlh.com/  (http://jdlh.com/)
>>        multilingual websites consultant
>>
>>        355-1027 Davie St, Vancouver BC V6E 4L2, Canada
>>           Canada mobile +1-604-376-8953
>

-- 
     --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant

       355-1027 Davie St, Vancouver BC V6E 4L2, Canada
          Canada mobile +1-604-376-8953

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20180222/32799206/attachment.html>


More information about the UA-discuss mailing list