All processing happens on your device. No telemetry, no analytics, no crash reports leave the device unless you explicitly opt in. Every opt-in is a separate switch and behaves like one.
OpenBurnBar's data flow is a few concentric rings. Zone A is your Mac. Zone B is your Apple ID, on Apple's infrastructure. Zone C is OpenBurnBar's Firebase and Google Cloud, behind sign-in and App Check attestation.
~/Library/Application Support/OpenBurnBar/OpenBurnBar.sqlite kSecAttrAccessibleWhenUnlockedThisDeviceOnly ~/.claude/, ~/.codex/, ~/.factory/ and more
Disabling sync entirely does not affect local data. The full product keeps working.
iCloud.com.openburnbar.app apiKey, token, cookie, credential A plain map of everything BurnBar keeps for you. It's built from the data-domain registry our apps consume, so the page and registry cannot quietly drift apart.
How the license and the seal back this up → the trust page
Sealed on your device. Our servers never see the content or the key.
Assistant chats, CLI agent transcripts, mobile mission prompts/results, saved text snippets, rollback scope/diagnostics, approval rules, agent personas, subscription graph edges, and conversation recall metadata are sealed on-device before Firestore receives them.
Full conversation bodies + the encrypted search index + project memory. Sealed on-device; the server holds only ciphertext, aggregate cockpit facets, and opaque search/integrity hashes.
The keyword search index is deterministic — repeated and co-occurring search terms produce stable keyed digests, so the server can learn which terms recur and appear together across your logs (the search structure), and the integrity hashes can confirm a guessed body or chunk; every title, snippet, body, and path stays sealed and unreadable.
Your private semantic memory: repo docs, notes, and chat-derived memories your agents recall. Text is sealed on-device; hosted ANN recall is an explicit opt-in over cloaked vectors and opaque keyed hashes. Approved chat memories replicate only as sealed fact envelopes plus opaque source hashes and forget receipts. Those structures still reveal structural signals such as vector geometry, recurrence/co-occurrence patterns, counts, and access timing. Use local-only recall for sensitive memories when available.
A connected repo stores only an opaque keyed match token plus a sealed repo name — the cleartext repo name is observed transiently server-side only to route an inbound GitHub push webhook, never stored.
How the cloak worksWhich devices are trusted to decrypt your data, and the wrapped vault keys that make end-to-end encryption possible. The crux of the whole E2EE model.
Sealed envelopes. Our servers hold ciphertext, not content — the key stays under your device trust.
Computer-use (Agent Control) sessions and their tamper-evident escrow audit trail.
Files, screen, and video relayed between your Mac and phones (Floo media).
An attachment manifest records only an opaque content hash, mime type, byte size, an opaque per-peer device-id hash, direction, and timestamps — the human-readable file name is sealed on-device (sealedFilename) and never readable by the server.
Operational metadata, stored as readable text — our servers can read this.
Per-session token counts, cost estimates, and provider/model/device telemetry. Project names and budget labels are sealed on-device; the server groups spend only by opaque per-project hashes.
Connected AI provider accounts. Labels + status only — the actual credentials live in Google Cloud Secret Manager, never in your data tree.
Your paired Macs, phones, and relays and which can talk to your account.
Paired relay and hosted-gateway frame contents are only claimed as sealed after paired E2EE is enabled and the runtime-readiness gate is complete; relay routing metadata, public keys, coarse tool labels, thread ids, attachment ids, and delivery state remain visible. The per-agent subscription graph is cloaked behind opaque keyed doc ids.
Coding agents you've granted hosted-MCP access to, the scopes they hold, and their access audit trail.
Your subscription entitlements (Cloud Pro, Ultra) and their change history.
A unified, tamper-evident log of who/what accessed your data, when — across every device, agent, and grant.
Your notes are sealed on your own devices. To find the right one for your agent, our server works with a scrambled version of each note's “shape” — never the words.
We treat that as a known, written-down trade-off. Your content stays private; only the shape can leak — and we say so out loud.
Read the full analysisOff by default. Enable in Settings → Account. Even when on, only metadata syncs unless you separately enable Chat backup, Conversation metadata backup, or Session-log sync.
Off by default. Uses your Apple ID and iCloud Drive; deletions in iCloud Drive remove the data. Conflict copies are possible — iCloud owns sync semantics.
Off by default. When used, the secret value is encrypted and stored in Google Cloud Secret Manager; Firestore stores only the redacted label. Remove the account in OpenBurnBar to delete it.
Off by default; paid entitlement required to activate. Content sealing is claimed only for paired E2EE paths after the runtime-readiness gate is complete. In that mode the relay/gateway routes encrypted content, while routing metadata, public keys, coarse tool labels, thread ids, attachment ids, and delivery state remain visible.
Off by default. When on, anonymized crash reports are sent to Sentry. User identifier is a SHA seed derived from bundle id and full user name — not direct PII.
~/Library/Application Support/OpenBurnBar/.
iCloud.com.openburnbar.app in iCloud Drive.
Privacy controller: Imagine That AI LLC.
For privacy questions, write to privacy@imagine-that.ai.
Every promise on this page points at a file you can read — the threat model, the Firestore rules, the JWS verifier.