[web] UI fails to load over plain HTTP on a non-loopback host — mintRpcId() calls crypto.randomUUID(), which is undefined in insecure contexts

[zhao-gd]

Summary

When the DSH web UI is served over plain HTTP on a non-loopback host (e.g. http://<LAN-IP>:3080 or http://<tailscale-IP>:3080), the browser treats the origin as a non-secure context (window.isSecureContext === false). In that environment crypto.randomUUID is undefined.

dsh-client-connection's AbstractApiClient.mintRpcId() calls crypto.randomUUID() directly, so minting the very first RPC id (host.describe) throws TypeError: crypto.randomUUID is not a function. That throw is swallowed by the connection loop's catch, which aborts the current generation — closing both events.mux and events.host WebSockets while they are still CONNECTING.

Result: the browser logs WebSocket connection to 'ws://…/api/events.mux' failed: WebSocket is closed before the connection is established., the host.describe request is never actually sent, and the whole UI (sidebar etc.) stays blank, stuck in an infinite reconnect loop.

The same UI works perfectly when the same server is reached over HTTPS or over loopback (http://127.0.0.1:3080), because those are secure contexts where crypto.randomUUID exists.

Environment

• dsh 0.1.0-rc.6 (all @deepseek-ai/dsh-* packages at 0.1.0-rc.6)
• Reproduced in Chrome (headless, DevTools Protocol) — any browser behaves the same
• Access path: browser → http://100.68.55.117:3080 (Tailscale IP of the host, plain HTTP) → tailscale serve --tcp 3080 3080 → 127.0.0.1:3080
• Confirmed via CDP: window.isSecureContext === false, typeof crypto.randomUUID === "undefined", typeof crypto.getRandomValues === "function"

Steps to reproduce

1. Boot dsh --profile <web-profile> --port 3080 bound to loopback (the only supported --host today).
2. Expose it over plain HTTP on a non-loopback address — e.g. a TCP reverse proxy (tailscale serve --tcp 3080 3080) or a plain-HTTP reverse proxy — so the browser origin is http://<non-loopback-host>:3080.
3. Open http://<non-loopback-host>:3080 in a browser.

Observed: the sidebar is completely blank; DevTools shows the events.mux / events.host WebSockets failing with "closed before the connection is established", and [web-runtime] connection lost, retry #N repeats forever. The POST /api/host.describe request is never issued.

Expected vs actual

• Expected: the UI loads over any reachable HTTP host (the harness already has a --trusted-host mechanism for exactly this), minting RPC ids through the browser-safe randomUuid() helper.
• Actual: mintRpcId() uses crypto.randomUUID() (secure-context-only), so the first RPC id mint throws, the handshake aborts, and the UI never loads on non-secure contexts.

Root cause (from reading the source)

In @deepseek-ai/dsh-client-connection (lib/client.js):

mintRpcId() {
    return RpcId(crypto.randomUUID());   // throws on non-secure contexts
}

The same package already ships a browser-safe helper a few lines away:

// lib/types/client/random-uuid.js
/** Browser-safe UUID generation for client-side wire correlation. */
/**
 * Generate an RFC 4122 version 4 UUID without requiring a secure context.
 * @returns a UUID backed by crypto.getRandomValues(), which browsers expose on insecure origins.
 */
function randomUuid() {
    const bytes = globalThis.crypto.getRandomValues(new Uint8Array(16));
    // ... sets v4 variant/version bits, hex-encodes, formats with dashes
}

…but mintRpcId() doesn't use it. The host.describe() unary call (callUnary) reaches mintRpcId() before it issues the HTTP request, so the failure happens before any /api traffic is sent — which is why the symptom is "WebSocket closed before established" (the abort closes the WebSockets) rather than an HTTP error.

There is at least one more direct crypto.randomUUID() usage in the same bundle (MessageId(crypto.randomUUID()) for session messages), which hits the same wall on non-secure contexts.

Suggestion

1. Make mintRpcId() (and any other client-side id minting) use randomUuid() instead of crypto.randomUUID(), since randomUuid() already exists and is documented as the insecure-origin-safe path; and/or
2. Add a randomUuid()-backed polyfill for crypto.randomUUID on the client, so no call site can accidentally depend on the secure-context-only API.

This is the same class of "works over loopback/HTTPS, breaks over plain HTTP on a non-loopback host" issue that's easy to miss in dev (where 127.0.0.1 is always a secure context).

[mattheliu]

I reproduced this behavior. Replacing the direct crypto.randomUUID() usage with the existing crypto.getRandomValues()-based helper fixes the initial RPC failure and reconnect loop.

However, this does not make the complete Settings UI available over a non-loopback HTTP origin. In my test, the next failures were:

1. HTTP 403 from the Host/Origin trust fence.
2. settings are unavailable in this browser because the frontend selected remote/memory settings mode from location.hostname.

A reverse proxy can technically normalize the upstream Host/Origin and make the client behave as loopback, and I verified that llm.providers, settings.describe, and settings.mutate then work. But that bypasses the intentional loopback-only security boundary for sensitive settings APIs.

Therefore the safe workaround remains HTTPS plus authentication, or an SSH/platform port forward that preserves a localhost browser origin. The UUID fallback should still be fixed upstream independently. I posted the more detailed reproduction and security notes in #3302.

[aicoding-2026]

Confirmed still broken on 0.1.1-rc.2 (master b150a551). Upstream ede278d0c7 fixed only the generic connection channel, but three more client-reachable call sites still mint with bare crypto.randomUUID():

• AbstractApiClient.mintRpcId (host-apiproxy, inlined into the connection client bundle) — the one that kills the very first host.describe RPC you traced;
• browserDraftAttachment (ui-conversation) — draft attachment ids;
• createMessage (llm) — also runs in the browser in fixture/demo mode.

I've pushed a complete, cherry-pick-ready fix to a fork branch: https://github.com/1005281342/deepseek-harness/tree/fix/randomuuid-secure-context (two commits; generalizes the connection-local helper from ede278d0c7 into a shared zero-dependency @deepseek-ai/dsh-random-uuid package, routes all three sites through it, and adds per-site regression tests that stub crypto down to getRandomValues only). 72 tests green, tsc -b clean on both faces, oxlint clean — and verified live on a plain-HTTP LAN deployment via an equivalent runtime patch of the same call sites.

See also #4376 (same analysis against rc.2, in Chinese) and the older reports #2396 / #3635 / #1919 / #942.