[CPWG] Verisign

Wed Jan 8 00:22:35 UTC 2020

 Hi Roberto, 
I don't know specifically what tables of potential problems you are referring to.  But since I'm on the Latin Generation Panel (that is, the part of IDN working on the Latin alphabet based scripts) I do know that we haven't published our lists/tables yet. 
As for why these particular issues are getting raised, I would not that for the most part scripts are used by one, or at most a half dozen, different languages.  The Latin script is used by over 2 hundred.  Because on the way it evolved, what that script has is 26 letters modified by a couple dozen diacritics.  Some of which are essentially indistinguishable.  By the time the various combinations are gathered, we are over 200 symbols. 
Any given language (and it's users) maybe involved a half dozen of those diacritics.  Users have trouble identifying the others simply because they have never encountered them and don't realize that there might be something to look for.  You may be familiar with the cedilla under the letter C used in French.  But would it even occur to you to look for one under a letter M?  You may be familiar with the acute accent used over some vowels.  But if the dot over a letter I was replaced by one, would you realize it meant you had a different character? 
To date, we have seen criminal activity involving a relatively small number of symbols.  (I believe there was mention in Montreal of a scam involving replacing the J in EasyJet's name with an I.)  But criminals have the same challenges other users have: they just aren't aware (yet!) of all the possibilities that await. So it may not be unreasonable to foresee a surge in problems when ICANN's handy list of variants and confusables (focused on TLDs, but work anywhere in the name) is published. ,   I suppose we could reduce the problem by forcing users to use the actual IP address, rather than domain names.  If nothing else, people would have to pay more attention in order to make sure that they hadn't accidentally gotten the wrong address.  Of course, that loses the ease of use that domain names provide....
Bill
    On Tuesday, January 7, 2020, 04:07:43 PM PST, Roberto Gaetano <roberto_gaetano at hotmail.com> wrote:  

 Hi Bill.Thanks for answering my question.

The reason why I was asking for data is that I am very suspicious about analyses based only on suppositions, in particular when suppositions are addressed in one direction only.
Since we are in the domain (pun not intended) of hypotheses, I will propose mine - supported, when possible, by observation - going in a different direction.
IDNs are being deployed for years now. Had reputable organizations felt the risk of registrations of IDNs that are confusingly similar (personally I find the qualification of “indistinguishable” factually incorrect) as a serious risk, we would have witnessed a spike in defensive registrations. To me, the fact that it did not happen is, if not a proof, at least an indication that the vast majority of these organizations do not see this as a serious threat.
As you say, ICANN has produced a few months ago tables of the potential threats. My observation is that crime normally acts fast - generally before the potential pitfall is brought to the general public. Why would this case be different?
My observation is that a cure that limits the effects of a problem without addressing the root cause is seldom effective. In this case the root cause is, IMHO, that the “real” url is not the displayed one, therefore potentially inducing the user in error. Maybe to solve this problem is not trivial, but it seems to me that addressing the behaviour of the browsers will produce far better results in the long term than creating blacklists, regulating the domain name market, forcing defensive registrations, or whatever else. Unless, of course, the objective is not solving the problem but influencing the domain name market.
I would like to conclude with a provocative question. How come that the potential problems supposedly originated by the introduction and deployment of IDNs are raised only by people and interest groups that are operating in a plain ASCII environment - and more often than not of English mother tongue?
Cheers,Roberto

On 07.01.2020, at 18:45, Bill Jouris via CPWG <cpwg at icann.org> wrote:
Hi Roberto, 
I don't work for Citi Bank, and am not aware of knowing anyone who does.  So I have no idea. 
I would note that, at this moment, we are probably 6 months from ICANN publishing the IDN effort's tables of all the variations on the Latin alphabet.  Having that readily available will make coming up with indistinguishable domain names much easier for bad actors.  And thus the need for defensive registrations. 
In short, the problem wrt the need for defensive registrations is still at the readily foreseeable stage, rather than the already exploding in our face stage.  
Bill

Sent from Yahoo Mail on Android

On Tue, Jan 7, 2020 at 2:16 AM, Roberto Gaetano<roberto_gaetano at hotmail.com> wrote:Hi Bill.Just a couple of questions wrt:

The only obvious defense, for registrants who want their customers to arrive reliably at their website, will be defensive registrations.  Lots of defensive registrations.  (I did a quick calculation for Citi Bank.  4 letter domain name.  Close to 300 readily confusable variations.  Longer names would have more, of course.)

How many actual defensive registrations has Citi Bank?
Thanks,R.

_______________________________________________
CPWG mailing list
CPWG at icann.org
https://mm.icann.org/mailman/listinfo/cpwg

_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20200108/716b1d78/attachment.html>