For top 10k domains, they'd be blocked. For instance, the following is blocked:

googlẹ.com 

For other domains, there's no way for poor Chrome on the client-side to tell which is legitimate and which is spoofing attempt. Chrome just has an incoming name with no reference to check against !

 As I keep saying, SafeBrowsing with a lot more data/signals at their hands should take this issue up. 

A tentative hack fix would be to add 'mymonero.com' to the top domain list. 

Another alternative would be to just block U+1E00-U+1E9B and Latin extended C-E blocks  (or their curated subsets made up of characters very unlikely to be used in domain names *legitimately*. e.g. letters for Indic transliteration) 

BTW, the reason I talked about U+1E00 ~ U+1E9F instead of up to U+1EFF is that U+1EA0 ~ U+1EFF is for Vietnamese. Note also that we can't simply block U+1EA1 (Latin small Letter A with dot below) because it's a legitimate letter in Vietnamese. 

I wonder if there is a way to collect the list of domains for financial institutions. Even if they'd not make top 10k, we may as well add them to our list of domains to protect from spoofing attempt. 

> U+1E00-U+1E9B and Latin extended C-E block

Likewise for Cyrillic extension and Greek extension blocks. 

jshin: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

jshin: Uh oh! This issue still open and hasn't been updated in the last 29 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm removing 1e00 ~ 1e9b and a few other blocks from the allowed set. 

Safe Browsing folks: Like the other one I CC'd you on last night, is there a way for SB to handle this? There are a million bugs in this class, and we need a strategy to deal with them systematically. Maybe we should set a Q12018 OKR, have a meeting, et c. +estark also.

If these phishy domains winded up in SB blacklist, we will definitely catch them.
I guess PhishGuard will make things slightly better. Since if any of these phishy domains try to ask for Google password, we will warning users about it.

I guess what #c4 suggests is to have a SB list of known good domains that we won't tolerate spoofs of, similar to the top-10k list.

Before we explore the possibility of having a SB list for this, can you (jshin@) please clarify the following for my information:

I thought that you recently added code to show PunyCode if there was use of mixed character sets i.e. for instance, ASCII and Cyrillic, due to the large number of VRP bugs we got for those. Can you explain what was fixed there and why does that not address this issue?

For context, this question came up during the VRP panel today for https://crbug.com/619834 also.

> I thought that you recently added code to show PunyCode if there was use of mixed character sets i.e. for
> instance, ASCII and Cyrillic, due to the large number of VRP bugs we got for those. Can you explain what was
> fixed there and why does that not address this issue?

There's some confusion about character sets vs scripts.

ASCII is a character set (a technical boundary -- the set of characters supported by some encoding scheme); other character sets include Latin-1 (a.k.a., ISO-8859-1, i.e., the first 256 characters of Unicode) and Unicode.

Cyrillic is a script (a semantic boundary -- the set of characters that make up the written form of a group of languages); other scripts include Latin and Devanagari.

The character 'ṇ' (U+1E47; LATIN SMALL LETTER N WITH DOT BELOW) is not in the ASCII or Latin-1 set, but it is in the Latin script.

We do not use Punycode for mixed character sets. We block Punycode for mixed *scripts*. All of the letters in "mymoṇero" are in the Latin script, so this is not covered by the mixed script rule. (I'm not arguing we should not block this case, but explaining why it is not covered by the mixed script rule.)

Matt, Thank you answering the question in comment 13. 

https://chromium-review.googlesource.com/802978 blocks rarely used LGC blocks.

Not all combinations enumerated in the bug report are blocked because some of them use Latin letters used in Vietnamese which are not blocked by the above CL. (see comments 4,5 and 6)

Removing SafeBrowsing component since SB doesn't explicitly handle IDN spoofing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9538209b25b6fb13c54e1bdb170f19a2dd5b3c47

commit 9538209b25b6fb13c54e1bdb170f19a2dd5b3c47
Author: Jungshik Shin <jshin@chromium.org>
Date: Sun Dec 03 00:42:52 2017

Disallow extremely rarely used LGC character blocks.

Explicitly disallows the following blocks.

Latin Ext B (Pinyin subblock), Latin Ext D, Cyrillic Ext B/C,
Greek Ext, Latin Additional (other than Vietnamese).

Note that Latin Ext C & E, Cyrillic Ext A do not belong to
[:IdentifierStatus=Allowed:] and need not be explicitly
banned.

218 characters are blocked. In the Unicode set notation, they're

[:IdentifierStatus=Allowed:] &  [:Ll:] &
[[\u01cd-\u01dc] [\u1c80-\u1c8f][\u1e00-\u1e9b]
 [\u1f00-\u1fff][\ua640-\ua69f][\ua720-\ua7ff]]

Below are the number of domains blocked before and after this CL out of
about a million .com domains as of 2017-11-30.

  6400 : before this cl
  7058 : after this cl
   658 : additional domains blocked with this CL


Bug:  chromium:770709 
Test: components_unittests --gtest_filter=*IDN*
Change-Id: I4de1df5f79b43d9ceddfd01c7dd9af61d1a0e130
Reviewed-on: https://chromium-review.googlesource.com/802978
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521222}
[modify] https://crrev.com/9538209b25b6fb13c54e1bdb170f19a2dd5b3c47/components/url_formatter/idn_spoof_checker.cc
[modify] https://crrev.com/9538209b25b6fb13c54e1bdb170f19a2dd5b3c47/components/url_formatter/url_formatter_unittest.cc

https://bugzilla.mozilla.org/show_bug.cgi?id=1349316 is a Mozilla bug of a similar nature. 

I informed them of what we did. 

I don't know why duplicates are not recorded here. 

Anyway, from  bug 802131 :  goldmaṇsachs.com  

from  bug 801828 : https://shop.bitmaiṇ.com . 

Both have n with a dot below. 

 Issue 812155  has been merged into this issue.

 Issue 812155  reported this for http://www.airfrạnce.com/ 

Is there still work to do here after the CL in c#18?

Other than bug 722022, there's not much we can do here. Let me close this bug. 

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot