Security & Responsible Disclosure

Email security@dfacto.ai with details and reproduction steps. We aim to acknowledge within 2 business days and will keep you updated until it is resolved.

The Audiowire application, the background service and its local API, the platform drivers, the command-line client, the licence issuer, and this website.

We will not pursue action against researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate before public disclosure.

Not the samples in flight. The asset is the configuration that decides what gets recorded and where it goes. An attacker who can add an application source and point a monitor somewhere they can read has built a wiretap using our product, with our driver, with no prompt shown to you. That is the attack the design exists to stop.

Secondary, in order: the routing graph, which is a durable list of the applications you record; the running-application list, which is a live inventory of what you have open; and the device table, because a device named “MacBook Pro Microphone” is a phishing primitive.

The service’s local socket admits only the service’s own user. The macOS driver’s control property admits only a process satisfying Audiowire’s code-signing requirement — before that was tightened, a sandboxed App Store app with no entitlements could rewrite the whole device table. The Windows driver’s device admits only SYSTEM, which in practice means one small helper that re-authorises every caller per user.

A process running as a different unprivileged user is excluded from all three. So is a sandboxed or low-integrity process. Full reasoning: docs/privilege-model.md.

A malicious process running as you— a bad npm postinstall, a browser-extension helper, a downloaded game — is not an attacker we can defeat, and we do not claim to. It can already read and rewrite your routing graph directly, replace our binaries if they are user-writable, and attach a debugger to the service. On Linux it can capture any application’s audio with no help from us at all.

Which is why there is deliberately no authentication token on the local socket. A secret readable by the user protects against a process running as the user only until that process reads the secret. Adding one would be ceremony that reads as a boundary in a diagram and is not one in memory.

The application has no network code and must never acquire any, so remote attack is not in the threat model — there is nothing listening. Licences verify offline against a public key compiled into the binary; the signing key is held offline. The background service never runs with elevated privilege: elevation happens once, in a separate installer, for the driver only. Audio crosses threads through a single-producer single-consumer ring whose writes are all-or-nothing, so a stall drops a whole block rather than shifting channel alignment.

The full internal review, including the findings that are still open, is public: docs/security-review.md.

Every statement above describes code in a public repository that has never been released. No build is signed or notarised, no installer has run on a user’s machine, and the Windows driver has never been compiled. Treat this page as a description of the design, verifiable by reading the source, and not as a claim about a product in the field — because there is not one.