Report vulnerabilities through GitHub's private advisory form. Please do not open a public issue for anything exploitable.

The acoustic modes need the microphone, and that is the whole of modem's access to anything sensitive. What it does with it:

• Audio never leaves your device. It is demodulated in the page, by WebAssembly, on your own machine. There is no upload, no transcription service, no server-side processing. The site's Content-Security-Policy allows outbound connections to Google Analytics and nowhere else, and analytics receives page views, never audio.
• The stream is released when you leave. Pressing Back or Stop stops every track. This was not always true: until 17 September 2026 a stream that arrived after you had left was left running, and the window was however long you took to answer the permission prompt. It is fixed and there is a test that fails if it regresses (the microphone is released even if permission arrives after Back).
• Processing is asked to be off, and reported when it is not. modem requests raw audio with echo cancellation, noise suppression and automatic gain control disabled, then reads back what the platform actually applied and says so on screen. That is a fidelity measure, not a privacy one, but it means the page tells you what your browser is really doing.
• The one-device demo never opens the microphone at all. It cross-wires two endpoints in software. Only /originate and /receive ask.

The native binary opens the default input device through cpal when run with --acoustic, and does nothing with the samples except demodulate them.

Two things, both about analytics, and the modem behaves identically whichever way they go.

• Google Analytics sets its own cookies (_ga, _ga_*) by default. Since 30 September 2026 the site counts visits unless you opt out, under the UK statistical-purposes exception for analytics: statistics only, no advertising signals, Google Signals off. A notice says so on your first visit, with "Opt out" beside "OK" at the same size, and "Cookie settings" in the footer brings it back. How it works for every DBHQ site is at dbhq.uk/privacy.
• Your answer is a cookie, dbhq_analytics=on or off, on .dbhq.uk. Opting out is a real opt-out: the _ga cookies are deleted, nothing more is sent from that page, and no later page loads the analytics script at all. Because the cookie is on the parent domain, opting out here opts you out on every *.dbhq.uk site.

/lab and its /lab/api/* endpoints are an operator tool for calibrating two real devices against each other. Writes require a key. The key is a bearer token rather than identity - anyone holding it can write - and what it protects is a free-tier Cloudflare KV quota, not anything confidential.

• No stored report is ever served back by the worker. The operator reads them from KV directly.
• Every key written expires after seven days.
• Requests are capped at 64 KB.
• /lab/api/plan is readable without a key. It returns the instruction the devices are already carrying out, which is not a secret.

If the key is missing from KV the write endpoints return 503 rather than accepting anything. That is deliberate: an unconfigured lab is closed, not open.

Every GitHub Action is pinned to a commit SHA, and Dependabot keeps those pins moving - a pin with no updater is a pin that rots. Release binaries are built from the commit the tag points at, and the release notes record that SHA.

The page loads no third-party JavaScript except Google Analytics, and not that once you opt out.