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.
