Why E2E chat is not on the web

Buzzio will never ship end-to-end private chat in a normal browser client.

web.buzzio.dev is a phone-approved linked companion for shared surfaces (permanent open-history groups, Communities, Broadcast, and service bot DMs). It is not a second sealed client. This page explains the mechanism and the product refusal — not a roadmap item.

Product rule (non-negotiable)

Linked web sessions are time-boxed, revocable from the phone, and use an opaque session token. They do not claim exclusive device login and do not bump device_session_epoch. See engineering note docs/LINKED_WEB_SESSION.md in the app repo (internal).

What “E2E” means for Buzzio sealed chat

For sealed surfaces, Buzzio’s model is:

1. 12-word mnemonic generated on-device → messaging keys derived locally.
2. Ciphertext produced on-device (X3DH + Double Ratchet for 1:1; sender keys for E2E groups).
3. Relay path aimed at blind delivery, not a durable readable cloud inbox.
4. Readable private history in device SQLCipher, not operator-readable sealed archives.

If private keys or decrypted sealed history move into a browser tab, the endpoint changes even when wire formats still look encrypted. Buzzio refuses to call that “the same E2E.”

Why browsers fail the sealed threat model

A native app can use OS secure storage and a constrained process. A browser page is a shared execution environment.

Ceiling: Cryptography in JavaScript is possible. Honest sealed E2E in a general-purpose browser is not under Buzzio’s threat model for private chat. Shipping it would either put long-term secrets in a weaker endpoint or quietly turn “E2E web” into decrypted companion access.

What linked web *is* (and is not)

Is: A convenience client for rooms that are already shared by design — TLS in transit, plaintext (or product-readable) content on Buzzio servers so moderation, backscroll, discovery, and multi-device shared history can work. See Sealed vs shared.

Also: Note to Self on linked web — notes-only session key from the phone, device history package on link, and a 3-day encrypted mailbox for live phone↔web messages. Buzzio does not keep a permanent Note to Self cloud vault. See Note to Self.

Also: Saved Messages on linked web — the phone wraps a stable Saved Messages key on link (does not rotate on every browser). Ciphertext stays durable; the browser holds the key only for that session. This is companion ciphertext access, not sealed 1:1. See Saved Messages.

Is not:

• A place to enter or store the recovery phrase
• A decryptor for 1-to-1 / Whisper / E2E group ciphertext
• Proof that “Buzzio has full WhatsApp Web for private chat”
• A substitute for phone-bound exclusive session controls
• A durable encrypted notes archive on Buzzio servers

Phone remains the authority: scan dual QR (challenge → confirm), choose duration, revoke anytime.

Why Buzzio will not “add it later”

Other products optimize for desktop parity. Buzzio optimizes for an honest sealed lane.

Adding sealed chat to the browser would require one of:

1. Exporting seed or long-term keys to web storage / memory
2. Server-side or companion decryption that breaks the sealed story
3. Weakening phone-first identity so a browser equals a full second device

All three conflict with Privacy guarantees and the sealed vs shared split. The refusal is permanent product policy, not temporary engineering debt.

How to verify the claim

Broader sealed claims: Verify zero metadata · How to verify.

Related pages

• Sealed vs shared privacy model
• Privacy guarantees
• What Buzzio can see
• Threat model
• Official Buzzio sites (web.buzzio.dev)
• Public explainer: Why Buzzio will never put E2E chat on the web