Security

This is the user-facing summary. The full engineering detail — exact algorithms, exact database queries, exact test coverage — lives in the project's docs/nullimage/ directory (security-model, threat-model, crypto-spec). Every claim below is paired with what it does not cover — a security document that lists only what works is marketing, not documentation.

What we guarantee

• Your image is encrypted in your browser before it ever leaves your device. We use AES-GCM-256. The encryption key is generated in your browser and is never sent to our server, in any request, ever.
• The key lives only in the link's fragment — the part after #. Browsers never send that part to any server. That is a property of how browsers work, not a promise we're making on top of it.
• We cannot decrypt your image, even if compelled to. We don't have the key, and there is no server-side mechanism that has ever had it.
• We strip EXIF metadata (GPS location, device info, timestamps) from your image before it's encrypted — in your browser, before anything is sent. We never see this data in any form, stripped or not.
• A password, if you set one, is checked before a burn-after-view image is consumed — a wrong guess never destroys your image.
• The database is not the whole story — even someone with full read access to our database and storage cannot decrypt an image, read its real filename, recover a password, or recover a raw IP address. Passwords are hashed (Argon2id); IP addresses are only ever stored as a one-way HMAC used for abuse-rate-limiting, never in reversible form.

What we do not guarantee

• Anyone who has the complete link can view the image. That's not a bypass — it's how the system works. If you send someone the wrong link, or your link leaks, that link works for whoever has it, the same as it works for the intended recipient.
• We can see that an image exists, roughly how big it is, and roughly when it was created and viewed. We cannot see its content. Confidentiality of content is protected; the fact that our service is being used is not invisible to us.
• If you lose the link, the image is unrecoverable. There is no account, no email, no "forgot my link" flow, and no server-held key to recover from.
• We cannot protect you from a compromised device — yours or the recipient's. If malware on either end can read the screen or the clipboard, encryption in transit and at rest doesn't help.

Reporting a vulnerability

Email [email protected] (also served at /.well-known/security.txt). Please include enough detail to reproduce the issue. We ask that you not publicly disclose a vulnerability until we've had a reasonable chance to address it.

What's been tested, concretely

• Every claim above has a corresponding automated test: the full AES-GCM-256 scheme including every tamper case (chunk swapping, splicing, truncation, wrong key), password-bypass attempts, token forgery/replay, id enumeration, path traversal, SQL injection attempts, cache-poisoning, and content-type confusion.
• Concurrency: burn-after-view has been tested under genuinely simultaneous requests and verified to grant exactly one view, never zero, never more than one.
• Cross-browser: the full flow has been verified on Chromium, Firefox, and WebKit, plus mobile viewports on both Chromium and WebKit engines.

What has not been independently verified

• No third-party security audit or professional penetration test has been performed.