Intent to Ship: Randomizing TCP Port Allocation on Windows
Ari Chivukula
Contact emails
ari...@chromium.org, awi...@chromium.org, mike...@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, 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
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 to Windows 10, 2020 H1 and tested it in Edge.
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
WebKit: Appears to inherit OS defaults
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.
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
Estimated milestones
139
Link to entry on the Chrome Platform Status
Domenic Denicola
Jeremy Roman
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 category. (Which is... confusingly named.) But, in case it helps, LGTM1.On Thursday, June 19, 2025 at 12:12:34 AM UTC+9 Ari Chivukula wrote:Contact emails
ari...@chromium.org, awi...@chromium.org, mike...@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, 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
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 to Windows 10, 2020 H1 and tested it in Edge.
--
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+...@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.
Daniel Bratell
I'm also not sure it needs API Owner approval, but I'll second Domenic: LGTM2
(It does get some extra visibility this way which might be helpful, especially if it triggers some unexpected problems)
/Daniel
Ari Chivukula
Will Harris
Ari Chivukula
Erik Anderson
There was no new API here and thus no API detection mechanism. It’s just a bug fix that ensures sockets are not rapidly reused toward the beginning of the available range.
Even when the bug is present, most networks work fine; it’s stateful off-device middleboxes that might not see that the connection got terminated and then get confused by a new connection from the same source port. The use of this port randomization flag was shipped before, even with the Windows bug; it took a couple of major Chrome releases before it was determined it should be turned back off. That was the right decision, but that’s also an indication that the risk of extreme breakage is low.
The bug fix shipped has shipped with the Windows monthly security update at least as early as November 2023 (some releases earlier). At this point, only a device that hasn’t taken a security update from Windows for 18+ months would see the buggy behavior. I suppose if you wanted to be extremely paranoid, you could look at the fourth version component on those older versions to check for that update. Or just scoping to 22H2+ is reasonable too.
Rick Byers
Ari Chivukula
Erik Anderson
That sounds reasonable, thanks!
I also took a look with Will re: the exact fixed version numbers and rough rates of update adoption to reason about risk. It looked like a small but large enough number of unpatched users to give us pause. I added a note to the bug about potential options there.