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
    <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]> 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 <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].
        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/f803f1a3-5ada-46b3-a52a-59196d16ac3f%40chromium.org.

Reply via email to