BuzzioDocs

Security disclosure

How to report security issues and product bugs, what is in scope, Safe Harbor expectations, and our public audit status.

Private security reports (preferred): security@buzzio.dev — subject Security Report
Product bugs & ideas (public community): https://forum.buzzio.dev/
General / privacy contact: founder@buzzio.dev
Open-source crypto: github.com/ve-21/buzzio-crypto-open-source · SECURITY.md
Open-source client reference: github.com/ve-21/buzzio-client-open-source · SECURITY.md
How to verify claims: How to verify


Independent audit status

No third-party security audit has been published yet for the Buzzio production app, the educational crypto package, or the educational client reference.

That is an honesty statement, not a claim that “security is finished.” Docs and the open crypto package describe mechanisms for review; they are not a substitute for a published formal audit.

Public home for audit status, scoped plan, and future summary: Independent security audit (on doc.buzzio.dev — no separate subdomain). When a report is published, we will link it there, here, on Cryptography overview, and on the product Security page.

Bug bounty: not offered yet. A paid program may come later; until then, thanks and coordinated disclosure via security@buzzio.dev are the path.


How to report security issues

Email security@buzzio.dev with subject Security Report.

Include steps to reproduce and impact. Do not post exploit detail on the public Forum. Do not include mnemonics, recovery keys, session tokens, or private keys.

Contact order: (1) security@buzzio.dev for all security findings · (2) Forum for non-security product bugs and ideas only · (3) founder@buzzio.dev for privacy / general contact. See also Contact.


How to report product bugs and share ideas

Join Buzzio Forum for public product discussion:

  1. Create an account and join the community.
  2. Report product bugs (non-security) in the appropriate category.
  3. Share ideas and feedback.
  4. Join community program discussions — help test, review, and shape priorities.

Security findings belong in email to security@buzzio.dev, not in public Forum posts.

Never include (anywhere)

Forbidden Why
12-word recovery phrase Account takeover
Backup recovery keys Unlocks encrypted history backups
Session tokens / private keys Same class of risk
Live production secrets (CA keys, peppers) Contact privately; do not paste in public threads

Staff cannot “look up” your phrase. If you pasted it anywhere, treat that identity as compromised.


Scope

In scope (examples)

Area Examples
Sealed messaging crypto design / reference package Breaks in X3DH, ratchet, sealed envelope, sender keys as documented / open-sourced
Client security Auth bypass, unauthorized access to another user’s sealed content, serious local data exposure
Delivery / abuse controls Issues that defeat blocks, spoof sealed delivery in a harmful way, or leak sealed content
Shared-mode boundaries Cases where something labeled sealed behaves like shared (or the reverse) without disclosure
Docs honesty Material misstatements we should correct on doc.buzzio.dev

Out of scope (examples)

Area Notes
Social engineering of users Phishing individuals
Denial of service against Firebase / CDN vendors Report to the vendor where appropriate
Issues that require physical access + unlocked phone + malware already on device Endpoint compromise is outside messenger crypto claims
“No Tor / no absolute anonymity” Already an honest non-claim — see How to verify
Theoretical issues without impact Prefer actionable repro steps
Spam / cosmetic UI nits filed as “security” Use Forum product categories instead

Shared rooms (Communities, Broadcast, open-history groups) intentionally store more — reporting that they are not sealed is not a vulnerability; reporting a mislabel is.


Safe Harbor

If you research and report in good faith:

  1. You make a good-faith effort to avoid privacy violations, data destruction, and service disruption.
  2. You do not exploit a vulnerability beyond what is needed to demonstrate it.
  3. You do not access or exfiltrate data that is not yours (stop when you confirm impact).
  4. You report promptly via security@buzzio.dev and give us a reasonable time to respond before public disclosure.
  5. You never publish recovery phrases, user private keys, or other users’ message content.

Under those conditions, Buzzio will not pursue legal action against you for the research methods that were necessary and proportionate to demonstrate the issue. We may still ask you to delete data you should not have retained.

Safe Harbor does not cover: ransomware, extortion, attacks on third-party users, physical break-ins, or continuing exploitation after we ask you to stop.


What is open vs closed

Open (educational) Closed (production)
Crypto reference algorithms & tests (repo) Full mobile app, Firebase wiring, Cloud Functions
Client UI reference (encryption banners / verify stubs) (repo) Production app binary, backend protocols, secrets
Generic demo salts / demo CA material in the package Real PBKDF2 salts, HKDF peppers, CA private key

Security of messaging crypto must not depend on hiding algorithms (Kerckhoffs). Security does depend on keeping private keys, CA material, and production peppers secret.