How Squawk Secret protects what you send

End-to-end encrypted in your browser

Squawks you create in Squawk Secret are encrypted in your browser before anything is sent. Your browser generates a random 256-bit key for that one squawk and encrypts the text and each file with AES-256-GCM. Only the encrypted data reaches our servers. The key goes into the link after the # symbol, which browsers never send to a server, so it doesn't appear in our systems, web logs, proxy logs, or referrer headers.

When the recipient opens the link, their browser decrypts it. To count views and enforce passphrases, the recipient's browser sends a proof derived from the key, never the key itself; we store only a one-way fingerprint of that proof. We can't read your squawks, and neither could anyone who copied our database or our servers.

When the view limit is reached or the expiration passes, the encrypted data is erased.

Because encryption happens in your browser, we can't inspect the contents of attached files. We still block dangerous file types by name, and your browser checks files for programs before encrypting them.

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 squawk.

Senders can also turn on screenshot and copy deterrents for a squawk. 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.

The API

Business teams can send squawks from their own systems with API keys. Keys are stored only as a one-way hash, can be limited to specific networks and permissions, and are logged on every use. The API can create, check, and destroy squawks but can never read one back, so a leaked key can't be used to collect passwords. Webhook notices are signed and never include a squawk's contents or link.

Who can open it

Senders can lock a squawk 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 squawk 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.

For subprocessors, data retention, certifications, and how to report a vulnerability, see our Trust center.

Where the line is

We think you should know exactly what we can and can't see.

Emailed links. If you ask Squawk Secret to email a link for you, the link, including its key, passes through our mail system to reach the recipient. It is never stored. For full end-to-end protection even then, add a passphrase and share it another way, such as by phone: we never see the passphrase.

Healthcare and HIPAA (coming soon). On the Healthcare plan we sign a Business Associate Agreement with you, and HIPAA safeguards are enforced for your whole organization: two-step verification, a 15-minute idle sign-out, recipient-locked links that last at most 7 days, no AI assistant, and access records kept six years. Patient information stays in the end-to-end encrypted parts of the service, which we can’t read.

Certificates of Delivery. A certificate lists who sent what (file names, sizes, and SHA-256 fingerprints taken in the sender’s browser), the protections used, and every attempt to open it. We sign it with an Ed25519 key whose public half is published, and keep the signed facts, so anyone can check a certificate at its verification link. It never contains the contents, and text is never fingerprinted.

Two-person secrets. With “two people together,” the key is split between two links; each half on its own is random noise. To open it, one person’s browser sends their half, encrypted to the other person’s screen, through us. We only ever relay it sealed, and we never email these links, so we never hold both halves and can’t open it. With “require approval,” our servers hold back the encrypted content until a named teammate approves.

Squawk Guard. In Outlook, the check for passwords, card numbers, and similar runs inside Outlook on your computer; the email isn’t sent to us. In Teams, where the app is added to a channel or group chat (with its owner’s approval), each message is checked on our server in memory, never stored or logged; a warning names only the kind of information found.

Links sent in Microsoft Teams. When you use the Teams app’s message-box buttons, your secret is encrypted in the Teams window like anywhere else, but the finished link, including its key, passes through our server and Microsoft’s to become the card in your chat, and it stays in that chat, as a link would in an email. It is never stored by us. The same passphrase advice applies.

Squawk Drop file sizes. File names, types, and contents are encrypted, but we can see how large each file is and when it arrived, because storage needs to know.

Who joins a secure chat. We confirm each guest by a code sent to their invited email address before their browser can receive the chat's key. That means you rely on us to check who a guest is: everyone in a chat, and when they joined, is shown to its hosts, so an unexpected participant would be visible.

The API. Squawks created through the API are encrypted on our servers, because your system sends us the contents to protect. They are encrypted immediately, never written to disk unencrypted, and the key is never stored.

Requests

Requests are end-to-end encrypted too. When you create one, your browser generates a key pair for it. The public key goes to us so responders' browsers can encrypt to it; the private key stays in your browser and in a private link you save. Each response is encrypted in the responder's browser with its own key (ECDH P-256 and AES-256-GCM) before it's sent, so we store only data we can't read. You read responses in the browser that created the request, or anywhere you open your private link. If you lose both, no one, including us, can recover those responses. Closing a request erases them.

Forms and fillable PDFs

Intake form answers, typed signatures, and files attached to fields are part of the encrypted response. For fillable PDFs, the responder's browser fills in the form, locks the fields, and adds a signature record page, then encrypts the completed PDF before it's sent. We store the blank form so it can be shown to responders; it holds no answers.

Squawk Drop

A Squawk Drop gives your team one page where clients can send you information and files at any time. A Business account can have up to 10, and each has its own key pair: the public key lets senders' browsers encrypt to it, and the private key stays in the browsers of the people allowed to open that box and in a recovery link you save. Each browser has a key pair of its own; when someone is added to a Squawk Drop, a teammate's browser that already holds the box's key seals a copy to the new browser's public key, so the key passes between your team's browsers and we only ever store sealed copies we can't open. The receiving browser checks that the key really is that box's key before using it. We give a box's encrypted items only to the people listed on it, and removing someone stops that immediately and deletes their sealed copies. Files are encrypted in the sender's browser in 8 MB pieces, each bound to its file and position, and uploaded straight to encrypted storage, up to 2 GB per submission. File names are encrypted too. You can limit a Squawk Drop to approved senders, who confirm their email with a code, and choose how long items are kept, up to a year.

Squawk Vault

Squawk Vault is long-term storage that only its owner can open. Your browser makes a random vault key and seals it twice: once with a key derived from your passphrase (PBKDF2-SHA256, 600,000 rounds, with a random salt) and once with your recovery key. We store only those sealed copies; the passphrase and recovery key never reach us. Each file gets its own random key, sealed with the vault key, and is encrypted with AES-256-GCM in 8 MB pieces in your browser before it is uploaded straight to encrypted storage. File names and types are encrypted with the file's key too, and folder names with the vault key, so we see only sizes and dates. Admins of your organization have no access to anyone's vault. There is no back door: if a passphrase and its recovery key are both lost, the files cannot be decrypted.

Squawk Keeper

Squawk Keeper has its own lock, separate from Squawk Vault: a random key made in your browser and stored only sealed, once with a key derived from your keeper passphrase (PBKDF2-SHA256, 600,000 rounds) and once with your keeper recovery key. Each entry has its own key, sealed with that one, and its contents, including any authenticator key, are encrypted with AES-256-GCM in your browser. We see only sizes and dates.

A shared folder has its own random key, and a copy of it sealed to each member's public key. Each person's keeper holds an ECDH P-256 key pair for this: the public half is stored openly so teammates can seal a folder key to them, the private half sealed with their own keeper key. The server never holds a usable copy, so it cannot read a folder's name or anything in it, and neither can an administrator who is not a member. Only someone already in a folder can share it.

An account owner may turn on an organization recovery key so that a shared folder is not lost when everyone who held its key has left. It is a key pair made in the browser from a recovery key shown once: the private half is stored sealed with that recovery key, so the stored copy is useless without it. Each shared folder key is also sealed to it. While it is on, everyone in the organization is told, in the app, that shared folders can be recovered by whoever holds it. It covers shared folders only: personal entries are never sealed to it, and nobody but their owner can read them. Using it is recorded, and everyone in the folder is emailed. Removing someone from a shared folder stops us giving them that folder, but does not change the passwords in it.

The browser extension decrypts in the browser too. It is connected with a code that lasts five minutes and works once, and the token it receives can only read your sealed keeper entries and save new ones; it cannot reach anything else in your account. Your keeper key is held in the browser's memory, never on disk, and is thrown away when the extension locks or the browser closes. The extension decides which saved login belongs to a page on your own computer, so the sites you visit are never sent to us. Squawk Keeper is in beta.

Secure chats

Each secure chat has its own random key, created in the host's browser. Every participant's device has its own key pair, and receives the chat key sealed to that device alone, handed over by a device that already has it. Messages, masked credentials, and files are encrypted with the chat key, so we relay and store only encrypted data. Guests confirm their invited email address with a code, and hosts can also require a passphrase they give guests another way. When a chat is closed or reaches its time limit (at most 7 days), its messages, files, and keys are erased for everyone; we keep only a record of who joined and when. Removing a guest stops their access to new messages, but not to what they already saw.

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. Business teams can sign in with Microsoft 365, Google Workspace, or Okta; we match each company by its Microsoft tenant, Google Workspace domain, or Okta domain and a DNS-verified email domain, never by email address alone. 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 squawk 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.