Hi again, This has not shipped yet, because I've been trying (very intermittently) to make the enterprise policy work in https://crrev.com/c/7010851. However, like others have found with URL parser changes previously, the enterprise policy system is not well suited to this. In summary, enterprise policy isn't loaded and applied early enough to apply to all uses of the URL parser. This could be worked around by mapping the policy to a local state pref which is available during early startup, but then it would apply to all users and leak between users. The conclusion in the review is that the risk (and cost) of adding this policy is much higher than the benefit.
This is a very low-risk change to begin with, so the new plan I'd like to pursue is simply shipping with a Finch kill switch. In case of a problem, I would disable it with Finch and additionally revert+backport to minimize the impact while investigating. If someone could re-affirm their LGTM with this updated plan, I'll go ahead. Best regards, Philip On Tue, Sep 30, 2025 at 6:34 PM Mike Taylor <[email protected]> wrote: > LGTM3 > On 9/30/25 12:57 a.m., Philip Jägenstedt wrote: > > Great, I have updated the rollout plan in the chromestatus entry to "Will > ship enabled for all users" > > On Mon, Sep 29, 2025 at 11:39 PM Daniel Clark <[email protected]> > wrote: > >> 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 (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/CAARdPYcJE8BqWVC3hMJLD4YT0giiuq%3DCjb5Wzh_4_Kks3PJy9w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcJE8BqWVC3hMJLD4YT0giiuq%3DCjb5Wzh_4_Kks3PJy9w%40mail.gmail.com?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/CAARdPYdyNUGMaTDWK%2BYK-%3D_HtnqefAwHVB0Xkz455JbKSDT7NA%40mail.gmail.com.
