Oriya Digit Zero ୦ U+0B66 also works
and here is a fake google.com test on MAC OS

Deleted: google.jpg 23.5 KB

	google.jpg 23.5 KB View Download

It's similar to 673971. mgiuca@, could you take a look? Thank you.

jshin deals with character blacklisting.

Again, none of these domains in this bug can be registered in {com,org,net, etc}. 

as a matter of fact, 
if use a same character set,then the domain could be registered
for example,
http://www.xn--zjc.com/ (oriya charset) is registered
the for an other example,
http://www.xn--cgcasbcg.com/ could be registered

so.com is one of the biggest search engine in china (so.jpg)
here comes the fake one
http://www.xn--5ec6f.com/ (fake.png)

and it could be registered because use the same charset(gujarati)

Deleted: so.jpg 24.8 KB

	so.jpg 24.8 KB View Download

Deleted: fake.png 1.2 KB

	fake.png 1.2 KB View Download

Deleted: regist.jpg 40.0 KB

	regist.jpg 40.0 KB View Download

http://www.unicode.org/charts/PDF/U0370.pdf
also Greek and Coptic could be used to spoof

here comes a fake paypal.com (paypal.jpg)
http://www.xn--kxadah2ec.com/

and it could be registered

so i think total of them will be of Medium Security_Severity?

Deleted: paypal.jpg 5.9 KB

	paypal.jpg 5.9 KB View Download

Deleted: regist.jpg 30.7 KB

	regist.jpg 30.7 KB View Download

here is the fake paypal test on my local server (I'm too poor to regist it :(
also character "K W O" and etc could be used to spoof any other website.

Deleted: local.jpg 156 KB

	local.jpg 156 KB View Download

re: comment 11

Anyway, there's no way to block a domain made of a single Oriya character just because that letter looks like 'o'. ( www.୦.com )

That's NOT the same issue as you originally reported. What I said is that mixed-script examples in your original report cannot be registered. 


As for so.com, it has to be added to the top domain list in bug 722022. Even with that added, ઽ૦.com might not be regarded as a spoofing attempt against so.com.  

The same is true of www.ραγραί.com (paypal.com is already in the top domain list). 


re: ૭૦૦૭૮૬.com : what does this look like? 

does this top domain list solved spoof so.com or paypal.com in this stable version?
i'm not clear but seems it was not transformed into punycode.(since another spoof use Malayalam was registered by someone)
thanks for reply

www.ραγραί.com is not shown in punycode because it's not regarded as look-alike of www.paypal.com . 

If ί (U+03AF) were to be regarded as similar to 'l',  'i' (Latin smaller letter i) would be, too.  

>  Even with that added, ઽ૦.com might not be regarded as a spoofing attempt against so.com.  

It'd not (see http://unicode.org/cldr/utility/confusables.jsp?a=so&r=None ). 

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

commit fd34ee82420c5e5cb04459d6e381944979d8e571
Author: Jungshik Shin <jshin@chromium.org>
Date: Wed Oct 04 23:25:49 2017

Change the script mixing policy to highly restrictive

The current script mixing policy (moderately restricitive) allows
mixing of Latin-ASCII and one non-Latin script (unless the non-Latin
script is Cyrillic or Greek).

This CL tightens up the policy to block mixing of Latin-ASCII and
a non-Latin script unless the non-Latin script is Chinese (Hanzi,
Bopomofo), Japanese (Kanji, Hiragana, Katakana) or Korean (Hangul,
Hanja).

Major gTLDs (.net/.org/.com) do not allow the registration of
a domain that has both Latin and a non-Latin script. The only
exception is names with Latin + Chinese/Japanese/Korean scripts.
The same is true of ccTLDs with IDNs.

Given the above registration rules of major gTLDs and ccTLDs, allowing
mixing of Latin and non-Latin other than CJK has no practical effect. In
the meantime, domain names in TLDs with a laxer policy on script mixing
would be subject to a potential spoofing attempt with the current
moderately restrictive script mixing policy. To protect users from those
risks, there are a few ad-hoc rules in place.

By switching to highly restrictive those ad-hoc rules can be removed
simplifying the IDN display policy implementation a bit.

This is also coordinated with Mozilla. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1399939 .

BUG= 726950 ,  756226 ,  756456 ,  756735 ,  770465 
TEST=components_unittests --gtest_filter=*IDN*

Change-Id: Ib96d0d588f7fcda38ffa0ce59e98a5bd5b439116
Reviewed-on: https://chromium-review.googlesource.com/688825
Reviewed-by: Brett Wilson <brettw@chromium.org>
Reviewed-by: Lucas Garron <lgarron@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#506561}
[modify] https://crrev.com/fd34ee82420c5e5cb04459d6e381944979d8e571/components/url_formatter/idn_spoof_checker.cc
[modify] https://crrev.com/fd34ee82420c5e5cb04459d6e381944979d8e571/components/url_formatter/url_formatter_unittest.cc

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