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/";> 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 (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]> wrote: > LGTM2 > > On Monday, September 29, 2025 at 11:25:35 AM UTC-7 [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] >>> >>> *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). 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]. > 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/CAARdPYdrVd-vyZozo4ws69tZ5X2r4x3bZxPHriBEVaYr3Z5%3Dvg%40mail.gmail.com.
