How Squawk Secret protects what you send

When you create a secret

We generate a random 256-bit key for that one secret and encrypt the text and any files with AES-256-GCM. The key goes into the link after the # symbol. Browsers never send that part of a link to a server, so it doesn't appear in web logs, proxy logs, or referrer headers. We don't store the key anywhere.

Our database holds only the encrypted data and a one-way hash of the link's ID. Someone with a full copy of the database still can't decrypt a single secret without the link.

When it's opened

The recipient's browser presents the key from the link, the secret is decrypted in memory and returned over HTTPS, and the view is counted. When the view limit is reached or the expiration passes, the encrypted data is erased.

For a second factor, add a passphrase and share it another way, such as by phone. Without it, the link alone won't open the secret.

Senders can also turn on screenshot and copy deterrents for a secret. The recipient then presses and holds to view the text, it blurs whenever the window loses focus, it can't be selected, copied, or printed, and the recipient's IP address and the time are watermarked across it. No website can fully prevent a screenshot or a photo of the screen, so we describe this as a deterrent: its real strength is that a leaked capture shows who opened it and when.

Who can open it

Senders can lock a secret to specific email addresses. Anyone opening it must then enter a one-time code we email to one of those addresses, so a forwarded or intercepted link is useless to anyone else. Senders can also limit a secret to certain networks, such as a client's office. Business admins can require these and other safeguards, like passphrases and maximum lifetimes, for their whole team.

Where encryption happens

Encryption and decryption run on our servers, not in your browser. That means the service briefly handles the unencrypted contents in memory at the moment a secret is created and at the moment it's opened. It is never written to disk unencrypted, and the key is never stored. We think you should know exactly where the line is.

Requests

Each request link gets its own key pair (X25519). Responses are encrypted with AES-256-GCM as they arrive, before they're stored, and can only be opened by the person who created the request after signing in. Closing a request erases its responses.

Accounts and access

Passwords are hashed with scrypt and never stored in readable form. Every account can turn on two-step verification with an authenticator app (we don't use text messages for sign-in codes), and Business admins can require it for their whole team. New accounts confirm their email address and mobile number, and a card is required before any plan starts, including free trials, so every account belongs to a real, reachable person. We email you whenever your account signs in from a new device, and idle sessions sign out automatically. You can sign out of every device at once from Settings, and when a Business admin removes someone, that person's sessions end immediately.

Transport and hardening

All traffic uses HTTPS with HSTS. Pages run under a strict Content Security Policy that blocks inline and third-party scripts. Sign-in, reveal, and form submissions are rate limited, and every attempt to open a secret is logged with time, IP address, and outcome.

Payments

Payments are handled by Stripe. Card numbers go directly to Stripe and never touch our servers.

Reporting a problem

If you believe you've found a security issue, email support@squawksecret.com. If you received a link you think is being misused, tell us and we'll destroy it.