VANISH PRIVATE CHAT GUIDE
Security, explained plainly
Vanish reduces what the backend can read and explains what it cannot guarantee.
Current protections
Vanish uses AES-256-GCM, separate keys, random identifiers, server-enforced expiry, cleanup, rate limits, and strict browser security headers.
Known limitations
Vanish has not had an independent security audit. It lacks identity verification and forward secrecy. Invite holders can enter, and participants can copy content.
Backend and database controls
Only the protected Edge Function uses the service role. Browser roles have no table or database-function access. Row Level Security, fixed function search paths, strict origin checks, request limits, payload validation, and room capacity limits provide defense in depth.
Creator control
New rooms have a separate creator capability kept in the creator browser session. It is not part of the shared invite. Ending a room blocks further access and removes live message rows, but cannot erase copies, logs, or backups.
Browser protections
The site uses a restrictive Content Security Policy, HTTPS enforcement, frame blocking, MIME-sniffing protection, a no-referrer policy, and limited browser permissions. Message text is inserted through text nodes rather than HTML.
Optional PIN
A room creator can require a 4–6 digit PIN. The invite secret and PIN are mixed through PBKDF2 before room keys are derived. A short PIN adds friction if a link leaks, but is not a substitute for protecting the complete invite.
Threat model
The design protects message bodies if application storage is inspected without the invite secret. It assumes modern uncompromised browsers, correctly functioning cryptography, careful invite sharing, and trustworthy recipients.
Questions and answers
Has Vanish been independently audited?
No. Automated protocol and tamper tests exist, but no independent audit has been completed.
Does Vanish provide forward secrecy?
No.