OpenBurnBar
GitHub Download
Security

A defensive product, not a hardened castle.

OpenBurnBar is a developer tool that runs as your user. That posture shapes every security choice we make. Here's what we defend against, what we don't pretend to, and how to reach us if you find something.

Threats & mitigations

The top five we actively defend.

  1. 01

    Local user impersonation of the daemon RPC

    The daemon socket is a UNIX socket under your home directory with filesystem ACLs set to 0o600. Every RPC requires an auth token; the token is passed via launchd EnvironmentVariables, not CLI args — keeping it out of ps aux. The plist itself is 0o600.

  2. 02

    Secrets at rest

    Provider API keys go in the macOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly. The SQLCipher database key is held the same way. Equivalent risk to any unsandboxed app running as your user.

  3. 03

    Unauthorized cloud access

    Firestore is gated by Firebase Auth, owner-scoped rules per users/{uid}/…, a secret-field-name denylist (apiKey, token, cookie, credential, …), and Firebase App Check attestation. provider_account_secret_refs is server-only — all client reads denied.

  4. 04

    Replayed or forged App Store entitlements

    Every JWS receipt is verified server-side against a vendored set of Apple root CAs, pinned by SHA-256. The appAccountToken is a UUID bound to your Firebase UID. Entitlement state is re-reconciled against getAllSubscriptionStatuses.

  5. 05

    Cross-device credential exposure

    Cross-device credential transfer uses ECIES (P-256 + AES-GCM) escrow. Private keys never leave the device Keychain. Firestore only ever sees ciphertext and non-sensitive metadata.

What we don't pretend

Known limits, on the page.

  • The macOS app is not sandboxed. Like most developer tools, it runs as your user. The security boundary is Developer ID signing + notarization + Gatekeeper, plus a defensive daemon and Keychain-scoped secrets.
  • Provider APIs are not certificate-pinned. System trust store applies. If you need vendor-side pinning, this is on the candidate list.
  • The optional Cursor connector tunnel routes BYOK traffic through Cloudflare when you turn it on. This is the only way today to land Cursor BYOK on a localhost endpoint.
  • iCloud uses your Apple ID, not our infrastructure. Conflict copies can happen; that is iCloud's behavior.
  • App Check enforcement is checked at launch-time and operationally, not at every request from a runtime probe. The commercial-launch gate enforces it before publishing.
  • Sentry diagnostics (opt-in) anonymizes the user ID via a hash seeded from the bundle ID and full user name. Not direct PII, but worth knowing.
Releases

Provenance you can verify.

  • Signed and notarized with a Developer ID, stapled. spctl verifies on Gatekeeper-enabled Macs.
  • SHA-256 and SHA-512 checksums are published next to each release artifact.
  • Optional GPG-signed checksum file for stronger chain of trust.
  • SPDX SBOM per release.
  • Release-metadata JSON with build commit, build date, and verified artifact hashes.
Reporting

If you find something, tell us.

Email privacy@imagine-that.ai with a description of the issue. Please don't open public GitHub issues for active vulnerabilities — give us a chance to fix them first.

See the full SECURITY.md for the canonical disclosure policy.