Privacy

Where your proof photos actually go

PlayNObey · 20 September 2026 · 5 min read

Where does a proof photo go when you press send?

In almost every app of this kind, it goes to the company's server and stays there. You take the picture, the app uploads it, a copy lands in cloud storage, a row in a database points at that copy, and the other person's phone downloads it when they open the review screen. Nothing about that is unusual — it is the normal way to build an app, and it is how the feature works in every D/s task tracker we are aware of.

It is worth stating anyway, because of what the picture is. Proof photos are the single most sensitive thing these apps hold. More sensitive than the task list, more sensitive than the chat. And the person who took it usually assumes it went to one other person.

What "encrypted" means in a privacy policy, and what it usually does not

Almost every app in this category says it encrypts your data. The word is doing much less work than it looks like.

The default meaning is encryption at rest: the disk the server writes to is encrypted. That protects you against somebody physically stealing a drive from a data centre. It does not protect you against the company's own staff, a leaked access key, a misconfigured storage bucket, a subpoena, or an acquisition. In all of those cases the files are read exactly as the application reads them, because the application has the key.

The stronger version is end-to-end encryption, where the content is encrypted on your device with a key the server does not have. Then a server operator holds ciphertext and nothing else. A middle position — one that SubTasks markets explicitly — is field-level encryption, where each piece of user content is encrypted separately before it reaches the database, with the keys held apart from the ordinary database credentials. That is genuinely better than disk encryption. It still means the company can decrypt your photo if it decides to.

None of this makes any of those apps dishonest. It makes the word "encrypted", on its own, close to meaningless. Read for the sentence that says who holds the key.

Has this actually gone wrong?

Yes, recently and at scale. In early 2026, researchers found five dating and kink apps — including one called BDSM People — storing user images in cloud buckets with no password on them at all. Roughly 1.5 million private images were exposed, and the developer took over two months to close the hole after being told about it.

That is the specific shape of the risk, and it is worth being precise about it: nobody was hacked. There was no clever attack. Files that were meant to be private were sitting on the open internet because of one configuration mistake, and they stayed there until a journalist published. Every app that uploads your photos is one such mistake away from the same outcome, no matter how good its intentions are.

How to check the app you already use

This takes about a minute and works on any of them.

1. Open the privacy policy and search for the word delete. If deleting your account removes your data "within 30 days" or "subject to our retention schedule", the files are on a server.
2. Search for third party or sub-processor. A list of cloud providers means your photos are on their infrastructure too.
3. Turn on flight mode and try to open a proof photo that somebody sent you last week. If it appears, it was stored on your device. If it does not, it is being fetched from a server every time.
4. Check whether there is a web version. If you can log in from a browser on a computer you have never used before and see your photos, then the server can see them too. That is not a criticism — it is arithmetic.

Test four is the fastest one, and it is also why the honest answer for most apps is not hidden in the policy at all. It is on the marketing page, advertised as a feature.

What PlayNObey does instead

Proof stays on the device that took it. Quests, images, video, personas and the proof itself live in a database inside the app on your phone or computer. There is no upload step, because there is nowhere to upload to.

When two people play together, their devices talk to each other directly. If the other person is offline, the message is encrypted on your device and left with a relay that holds it until they collect it — the relay stores a sealed blob and cannot read it. Exactly three things ever leave a device, and each one is a deliberate act: a message to somebody who is offline, anything you choose to publish to the community, and one daily "this device was used" ping, if you switch it on.

There are trade-offs and we would rather write them down than let you find them.

• Lose the device, lose the data. There is no server holding a copy to restore from. Export what you want to keep.
• A second device gets its own key. Messages sent to your phone cannot be read on your laptop. That is a consequence of the private key never leaving the device, and it will surprise you the first time.
• The relay publishes public keys, so a hostile relay could in principle substitute its own. We show a fingerprint in the chat header and under the QR code so you can compare it out of band.
• The local database is not itself encrypted at rest yet. Someone with your unlocked device can read it. Use your operating system's disk encryption and a screen lock.

The full statement is on the privacy page and it is written as a description of what the code does, not as a policy about what we intend.

Is a local-first app worse to use?

In two specific ways, yes, and they are the ones above: no cloud backup, and per-device keys. In every other way it is the same app, and in one way it is better — it works with no signal, because the thing it is reading is already on the device.

The question is what you want the trade to be. A server gives you recovery and makes photos appear on every device you own. It buys that by holding your proof photos on somebody else's computer, permanently, under terms that can change. We decided that for this particular kind of picture, that price was too high, and built the app so we never have to be trusted with it.

If you want to see the mechanism rather than take our word for it, the relevant code and the privacy statement are the same document — that is deliberate.