BuzzioDocs

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.
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. 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” is used only in the scoped sense — not absolute operator blindness.


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 Ghost 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.


6. How to verify claims

Hands-on (build tests, envelopes, claim vs non-claim): How to verify · Open-source: buzzio-crypto-open-source

Question Read
Run crypto tests yourself? How to verify
Sealed vs shared for each feature? Sealed vs shared
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
Why this ranks vs slogans? Why Buzzio 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 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.