Web GUI unusable from non-loopback HTTP origins: crypto.randomUUID requires a secure context (breaks LAN access over 0.0.0.0 bind)

[SakuraToErii]

Summary

The web GUI loads but shows no conversations — and throws TypeError: crypto.randomUUID is not a function in the console — when accessed from another device over plain HTTP at a non-loopback address (e.g. http://192.168.x.x:3080 or a VPN virtual IP), even though the same server works perfectly at http://127.0.0.1:3080.

Environment

• @deepseek-ai/dsh 0.1.0-rc.6 (npm global install), macOS
• Profile: web (@deepseek-ai/dsh-web-app bundle)
• Bind host set to 0.0.0.0 via ~/.dsh/profiles/web/cordis.patch.yml:

- id: webserver
  config:
    host: 0.0.0.0

Root cause

The client bundles call crypto.randomUUID() without a fallback in three places:

• dsh-client-connection/lib/client.js — mintRpcId() (return RpcId(crypto.randomUUID())) — every RPC call (session.list, workspace, model picker, …) goes through this
• dsh-client-connection/lib/client.js — createMessage() (id: MessageId(crypto.randomUUID()))
• dsh-client-ui-conversation/lib/client.js — browserDraftAttachment() (id: crypto.randomUUID())

crypto.randomUUID() is only exposed in secure contexts (HTTPS, or loopback origins like http://127.0.0.1). A plain-HTTP LAN address (http://<lan-ip>:3080) is not a secure context, so the first RPC throws TypeError: crypto.randomUUID is not a function and the session list never renders.

The server side is fine: the browser-trust fence deliberately supports LAN IP literals (auto-derived from the bind when host: 0.0.0.0, see resolveLanTrust in dsh-web-app), and curl against /api/session.list with Host: <lan-ip>:3080 returns ok: true with the same sessions as loopback. So LAN access is half-baked: the transport is open, but the frontend cannot run outside a secure context.

Steps to reproduce

1. Start dsh web bound to all interfaces via the cordis.patch.yml override above. (Note: the CLI flag --host 0.0.0.0 is intentionally rejected for safety, but the config-patch path is not.)
2. From another device on the same network (or a VPN like EasyTier/Tailscale), open http://<lan-ip>:3080.
3. Observe: the page loads, the sidebar shows no conversations; the console shows TypeError: crypto.randomUUID is not a function.
4. The same URL from http://127.0.0.1:3080 works perfectly.

Suggested fix

The bundle already contains a secure-context-free UUID helper — randomUuid() in dsh-client-connection/lib/client.js, implemented with crypto.getRandomValues() (which is exposed on insecure origins). Options:

• Replace the three bare crypto.randomUUID() calls with randomUuid() (wire correlation and message ids do not need the RFC-4122 name guarantee), or
• Polyfill crypto.randomUUID at the client entry when missing.

Workaround (verified locally)

We patched the installed bundle (backed up): mintRpcId() and createMessage() now use randomUuid(), and the conversation bundle's draft-attachment id uses an inline getRandomValues UUID. After restarting dsh web, a phone at http://10.144.144.71:3080 (EasyTier virtual IP) shows the exact same session list as localhost. The patch survives until the next dsh upgrade.

Also worth considering: the flag path rejects --host 0.0.0.0 for safety while the config path allows it — either align the two (document/reject LAN binds) or make the frontend work over non-secure origins.

[mattheliu]

Confirmed in another Linux/npm installation.

A crypto.getRandomValues() UUID fallback fixes the first crypto.randomUUID is not a function failure, but there are additional remote-browser restrictions afterward:

• API requests may return 403 because of the Host/Origin trust fence.
• The Settings UI selects remote/memory mode from location.hostname.
• Settings and credential operations are intentionally loopback-only in the current implementation.

I verified a local compatibility proxy that handled the UUID fallback, HTTP/WebSocket forwarding, and loopback Host/Origin normalization. It made the UI work on a restricted private network, but this approach bypasses the loopback security boundary and must not be exposed publicly.

I posted the detailed reproduction and security notes in #3302.