Security and privacy are built into Corvus Connection, not added after the fact. We collect as little of your data as a feature needs, encrypt what we hold, and design each layer so a single failure does not expose the rest. This page describes what is in place today, the standards we work toward, and how to reach us if you find a problem.
Our commitment
Least data: we ask for only the account scopes and information a feature requires, and we do not sell your data.
Encrypted by default: traffic is protected in transit, and secrets and tokens are protected at rest.
Defense in depth: authentication, secret storage, and network exposure are handled as separate layers, so a weakness in one does not open the others.
Local first: when you run the standalone desktop app, your stream data and your connected-account credentials stay on your own machine.
Protecting your personal data
Data minimization: each integration requests the narrowest set of permissions that lets it work. We do not gather personal data that a feature has no use for.
Consent up front: the desktop app asks you to accept its terms before first use, and the consent record it keeps holds no personal information.
Scrubbed logs: a redaction policy strips tokens, keys, and sensitive fields from log messages and traces before they are written or exported, so diagnostics never carry your secrets.
Your data stays yours: in standalone mode, viewer and event data lives in local storage on your device rather than on our servers.
Encryption
In transit: every call to our services and to the platforms you connect (Twitch, Spotify, and the rest) travels over HTTPS with TLS.
At rest in the cloud: secrets are held in Azure Key Vault, and the keys that protect sign-in cookies and stored data are backed by a Key Vault key ring rather than a value baked into the app.
At rest on your device: account tokens and other credentials are sealed with Windows Data Protection (DPAPI) in an encrypted local store, and integration data that includes secrets is kept in an encrypted database file.
Not exposed to your network: the local overlay server and the integration gateway bind to loopback (127.0.0.1) only, so they are reachable from your own machine and not from the wider network.
Credentials and secrets
Never in source or config: secrets do not live in the code or in settings files. Development uses per-developer user-secrets, and production reads from Azure Key Vault.
Brokered sign-in: platform logins run through a token broker, so long-lived client secrets stay on the server and never reach your machine.
Short-lived tokens: access tokens are refreshed automatically. A token that lapses is re-issued rather than left active.
Secret scanning: our build pipeline scans every change for leaked keys and credentials and fails if it finds any.
Authentication and access
Standard protocols: sign-in uses OpenID Connect and signed JWT bearer tokens. We do not roll our own login.
Scoped desktop bootstrap: the desktop app connects with a limited API key, not your account password.
Least privilege: each connection is granted only the permissions its feature needs, and licensing checks are verified against a signed key so they cannot be forged offline.
Standards we work toward
Corvus Connection does not currently hold any security or compliance certification. The standards below are the practices we align our work to and aim to meet or exceed. They are goals and guardrails, not a claim of audited or certified conformance.
OWASP Top 10: the web and API surface is reviewed against the common web application risks it catalogs.
GDPR and CCPA principles: data minimization, using data only for the purpose it was given, and honoring requests to access or delete personal data.
SOC 2 and HIPAA safeguards: we model how we handle sensitive data on the controls these frameworks describe. These describe how we work; they are not a claim of formal certification.
WCAG 2.2 AA: accessibility is part of how we judge quality. See the accessibility page for the detail.
Supply chain and build integrity
Pinned dependencies: package versions are centrally managed and locked, and builds run in a locked mode that fails if a dependency changes unexpectedly.
Dependency auditing: the build flags packages with known vulnerabilities so they are caught before a release.
Signed releases: desktop builds are code-signed, and updates are verified before they install.
Third-party and user-shared content
Corvus Connection lets you write and run scripts and build node graphs, and it lets you import and share them with other people. We work to keep our own code free of malicious behavior, but that assurance does not extend to content that other people write.
Not verified by us: scripts, node graphs, and overlays that come from third parties or from other users are not reviewed, verified, or endorsed by The Omen Den L.L.C.
They run with the access you grant: imported scripts and graphs run on your machine with the permissions you give them. Treat them the way you would any code from the internet: read it before you run it, and import only from sources you trust.
Provided "as-is": third-party and user-shared content is supplied without warranty of any kind. The Omen Den L.L.C. is not responsible for what such content does, and you use it at your own risk.
Report a vulnerability
Found a security issue? Email support@theomenden.com with a description and the steps to reproduce it. We aim to acknowledge reports quickly, keep you updated on the fix, and credit you if you would like. Please give us a reasonable window to release a fix before sharing the details publicly.
What we're improving next
A formal third-party assessment against the frameworks above, so alignment becomes verified conformance.
Wider encrypted-at-rest coverage and automated rotation of the keys that protect it.
A published security.txt and a signed disclosure policy, so reporters have a clear, verifiable point of contact.
