Threat model

This page states who we defend against, what we guarantee, and what remains out of scope. Professional privacy docs without a threat model are incomplete.

Assets

Asset	Sensitivity
Sealed message / call content	Highest — E2EE; operator should not read
Sealed conversation graph after delivery	High — minimize durable server archive
Identity keys / mnemonic	Highest — device + user custody
Local SQLCipher history	High — device compromise exposes
Shared-room content (communities, OHG, broadcast)	Medium — operator can operate feature; text under service keys; media as CDN bytes with signed access + content-hash dedup (within-room and global across shared surfaces; existence oracle accepted for shared CDN class) (dedup)
Account / profile / username	Medium — necessary for product
Push tokens / online presence	Medium–Low — operational
Payment entitlements	Low content risk — store-mediated

Adversaries

1. Buzzio operator (honest-but-curious staff / infra admin)

Goal: Read sealed chats or reconstruct private social graphs from server data.

Mitigations:

E2EE content keys never leave devices on sealed surfaces
Delete-on-delivery pending inbox
Sealed-sender outer envelopes (from: "sealed")
Local-first history
Policy: never sell data

Residual: CF may see sender at cert verification; undelivered queues; shared-mode DEKs; FCM “R at T” wakes. Online/typing for sealed 1:1 uses opaque conversation tokens (presence_conv), not a durable global online map under Ghost ID. Cert gating is intentional — see Why delivery still learns the sender. Full list: Privacy guarantees.

2. Cloud infrastructure provider (Google Firebase / FCM)

Goal: Observe accounts, connections, delivery metadata.

Mitigations: Minimize plaintext envelope fields; wake-only pushes; short retention.

Residual: Provider necessarily sees auth, connections, FCM routing, and that sealed wakes occur. Out of scope: making Firebase unable to see that Buzzio is used.

3. Network observer (ISP, Wi-Fi, nation-state on the wire)

Goal: Correlate traffic, timing, destinations.

Mitigations: TLS to Google/Cloudflare/Bunny; ciphertext payloads.

Residual: Not Tor/VPN. Timing and destination IPs remain visible. Optional user VPN is outside Buzzio’s core claim.

4. Malicious peer (other chat participant)

Goal: Exfiltrate content they can already decrypt; screenshot; forward.

Mitigations: Secure View / screenshot hardening; vanish; once-view; view-once media; keep controls.

Residual: A malicious peer who can read the chat can always copy content by other means (second camera, memory). UX hardening is not cryptography.

5. Device thief / malware on endpoint

Goal: Unlock phone or scrape decrypted DB.

Mitigations: OS lock screen; SQLCipher; Secure View; short vanish timers; no cloud plaintext inbox by default.

Residual: Unlocked compromised device defeats client-side E2EE after decrypt. Buzzio cannot fix a rooted malware environment.

6. Abusive account / spam / harassment

Goal: Flood, scam, impersonate.

Mitigations: Blocks, reports, rate limits, App Check, cert-gated sealed delivery, freemium gates, community moderation tools.

Residual: Safety records are operational data — they slightly expand what servers store relative to a pure relay.

Guarantees by surface (summary)

Surface	Content vs Buzzio	Durable private graph goal
1:1 sealed	Confidential	No durable archive after delivery
Whisper private	Confidential	No durable archive after expiry
E2E groups	Confidential	No open durable transcript
Private calls	No server recording archive	Minimal durable call metadata when idle
OHG / Communities / Broadcast	Operator can operate	History retained for product
Whisper Questions	Owner-readable by design	Stored for owner

Explicit non-goals

Anonymity networks (Tor/I2P) as default transport
Hiding that a Buzzio account exists on Firebase
Making shared rooms operator-blind
Perfect anti-screenshot on every OEM
Recovering user keys without the mnemonic / recovery key
Phone-book / SIM-based contact discovery
Custodial account restore (staff unlock of keys or wallet)