Security

The short version

Pocket Archive is a pipe, not a warehouse. Your audio, transcript and summary move from HeyPocket through a Cloudflare Worker into cloud storage you already own, and are held only in memory for the seconds that takes. We keep the credentials needed to do that, and a small cache so the dashboard has something to show. All of it is encrypted with a key our database does not hold.

• ✓ Your recordings are never written to our storage. Not the audio, not the transcript, not the summary. They stream through and land in your own Drive or OneDrive.
• ✓ On Google Drive we cannot open a file we did not create. That is enforced by Google, not promised by us, and you can confirm it on your own Google account page.
• ✓ Everything sensitive we do keep is encrypted under a key held in a Worker secret, separate from the database that holds the data.
• ✓ Deleting your account revokes our access and erases our copy. The files already in your cloud are yours and are left alone.

What we can see in your cloud storage

This is the question worth asking of anything that connects to your Drive, and the two answers are not the same. We would rather you read the difference here than discover it later.

Google Drive — narrow, and enforced by Google

We request drive.file and nothing else. That scope lets an app open only the files it created itself. Your existing documents, photos and folders are not merely off-limits by policy; they are invisible to our access token. If we wanted to read them, the request would fail at Google.

Confirm it yourself: Google Account → Third-party apps lists Pocket Archive and the exact access you granted, and revokes it in one click.

OneDrive — broader, and we would rather say so

Microsoft Graph has no equivalent of drive.file for a folder you choose. To create and write the Pocket Archive folder in your OneDrive we request Files.ReadWrite, which grants read and write access to your OneDrive as a whole.

We use it only to create our own folder and write your recordings into it, and nothing in the code reads anything else. But that is us telling you what our code does, which is a weaker guarantee than Google's, and we are not going to dress it up as the same thing.

Microsoft does offer a narrower Files.ReadWrite.AppFolder scope, which would confine us to a dedicated app folder. Moving to it would relocate existing users' archives and require everyone to reconnect, so it is a change we will announce rather than spring on you. If you would rather have the narrower permission sooner, say so — that is useful signal. You can review or revoke this at any time at Microsoft My Apps.

Everything we store

Not a summary — the actual list, including the two entries that have nothing to do with syncing. "Encrypted" means AES-256-GCM under a key held in a Worker secret, which is not readable from the database, the dashboard, or any API.

The action items, folder names, participant names and recording list are the ones people are surprised by, which is exactly why they are listed. They are derived from your meetings, we cache them so the dashboard can render without calling HeyPocket on every page load, and they are encrypted for that reason.

What never reaches our storage

Audio files, transcripts and summaries are streamed from HeyPocket through the Worker and into your cloud storage within a single request. They exist in memory for the seconds that takes and are never written to a disk we control. There is no bucket of your recordings to steal, subpoena, or accidentally leave public, because there is no bucket.

We also never receive your Google or Microsoft password. Sign-in happens on their site; we are handed a token afterwards and never see the credential behind it.

If we were breached tomorrow

Most security pages will not write this section. It is the most useful one, because "we take security seriously" tells you nothing about what you would actually lose.

If someone got our database, and only that

They would get a list of email addresses, plan and usage figures, and ciphertext where the tokens and cached content are. No recordings, no transcripts, no summaries, no readable action items, and no working access to anyone's Drive. The decryption key is not in the database.

If someone got the database and our Worker secrets

Then they could decrypt the tokens and write to, and on OneDrive read, connected accounts. This is the real worst case and we are not going to pretend it away. What limits it: on Google Drive the token still only reaches files we created, so the rest of your Drive stays out of reach even in this scenario. And revoking our access at Google or Microsoft cuts it off immediately and without our involvement.

What we would do

Notify affected users by email with what we know and when, revoke and rotate every credential we hold, and publish what happened. Encryption keys can be rotated without downtime; connected accounts would need to be reconnected, and we would say so plainly rather than letting syncs fail quietly.

Encryption, specifically

In transit. TLS 1.3 everywhere, with HSTS set to two years and preload, so after one visit your browser refuses to speak plain HTTP to this domain at all. Nothing here is served over an unencrypted connection.

At rest. Every sensitive field is sealed with AES-256-GCM under a 256-bit key that lives in a Cloudflare Worker secret. Worker secrets are write-only: the dashboard shows them masked and no API reads them back. Our database is encrypted by Cloudflare too, but that key is Cloudflare's, so on its own it does not protect you from us or from anyone who reaches our account. This second layer does.

Each field gets its own random nonce, so two identical values never produce the same ciphertext and nothing can be inferred by comparing them.

Each ciphertext is bound to the exact record and field it belongs to. It is not enough to hold an encrypted token; it only decrypts in the one place it was written. Copying a sealed token from one account into another — a real attack, and the obvious one against a design like this — produces a value that will not open. There is a test that performs exactly that transplant and asserts it fails. To be precise about the limit: this stops a ciphertext being moved somewhere else, not an old ciphertext being put back where it came from. Someone holding a database backup could restore a credential to the record it was taken from. Revoking our access at Google or Microsoft ends that, since it invalidates the credential itself rather than our copy of it.

Keys can be rotated without downtime. The previous key stays available for reading while a scheduled job re-encrypts records onto the new one, after which the old key is destroyed.

Proving a webhook is real

A webhook endpoint that accepts anything is a way to feed you forged data. Ours does not. Every delivery must carry an HMAC-SHA256 signature computed with a secret unique to your account, plus a timestamp. Missing signature, missing timestamp, or a signature that does not verify, and the request is rejected before anything is read. Failing closed is the default, not a setting.

Deliveries are also deduplicated, so a replayed request cannot cause a second upload or a second charge.

Sessions and sign-in

We never see or store a password. You sign in with Google, and we receive a token afterwards. Your session is an HMAC-SHA256 signed cookie that expires after 24 hours and cannot be altered without invalidating the signature. Admin access is separate, and the admin console shows only whether a credential is present, never its value.

Enhanced transcripts and AI

Enhanced transcripts are optional and paid, and nothing below happens unless you ask for it on a specific recording. Your ordinary syncs never touch any of this.

Step one, transcription. The audio is transcribed with speaker separation by a Deepgram model running on Cloudflare's own infrastructure, in the same edge network as the Worker. The audio is not sent to a third-party API for this.

Step two, naming the speakers. To work out which speaker is which, we send a sample of the conversation to Anthropic's API — never the whole transcript. The sample is up to eight turns per speaker, plus up to forty lines that look like they mention a name, each one truncated. Those are where the evidence for who is who actually lives. The model returns a mapping from speaker numbers to names and nothing else — it never rewrites the transcript body, so it cannot put words into your meeting that were not said.

Your original transcript is never modified. The enhanced version is written alongside it in your own storage.

Anthropic does not train on data submitted through its API. If you would rather no part of a conversation leave Cloudflare's network, do not use enhanced transcripts; ordinary syncing is unaffected.

Who else touches your data

The complete list. If a company is not here, your data does not reach it.

Deletion and retention

You can delete your account yourself from your profile page. You have to type your own email address to confirm, so a stray click — or a link someone talked you into following — cannot wipe your account.

Deleting cancels any subscription first, so a closed account cannot keep charging your card. It then hands your Google authorisation back to Google, which invalidates our access immediately, and removes our records.

Your recordings are not touched. The files in your Drive or OneDrive are yours. We delete our records, not your archive.

A 30-day window to change your mind. For 30 days, signing in again restores the account. After that the archived copy expires and is gone. If you want it gone immediately rather than in 30 days, email us and we will purge it.

Two caveats worth stating. Microsoft has no equivalent one-call revocation, so if you connected OneDrive, revoke it yourself at Microsoft My Apps. And a line recording that an account was created, deleted or restored, with its email address, is kept about 13 months — an audit trail that disappears with the account is not an audit trail.

Verify this yourself

Everything below is a third party checking us, not us describing ourselves. That is the only kind of assurance worth much.

• • Scan our HTTP security headers — content security policy, HSTS, framing and referrer rules, graded independently.
• • Mozilla Observatory — a second opinion on the same, from Mozilla.
• • Qualys SSL Labs — our TLS configuration and certificate chain.
• • Your Google permissions — see the exact access you granted us, in Google’s words, and revoke it in one click.
• • Your Microsoft permissions — the same for OneDrive.
• • /.well-known/security.txt — our machine-readable disclosure contact, per RFC 9116.

Open the folder we create in your own Drive and look at it. Everything we produce is a plain audio file and plain Markdown, readable without us, and portable the day you stop paying us.

What we do not claim

A page that only lists strengths is sales copy. These are the limits, stated by us rather than found by you.

• We are not SOC 2 or ISO 27001 certified. Those are audits costing tens of thousands of dollars and months of calendar time, and Pocket Archive is a small independent product. Anyone displaying a trust seal has usually bought a scan, not an audit. We would rather give you specifics you can check than a badge you cannot.
• This is not end-to-end encrypted. We hold the key that decrypts your tokens, because the service has to use those tokens to write to your storage while you are asleep. A product where we could not decrypt them would be a product that could not sync. That is the trade, and you should know which side of it you are on.
• Your email address is stored unencrypted. It is the index we look accounts up by. Encrypting it would break sign-in.
• On OneDrive our permission is broader than we would like. See above. We are not going to bury it.
• We depend on other companies. HeyPocket, Cloudflare, Google, Microsoft, Stripe, Anthropic and Resend each have their own security posture, and ours cannot exceed theirs. The subprocessor list above exists so you can judge them yourself.
• We have no bug bounty. We cannot pay for findings yet. We will credit you, respond quickly, and never threaten a researcher who reports something in good faith.

Reporting a vulnerability

Email security@pocketarchive.us. We aim to acknowledge within 72 hours and to tell you what we found and when it is fixed. Test against your own account only, and please do not run automated scans that would degrade the service for other people.

We will not pursue legal action against anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before going public.

Machine-readable version: /.well-known/security.txt