Pup - the AI's own browser

@@ -95,20 +95,18 @@ first vendor page popped the dialog. Fix (v2.0.393, both launch sites): `--disab (`Get-NetTCPConnection -State Listen` + `Get-NetUDPEndpoint` filtered to chrome-win64 PIDs, every 2s for 40s, excluding 127.0.0.1/::1); the only acceptable output is "NO non-loopback sockets". -## 2026-09-04, corrected: it was WebRTC, and the launch switch is not enough+## 2026-09-04, corrected twice: still OPEN -The QUIC/WebRTC-switch fix above (2.0.393) did NOT stop the binds, and neither did handing DNS-to the OS resolver (2.0.394: `AsyncDns` off; 2.0.395: `UseDnsHttpsSvcb`/ECH off too). A VALID-measurement - every flag confirmed on the live browser's command line, DigiKey's Cloudflare-"Just a moment" challenge confirmed on screen - still caught twelve paired IPv4/IPv6 UDP sockets,-all owned by the network-service process, only while the challenge ran (TI loads bind nothing).-That is WebRTC ICE candidate gathering (challenge pages fingerprint through it), and Chrome for-Testing ignores `--force-webrtc-ip-handling-policy`. The lever that works is the PROFILE PREFS the-enterprise WebRtcIPHandling policy writes, which pup now sets pre-launch in the profile it owns-(2.0.396, prepareCleanProfile): `webrtc.ip_handling_policy = disable_non_proxied_udp`,-`webrtc.nonproxied_udp_enabled = false`, `webrtc.multiple_routes_enabled = false`. WebRTC still-works over TCP/proxied transport; it just never binds a raw UDP socket. The DNS/QUIC flags stay-(they remove other UDP bind paths) but were not this trigger.+Neither the QUIC/WebRTC launch switches (2.0.393), nor handing DNS to the OS resolver (2.0.394+`AsyncDns` off, 2.0.395 `UseDnsHttpsSvcb`/ECH off), nor the WebRTC profile prefs the enterprise+WebRtcIPHandling policy writes (2.0.396, confirmed present in Preferences) stopped the binds. A+VALID measurement on each build - every flag confirmed on the live browser's command line, the+DigiKey Cloudflare "Just a moment" challenge confirmed on screen, sampler running concurrently -+still caught twelve paired IPv4/IPv6 UDP sockets, all owned by the network-service process, only+while the challenge ran (TI loads bind nothing). Attribution is the next step (which destination+ports those sockets talk to, and whether the page creates any RTCPeerConnection at all), not+another flag. The flags and prefs stay in place: each removes a real UDP-bind path, they just were+not THIS one.  Three measurement traps that produced false zeros on the way here, so they are not repeated: 1. A "no sockets" reading is meaningless unless the challenge page provably loaded during the@@ -116,5 +114,5 @@ Three measurement traps that produced false zeros on the way here, so they are n 2. The browser under test must carry the flags: read its command line. A warm Chrome launched by    the previous build silently invalidates the run; `pup_close` did not always take it down, so on    the test VM kill pup's own browser PID first and confirm zero chrome-win64 processes.-3. Run the sampler CONCURRENTLY with the page load; the sockets exist only for the seconds ICE-   gathering runs and are gone by the time a sequential sampler starts.+3. Run the sampler CONCURRENTLY with the page load; the sockets exist only for the seconds the+   binding activity runs and are gone by the time a sequential sampler starts.