Pup - the AI's own browser

Summary

pup writes "webrtc": {"ip_handling_policy": "disable_non_proxied_udp", "multiple_routes_enabled": false, "nonproxied_udp_enabled": false} into the profile Preferences (~/.adom/pup-profiles/adom-you/Default/Preferences, introduced in 2.0.396 during the investigation in #91).

As documented in #91, disable_non_proxied_udp did not suppress the Windows Firewall UDP prompt (which comes from Chromium's network-service IPv6 reachability sockets during Cloudflare challenge loads, with zero WebRTC PeerConnections), but keeping it in Preferences breaks WebRTC UDP streaming web apps in pup — specifically Google DeepMind's Project Genie (https://labs.google/fx/projectgenie).

Environment

• Bridge version: rust/2.0.736 (shell: "rust")
• Browser build: 156.0.8078.73 (chrome-for-testing)
• OS: Windows (win64)

Reproduction & Root Cause

1. Open https://labs.google/fx/projectgenie/tools/projectgenie/creation in pup (pup_open_window), sign in with a Google AI Ultra account, enter a world prompt + character prompt, and click Create world.
2. Project Genie generates the preview image (createImage), creates a session (bottleCreateSession), and calls bottleConnectSession, which returns Google's ice-lite WebRTC offer (74.125.247.225:19306 / 74.125.247.237:19306 UDP) along with iceServers:
   • stun:74.125.247.128:3478
   • turn:74.125.247.128:3478?transport=udp
   • turn:74.125.247.128:3478?transport=tcp
3. Because Preferences has:

   "webrtc": {
     "allow_legacy_tls_protocols": false,
     "ip_handling_policy": "disable_non_proxied_udp",
     "multiple_routes_enabled": false,
     "nonproxied_udp_enabled": false
   }
   

   Chromium refuses to bind any local UDP sockets for RTCPeerConnection. Running a candidate check inside pup_eval:

   const pc = new RTCPeerConnection({iceServers: [{urls: "stun:74.125.247.128:3478"}]});
   pc.createDataChannel("test");
   

   emits only a bogus TCP active candidate (candidate:... 1 tcp ... 0.0.0.0 9 typ host tcptype active) and zero host or srflx UDP candidates.
4. With TURN configured, pup only gathers the turn:74.125.247.128:3478?transport=tcp relay candidate (which allocates an internal 10.x.x.x address). Google's media server (74.125.247.225:19306 UDP) never responds to STUN connectivity checks from that TCP relay candidate (requestsSent: 8, responsesReceived: 0, state: "failed"), RTCPeerConnection.connectionState transitions to "failed", bottleStartBottleSession never fires, and the Project Genie UI hangs on "Creating your world…" indefinitely until the 60-second backend session timeout expires.
5. Control test: Opening the exact same session in a browser profile where Preferences does not set webrtc.ip_handling_policy = "disable_non_proxied_udp" immediately gathers a srflx UDP candidate via stun:74.125.247.128:3478, connects in <500 ms (connectionState: "connected", iceConnectionState: "connected"), calls bottleStartBottleSession, and streams the live 1280×704 interactive 3D world over WebRTC.

Suggested Fix

1. Remove "webrtc": {"ip_handling_policy": "disable_non_proxied_udp", "multiple_routes_enabled": false, "nonproxied_udp_enabled": false} (and --force-webrtc-ip-handling-policy=disable_non_proxied_udp if passed on launch) from pup's profile Preferences writer — or reset existing Preferences to "ip_handling_policy": "default" ("multiple_routes_enabled": true, "nonproxied_udp_enabled": true) on startup.
2. Since #91 already proved that the Windows Firewall prompt on a fresh browser binary is triggered by Chromium's network-service UDP sockets on Cloudflare challenges (with zero WebRTC PeerConnections) and is solved by the elevated firewall rule helper in adom-bridge, keeping disable_non_proxied_udp in Preferences provides no firewall benefit while breaking WebRTC UDP media/streaming applications in pup.