Security

Security and data handling

The strongest security property of this application is architectural: your screenshots never leave your Mac, so there is no server holding them to be breached.

What is actually done

Signed and notarizedEvery release is signed with an Apple Developer ID, built with the hardened runtime enabled, notarized by Apple and stapled — so Gatekeeper can verify it even with no network. A release script refuses to publish a build that fails any of those four.
Updates are signed twice overSparkle verifies an EdDSA signature over the downloaded archive against a public key compiled into the app, on top of the code signature. An update that is not signed by our private key will not install, whatever the server says.
Updates never run on their ownThere is no background update check and no schedule. The app contacts the appcast only when you press Check for Updates.
The licence key lives in the KeychainIt is written to the macOS Keychain after activation and never to logs, preferences or the database.
Optional encryption for recognized textAES-GCM over the extracted text and word positions, with the key generated on your Mac and held in the Keychain. Off by default, because it costs you plain-file inspectability.
No secrets to leakThere are no accounts, no passwords, no tokens and no server-side copy of your library. The most valuable thing a breach of our infrastructure could yield is a list of email addresses and licence keys.

The two servers that exist

The whole remote surface is an update feed and a licence check. Both are listed on the status page, and both are user-initiated:

  • https://updates.screenshotinbox.com/appcast.xml — a static signed update feed. It stores nothing about you.
  • https://api.screenshotinbox.com — verifies a licence key once, at activation.

If both were taken offline permanently, an installed copy would keep working indefinitely. That is the intended failure mode.

What we are honest about

Screenshot Inbox is not sandboxed. Watching your screenshot folder and moving files out of it are exactly the things the App Store sandbox forbids, so the app ships directly instead, with notarization rather than sandboxing as the containment story. The trade-off is stated here rather than buried, because it is a real one.

The application is also not a backup system. It is careful — destructive actions are proposed and confirmed, removals go to a recoverable Trash — but keep backups regardless.

Encrypting the recognized-text index does not encrypt your screenshot images. For whole-disk protection, FileVault is the right tool and this setting is not a substitute for it. See Encrypting the index.

Verifying a build yourself

Every release publishes a SHA-256 checksum on the download page. Beyond that, on any Mac:

codesign --verify --deep --strict --verbose=2 /Applications/Screenshot\ Inbox.app
spctl --assess --type execute /Applications/Screenshot\ Inbox.app

The first confirms the signature is intact, the second that Apple's notarization is recognised. To confirm the network behaviour rather than take our word for it, run a network monitor and use the app normally — the Privacy page describes the test.

Reporting a vulnerability

Write to support@screenshotinbox.com with Security in the subject. Please include enough detail to reproduce it. You will get a human reply within three working days.

  • We will not threaten legal action against anyone who reports a flaw in good faith and does not exfiltrate other people's data.
  • We will tell you when it is fixed, and credit you in the changelog unless you would rather we did not.
  • There is no paid bounty programme. Saying so is fairer than implying one.

Incidents

If a breach ever affected data we hold — the licence and support records listed in the privacy policy — we would email the people affected and post the detail in the changelog. There has been no such incident as of 1 September 2026.

Contact

Udaan Technologies Pvt. Ltd. — support@screenshotinbox.com

Last updated 1 September 2026 · current release 0.1.0