On this page
Current status Why a scoped audit (not “audit everything”) Planned Scope A — Sealed messaging crypto Planned Scope B — Delivery & metadata ceilings Planned Scope C — Client custody & local security *(recommended with A, or next)* Later Scope D — Shared surfaces & media *(explicitly deferred)* Later Scope E — Wallet / payments *(optional, separate)* Artifacts to give auditors (data room) Engagement checklist (internal + public) Published reports Public summary template (fill after audit) What this page will never claim Related How Buzzio turns documented claims into third-party-reviewed claims : scoped independent review, remediation, then a public summary on this site.
Hosted here on doc.buzzio.dev — not a separate trust subdomain. Product page: Security overview . Report issues anytime via Security disclosure .
Honesty is intentional: the 2026-09-24 summary documents shipped hardening + audit readiness . It is not a substitute for a published formal third-party audit. Cert CA is ECDSA-secp256k1 v2 (docs reconciled 2026-09-24; older “HMAC CA” wording was stale).
Buzzio’s strongest privacy claims sit on sealed surfaces (1-to-1, Whisper private chat, E2E groups, private call setup). Shared rooms (Communities, Broadcast, open-history groups) store more by design — see Sealed vs shared .
A useful first engagement reviews sealed crypto + delivery ceilings , not every UI surface or billing path. That matches what privacy-focused readers actually need to trust.
In scope
Notes
Educational crypto package
buzzio-crypto-open-source
Production crypto mapping
Closed-app lib/core/crypto/ (e.g. crypto_engine, sealed sender, sender keys) under NDA
Protocol claims
X3DH, Double Ratchet, AES-GCM, sealed envelopes, sender keys as implemented
Auditors should explicitly try to break or falsify these:
#
Check
Pass looks like
A1
X3DH bootstrap Session setup matches claimed 4-DH / HKDF construction; no obvious weak binding or missing authentication
A2
Double Ratchet Forward-secrecy / break-in recovery goals hold as claimed for the implementation (not only the paper)
A3
AES-GCM usage Nonces, associated data, and key lifetime are safe; no key/nonce reuse classes
A4
Sealed outer envelope Eph ECDH → HKDF → AES-GCM hides sender on the outer path as documented; downgrade to plaintext-from is denied where claimed
A5
Sender certificates Certs enable abuse controls without letting a peer forge sealed delivery as someone else
A6
Sender keys (E2E groups) Group ciphertext confidentiality holds for non-members; member add/remove / rekey behavior does not leave durable operator-readable group DEKs
A7
Identity / mnemonic → keys Derivation is sound; phrase never leaves device; Buzzio ID is not derived from the phrase (as claimed)
A8
Prekey / signed-prekey lifecycle Exhaustion, reuse, or stale prekey attacks do not yield practical session compromise beyond documented residuals
A9
Sealed media helpers Chunk encryption for sealed / Stories paths does not put content keys on the server
A10
Open vs production divergence Document material differences (HKDF labels, salts, wiring). Educational package ≠ store binary unless report says so
A11
Known-answer / unit tests Crypto package tests are meaningful; critical paths are covered or gaps are listed
Out of scope (examples)
Why
Tor-grade network anonymity
Already a documented non-claim
“Shared rooms are operator-blind”
Not a product claim
Social engineering / unlocked-phone malware
Endpoint compromise outside messenger crypto claims
Full Communities / Broadcast / OHG product surface
Later — Scope D
In scope
Notes
Sealed delivery path
Blind-relay style, delete-on-delivery / short undelivered TTL
What servers still learn
Push wakes, account/safety records, connection patterns — see What Buzzio can see
Mislabel risk
Anything labeled sealed that behaves like shared (or the reverse) without disclosure
Rules / Functions boundaries
Issues that could expose sealed plaintext or durable sealed chat archives contrary to docs
#
Check
Pass looks like
B1
Delete-on-delivery Sealed 1:1 relay copy is removed on take; undelivered purge matches ~3-day class claim
B2
No durable private graph After delivery / Whisper expiry, no durable server archive of who privately talked to whom as claimed (scoped zero metadata )
B3
FCM / push minimization Wake payloads omit sender / caller IDs where docs say they do; no sealed body plaintext in push
B4
Sealed controls Receipts, Secure View, vanish, once-view do not recreate clear A↔B control paths contrary to Privacy guarantees
B5
Call invite sealing 1:1 / conference invite path does not leak caller_id / sender_id_hint on preferred path
B6
Presence / typing Conversation-scoped opaque tokens; no durable global online map under stable Buzzio ID as claimed
B7
Whisper private mapping Membership / creator maps match membership-gated design; no unexpected public graph
B8
Block / rate-limit integrity Sealed path cannot trivially bypass block or spam gates in a harmful way
B9
AuthZ on inbox / ACL User A cannot read User B’s sealed inbox or sealed controls via rules / Functions bugs
B10
Legacy write denial Client creates on legacy plaintext-from pending / sealed_controls paths are denied where cutover is claimed complete
B11
Docs honesty Material mismatches between doc.buzzio.dev claims and shipped behavior are findings (or doc fixes)
B12
Operator residual honesty Cert verification, undelivered queues, FCM “R at T”, and shared-mode storage are acknowledged — not hidden
Often missed if the engagement is “crypto only.” Worth including when budget allows.
#
Check
Pass looks like
C1
SQLCipher / local DB Readable sealed history is encrypted at rest; no accidental plaintext exports in logs/backups
C2
Secure storage of keys Identity / session material uses platform secure storage appropriately
C3
Encrypted backup / vault Opt-in backups are client-encrypted; staff cannot unlock without user recovery key
C4
Multi-device / account import Adding a device does not exfiltrate keys to Buzzio; vault import threats are bounded
C5
Auth / session hijack Serious auth bypass or account takeover classes are absent or documented
C6
App Check / abuse hooks Client attestation gaps are understood; not silently assumed perfect
C7
Screenshot / Secure View Treated as UX hardening, not a crypto guarantee (aligned with threat model)
C8
Logging / crash telemetry No sealed plaintext, mnemonics, or recovery keys in logs sent off-device
Not required for the first public “sealed claims” summary. Schedule when Communities / Broadcast / OHG trust matters as much as sealed chat.
#
Check
Notes
D1
Shared-room text under service keys — ACL / role bugs
Expected operator-readable; still must not leak across rooms/users wrongly
D2
Shared media dedup / CDN signed URLs
Existence oracle accepted for shared CDN class; authZ still required (dedup )
D3
Moderation / ban / audit-log integrity
Admin tools must not become sealed-chat oracles
D4
Whisper Questions
Owner-readable by design — check authZ only
D5
Stories retention / share links
Ops paths labeled shared or time-bounded as documented
#
Check
Notes
E1
Non-custodial wallet tied to mnemonic
Phrase = messaging + funds risk; no staff spend path
E2
Store entitlements / Premium
Billing abuse ≠ sealed-chat break; separate severity
Artifact
Why
Frozen tags / commits
Open crypto + production crypto + app version / store build id
Threat model + Privacy guarantees Claim ceilings
Sealed vs shared + What Buzzio can see Mislabel prevention
Sealed sender + Message delivery Envelope + relay path
How to verify Reproducible baseline
RTDB / Firestore rules + relevant Cloud Functions (NDA)
AuthZ / delivery
Known residuals list
Cert gating, FCM wakes, undelivered TTL, shared-mode — so time is not wasted “discovering” non-claims
Prior findings / disclosure inbox themes
Avoid repeat noise
Freeze a review tag — open crypto commit + matching production crypto commit / app version Choose scopes — minimum A+B ; prefer A+B+C for first public summary Brief auditors with threat model, this page’s checklists, and Security disclosure in/out lists Remediate Critical / High before marketing the result Optional fix verification pass on remediations Publish the public summary on this page , Cryptography overview , Security disclosure , and the product Security page Changelog entry with date, auditor name, scopes covered, and version audited
Date
Title
Type
Link
2026-09-24
Sealed privacy hardening summary
Eng / product public summary (not third-party)
Open
No third-party firm attestation PDF yet. When Scope A+B+C completes, each firm entry will include auditor name, versions, checklist IDs, finding counts, and a PDF under /downloads/.
Copy this block into the published PDF / this page when ready:
Buzzio — Independent security audit summary
Auditor: _______________
Engagement dates: _______________
App version: _______________
Open crypto commit: _______________
Production crypto commit (or build id): _______________
Scope: A crypto [ ] B delivery/metadata [ ] C client custody [ ]
D shared surfaces [ ] E wallet/payments [ ]
Checklist IDs covered: A__ B__ C__
Out of scope (short): _______________
Findings:
Critical: __ (fixed: __ / accepted: __)
High: __ (fixed: __ / accepted: __)
Medium: __ (fixed: __ / accepted: __)
Low/Info: __
One-sentence result: _______________
Honest residual: This review does not prove the absence of vulnerabilities.
It evaluates the stated sealed claims for the versions above as of the
engagement dates.
Full / redacted report: _______________
Report issues: security@buzzio.dev (see Security disclosure)
That educational open packages equal the Play/App Store binary unless the report says so
That shared-history features were proven sealed
An undated “we are audited” badge without scope and version
Absolute security or Tor-grade anonymity
That every checklist ID was tested if the engagement was narrower
