Security overview

Keys and envelopes

The front page makes a promise: you share pictures with the people you pick, and nobody else — including us — can look at them. This page is for readers who want to know what that promise rests on before believing it.

The whole thing in one paragraph

Your keys are created on your phone and never leave it in a form anyone else can use. A picture is locked before it is uploaded, and the key that opens it is packed into a sealed envelope addressed to one specific person. We store the locked picture and the sealed envelopes. We hold no key to either. That is not a policy we promise to follow — it is an arrangement in which we have nothing to hand over, to sell, to lose in a breach, or to be compelled to produce.

Who holds what

Three parties are involved in every share, and only two of them can open anything.

Your phone

Creates your keys, locks each picture, and seals one envelope per person you share with.

Can open everything of yours

Our server

Stores locked pictures and sealed envelopes, and checks who is currently allowed to fetch which.

Can open nothing

Their phone

Opens the envelope addressed to it, and with it the pictures you allowed — on screen, in the app.

Can open what you allowed

The middle column is the one that matters. A service that can show you your own pictures on a new device without you supplying anything is a service that holds your key. Ours cannot: sign in on a new phone and you will be asked for your recovery passphrase, because there is no other way to get your private key back. The inconvenience is the proof.

One envelope per person

This is the part people usually mean when they ask whether "individual sharing" is real, or just a switch in a database that decides who is shown what.

Every folder has its own key, and each picture inside has a key of its own on top of that. When you let someone in, your phone seals a copy of that folder's key so that only their device can open it. Three people means three separate sealed copies, each useless to the other two:

Sealed for Ada
Sealed for Ben
Sealed for Cleo
No copy for us

Four consequences follow, and they are the reason the arrangement is worth the trouble:

There is no shared password to leak. Access is not a secret passed around a group; it is a separate sealed copy per person.
We cannot add a recipient. Sealing a copy requires a key we have never had. If someone has access to your folder, a device of yours put them there — no configuration change on our side can do it.
Letting one person in changes nothing for the others. No re-sharing, no notification to the rest, no common key to update.
A single picture shared on its own gets its own key, not the key of some larger collection. Sharing one thing never quietly widens into more.

The person you share with does not have to be online, or even to open the app, for the share to be prepared — their public half is enough, and that is what a public key is for. What they cannot do is receive anything before they have accepted a connection request from you.

What we can see

Encryption protects contents. It does not hide that something happened, and a page that implies otherwise is not being straight with you.

Both columns are complete as far as media are concerned.
We can see	We cannot see
Usernames, email addresses, public keys	Private keys — yours never reach us in usable form
Which accounts are connected, and who shared with whom	Folder and picture keys, at any moment, in any form we can open
How many pictures a folder holds, how large they are, when they arrived	The pictures and videos themselves
That a folder exists	What the folder is called
Who fetched what, and when	Your recovery passphrase or your 24 words

Taking access back

Revoking is immediate: from that moment the server refuses that person every part of that folder, and their sealed copy of the key is destroyed. Everything you add afterwards is locked with a new key they were never given.

Here is the limit, stated plainly because the alternative is a comfortable lie: revoking cannot reach back into what someone has already seen. Material that existed before the revocation was, for a while, legitimately readable on their device. From then on it is our access check that keeps them out of it, not arithmetic. Anyone who tells you a revocation un-shows a picture is selling something.

The same honesty applies to the time limits — a fixed end date, a window that starts when the picture is first opened, or a single viewing. They decide how long the app will show something. They cannot decide what a person remembers, or what a second camera recorded.

If you lose your phone

Your private key can be restored on a new device from your recovery passphrase, or from the 24 words you wrote down when you signed up. What we store to make that possible is itself locked with something only you know, and we do not hand it out on a username alone — you have to sign in, or confirm through a link sent to your email address, before it is released at all.

Which means the uncomfortable part is true: lose both the passphrase and the words, and your media are gone. Not withheld pending support — gone, for us as much as for you. A service that can rescue you from that is a service that could always read along.

What this does not protect against

A second camera pointed at the screen. No app can prevent it. The app blocks capture on unmodified Android and tells you when someone tried, which is a different and smaller thing.
A modified device or a self-built app. Whatever is on a person's own screen can be extracted by that person if they are determined enough. Our design decides who may see something; it cannot govern what their hardware does afterwards.
Traffic analysis. The right column of the table above is not a secret we are keeping — it is a list of what we genuinely cannot read. The left column is real, and it is enough to reconstruct a social graph.
A recipient who reports content. Reporting decrypts a copy on the reporter's device and sends it to us for review. That is the one path by which we can ever see a picture, it exists because the law requires it, and it starts with a person you chose to share with.

How to check us

Claims are cheap. These are the ones that would be observably false if we were lying, which is what makes them worth making.

A new device always asks for something you know

If your pictures ever reappeared on a fresh install after nothing more than an ordinary sign-in, we would be holding your key. Watch for it.
Nobody can be added to your folder without your device

Check the list of people you have shared with. Anything you did not put there yourself would be an entry we could not have created.
Support can never recover a lost passphrase

Ask us to. The answer will be no, in every case, forever — including the cases where saying yes would be much better for us.
There is no web version, and there will not be one

A browser page cannot stop what it shows from being saved. Building one anyway would be the quiet moment where the promise turns into marketing.