Why Buzzio Will Never Put E2E Chat on the Web
Buzzio’s private chats — 1-to-1, E2E groups, Whisper private chat, encrypted calls, and Vault — stay on your phone. web.buzzio.dev is a linked companion for shared rooms only. That is not a missing feature. It is a deliberate refusal.
What “end-to-end” actually requires
End-to-end encryption only means something if your private keys stay out of reach of everyone except you — including the company that runs the product, and including anyone who can compromise the place where those keys live.
On Buzzio:
- Your 12-word recovery phrase is created on the device.
- Messaging keys are derived locally from that phrase.
- Sealed chat history decrypts in local encrypted storage on the phone.
- Buzzio’s servers are built as a blind relay for sealed surfaces — not as a place that holds readable private transcripts.
Move that key material into a normal browser tab, and the security story changes — even if the math on the wire still looks “encrypted.”
Why browsers are a bad home for E2E keys
A phone app can use OS-backed secure storage, app sandboxing, and a smaller attack surface. A browser tab does not.
| Risk | Why it matters for E2E |
|---|---|
| Malicious or compromised extensions | Can read page memory, storage, and clipboard |
| XSS / injected scripts | One bad script on the origin can exfiltrate keys or plaintext |
| Supply-chain / CDN / dependency compromise | Web clients are often updated continuously from remote assets |
| Shared or workplace machines | Profiles, sync, screenshots, and leftover session state |
| Debuggers and “view source” culture | Keys that must live in JavaScript are easier to steal than keys in a phone secure enclave |
You can wrap ciphertext in clever protocols and still lose the plot if the endpoint is a page that any extension or XSS can read.
Claiming “full E2E web chat” while private keys sit in browser storage is the kind of promise Buzzio refuses to make.
Why “possible” is the wrong question
Technically, you can run crypto in JavaScript. That does not make browser E2E honest for a messenger whose sealed lane is supposed to compete with phone-first private apps.
Doing it “for convenience” would force one of these bad choices:
- Put seed or long-term keys in the browser — then a single web compromise can drain the private graph.
- Mirror decrypted history to the web — then “E2E” becomes marketing around a cloud-readable companion.
- Weaken exclusive device / phone-bound identity — so a browser session behaves like a second full client.
Buzzio’s product model is the opposite: sealed identity and sealed history stay phone-first. A web session must never become a second place that holds your recovery phrase or sealed chat keys.
What the web is allowed to do
web.buzzio.dev is phone-approved and time-boxed. It can open only:
- Permanent open-history groups
- Communities
- Broadcast channels
Those surfaces are already shared by design (TLS in transit; content readable for the product to work). Putting them on a linked browser session does not pretend they are sealed.
The phone remains the only place for:
- Private 1-to-1 chat
- E2E groups and Whisper private chat
- Encrypted calls
- Private Vault and seed-level secrets
- Approving, timing, and revoking the web link
You scan QR codes on the phone, choose how long the session lasts, and can cut it off anytime. Linking web does not log the phone out or replace exclusive device login.
Honest trade-off
Other messengers ship a full desktop or web client for everything. That is convenient. It also expands the place where private keys and plaintext can leak.
Buzzio chooses a clearer line:
- Sealed chat stays on the phone.
- Shared rooms can use the browser as a companion.
- We will not market browser E2E we cannot honestly defend.
If you need private messages, open Buzzio on your phone. If you need Communities, open-history groups, or broadcast on a larger screen, link the web — knowing exactly what that session can and cannot see.