From 037326ae272e297138c9e25635083990c114840c Mon Sep 17 00:00:00 2001 From: vdmo Date: Thu, 1 Oct 2026 17:46:30 +1000 Subject: [PATCH 1/2] docs(cables-relay): update verification status with real browser-automation findings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The "not tested against real cables.gl" caveat was written before live browser automation against the actual cables.gl editor (real op class confirmed, real DOM field editing verified). Replace it with what was actually proven, and name the real blocker found afterward — Chrome's Local Network Access policy blocking a public-origin page from reaching localhost, not a defect in the relay or in cables. Co-Authored-By: Claude Sonnet 5 --- tools/cables-pchi-relay/README.md | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/tools/cables-pchi-relay/README.md b/tools/cables-pchi-relay/README.md index 239eff8..d9cd030 100644 --- a/tools/cables-pchi-relay/README.md +++ b/tools/cables-pchi-relay/README.md @@ -95,9 +95,28 @@ Tested live, both directions, against a real running Conductor — including an explicit check that the CORS preflight (`OPTIONS` with `Origin`/`Access-Control-Request-*` headers, exactly what a browser sends, not just a plain `curl`) returns the right headers, and that the -actual `POST` does too. **Not tested against real cables.gl** — the -WebSocket-receive shape is confirmed from a real official example, but -the outbound HTTP-request op and the WebSocket message parsing on the -cables side are not independently confirmed the way TiXL's operators -were confirmed against real compiled source. If you wire this up in an -actual patch and something doesn't match, please open an issue. +actual `POST` does too. + +**Tested against real cables.gl via browser automation** (a real +headless Chromium driving the live, currently-maintained +`https://cables.gl/edit/gu7DBo` example patch — not a synthetic +harness): the real op class (`Ops.Net.WebSocket.WebSocket_v2`) was +located and confirmed, its canvas was found inside cables' own +separate-origin `sandbox.cables.gl` iframe, and its URL parameter field +was genuinely read back and edited through cables' real UI, not +assumed. + +A full live round-trip — the public cables.gl site actually exchanging +messages with a relay on `localhost` — was not completed. It's blocked +by a real, current browser security boundary: Chrome's Local Network +Access policy refuses a public-origin page (`sandbox.cables.gl`) a +connection to a loopback address without an interactive permission +grant, which headless automation can't click through. This is not a +bug in the relay or in cables — an interactive user hitting +`https://cables.gl` would see a one-time Chrome permission prompt, and +a standalone or Electron build of cables (not loaded as a remote HTTPS +page) would likely avoid this policy entirely, since that's not the +scenario it targets. + +If you wire this up in an actual patch and something doesn't match, +please open an issue. From 90d98fdd5b0f742f8e1e311eb41208cfa4e02b4d Mon Sep 17 00:00:00 2001 From: vdmo Date: Thu, 1 Oct 2026 18:31:30 +1000 Subject: [PATCH 2/2] docs(cables-relay): confirm the full live round-trip actually works Follow-up to the previous commit on this branch, which documented that a round-trip wasn't completed yet. It now is: driven end to end against the real public cables.gl editor, the live WebSocket_v2 op showed Connected/Valid JSON/Raw Data with this relay's real DENY payload, reproduced twice. Records exactly what unblocked it (Chromium feature flags, not a permission grant) and what's still unconfirmed (whether a real user's interactive permission prompt behaves the same way). Co-Authored-By: Claude Sonnet 5 --- tools/cables-pchi-relay/README.md | 33 ++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/tools/cables-pchi-relay/README.md b/tools/cables-pchi-relay/README.md index d9cd030..3d9a6a5 100644 --- a/tools/cables-pchi-relay/README.md +++ b/tools/cables-pchi-relay/README.md @@ -106,17 +106,28 @@ separate-origin `sandbox.cables.gl` iframe, and its URL parameter field was genuinely read back and edited through cables' real UI, not assumed. -A full live round-trip — the public cables.gl site actually exchanging -messages with a relay on `localhost` — was not completed. It's blocked -by a real, current browser security boundary: Chrome's Local Network -Access policy refuses a public-origin page (`sandbox.cables.gl`) a -connection to a loopback address without an interactive permission -grant, which headless automation can't click through. This is not a -bug in the relay or in cables — an interactive user hitting -`https://cables.gl` would see a one-time Chrome permission prompt, and -a standalone or Electron build of cables (not loaded as a remote HTTPS -page) would likely avoid this policy entirely, since that's not the -scenario it targets. +**The full live round-trip is verified, too.** Pointed at this relay, +the real op's own parameter panel reported `Connected: true`, +`Valid JSON: true`, and a `Raw Data` value carrying this relay's actual +`gate_state: "DENY"` payload from a real Conductor rule firing — +reproduced twice. Getting there meant working through a real browser +security boundary first: a public-origin page (`sandbox.cables.gl`) +reaching a loopback address trips Chrome's Local Network Access checks +(`net::ERR_BLOCKED_BY_LOCAL_NETWORK_ACCESS_CHECKS`). Granting the +corresponding `local-network-access` permission programmatically (the +mechanism Chrome exposes for automated testing, via +`Browser.setPermission`) did *not* clear it; disabling Chromium's +underlying `LocalNetworkAccessChecks`/`LocalNetworkAccessChecksWebSockets` +feature flags at browser launch did. Both are automation-only levers — +nothing a site can trigger for a visitor — and it's not independently +confirmed that a real person clicking through Chrome's actual one-time +interactive prompt lands in the same working state (the permission-grant +experiment above suggests it might not, though that could equally be a +quirk of the CDP-driven grant rather than the real prompt flow). For +production use without browser flags, cables' own +[standalone/Electron build](https://cables.gl/standalone) — a real, +officially distributed download, not loaded as a remote HTTPS page — +is the clean path around this entirely. If you wire this up in an actual patch and something doesn't match, please open an issue.