Security

Read this before you expose a harness to your network. The canonical document is docs/SECURITY.md; this page is the same trust model stated for someone about to tap Scan network.

The harness has no authentication

dsh web serves plain HTTP with a trust fence, not authentication:

• Every /api request is accepted only when its Host header is loopback or a configured trusted authority. When the server binds 0.0.0.0, it auto-derives and trusts its own LAN IP literals.
• There are no tokens, no cookies, no TLS, no pairing.

What follows from that:

Any device on the same network can send requests with a trusted Host and drive the agent — including running commands on the host computer.

The trust fence stops a browser on another site from driving your harness. It does not stop a device on your LAN. Treat "the harness is on the network" as equivalent to "everyone on this network can run commands on my computer".

Practically:

• Only bind 0.0.0.0 on networks you fully trust — your home network, your own lab. Never on public, guest, hotel, or conference Wi-Fi.
• If you only want to use the app, prefer adb reverse over USB: the harness stays on loopback and nothing is exposed. See Getting Started.
• DSH Mobile shows a warning banner whenever you connect to a non-loopback host, on purpose.

What stays loopback-only

Some surfaces are refused for network clients by harness design, and the app shows them read-only with a banner rather than pretending: settings, credentials, model discovery, host directory pickers and file opening, and agent-preset authoring. See Compatibility.

Note what this does not include: a network client can still send prompts, approve permission requests, and change the permission preset. The fence limits configuration, not agency.

What the app stores

• Remembered host addresses (host, port, display name, last-seen version, working directory) and your app preferences — in app-private storage only.
• No session content is persisted to disk. Transcripts live in memory and are re-fetched from the harness on connect.
• Clear the stored addresses with Settings → Data → Forget remembered harnesses.

The app permits cleartext HTTP because the harness serves plain HTTP. That is a necessity of the protocol, not a preference.

What the app connects to

Every connection is to a LAN endpoint you entered or picked from a scan, with one exception:

• The update check. On start the app asks api.github.com for this repository's latest release, over HTTPS, so it can tell you when a newer APK exists. It sends nothing identifying beyond what any HTTPS request carries, and it is the only request that leaves your network. Turn it off at Settings → About → Check for updates.
• Scanning probes only your own device's IPv4 /24, and only with a TCP connect followed by the harness's own host.describe.

There is no analytics, no crash reporting, and no telemetry of any kind.

Reporting a vulnerability

Report security issues privately — either Report a vulnerability on the repository's Security tab, which keeps the report and the discussion private on GitHub, or email sor@zyphite.com. Please do not open a public issue for a vulnerability.

Include what an attacker can do, the steps to reproduce it, the app and harness versions, and how the app was connected. The harness having no authentication is the documented model described above, so that on its own does not need reporting — a way around the trust fence does.

What would actually fix this

The gaps are upstream, in the harness, and are tracked as issues on this repository:

1. An authentication layer (pairing token) on the web server.
2. An explicit --lan flag — the CLI currently blocks --host 0.0.0.0, which is why LAN mode needs a patch at all.
3. mDNS advertisement, for zero-touch authenticated discovery instead of a subnet sweep.