crypto.randomUUID on the browser RPC path breaks the web UI on insecure origins

[sorsama]

What happens. A browser served the web app over plain HTTP from any non-loopback address never gets a live page. Sign-in and every other unary call succeed; sessions, workspaces, and the model picker never arrive, and the console repeats [web-runtime] connection lost, retry #N forever. The same page works at https:// or on 127.0.0.1.

Cause. crypto.randomUUID is [SecureContext] in WebCrypto: browsers expose it over HTTPS and on localhost, nowhere else. AbstractApiClient.mintRpcId calls it on the hot path of every unary RPC — packages/host/apiproxy/src/fetch/client.ts:298:

protected mintRpcId(): RpcId {
  // crypto.randomUUID is a Web API (browser + Node ≥19): keeps this base platform-neutral.
  return RpcId(crypto.randomUUID())
}

The comment is right that it is a Web API and wrong that being one makes it available. On an insecure origin it is undefined and the call throws.

The failure lands in ConnectionController.loop's readiness handshake (packages/client/connection/src/client/connection.ts): this.api.host.describe({}) throws, the catch aborts the generation, and both events.mux and events.host — which hold that generation's abort signal — are closed while still CONNECTING. The supervisor backs off and retries indefinitely. Unary RPCs appear to work because a thrown mint is indistinguishable from a transport failure at the call site, which is what makes this look like proxy or WebSocket damage rather than the page closing its own sockets.

Already half-fixed. ede278d0c7 ("fix(connection): mint RPC ids on insecure origins") added packages/client/connection/src/client/random-uuid.ts for exactly this, with a doc comment naming insecure origins. In the shipped bundle it is reachable only from client/fixture.ts and client/rpc.ts; the carrier every real unary call goes through was not changed. Two further browser call sites still use the secure-context API directly:

• packages/client/ui-conversation/src/client/service.ts:66 — crypto.randomUUID() as DraftAttachmentId
• createMessage — MessageId(crypto.randomUUID())

Repro. Serve the web app from a LAN address over plain HTTP and open it in any browser. Confirmed against 0.1.1-rc.2 source and the published 0.1.0-rc.7 and 0.1.1-rc.1 bundles. Verified in headless Chrome on such an origin that isSecureContext is false and crypto.randomUUID is undefined, while crypto.getRandomValues is present.

Suggested fix. Reuse the helper that already exists — crypto.getRandomValues carries no secure-context requirement, so it works everywhere randomUUID does and in the places it does not. apiproxy sits below client/connection in the dependency graph, so it needs its own copy or a shared one.

---

Related, same root shape. ConnectionHandle.isLoopback is derived from the address bar — pageLocation === undefined || isLoopbackHostname(pageLocation.hostname) in packages/client/connection/src/client/index.ts:132. An authenticated reverse proxy in front of the harness can carry the configuration plane safely, but has no way to say so: the client creates the settings mirror with memory persistence and never sends the calls, and ui-deliverables disables canOpenPath on the same signal. A host-supplied hint — a webserver/index-inject global row, or a field on host.describe — would let the process that actually knows answer the question, rather than inferring it from a hostname the host never sees.

Context: both of these surfaced while building dsh-relay, an authenticated remote-access plugin that fronts an untouched loopback harness.

[denial123789]

I source-checked the reported chain against rc.2 commit b150a551b8d465e31e418e1b2eaf5e79bbb7d28e. One useful operational distinction is that the repeated connection lost warning is a convergence symptom, not proof of a WebSocket failure.

A high-confidence attribution to the typed UUID path needs all four observations:

1. window.isSecureContext === false;
2. typeof crypto.randomUUID === "undefined" while typeof crypto.getRandomValues === "function";
3. no matching typed host.describe request appears in DevTools Network;
4. the same build reaches connected state through HTTPS or a real loopback browser origin.

That combination matches the source order: both event pumps start, typed host.describe({}) throws during RPC-ID minting before fetch, the readiness catch aborts the shared generation, and the supervisor backs off and retries. If host.describe does reach the server, the incident should instead be routed through transport, Host/Origin trust, or server lifecycle evidence.

The safest bounded recovery remains loopback (including SSH local forwarding) or an authenticated HTTPS gateway; adding a UUID fallback would repair compatibility but would not make direct remote exposure authenticated.

I added the source-linked flow and decision gate to this independent community runbook: https://sandbaseai.github.io/deepseek-harness-handbook/remote-web-secure-context.html

[Jstn-1g]

Status update (2026-08-27): official dsh-v0.1.2-alpha.1 now contains a complete independent implementation in 0bee546, including a shared zero-dependency crypto utility plus the RPC, message, and draft-attachment call sites. That official work predates this Aug 27 reference, so this should be treated as independent convergence—not adoption or contributor credit for this branch. The reference below remains a reproducible rc.2 record only.
Verified reference implementation for the reported browser-RPC failure (not an upstream merge).

Source baseline: b150a55
Reference branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4756-randomuuid-fallback
Exact commit: Jstn-1g@c66bf95

Reproduction

• With an insecure browser origin where crypto.randomUUID is absent but crypto.getRandomValues is present, the typed host.describe call throws while minting its RPC id, before fetch is invoked.
• This matches the reported readiness abort/retry loop and distinguishes it from a request that reached the transport.

Implementation

• Centralizes the existing browser-safe UUID helper in the shared fetch-carrier client.
• Sources all 16 bytes from crypto.getRandomValues, sets UUID-v4 and RFC variant bits, and retains 122 CSPRNG-derived bits.
• Routes AbstractApiClient.mintRpcId through that helper and re-exports it from client-connection so there is one implementation.
• There is no Math.random or deterministic fallback. If getRandomValues is unavailable, the call fails closed before transport.

Verification

• Focused UUID cases: 2/2
• Complete fetch-carrier suite: 37/37
• Full GUI suite: 3,995 passed, 4 skipped
• Host and connection type-checks, full build, scoped and full lint, duplication scan, bilingual doc pairing, diff/precommit checks, and the full pre-push gate all passed.
• A bounded security diff review covered randomness, UUID semantics, failure behavior, and dependency direction: four reviewed surfaces, zero findings.

Scope

• This fixes the fetch-carrier RPC hot path that causes the reported startup failure.
• Two other pre-existing direct crypto.randomUUID call sites (draft attachment identity and llm/createMessage identity) remain separate follow-up work; a comprehensive shared fix belongs in a lower-level runtime utility with their owning tests.
• This compatibility fix does not make plain HTTP authenticated or encrypted. Loopback forwarding or HTTPS remains the safe deployment posture.

[0x4007]

Comprehensive rc.2 follow-up, extending the narrower RPC-only reference above.

Baseline: b150a551b8 (dsh-v0.1.1-rc.2)

Complete apply-ready patch: https://gist.github.com/0x4007/1529e9fb2535a772c5981ec859c004e8

Additional scope covered

• Moves the existing getRandomValues() UUID-v4 implementation to the shared fetch-carrier client and routes the real AbstractApiClient.mintRpcId() hot path through it.
• Routes the browser connection RPC/fixture through that shared implementation.
• Replaces the remaining direct crypto.randomUUID() calls in createMessage() and browser draft-attachment identity, with owning-package regression tests.
• Uses all 16 CSPRNG bytes, sets RFC 4122 v4/version and variant bits, provides no Math.random() fallback, and therefore fails closed if Web Crypto randomness itself is unavailable.
• Adds a shipped-Web-UI Chromium regression using a non-loopback plain-HTTP authority mapped to the local test server. It asserts:
  • window.isSecureContext === false
  • typeof crypto.randomUUID === "undefined"
  • typeof crypto.getRandomValues === "function"
  • workspace selection succeeds through the real in-app picker
  • a prompt can be sent and the replay response LIGHTHOUSE appears
  • no page errors or console warnings occur

Verification

• Full build and repository type checks passed.
• Full lint, documentation synchronization, and duplication checks passed.
• 67 focused carrier/message/conversation tests passed.
• Replay validation and the new plain-HTTP Chromium E2E passed.
• A live patched UI selected /home/codex, sent Respond with only NETWORK_UI_OK., and received NETWORK_UI_OK from the configured provider.

This patch changes browser compatibility only. It does not enable 0.0.0.0, weaken trusted-authority checks, expose loopback-only privileged APIs, or claim that plain HTTP is authenticated. The deployed validation keeps DSH on 127.0.0.1 behind a private tailnet HTTPS proxy.

[argszero]

Source-checked the full gist patch against rc.2 (b150a551b8) — coverage is complete, plus one consolidation suggestion.

Coverage verification. The patch hits exactly the browser-runnable call sites and nothing else:

• packages/host/apiproxy/src/fetch/client.ts mintRpcId (~:300, the reported hot path)
• packages/client/ui-conversation/src/client/service.ts browserDraftAttachment (crypto.randomUUID() as DraftAttachmentId) — the second browser-side user, correctly included
• packages/llm/llm/src/message.ts createMessage — defensively covered

Every remaining crypto.randomUUID in the tree is host-only (node:crypto imports, or server-side runtime — e.g. interaction/commands CommandRuntime.instanceToken is a host registry, never bundled to the browser), so nothing browser-runnable is missed. The stubbed-crypto unit tests and the plain-http-network e2e also match the repo's test conventions. Functionally this is ready to upstream.

One consolidation suggestion. The patch introduces the same randomUuid() implementation three times — exported from apiproxy/client, plus local copies in ui-conversation and llm — each wrapped in /* jscpd:ignore-start */. That suppression is novel for this repo: today there are zero jscpd:ignore comments in packages/, and pnpm run duplication (jscpd --config .jscpd.json packages scripts) is a standing gate that the three copies would trip without the workaround.

A simpler home consistent with the repo layout is a tiny shared package under packages/util/ (the designated zero-dependency utility layer, e.g. @deepseek-ai/dsh-random-uuid). Layering stays clean — llm already depends on dsh-brand/dsh-invariants/dsh-timeout, ui-conversation already imports values from many dsh-* packages in its client bundle, and client/connection already imports from apiproxy — so all three consumers take a one-line import and the jscpd suppression disappears entirely. The "client bundles may not import one another's values" caveat applies to importing from apiproxy specifically; a dedicated util package sidesteps it.

Great work on the e2e scenario — the --host-resolver-rules + isSecureContext tripwire is a nice way to reproduce the insecure-origin shape locally.

[argszero]

Terminal status: this is fixed natively in 0.1.2-alpha.1, and the consolidation suggestion from the thread was realized as the repo's new packages/util/crypto module.

Verified against the current tree:

• @deepseek-ai/dsh-util-crypto exports randomUUID() minted from crypto.getRandomValues() (unrestricted everywhere), with a no-restricted-properties lint rule pointing crypto.randomUUID callers at it.
• The two browser-runnable call sites flagged in my coverage pass now import it: packages/client/ui-conversation/src/client/service.ts (draft attachment ids) and packages/llm/llm/src/message.ts (message ids).
• Zero crypto.randomUUID remains in packages/client — the browser bundle path is clean.

So the single-util-package home that the gist's three duplicated randomUuid() copies pointed at is now the official pattern (and the jscpd:ignore workaround is unnecessary). Thanks to everyone who contributed patch iterations — the insecure-origin e2e shape (host-resolver-rules + isSecureContext tripwire) is the right regression test to keep.