Independent security audit
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.
Current status
| Item | Status |
|---|---|
| Published third-party audit | None yet |
| Public summary PDF | Not available yet — this page is the future link home |
| Bug bounty | Not offered yet — coordinated disclosure via security@buzzio.dev |
| Open mechanisms for review today | How to verify · Crypto OSS · Threat model |
Honesty is intentional: open docs and educational packages are not a substitute for a published formal audit.
Why a scoped audit (not “audit everything”)
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.
Planned Scope A — Sealed messaging crypto
| 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 |
Checklist A — crypto & protocol
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 |
Planned Scope B — Delivery & metadata ceilings
| 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 |
Checklist B — delivery, metadata, abuse
| # | 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 |
Planned Scope C — Client custody & local security *(recommended with A, or next)*
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 |
Later Scope D — Shared surfaces & media *(explicitly deferred)*
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 |
Later Scope E — Wallet / payments *(optional, separate)*
| # | 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 |
Artifacts to give auditors (data room)
| 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 |
Engagement checklist (internal + public)
- 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
Published reports
No reports published yet.
When the first scoped audit completes, each entry will look like:
| Field | Example |
|---|---|
| Auditor | Firm or independent researcher name |
| Dates | Engagement window |
| Artifact versions | App x.y.z, crypto commit abc…, production crypto commit def… |
| Scope | A+B (+C if included) |
| Checklist coverage | Which A#/B#/C# items were in scope |
| Summary | Link to PDF under /downloads/ |
| Findings (counts) | Critical / High / Medium / Low — and fixed vs accepted |
| Residual note | Audits do not prove absence of bugs; result is as-of the dated scope |
Public summary template (fill after audit)
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)
What this page will never claim
- 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
Related
- Security disclosure — reports, Safe Harbor, bug bounty status
- How to verify — build tests and claim ceilings
- Cryptography overview
- Threat model
- Privacy guarantees
- What Buzzio can see
- Protocol one-pager
- Product Security overview