Not to my knowledge, but I'm adding @erik.ander...@microsoft.com <erik.ander...@microsoft.com> in case there is something I missed.
I'm fine with starting with 22H2+ only for now, and adding 20H1+ only if there's a reliable way to detect the fix or metrics on fix rollout % that are convincing. ~ Ari Chivukula (Their/There/They're) On Thu, Jun 19, 2025, 14:21 Will Harris <w...@chromium.org> wrote: > in general, it's preferable to do a capability test via an OS API rather > than simply gate on Windows version. Does the new API that Microsoft added > (and backported) provide a way for the OS to signal that this > better/working API is available? > > Will > > On Thu, Jun 19, 2025 at 11:15 AM Ari Chivukula <aric...@chromium.org> > wrote: > >> That's probably possible, though hopefully they have installed system >> updates in the past year. We could just target 2022H2 and later if needed. >> >> ~ Ari Chivukula (Their/There/They're) >> >> >> On Thu, Jun 19, 2025 at 10:54 AM Jeremy Roman <jbro...@chromium.org> >> wrote: >> >>> >>> >>> On Thu, Jun 19, 2025 at 12:10 AM Domenic Denicola <dome...@chromium.org> >>> wrote: >>> >>>> I believe this should be completely unobservable to web authors, right? >>>> (Apart from maybe fewer or more network errors.) >>>> >>>> If so, I don't think this needs any LGTMs, as it fits well under the >>>> Web-developer-facing >>>> change to existing behavior >>>> <https://www.chromium.org/blink/launching-features/#behavior-changes> >>>> category. >>>> (Which is... confusingly named >>>> <https://github.com/GoogleChrome/chromium-dashboard/issues/5145>.) >>>> But, in case it helps, LGTM1. >>>> >>>> On Thursday, June 19, 2025 at 12:12:34 AM UTC+9 Ari Chivukula wrote: >>>> >>>>> Contact emails >>>>> >>>>> aric...@chromium.org, awil...@chromium.org, miketa...@chromium.org >>>>> Explainer >>>>> >>>>> None >>>>> Specification >>>>> >>>>> None >>>>> >>>>> Summary >>>>> >>>>> This launch enables TCP port randomization on versions of Windows >>>>> (2020 H1 or later) where we do not expect to see issues with re-use of >>>>> prior ports occurring too fast (causing rejection due to timeouts on port >>>>> re-use). The rapid port re-use issue arises from the Birthday problem >>>>> <https://en.wikipedia.org/wiki/Birthday_problem>, where the >>>>> probability of randomly re-picking a port already seen rapidly converges >>>>> with 100% for each new port chosen when compared to port re-use in a >>>>> sequential model. >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>Network >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22> >>>>> >>>>> TAG review >>>>> >>>>> None >>>>> >>>>> TAG review status >>>>> >>>>> Not applicable >>>>> >>>>> >>>>> Motivation >>>>> >>>>> When port randomization is disabled (the default), sites are able to >>>>> count the amount of connections opened by other tabs if they check the TCP >>>>> port used for new connections before and after opening another window. >>>>> This >>>>> knowledge can be used to glean information about other sites like whether >>>>> they are logged in or not. >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> This launch only impacts Windows, and should not cause compatibility >>>>> issues as Microsoft backported their port randomization fix >>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5464674> >>>>> to Windows 10, 2020 H1 and tested it in Edge. >>>>> >>>> >>> Is it possible that we have users on versions >= 2020H1, < 2022H2 but >>> who have not received the backported fix (e.g., because they have not >>> installed the applicable update)? Would they encounter brokenness in Chrome? >>> >>> >>>>> Chrome previously attempted to roll this out in 2021 but ran into >>>>> (since resolved) issues where rapid port re-use caused network errors. >>>>> >>>>> Rollout on linux isn’t needed as port randomization is enabled by >>>>> default while on macOS an issue similar to the one on Windows with rapid >>>>> port re-use causing issues is still around. >>>>> >>>>> Gecko: Appears to inherit OS defaults >>>>> <https://github.com/search?q=repo%3Amozilla-firefox%2Ffirefox+setsockopt&type=code&p=1> >>>>> >>>>> WebKit: Appears to inherit OS defaults >>>>> <https://github.com/search?q=repo%3AWebKit%2FWebKit+setsockopt&type=code> >>>>> >>>>> Web developers: N/A >>>>> >>>>> Debuggability >>>>> >>>>> This will be gated behind the base::feature kTcpPortRandomizationWin, >>>>> so if breakage is suspected that flag could be turned off to detect >>>>> impact. >>>>> For how to control feature flags, see this >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:base/feature_list.h;drc=159a65729cf8fca4d9f453d12d97ab6515360491;l=259> >>>>> . >>>>> >>>>> Measurement >>>>> >>>>> The histogram Net.TCPSocket.PortReuseTimeWindows2.{IPType}.{Result} >>>>> will be used to gauge whether port re-use timings fall too low, while >>>>> Net.TcpConnectAttempt.Latency.{Result} will be used to detect increases in >>>>> overall connection failure rates. >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>> >>>>> No, just Windows >>>>> >>>>> Is this feature fully tested by web-platform-tests? >>>>> >>>>> No, as this is a blink networking focused change browser tests or unit >>>>> tests are more likely. >>>>> >>>>> Flag name on about://flags >>>>> >>>>> None >>>>> >>>>> Finch feature name >>>>> >>>>> kTcpPortRandomizationWin >>>>> >>>>> Rollout plan >>>>> >>>>> This will be rolled out slowly to detect issues early and either >>>>> change the version target or roll back. We don’t believe an experiment is >>>>> needed or desired as the issues we saw before were not very prevalent, we >>>>> likely need to go beyond 1% to get enough data on Windows to know if >>>>> there’s still a problem. >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> No >>>>> >>>>> Tracking bug >>>>> >>>>> https://crbug.com/40744069 >>>>> >>>>> Estimated milestones >>>>> >>>>> 139 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5106900286570496 >>>>> >>>>> -- >>>> 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 blink-dev+unsubscr...@chromium.org. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ac125fa-3adf-4193-a1ff-1bf28f2f6020n%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ac125fa-3adf-4193-a1ff-1bf28f2f6020n%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 blink-dev+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJXMP6tCc8KFK_sC07jAbxuX7e%3Dz2sBS-L%2BPU790vafdg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJXMP6tCc8KFK_sC07jAbxuX7e%3Dz2sBS-L%2BPU790vafdg%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DL_yey6QTmOv2mSx-uSyvTHebqDt3s3sm_KMxRZwKSqaA%40mail.gmail.com.
