Repros on Windows as well.

Deleted: Screen Shot 2017-08-17 at 4.59.32 PM.png 57.3 KB

	Screen Shot 2017-08-17 at 4.59.32 PM.png 57.3 KB View Download

Sigh.....   I wish U+25CC (dotted circle) were used across the board when a base character and a combining mark belong to different scripts (the condition is a bit more complex, but the gist is that).  

I thought at least Blink uses U+25CC (even though Omnibox - native layout - does not), but it does not on my Ubuntu box (DejaVu Sans Mono for Latin and Tibetan Machine Uni for Tibetan). Perhaps, the latter font does not have U+25CC. 

google༷.com   (U+0F37 after 'e'). 

Filed http://bugs.icu-project.org/trac/ticket/13328 . 

In the meantime, this issue strengthens an argument for going back to 'Highly Restrictive script mixing' (only allow mixing of CJK + Latin).  


Wait...   examples in this bug report cannot be registered at least for Verisign-controlled TLDs because it violates Verisign's script mixing rules.  

See https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-policy/registration-rules/index.xhtml .

Given the last para in the previous comment, security risk is rather low and I'm even tempted to open up this issue to the public. 

 bug 726950  is about U+0F35 after a Latin base character..

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