Security model — SendSelf

What gets encrypted

Every space has its own space key: a random AES-GCM 256-bit key that is created on the first device and only ever exists on the devices in that space. Before anything is uploaded, your device uses it to encrypt:

the text of your messages;
the contents of your files;
the details around them — file names, types and sizes, which files were sent together, and whether a message is temporary;
the names you give your devices and your spaces.

Each piece of ciphertext is also bound to the message it belongs to, so it cannot be lifted into another message without failing to decrypt.

Keys, and where they live

SendSelf has no accounts and no passwords on the server. What identifies you is a small set of keys, and the ones that matter never leave your devices.

The keys SendSelf uses, what each one does, and where it is kept
Key	What it does	Where it lives
Space key	Encrypts everything you share in a space.	Only on the space's devices. Replaced when a device is revoked; earlier keys are kept so your history stays readable.
Device keys	Each device has two P-256 key pairs: one to receive keys securely, one to sign what it sends.	The private halves never leave the device. The public halves are published so your other devices can recognise it.
Device token	A random 256-bit credential that lets one device use the API.	Kept on the device. The server stores only a hash of it, and each device has its own.
Lock key	Encrypts this device's local data, if you set a lock.	Derived when you unlock and held in memory only.

Linking a device

Adding a device never gives the server a copy of the space key that it can open:

1
The new device creates its own keys and shows a QR code (or a text code to paste) that carries its public keys.
2
A device already in the space scans it. If the keys the server relays do not match the ones in the code, it refuses to go on.
3
It seals the space key, and a fresh token for the new device, so that only the new device can open them — then hands the sealed package to the server to pass on.
4
The new device opens the package and joins. A pairing request that is not completed expires after 10 minutes.

The device that scans also signs the newcomer's public keys, and your other devices check that signature rather than taking the server's list of devices on trust. When a device joins, the chat says whether its keys were verified this way. If the keys of a device you already know ever change, your devices say so instead of quietly accepting them.

Only the space's owner and its admins can link or revoke devices; other devices are members.

Messages are signed

Every message — and every “delete for everyone” — is signed by the device that sent it. The signature covers who sent it, the key it was encrypted with, its id, and every encrypted field. Your devices check it against the sender they already trust before storing anything.

So the server cannot change a message, and cannot pass one off as having come from a different device in your space. What a signature does not cover is covered under limits below.

Removing a device

Revoking a device from the devices list does two things:

its token stops working at once, so it can no longer reach the space;
one of your remaining devices creates a new space key and seals a copy for each device that stays. The server passes those copies on without being able to open them.

From then on, everything is encrypted with a key the revoked device never receives. Your other devices keep the earlier keys, so your history stays readable.

Deleting and temporary messages

Delete for everyone sends a signed deletion through the same path as a message. The server drops its own copy straight away, and each of your devices deletes its copy once it has checked the signature.

A temporary message disappears from your other devices as soon as one of them opens it, and from that one when it is closed. Whether a message is temporary is part of the encrypted content, so the server cannot tell which ones are — or remove the flag to keep one around.

Both depend on your devices doing what the app asks. Neither can undo a screenshot, a file that was already saved elsewhere, or a device that never comes back online.

Protecting this device

Your history, your files and your keys are stored in this browser. Without a lock, anyone who can open this browser profile can read them.

Lock

A lock encrypts all of that at rest, with a key derived from a passphrase or PIN (PBKDF2-SHA-256, 600,000 iterations) or from a passkey. SendSelf then asks for it every time it starts, and you can lock it on demand. The secret is never sent anywhere, so it cannot be reset: if you forget it, you lose this device's copy — not the space, and not your other devices.

Recovery file

If every device in a space is lost, nothing on the server can bring the space back. A recovery file can: it restores this device in that space, identity and keys included. It is encrypted with a code that is generated for you and shown only once. The file and its code together are as good as the device itself, so keep them apart and safe.

A recovery file is a snapshot. After a device is revoked and the key changes, create a new one to cover what is sent from then on.

Command-line devices

The sendself command line lets a server, a script or an agent send to a space. It encrypts and signs on that machine exactly like the app, and it only sends: nothing in the space is ever delivered to it. Its keys live in a file on that machine, readable only by the account that linked it and with no lock of its own. Revoke it from your devices like any other device.

What the server can see

Encryption hides what you share, not the fact that you are sharing. This is what the service can and cannot see:

It cannot read

The text of your messages
Your files, their names and their types
The names of your devices and spaces
Which messages are temporary, or which files were sent together
The space key or any private key

It can see

That a space exists, and which devices are in it, with their public keys and roles
When messages are sent, roughly how large they are, and which devices still need them
When a device is added, revoked, or deletes a message
IP addresses and request timing, as any web service does

Encrypted messages and files are kept only until your devices have them, and never longer than 24 hours. The privacy policy lists everything the service stores and for how long.

Where the protection ends

We would rather you knew these than found them:

The app comes from the server. SendSelf runs in your browser as code served by sendself.4oli.com. Whoever controls that deployment could ship code that reads your messages while the app is open — encryption inside an app cannot protect you from the app itself. The code is open source, and the page is only allowed to run its own scripts, but you are trusting this deployment.
Your devices are part of the model. A device that is compromised, or unlocked in someone else's hands, can read everything on it.
No protection against replays yet. The server cannot forge or alter messages, but it could send a valid one twice, or deliver messages out of order. Timestamps are set by the server and are not signed.
Metadata is not hidden. Message sizes, timing and the number of devices are visible to the service.
The lock is opt-in and does not yet lock itself after a period of inactivity. Files shared into SendSelf from another app also wait briefly, unencrypted, in the browser's cache until the app picks them up.
Not independently audited. SendSelf is an early-stage project, and its security has not been reviewed by a third party.

Check it yourself

SendSelf is open source under the MIT license. The technical security document describes the model in full — algorithms, formats and open design questions — and the source code is what runs.

If you find a vulnerability, please report it privately through the repository's security page rather than in a public issue.

Built so the server can't read what you send

Encrypted on your device

Keys stay with you

Signed by the sender

Revoking changes the key