That sounds reasonable to me.

From: Philip Jägenstedt <[email protected]>
Sent: Monday, September 29, 2025 12:07 PM
To: Daniel Clark <[email protected]>
Cc: blink-dev <[email protected]>; [email protected] 
<[email protected]>; Chromestatus <[email protected]>
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: IDNA ContextJ rules

Thank you Alex and Dan,

What I proposed above is to gradually enable this feature with Finch as a way 
to mitigate the unknown risk.

However, I realized I could do some httparchive research to gauge the risk. 
Having done that, I'd now like to instead enable the flag and use Finch only as 
a kill switch.

Details of what I did:

I looked at all response bodies that match the regular expression 
"https?://xn--[a-z0-9-.]*/" and extracted all matches. There were 117k sites 
with matches. Then I decoded all of the hosts in the results, and there were 
only 59k unique hosts.

Out of those, a single one contained a U+200C or U+200D. That's a link in 
https://temora.com.au/relocate with this markup:

<a 
href="http://xn--https-wt3b//www.temorapodiatry.com.au/<http://xn--https-wt3b/www.temorapodiatry.com.au/>">

The "xn--https-wt3b" host there decodes to "\u200dhttps" and obviously it's not 
a working link or intentional.

To ensure my script wasn't broken I added 
xn--1ug574b1l58a.com<http://xn--1ug574b1l58a.com/> (which would be 
🐦‍⬛.com<http://xn--w5i.com/>) to confirm that would've been logged, and it was.

This isn't the widest possible search since it doesn't include Unicode 
hostnames. It seems like BigQuery doesn't support unicode escapes, so I 
couldn't search for domains containing U+200C or U+200D directly.

Nevertheless, I think that if there's only a single instance of such a host 
being encoded as xn-- punycode, then it's not going to be at all common. 
Together with the fact that the URLs don't work in Firefox or Safari at all, 
I'd like to ship using a kill switch, plus an enterprise policy just to be safe.

Does that plan sound OK?

On Mon, Sep 29, 2025 at 8:26 PM 'Dan Clark' via blink-dev 
<[email protected]<mailto:[email protected]>> wrote:
LGTM2
On Monday, September 29, 2025 at 11:25:35 AM UTC-7 
[email protected]<mailto:[email protected]> wrote:
LGTM1; thanks for doing this so carefully.
On Friday, September 26, 2025 at 12:05:02 PM UTC-7 Chromestatus wrote:
Contact emails
[email protected]<mailto:[email protected]>
Specification
https://url.spec.whatwg.org/#idna
Summary
IDNA is the mechanism for non-ASCII characters in domain names, encoding a URL 
like http://네이버.한국/<http://xn--950bt9s8xi.xn--3e0b707e/> as 
http://xn--950bt9s8xi.xn--3e0b707e/ (a redirect to 
naver.com<https://naver.com/>). The processing is defined by 
https://www.unicode.org/reports/tr46/#Processing and is invoked by 
https://url.spec.whatwg.org/#idna. The URL spec sets the CheckJoiners flag, 
which enables the ContextJ rules in IDNA2008: 
https://www.rfc-editor.org/rfc/rfc5892.html#appendix-A.1 
https://www.rfc-editor.org/rfc/rfc5892.html#appendix-A.2 This disallows ZWNJ 
(U+200C ZERO WIDTH NON-JOINER) and ZWJ (U+200D ZERO WIDTH JOINER) in most 
places in URLs. The implementation is to simply pass the UIDNA_CHECK_CONTEXTJ 
option to ICU, where this rule is implemented: 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/icu/source/common/uts46.cpp;l=1137-1204;drc=8a1988938d4298fbe8fb499b1a59fe4b04a21b15
 This would fix over 200 subtests in WPT relating to IDNA, which already pass 
in Firefox and Safari: 
https://chromium-review.googlesource.com/c/chromium/src/+/6990929 
https://wpt.fyi/results/url/IdnaTestV2.window.html All of the IdnaTestV2 cases 
that would regress from shipping ICU 77 
(https://chromestatus.com/feature/5143313833000960) would also be fixed again 
by this change.
Blink component
Blink>Network<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22>
Web Feature ID
url<https://webstatus.dev/features/url>
Search tags
idna<http://features#tags:idna>
TAG review
None
TAG review status
Not applicable
Risks

Interoperability and Compatibility
Interoperability is improved by bringing URL parsing closer to Firefox and 
Safari. The web compat risk is most likely very low because the URLs that will 
be rejected don't work at all in Firefox or Safari. On the other hand, any 
breakage would be very severe for the same reason. To make this change safely I 
would suggest a gradual Finch rollout.

Gecko: Shipped/Shipping Shipped for a long time, exact version not found

WebKit: Shipped/Shipping Shipped for a long time, exact version not found

Web developers: No signals

Other signals:
WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?
None

Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by 
web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yeshttps://wpt.fyi/results/url/IdnaTestV2.window.html
Flag name on about://flags
None
Finch feature name
UseIDNAContextJRules
Rollout plan
(RARE) Experiment users ramp up over time
Requires code in //chrome?
False
Tracking bug
https://crbug.com/40765949
Measurement
Cannot be measured with use counters because the URL parser is used in many 
places in Chrome, and not all of them have access to an ExecutionContext or 
similar. UMA could be used and give a proportion of URL parses affected metric, 
but given how many URLs are parsed and how rare even valid IDNA URLs seem to 
be, the number is probably vanishingly small and not informative of risk.
Estimated milestones
Shipping on desktop
143
Shipping on Android
143
Shipping on WebView
143

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop 
issues. Please list open issues (e.g. links to known github issues in the 
project for the feature specification) whose resolution may introduce web 
compat/interop risk (e.g., changing to naming or structure of the API in a 
non-backward-compatible way).
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6295810820145152?gate=5173132017139712
This intent message was generated by Chrome Platform 
Status<https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
[email protected]<mailto:[email protected]>.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e1379f3-b224-404f-bc72-a5a0d05b3f46n%40chromium.org<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e1379f3-b224-404f-bc72-a5a0d05b3f46n%40chromium.org?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB23296E457698614A88404FEEC51BA%40CH4PR00MB2329.namprd00.prod.outlook.com.

Reply via email to