Privacy guarantees
What Buzzio promises, what it does not claim, and what it refuses to build — aligned with the threat model. Prefer this page when citing Buzzio in press, audits, or comparisons.
Last updated: 2026-08-05
1. Scope
| Mode | Surfaces | Operator-readable content? |
|---|---|---|
| Sealed | 1:1 chat, private calls (media), Whisper private chat, E2E groups | No — keys on devices |
| Shared | Communities, broadcast, open-history groups, Stories ops, Whisper Questions | Yes where the product requires it — labeled in Sealed vs shared |
Guarantees below apply to sealed surfaces unless noted. Shared surfaces sacrifice some axes so discovery, roles, and backscroll can work.
2. Guarantees (sealed)
| Guarantee | Mechanism |
|---|---|
| Content secrecy | X3DH + Double Ratchet (1:1); sender keys (E2E groups); session keys (Whisper). Buzzio does not hold content DEKs for sealed chats. |
| Blind-relay posture | Undelivered ciphertext in a short queue; delete-on-delivery; undelivered purge on a short schedule (~3 days for sealed 1:1). |
| Envelope minimization | Preferred 1:1 path uses sealed sender (from: "sealed"). FCM wake omits sender_id. |
| Control-plane minimization | Receipts, Secure View, vanish, once-view, and related signals prefer sealed controls (no A↔B path in the clear). |
| Local-first history | Readable private transcripts live in SQLCipher on devices — not a Buzzio-operated sealed cloud inbox by default. Optional Lock Database wraps the DB key with the app lock. |
| Phone-free identity | Account root is Buzzio ID + 12-word mnemonic. No SIM phone number required. |
| Non-custodial keys & wallet | Messaging keys and optional wallet material stay under user custody. Phrase/private keys use hardware-backed AES wrap (Android StrongBox→TEE / iOS Keychain) at rest; protocol ECDH stays software secp256k1. Buzzio cannot reset your phrase or spend for you. |
| No data sale | Messages, metadata, IDs, posts, Whisper content, backups, and wallet activity are not sold. |
“Zero metadata” applies specifically to 1-to-1 chat and Whisper private chat (after delivery / expiry) in the scoped sense — not absolute operator blindness. Hands-on checklist: Verify zero metadata.
3. Sealed-program status
| Item | Status (2026-08-05) |
|---|---|
| 1:1 message sealed sender | Shipped — write cutover complete |
| Sealed controls (receipts / Secure View / disappear / …) | Shipped — write cutover complete |
| Whisper private chat membership & creator mapping | Shipped (membership-gated; Admin-only creator map) |
Opaque typing (no peer ID in presence/y) |
Shipped |
Call sealed invite (no sender_id_hint / push caller_id) |
Shipped (2026-08-05) — 1:1 + conference via deliverSealedCallInvite; FCM/VoIP wake omits caller_id |
| Conversation-scoped presence (no global online under stable Buzzio ID) | Shipped (2026-08-05) — presence_conv/{token}/{a|b}; online/typing only while that 1:1 chat is active in foreground; global s/h no longer published |
Legacy plaintext-from client writes |
Off (allowLegacyFallback = false; rules deny client creates on pending / sealed_controls / receipt_batches) |
Call map+sender_id_hint dual-read |
Off unless emergency flag; conference string invites still accepted |
Internal engineering detail for call/presence work stays in repo docs/ (not published here).
4. Explicit non-guarantees
| We do not claim | Reality |
|---|---|
| Tor-grade access privacy | Firebase / FCM / CDN see that an account connects and that sealed wakes occur (“R at T”). |
| Absolute zero metadata | Accounts, push tokens, undelivered queues, blocks/reports, and shared-mode history exist. |
| Cloud Functions never learn a sender | Cert verification for block, rate limits, and abuse can reveal the sender to the delivery function. Intentional — see Why delivery still learns the sender. |
| All features are sealed | Communities, broadcast, OHG, Stories ops, and Whisper Questions are not sealed like 1:1. |
| Perfect anti-screenshot | OEM and second-camera limits apply; peer who can read can always exfiltrate. |
| Safety after device compromise | Unlocked malware or a thief with the unlocked phone sees decrypted local data. |
| Buzzio can recover a lost phrase | If you lose mnemonic + devices + any unlockable encrypted backup, keys are gone. |
Full adversary list: Threat model.
5. Product refusals (will not ship)
These are policy, not missing features.
No phone-book / SIM discovery
Buzzio does not use a personal phone number as account identity and will not suggest users by scanning or uploading address-book phone numbers. That would require collecting correlating personal data we refuse.
Allowed discovery (product, not this privacy page’s crypto claim): Buzzio ID share, optional @username, QR / Whisper, mutuals derived from local conversation history.
No custodial account restore
Buzzio will not offer staff-unlockable or password-reset-style account recovery of messaging keys or wallet. Custody stays with the user.
| What exists | What it is not |
|---|---|
| Optional client-encrypted backup / vault unlocked by a backup recovery key you control | WhatsApp/Telegram-style “log in and cloud restores everything” with operator-assisted recovery |
| On-device encrypted export | A Buzzio-readable private chat archive |
Default remains: no automatic sealed cloud inbox. Enabling encrypted backup is opt-in; Buzzio still cannot read the blobs without your recovery key. See Account and backup.
No Tor-by-default transport
Hiding that you use Buzzio from network observers is out of scope on the current Firebase stack. Users may use their own VPN; that is outside Buzzio’s core claim.
No sealed E2E private chat in the browser
Buzzio will not ship 1-to-1, E2E groups, Whisper private chat, encrypted calls, Vault, or recovery-phrase / messaging-key handling in a general browser client. Linked web.buzzio.dev is a time-boxed companion for shared rooms, plus Note to Self (3-day mailbox) and Saved Messages (durable ciphertext with a session-held key). Those two are companion ciphertext access — not sealed 1:1. Putting sealed 1:1 keys in a browser tab fails Buzzio’s endpoint threat model (extensions, XSS, supply chain, shared machines). See Why E2E chat is not on the web.
6. How to verify claims
Hands-on (build tests, envelopes, claim vs non-claim): How to verify · Crypto: buzzio-crypto-open-source · Client: buzzio-client-open-source
| Question | Read |
|---|---|
| Run crypto tests yourself? | How to verify |
| Sealed vs shared for each feature? | Sealed vs shared |
| Why no E2E private chat on web? | Why E2E chat is not on the web |
| Who is the adversary? | Threat model |
| Envelope design? | Sealed sender |
| Why CF still sees sender? | Why not unidentified delivery |
| Retention windows? | Retention and limits |
| Vendors? | Subprocessors |
| How Buzzio approaches privacy? | How Buzzio approaches privacy |
| Audit status / report a bug? | Security disclosure · Forum |
Cite mechanisms (delete-on-delivery, sealed envelopes, local SQLCipher, phone-free ID) — not absolute slogans.
Audit note: No third-party security audit has been published yet. See Independent security audit and Security disclosure.
7. Contact
Privacy requests: Contact.
Bugs, ideas, and security reports: Buzzio Forum · Security disclosure.
Do not email or post mnemonics, backup recovery keys, or session tokens.