Project SEEN - Technical & Ethics
Covering the gap between what feels like it's happening and what is technically happening.
The Model
The app does not send files. It "advertises" condensed file packets to the server, and the server decides if it can accept them.
A condensed file is not your file. It is a small, degraded representation of your file--enough to convey presence, not enough to convey the file's full content or context. This is for storage purposes; for most files, witnessing the <5% size version is plenty for interpreting it. So the server receives this packet. If it accepts, the condensed version is stored briefly and entered into the artist's view. The original file stays on your device.
The artist however can request for the full file resolution anyway. If possible (i.e. barring file size limitations), the app will send over that full file version on the next transmission. The most likely reason is for getting videos and audios, where a lot of information is missing by only getting the condensed preview. A full-res file doesn't mean it won't be deleted, that'd be archiving and participants are notified separately for when a file is archived.
I acknowledge that psychologically, participants will feel as though the full file was sent for every file. That feeling is part of the experience and this page isn't meant to talk you out of it. This page exists to ensure the technical reality is also fully understood.
The artist's view page is an interactive version to discover much of the information that will convey what a condensed file means and the data that comes with it, but here it'll be streamlined.
Condensed file contents
Images
The image is resampled and compressed into a single square thumbnail at max 300px wide. Objects and faces are recognisable at most, detail is largely lost. A selection of metadata fields (see table below).
Video
Five square thumbnails extracted from frames across the video's duration. No audio nor motion. The same 300px constraint per frame. The selection of frames is every 20% through the video, or less frames for short videos.
Audio
No preview. Not even a waveform. The artist receives only the file name and available metadata. The content of an audio file is entirely inferred from what the file name and metadata.
Metadata
| Field | Notes / Examples |
|---|---|
| File name | i.e. "20260623_191546.jpg" or "Screenshot_20260623_191546_Discord.jpg" |
| File type / extension | i.e. "image/jpg" or "video/mp4" |
| File size | The original file size, not the condensed file. i.e. 2.94 MB |
| File location | The folder it came from, i.e. Camera, Screenshots, Downloads |
| Date created | Day and time the photo was taken, for example |
| File-dependent info | Video and audio include duration, i.e. 46.3s; image and video include resolution i.e. 1080x1920 |
| Media ID, Device ID, Ad ID | Used server-side to know the sender anonymously. |
| File hash (for deduplication) | Used server-side to reject repeat advertisements. |
Personally identifying metadata is deliberately ignored, such as GPS and device model/version. It's worth knowing this is the exact metadata corporations want when you upload your files to their servers; haphazardly leaving location data on your Instagram post is exploited as advertising gold. This is also a project inextricably about our surveillance world, after all.
MediaStore
If you're wondering how the app finds your files, Android has a handy functionality called MediaStore that indexes every file you see in your gallery. If you can see it in your Gallery, that is because MediaStore jotted it down.
When you grant full media permissions, you're letting the app read all of the indexes in MediaStore. In essence, if you can see it in your gallery, the app can send it to the artist. Files that only exist in other apps (not the Gallery), especially such as a secure folder app, are not going to be sent. Files in the trash are not going to be sent either.
These are all MediaStore rules. The app physically cannot look anywhere else without full storage permissions, which it doesn't want and cannot have.
Syncing
"How does the app sync in the background?" Another Android feature called WorkManager does exactly as it sounds, the app tells Android to run some code after X time, and when X time passes, as long as the app is in the background and you're on wi-fi, it will sync (otherwise, it'll sync later as soon as it can). "Background" in this case means even if the app is closed, as long as it was scheduled at one point, Android can wake it up through its WorkManager on schedule to do a sync, and it'll stay in the background. The only time this may fail is when restarting your phone, the app might not schedule and opening it once will allow it to schedule a sync.
The default sync interval for the app is 4 hours, and I recommend doing less than 6 hours to get frequent read receipt updates, but you can set the interval anywhere between 15 minutes and 24 hours. 15 minutes is the minimum time you can schedule with WorkScheduler. Due to how finicky scheduling gets, it has to finish a sync before it takes into account a new time, so if you're going from 24 hours to 15 minutes, you will likely need to wait 24 hours the first time. The file count isn't the same way, you can change this between 1 and 50 files sent per sync and it will always be responsive.
Besides transmitting files, a sync will fetch the read receipts from the server (which is why going for a lower sync interval is better for feedback), but only reads them 4 times a day. Checking several files can be a lot of requests so I rate limited it, here's how read receipts work: the app keeps a list of files it knows haven't yet been deleted, and asks about their status up to 4 times a day. If a file was seen and rejected, requested, or archived, it updates during this sync to be seen at the time stamp it was discovered. If the app has a file on their list that isn't on the server, the app knows the file was deleted from the server since last time and marks it deleted locally.
Third Parties
Many files will contain people other than the participant: photos of friends, family, strangers. Screenshots of conversations. These people have not consented to this project.
I do not have a solution to this. What I have is an honest posture: the artist treats all content, including content involving third parties, with the same deletion-first approach. The condensed format limits what is legible. Witnessing is the act, not archiving.
If you are uncertain about a file involving another person, you can delete it from the server at any time.
Server Authority
For starters, this server is hosted on Oracle's Cloud servers. Only I, the artist, have access to the server and the artist panel.
The server is not passive. It can reject an "advertised" file, usually if it's already seen it before, or it is insanely big. It can suppress a file hash permanently, so that file is never accepted again even if re-advertised. It can ban a device entirely, ending that device's participation, which is particularly useful for helping people who indeed want to withdraw.
This is a side-effect of the project, the cost of connecting people is propping up these awkward constraints and relying on the systems to manage it so we can truly focus on each other. The server is the authority in this relationship; not the artist, not the participant. You are sending files to a person, but the app is "advertising" files to a server that only accepts it if it matches its heuristic; so, to humanize it again: if it's being truthful. And the app, being an unfeeling thing too with its own heuristics, always tells the truth the server wants to hear, which is why it won't get in the way of us. It's impossible to have your files rejected before transmission unless you try or accidentally lie to the app by using it in an unintended way. I just wanted to be transparent about this element, and because I think it's mildly fascinating.
Sort order
When files arrive in the artist's view, they are sorted by newest-first but can be sorted by a kind of relevance score. Higher-resolution files score higher (though files get compressed, it makes a huge difference in previews). Files originating from your camera folder score higher than screenshots or downloaded files.
This affects the order in which files are seen, not whether they are seen. Every accepted file will eventually be reviewed, the score only determines where it appears in the queue. It is worth being transparent about this because it means I'm more likely to encounter camera photos before screenshots, and sharper images before compressed ones. The uncurated nature of the project is real; the order in which the artist moves through it is not entirely random. I can also sort by what expires soonest (so, files getting auto-deleted by the 30 day mark soon).