Ephemera Privacy Policy

Ephemera's messages and images are end-to-end encrypted — the server relays ciphertext it cannot read. It also has no accounts and persists no message content. Read "Security model" below for exactly what that does and doesn't protect against.

Overview

Ephemera ("the Application") is a minimal, no-signup messaging web app built on Cloudflare Workers and Durable Objects. This policy explains exactly what data the Application handles, where it lives, and what happens to it.

What data is processed

Ephemera processes only what's needed to relay a live, encrypted conversation:

Message and image content — encrypted on your device before it ever leaves it, then relayed as ciphertext in real time to the other person in the room. Ephemera's server never has the key and never sees the plaintext.
Encryption key material — each device generates a fresh public/private key pair for the room and sends only the public key over the relay, along with a handshake commitment used to detect tampering. Private keys never leave the device that generated them.
Room codes — short identifiers used to let people join the same room.

Ephemera does not ask for or collect your name, email, or any account information — there is no account system.

What is never stored

Message and image content — encrypted or not — is relayed live between connected participants and is not written to any database or persistent storage. Decrypted images held in your browser's memory for the preview modal are released when you leave the room. There is no message history to look back on, by design — once a room's participants disconnect and the room cleans up, there is nothing left to recover, for you or for anyone else. Encryption keys are generated fresh for each room and are never written to storage anywhere, on the server or on your device.

What the server can still see

End-to-end encryption hides content, not the fact that a conversation happened. Ephemera's relay still observes:

Which room codes exist and how many devices are connected to each.
Handshake public keys and commitments — these are meant to be public and reveal nothing about the resulting encryption key.
Message timing and approximate size (the ciphertext length).
IP addresses, as any relay server sees.

It cannot see message text, image content, filenames, MIME types, or even whether a given message is text or an image — that's all inside the encrypted envelope.

What is stored, briefly, and why

A server-side registry tracks which room codes currently exist and whether the system is at its active-room limit, so it can enforce a maximum of 3 active rooms at once and clean up abandoned rooms. This registry holds room lifecycle metadata only — never chat content — and entries expire automatically (roughly 10 minutes for inactive/unclaimed rooms, roughly 2 minutes after a room empties out).

Security model

Ephemera's messages and images are end-to-end encrypted. The two devices in a room agree on a session key themselves; the server relays only what it needs to make that possible, and never sees anything it could use to decrypt your content.

How the encryption works

Key agreement: ephemeral ECDH on curve P-256, using a commit-then-reveal handshake so the relay can't grind a substitute keypair to match an expected result.
Key derivation: HKDF-SHA256 over the ECDH output, binding both devices' public keys so a replayed or spliced handshake derives a different key.
Encryption: AES-256-GCM, an authenticated cipher — it hides content and detects tampering, with a fresh random IV per message.
Forward secrecy: keys are generated fresh for every room and never stored, so a key recovered later cannot decrypt an earlier conversation.
Enforced at the protocol level: Ephemera's server rejects any plaintext text or image message outright — only encrypted envelopes and handshake frames are accepted. Encryption isn't just what the app happens to do; the server won't relay anything else.

The safety code, and what it protects against

Both devices display a short safety code derived from the agreed keys. If those codes match, the key exchange completed exactly as both sides intended. If a relay attempted to substitute its own keys during the handshake — a man-in-the-middle attack — the two devices would derive different keys, and their safety codes would differ. Comparing the safety code is the actual security check; Ephemera doesn't force it, so an attack during the handshake is only caught if you do.

What this does and doesn't protect against

Situation	Outcome
Someone eavesdropping on the network	Defeated — they see only ciphertext, on top of the TLS connection itself
A curious or compromised relay operator	Defeated — the encryption key is never derivable from anything the server holds
A server breach, log dump, or data request	Defeated — nothing stored on the server can decrypt past conversations
A relay that actively tampers during the handshake	Detectable, not prevented — the safety codes will differ if you check them
Confirming who you're actually talking to	Not covered — there's no identity system, so the safety code confirms a shared key, not a person

There is also no authentication on room membership: anyone who has a room's code can join it, and rooms hold exactly two devices — a third is refused at the connection level. Treat Ephemera as end-to-end encrypted casual messaging, not as an audited secure-communications product.

Third parties and analytics

Ephemera does not use analytics, tracking, or advertising. It runs entirely on Cloudflare's infrastructure (Workers and Durable Objects) to serve the app and relay messages.

Authentication and payments

Ephemera has no accounts, sign-in, or payment functionality of any kind.

Data retention and deletion

There is nothing to delete on request, because message and image content is never persisted in the first place. Room metadata (the fact that a room code exists) clears itself automatically per the timings above — there is no manual deletion flow because none is needed.

Changes to this policy

Ephemera is an early-stage MVP and may change. If a future version adds persistence, accounts, or identity verification beyond the safety code, this policy will be updated first, and the version and effective date above will change accordingly.

Contact

Questions about this policy can be sent through the contact page.