Security Brief
USER01 is a privacy-first encrypted messenger built around local browser identity, client-side encryption, content-blind relay routing, and an optional Arbitrum subscription for higher limits.
This page explains product posture for technical reviewers. It does not claim
total anonymity, zero metadata, or independent external audit completion.
Design Goals
- Keep message and attachment plaintext on user devices.
- Let the relay route encrypted packets without needing message contents.
- Use a local identity vault instead of a central email/password account for normal chat.
- Fail closed for sensitive file-transfer paths when the private P2P/TURN path is not ready.
- Keep subscription state explicit and verifiable through an Arbitrum smart contract.
Architecture
| Layer | Role | Privacy Boundary |
|---|---|---|
| Browser client | Creates local identity, stores the encrypted vault, encrypts and decrypts messages, verifies peers, and starts wallet actions. | Trusted while the device, browser, extensions, and unlocked session are not compromised. |
| Relay | Authenticates sessions, routes ciphertext, handles quotas, issues TURN credentials, and records operational security events. | Designed not to receive plaintext message or attachment bodies, but it may process operational metadata. |
| Private TURN/P2P path | Supports secure file-transfer connectivity when direct peer paths are unavailable. | File flows are blocked if the expected secure path is not ready. |
| Arbitrum contract | Manages optional 0.01 ETH / 30 day subscription state and admin roles. | On-chain data is public; USER01 is not a custody, exchange, or investment service. |
Cryptographic Posture
- New message content uses client-side encryption before relay submission.
- Signed PFS key bundles, P-384 ECDH, HKDF, AES-256-GCM, and authenticated sender/recipient/message binding are used for the active message path.
- The local vault is protected by user-controlled PIN material and local browser storage.
- Safety numbers and peer trust checks help users detect key changes.
- Legacy RSA-OAEP behavior is decrypt-only fallback, not the active path for new messages.
Known Limits
- USER01 is privacy-first and pseudonymous; it is not total anonymity.
- The relay may process IP-level connection data, peer IDs, timestamps, quota counters, TURN grants, subscription state, delivery errors, and security events.
- A compromised device, wallet, browser, extension, or unlocked session can expose local data.
- Recipients can screenshot, copy, save, or forward decrypted content outside USER01.
- External smart contract, web/relay, and crypto protocol reviews remain recommended before stronger public claims.
Current Internal Gates
- Current internal release gates include TypeScript, production build, contract tests, subscription-flow audit, security-readiness audit, secret scan, production-header audit, and live monitoring checks.
- The production contract posture targets Safe multisig for admin/pause roles and timelock control for upgrades.
- Public copy should stay concrete: privacy-first, client-side encryption, content-blind relay, and operational metadata disclosure.
Reviewer Questions Wanted
- Is the first-contact trust model explained clearly enough?
- Does the local browser vault create unacceptable recovery or endpoint-risk confusion?
- Is the Arbitrum subscription path worth the wallet friction?
- What metadata disclosure would make the product more credible?
- What should be externally audited first: contract, relay, or crypto protocol?