Windows Firewall prompt for a freshly downloaded Chrome for Testing: bound-but-silent UDP sockets during Cloudflare challenge loads; no launch flag found (measurement trail)

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

John saw the 'allow public and private networks' dialog for chrome.exe (C:\users\azureuser.cache\puppeteer\chrome\win64-148.0.7778.97) on winvm on 2026-09-04, on a CfT binary freshly downloaded that day. pup's hard rule is zero firewall prompts. What was measured, each on a browser whose command line was read back and with DigiKey's Cloudflare 'Just a moment' challenge confirmed on screen, sampler running concurrently: (1) MediaRouter/mDNS was already off (2.0.120/2.0.293) - no 5353 listener. (2) 2.0.393 added --disable-quic and --force-webrtc-ip-handling-policy=disable_non_proxied_udp: no change, six to twelve paired IPv4/IPv6 UDP sockets on 0.0.0.0/:: still appeared, all owned by the network-service process, only while the challenge ran (TI loads bind nothing). (3) 2.0.394/395 turned off AsyncDns, DoH, UseDnsHttpsSvcb, ECH: no change. (4) 2.0.396 wrote the WebRtcIPHandling profile prefs pre-launch (confirmed in Preferences): no change; and chrome://webrtc-internals lists ZERO PeerConnections, so it is not WebRTC. (5) Windows Firewall connection logging joined against the sampled Chrome ports: none of those sockets ever SENT a packet (the only UDP in the window was two svchost DNS queries). So these are bound-but-silent UDP sockets - the signature of Chrome's own reachability/connect-without-send probing in the network service (IPv6 reachability check style), and a bare UDP bind is exactly what Windows prompts on for a new exe. No launch flag or pref I know of disables it. Consequence: every NEW CfT download on a fresh machine will pop this dialog on the first challenge-style page, once, and pup cannot add a firewall rule without elevation (a UAC is the same violation). The only zero-prompt lever is an already-elevated helper writing an inbound rule for the CfT exe after each download - filed as an ask on adom/adom-bridge. Three false zeros along the way are recorded in dev-skills/pup-no-firewall (challenge must be on screen; browser must carry the flags; sampler must run concurrently). All flags/prefs stay (each removes a real bind path); this issue tracks the remaining source.

2 Replies

John Lauer · 2mo ago

Why only winvm showed it, measured 2026-09-04: Windows shows the 'allow this app' dialog ONLY to administrator accounts; a standard user gets no dialog and Windows silently writes Inbound Block rules for the exe. ConfRoomROG: John's account is admin=False and it already holds two Inbound Block rules for chrome-win64 (CfT 148, silently created when that build was installed on 2026-07-24) - hence never a dialog there. winvm: azureuser is admin=True and the CfT exe was freshly downloaded on 2026-09-02 (cache wiped for a fresh-install simulation), so no rule existed and the dialog appeared. All profiles on both boxes have notifyOnListen=True, so the notification setting is not the difference; the account type is. Fleet exposure is therefore: administrator accounts, once per new CfT build, on the first challenge-style page. The bound-but-silent UDP sockets remain the trigger and the ab-helper rule (adom-bridge#141) remains the only zero-dialog lever; for standard users the silent Block rule Windows writes is already harmless to pup (no inbound needed).

John Lauer · 1mo ago

Closing as explained and documented. The measurement trail here plus the 2026-09-04 reply settle it: the dialog appears only for an administrator account and only for a browser exe Windows has never seen (a fresh Chrome for Testing download); a standard user never sees it because Windows writes silent Inbound Block rules. The cause is bound-but-silent UDP sockets in the network service during a Cloudflare challenge; no launch flag or pref removes them (all tried). There is no silent fix: pre-creating the rule needs elevation, which is a UAC prompt. Written up in the pup-browsers-and-chrome skill (2026-09-19): expect it once per new browser build on an admin account, answer it, it never returns for that exe. Reopen only with a launch flag that measurably stops the binds.

John Lauer closed this · 1mo ago