The strongest argument against showing A-labels is the technical side of point 3, and IMHO it is sufficient to make the case. Point 2 is a true statement but doesn't address the problem. Point 1 is about what else should be done to address the problem, but does not directly rebut the suggestion. In more detail, (for anyone in this choir who wants the full sermon ;) ) People who more naturally read a non-latin script - the primary market for non-latin script - are generally more able to read that accurately and less able to spot oddities in latin script or another script they don't read. This isn't a question of "deserving" to be allowed to use your own script (although it is true people do deserve that IMHO). It is about ensuring that people can effectively notice whether something is a meaningful URL they were looking for, or a corrupted version. It is easier for most people in their own script than noticing a corrupted version of a punycode string. This is also generally true for e.g. Europeans who do read Latin script. Dahlström, Dahlstrom, and Dahlstrőm *are* similar, and could be used for phishing attacks (one of them is part of a friend's email address). but xn--ksjdlfn and xn--sekdrtb are actually gibberish, and spotting whether gibberish has a mistake is pretty difficult for normal people. A better idea might be larger fonts, to make differences clearer. On user demand, offering a strict non-ambiguous *transliteration* could help (whether that is from or to a script such as Latin, or doesn't involve it at all as between say Thai and Arabic). But transliteration introduces some thorny and well-known problems. I hope that is the reason it isn't widely available, rather than just because a bunch of engineers assume everything begins with Latin script anyway... cheers cheers. On Tue, 20 Feb 2018 09:54:40 +0100, Jim DeLaHunt <jfrom.uasg@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), 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@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

-- Chaals is Charles McCathie Nevile find more at http://yandex.com

On Tue, Feb 20, 2018 at 10:40:31AM +0100, Chaals McCathie Nevile wrote:

People who more naturally read a non-latin script - the primary market for non-latin script - are generally more able to read that accurately and less able to spot oddities in latin script or another script they don't read.

This is only partly relevant, because even an ASCII label can cause trouble. If you doubt this, and you use an Apple product, I suggest that you try to transcribe a string in the default font in either iOS or OSX (Keychain Access) where the string contains exactly one of capital I, lower-case L, capital O, or the digit zero. There are certainly similar cases with composed Latin characters, and there are several well-worked-over examples in Arabic script -- the latter where characters that are all but guaranteed to use the same glyph are nevertheless different characters.

It is about ensuring that people can effectively notice whether something is a meaningful URL they were looking for, or a corrupted version. It is easier for most people in their own script than noticing a corrupted version of a punycode string.

The basic problem here is that domain names were a _lousy_ basis on which to build security policies, but we did it. (That sort of thing happens all the time. The automobile was a lousy basis around which to do social planning, but every North American city of any size shows that we did that, too. We shape our tools and thereafter they shape us.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

Hi, On Tue, Feb 20, 2018 at 12:54:40AM -0800, Jim DeLaHunt wrote:

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.

I sort of agree with that, but I want to note some cautions. 1. It is not possible as a general matter to ensure that nothing "confusable" ever gets registered. We have no control over the fonts people are using, or the visual acuity of people, or the context in which the label is presented. All of those have a great deal to do with whether people get phished, quite apart from the content of the labels. 2. The "no-script-mixing" rules that many of us are arguing for are also drags on innovation, and in some locales there are good reasons to mix scripts. That tension won't go away just because we said so. 3. The distinction between identifiers and branding appears to be almost totally lost on people, with even the Unicode Technical Committee, who recommend against emojis in identifiers, saying that they're ok in domain names (contrary to the IDNA2008 specifications). I don't have any idea what to do about this, because most people don't understand how context-free and locale-free identifiers could possibly work reliably. (That includes me.) 4. There is no way to make rules for the entire DNS, because it is a distributed datbase with distributed authority. More generally, however, the position, "Use the A-label form" is in effect the position, "Don't use IDNA." For the most conspicuous fact about A-labels is that they're equivalently meaningless to everyone. That hardly seems like a usability win.

3. The people for whom A-labels instead of U-labels

There is nobody for whom A-labels are useful. A-labels are those things that have the prefix (xn--) and a punycode-encoded string in them. 'anvilwalrusden.com' has two labels, neither of which is an A-label, though they're both LDH-labels. This is covered in painful detail in RFC 5890, so I refer the gentle reader to that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

OOPs ... I thought I was typing a fictitious web address for the here link but I was wrong. There is a domain called the.link<http://the.link>. It looks to be a revenue parked website. Next time, no matter how absurd and improbable I make my fictitious addresses, I will first check they are not real addresses before emailing. André Schappo On 21 Feb 2018, at 18:01, Andre Schappo <A.Schappo@lboro.ac.uk<mailto:A.Schappo@lboro.ac.uk>> wrote: I would argue that such security issues pale into near insignificance compared to the ubiquitous practice of link addresses not being self evident and up front. eg ...please click here<http://thanks.for.clicking.the.link/I/have/now/emptied/your/bank/account> for further information on ... I consider the up front presentation of link addresses should be common practice. I describe my working practice in schappo.blogspot.co.uk/2018/01/computer-science-internationalization_7.html<http://schappo.blogspot.co.uk/2018/01/computer-science-internationalization_...> My practice does not, of course, guarantee a website is safe, but if the up front presented address is different to the resultant address after clicking the link, this would help to arouse suspicion in users. So, yes, letʼs have IDNs presented up front to users as U-labels and not A-labels and not hidden behind a link labelled, for example, here<http://thanks.for.clicking.the.link/I/have/now/emptied/your/bank/account> André Schappo On 20 Feb 2018, at 08:54, Jim DeLaHunt <jfrom.uasg@jdlh.com<mailto:jfrom.uasg@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@jdlh.com<mailto:jdlh@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 🌏 🌍 🌎 André Schappo 小山@电邮.在线?Subject=你好小山😜<mailto:%E5%B0%8F%E5%B1%B1@%E7%94%B5%E9%82%AE.%E5%9C%A8%E7%BA%BF?Subject=%E4%BD%A0%E5%A5%BD%E5%B0%8F%E5%B1%B1%F0%9F%98%9C> schappo.blogspot.co.uk<https://schappo.blogspot.co.uk/> twitter.com/andreschappo<https://twitter.com/andreschappo> weibo.com/andreschappo?is_all=1<https://weibo.com/andreschappo?is_all=1> groups.google.com/forum/#!forum/computer-science-curriculum-internationalization<https://groups.google.com/forum/#!forum/computer-science-curriculum-internat...> 🌏 🌍 🌎 André Schappo 小山@电邮.在线?Subject=你好小山😜<mailto:%E5%B0%8F%E5%B1%B1@%E7%94%B5%E9%82%AE.%E5%9C%A8%E7%BA%BF?Subject=%E4%BD%A0%E5%A5%BD%E5%B0%8F%E5%B1%B1%F0%9F%98%9C> schappo.blogspot.co.uk<https://schappo.blogspot.co.uk> twitter.com/andreschappo<https://twitter.com/andreschappo> weibo.com/andreschappo?is_all=1<https://weibo.com/andreschappo?is_all=1> groups.google.com/forum/#!forum/computer-science-curriculum-internationalization<https://groups.google.com/forum/#!forum/computer-science-curriculum-internat...>

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@jdlh.com<mailto:jfrom.uasg@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@jdlh.com<mailto:jdlh@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

Hi Jim. Just a couple of comments for clarification. You say: 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. You are right. However, those are cases that are well-defined, and do not require a decision to be made on a case by case. What may happen with the “confusing similar” case is that not everybody agrees on what is similar and what is not. On the other hand, it is clear what is a text in Thai or Japanese script, so the outcome is predictable and not depending by human judgement. And further below: 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. I fully agree with you. I hope that what you indicate as reason 3. (which is IMHO the most powerful argument) will be accepted as a sufficient argument. Let me add that, although I admit that the problem becomes bigger with IDN, we already have it with ASCII labels - for instance confusing “O" and “0” - where we have no solution. Cheers, Roberto On 23.02.2018, at 01:35, Jim DeLaHunt <jfrom.uasg@jdlh.com<mailto:jfrom.uasg@jdlh.com>> wrote: 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@jdlh.com<mailto:jfrom.uasg@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@jdlh.com<mailto:jdlh@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@jdlh.com<mailto:jdlh@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