Privacy & Security Policy

cryptoscreen Privacy & Security Policy

cryptoscreen is designed for one-time encrypted messages. The note is encrypted on the sender device before upload. The service is designed not to receive plaintext, raw image bytes, PINs, decryption keys, contact lists, or account profiles.

What the server cannot read

The server stores ciphertext and encrypted attachment bytes only. The decryption secret is kept in the URL fragment after #s=, which browsers do not send to the server in normal HTTP requests. The six-digit PIN is entered locally and is not stored by the service.

What the service stores to make messages work

The production API stores encrypted message bytes, nonce, tag, salt, read policy, expiry time, failed attempt count, and a server-peppered PIN verifier. When a sender attaches an image, the service stores encrypted image object bytes in private R2 storage plus encrypted attachment metadata in Neon. User message rows and attachment metadata are deleted after a successful read, after the third wrong PIN, or after expiry cleanup. Unused user links expire after 30 days.

After a successful read with an image attachment, the app downloads the encrypted image bytes through a short-lived one-time read session. The R2 object is deleted after that one-time download. Expired attachment objects and read sessions are deleted by scheduled cleanup.

Status data and telemetry

cryptoscreen does not use ad SDKs, tracking SDKs, third-party analytics SDKs, or contact upload. There is no account profile.

One-time links necessarily reveal some delivery state. If a link no longer opens, the sender or recipient can infer that the message was already opened, expired, destroyed after wrong PIN attempts, or manually expired by the sender. This is part of enforcing one-time reads and does not require telemetry opt-in.

To support one-time deletion and the optional sent-message list, the service keeps minimal delivery-status metadata for a message id: whether the text was consumed, whether an encrypted image attachment existed, whether that image was consumed, whether the row expired or was destroyed, and whether a screenshot event was reported. This status metadata does not include plaintext, image plaintext, PINs, link secrets, sender identity, recipient identity, or contact data. Delivery-status metadata is deleted by scheduled cleanup after it has been inactive for about 30 days.

Interaction status sharing is opt-in in the app's Privacy settings and works reciprocally. If it is off, the app does not send optional read or screenshot status and does not fetch or show detailed interaction status for messages you sent. If it is on, you can see detailed interaction status only when the reader also shared interaction status from their app. Screenshot reports contain only a generic screenshot event and timestamp for that message. Screenshot detection is best-effort: iOS reports normal screenshots after capture, modified clients can omit reporting, and external cameras cannot be detected.

The service also keeps an aggregate count of how many sealed messages have been shared. That counter does not include message content, recipients, senders, or link secrets.

If you send feedback from inside the app, the service sends your written feedback anonymously to the maintainer with the app version/build, platform, rating, and timestamp. Feedback does not include your account, contacts, sender or recipient identity, sealed message content, image content, PINs, full links, or link secrets.

App Store data

Apple separately processes App Store downloads, crash diagnostics, reviews, and any App Store support interactions under Apple's own terms. This is Apple platform infrastructure, not a cryptoscreen tracking SDK.

Operational data

Cloudflare, Neon, and Cloudflare R2 provide the infrastructure for the public site, API, database, and encrypted attachment storage. They may process standard infrastructure logs needed to operate, secure, and debug the service. cryptoscreen application logs must not intentionally include plaintext, PINs, proofs, full message links, or raw image data.

Limits

cryptoscreen cannot stop a recipient from photographing the screen with another device, using a compromised device, or saving content after it is legitimately displayed. The product promise is narrower: the service is designed not to be able to read your message content, and normal message rows are one-time by default.

Contact

For privacy requests, use the contact address on the support page.