Files and people
Files and people
What sits on the service are files that people sent: photos in reviews, video walkthroughs. Everything below is written for their sake, not for form's sake.
What happens to a file on intake
- The type is determined by parsing — from the content, not from the extension and not from what the client says. The output file's extension is ours to assign.
- Virus scan. If the scanner is unreachable, intake
refuses with
503rather than letting the file through: passing a file silently while the check is down is a lie about work done. - Re-encoding. An image is never served the way it arrived.
- Metadata is stripped. EXIF and GPS do not survive the re-encoding.
The coordinates of someone's home in the metadata of a review photo are a leak nobody will notice. It raises no error, reaches no log and breaks no page. That is exactly why stripping metadata is built into the path rather than left to whoever uploads.
SVG is neither accepted nor served
Never, on the way in or on the way out. SVG is executable markup, not a picture: a script lives inside it and will run in the reader's browser on behalf of your domain. The check runs twice — on the content type and on the start of the file — because for SVG the type sniffer often says “text”.
What gets served is only: image/webp, image/jpeg,
image/png, video/mp4, an HLS playlist and its
segments. Everything else is a 415 refusal.
Delivery headers
The delivery host has no sessions, no JavaScript and not a single
Set-Cookie. Files are served by the web server straight from disk
— there is no executable code on that path at all. Content is served with
Content-Security-Policy: default-src 'none'; sandbox and
X-Content-Type-Options: nosniff: even if something dangerous did
get in, the browser would not run it.
Erasing ordinary user uploads
Every object has an owner_ref — whatever you call the
owner of the file. For ordinary catalogue images it is empty: they are not about a
person. For review photos and walkthrough videos it is required. Stock items
may be linked to an author and follow the retention rule below.
POST /api/v1/erase?owner_ref=user-8123
→ { "ok": true, "erased_objects": 14, "files_removed": 31 }The answer names a number, and that is the point of it.
Your personal-data gate should check the execution, not the intent: a row
marked deleted while it still lies on disk is a deletion that did not happen.
So erase removes both records and bytes, the deferred copies of
earlier versions included, and does it at once rather than on a schedule.
If any object under this owner_ref is linked to a Keepix stock item, including a withdrawn item, erase returns 409 asset_in_stock before deleting anything. The original must stay available for existing licences. Keep stock and ordinary uploads under different owner_ref values; account closure needs a separate review.
Logs
The delivery log with readers' addresses is rotated every day and kept in a single copy: no address stays on the machine longer than two days. We do not need it any longer than that for anything, and keeping it longer would be plain accumulation of other people's traces.
Signing keys
A tenant always has two keys in use — otherwise changing a key would mean downtime. The secret is shown once, at issue, and is not handed to the control panel: being able to sign a request is the right to write into someone else's storage.