app
Pup - the AI's own browser
Public Made by Adomby 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.
← Commit history
pup-no-firewall: corrected findings - WebRTC ICE from challenge pages, profile-pref lever (2.0.396), and the three false-zero measurement traps
1 file changed
+36
dev-skills/pup-no-firewall/SKILL.md+36@@ -82,3 +82,39 @@ renamed the feature: find the current kill switch, verify by socket probe, and u - [ ] It binds any server/socket to something other than loopback. - [ ] It adds/needs a firewall Allow rule, or asks the user to click a firewall dialog. - [ ] A flag change shipped without the socket probe above actually being run.++## 2026-09-04: the second listener class (measured on winvm)++MediaRouter/mDNS was not the only non-loopback bind. With that already disabled, a 40s socket+sampler on a freshly downloaded CfT caught five transient `UDP 0.0.0.0:<ephemeral>` sockets while+DigiKey and TI loaded: WebRTC ICE candidate sockets and QUIC (HTTP/3) client sockets. Windows+prompts on the FIRST such bind of a new exe, and every CfT download is a new exe, so a new user's+first vendor page popped the dialog. Fix (v2.0.393, both launch sites): `--disable-quic`,+`--force-webrtc-ip-handling-policy=disable_non_proxied_udp`, and `WebRtcHideLocalIpsWithMdns` in+`--disable-features`. Proof recipe: open a heavy vendor page and run the sampler+(`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++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.++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+ sample (read `document.title`: "Just a moment..." is the trigger).+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.