Privacy Policy

Our Privacy Philosophy

At nullroom.io, our mission is to provide a "volatile space" for conversation without a digital footprint. We believe that privacy is not just about hiding data - it is about the intentional non-existence of data.

Data We Do Not Collect

Personal Info

No names, emails, phone numbers, or accounts are ever requested or stored.

Message Content

Messages are sent directly between peers via WebRTC and never touch our servers in any format. They are fully end-to-end encrypted before leaving your device.

IP Addresses

Server logging is entirely disabled in production. IP addresses are only briefly held in volatile memory to rate-limit and prevent abuse, but are never written to any persistent storage.

Cookies

Zero tracking, analytics, or advertising cookies. A generic session cookie is used transiently only during the Monero donation flow and is cleared right after.

Data We Process Temporarily

Room UUIDs

Stored in volatile memory (Redis) and purged after 15 minutes to enforce session expiration.

Signaling Metadata

For standard link sharing, encrypted connection details are instantly relayed via WebSockets without ever being saved. If you use the optional 4-word handshake phrase, the encrypted connection blob is stored in memory for up to 3 minutes and acts as a strict "one-time read" before being instantly deleted.

File Transfer Gate

When you send a file, the server briefly receives only its size to authorize the transfer against the applicable limit. It never sees the file name, your connection type, or the contents - the encrypted bytes travel peer-to-peer and are never logged.

Security Architecture

E2EE

End-to-end encryption powered by the browser's Web Crypto API (AES-GCM 256-bit) with a post-quantum hybrid key exchange.

Post-Quantum

ML-KEM-768 (NIST FIPS 203) key exchange runs automatically over the data channel. The quantum shared secret is fused with the classical URL key via HKDF-SHA-256, producing a hybrid session key resistant to "harvest now, decrypt later" attacks.

Peer-to-Peer

Data travels directly between browsers via WebRTC - not through our servers.

Client-Side Keys

The encryption key lives in the URL fragment (#), which browsers never send to the server. This classical key serves as one of two inputs to the hybrid derivation.

Mutual Confirmation

Both peers verify role-specific HMAC confirmations before activating the hybrid key, preventing reflection and man-in-the-middle attacks on the key exchange.

Third Parties

STUN/TURN Relays

A self-hosted TURN server (coturn) is used for NAT traversal. Relay traffic is encrypted via TLS. No third party sees routing metadata.

Payments

Donation payments are processed anonymously via Monero. We use a "Blind Token" signature system to ensure that your payment identity is strictly decoupled from your chat sessions.