How your photos are protected
Audited and written September 24, 2026
A photo is the most personal thing this app touches, so this page says exactly what happens to one after you tap Narrate: how it travels, where it sits, who can read it, and how it is deleted. It was written after checking the live system, not the plan, and it will be updated whenever any of this changes.
The short version
- Your photo only ever travels over encrypted connections.
- It is stored on Amazon S3, encrypted at rest, in a bucket that blocks all public access.
- One AI service reads it to write the narration. It does not train on it and deletes it within 30 days. The voice service never sees the photo at all.
- Only the phone that uploaded a photo can get it back. Deleting it in the app deletes every file made from it.
- It is not end-to-end encrypted. The server has to see the picture to narrate it, and so, in principle, can Mark, who runs the server.
What is kept, and where
Narrating a photo produces up to seven files: the photo itself, the narration audio, the timing of each spoken word, the transcript, the title, and, only if you ask for them, an exported video and an animation. The photo is re-saved as a plain JPEG on the way in, which strips the metadata your camera embeds, including the location it was taken, the device, and the time.
All seven live in one Amazon S3 bucket in the United States. The bucket encrypts everything at rest with AES-256, blocks every form of public access, has no per-file permissions that could be loosened by mistake, and keeps no old versions, so a deleted file is gone rather than hidden.
The database on the server holds your phone's random identifier and the IDs of its files. It holds no photos. It is backed up nightly to the same encrypted bucket and each backup is deleted after seven days.
In transit
Between your phone and the server, and on this website, connections use TLS 1.2 or 1.3 with a Let's Encrypt certificate. Older protocols are refused, plain HTTP is redirected, and browsers are told to remember that. Between the server and Amazon, Anthropic, ElevenLabs and fal.ai, every connection is HTTPS.
Who else sees your photo
| Service | What it receives | What happens to it |
|---|---|---|
| Anthropic (Claude) | The photo, sent as image data inside the request, plus the narrator's instructions. It writes the narration and the title. | API data is not used to train models and is deleted within 30 days. Anthropic's privacy center. |
| ElevenLabs | The narration text only. It never receives the photo. | It turns the text into the voice. ElevenLabs' privacy policy. |
| fal.ai | Only if you animate a photo: a private link to it that expires after one hour, plus the motion prompt. | It makes the clip, which we copy into our own storage. fal keeps request records for 30 days and generated clips on its network for about seven. fal's privacy policy. |
| Sentry | Error reports from the server when something breaks. | Never a photo. Reports can include your phone's IP address and request headers. |
| Amazon Web Services | Everything: it hosts the server and the storage. | Amazon's staff do not have access to the bucket's contents in normal operation. |
On the server
The server is one small Ubuntu machine on AWS. While a photo is being narrated it exists in memory; while a video is being exported it is written to a temporary file and deleted when the export finishes. Logins to the machine require an SSH key, password login is off, and repeated failed attempts are banned automatically. The server's own disks are not yet encrypted.
Getting files back, and deleting them
Every file is tied to the phone that made it. A request for a file from a different phone, or with no session at all, is answered as if the file did not exist. There is no public sharing any more; the old website's share links stopped working when it was retired.
Deleting a photo in the app removes all seven of its files from storage and the record from the database in one step. Because the bucket keeps no versions, that is final. A database backup can keep the record ID, not the photo, for up to seven days.
What this is not
It is not end-to-end encryption. The narration is written by a model that has to look at the picture, so the server and Anthropic both see it unencrypted while they work. Mark holds the keys to the storage and could read what is in it; the promise is that he does not, not that he cannot. The one shared access key lets a phone use the app; it does not unlock any other phone's photos, because each phone's files are tied to its own identifier. Treat it like a house key all the same.
Found and fixed on September 24, 2026
Checking the live system for this page turned up two real problems. Both were fixed the same day.
- The route that serves files checked ownership for photos, audio, timings and transcripts but not for titles, exported videos or animations, and it would also hand the nightly database backup to anyone who guessed its file name. Server logs, which go back to September 10, show these paths were only ever reached by our own test during this audit. The route now serves only the seven file types, only to the phone that owns them.
- Deleting a photo removed four of its seven files; the word timings, the exported video and the animation were left behind. It removes all seven now.
- Eight photos from testing in December 2025 were found as leftover copies on the server's disk, outside storage and the database. They were removed.
Questions, or something you think is wrong here: dchattenborough@gmail.com.