Philip, thanks for landing this in https://crrev.com/c/7112300/4 - this has helped with the ICU 78.2 roll as well!
On Tuesday, March 17, 2026 at 11:01:06 PM UTC+2 Chris Harrelson wrote: > LGTM to continue with your new plan. > > On Tue, Mar 17, 2026 at 1:59 PM Philip Jägenstedt <[email protected]> > wrote: > >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdyNUGMaTDWK%2BYK-%3D_HtnqefAwHVB0Xkz455JbKSDT7NA%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/400099a8-5658-4f68-a01a-7ec757d4ffc2n%40chromium.org.
