How PassbackAI handles your data

(Short answer: it doesn't.)

The whole thing in one paragraph

PassbackAI is a browser-only review surface for LLM responses. When you paste an answer, review it, mark it up, and copy the export, none of it touches a server — the review tool and the browser extension keep your content in your browser. Your copied text moves from one tab in your browser to another tab in your browser, in RAM, and is cleared the moment the destination tab receives it. Nothing about you and nothing about your content leaves the machine you're sitting in front of — unless you take one of two deliberate, opt-in actions, and the two are not the same. Share by private link and your browser encrypts the document first, uploading only ciphertext; the key that opens it stays in the link's # fragment and never reaches us, so what we store is end-to-end encrypted and we can't read it. Route a document to a reviewer through your connected AI and it's stored on our backend under server-managed keys instead — encrypted at rest, but not zero-knowledge: Claude needs the plaintext, so we can read a routed doc. Those are the only two exceptions, and you trigger each yourself. The website also sends anonymous usage events to Vercel Analytics — page views, and aggregate counts like "a comment was added" or "export was copied" — but never the document, never the annotations, never anything you typed.

That paragraph is the whole product, and it's the whole privacy model. The rest of this page is just the cost of you not having to take our word for it.

What runs where

Two small content scripts run on every webpage you visit. They have to, because the value of PassbackAI is detecting when you copy a long response on any LLM chat — Claude, ChatGPT, Gemini, Perplexity today, and whatever launches next. We can't pre-list every chat tool that hasn't been invented yet. So the scripts run everywhere, and they do exactly two things:

1. The first script wraps navigator.clipboard.writeText — the function any web page calls when it puts text on your clipboard. When that function is called with a string longer than 300 characters, the script forwards the text to the rest of the extension and lets the original write through unchanged. The whole thing is about a kilobyte.
2. The second script listens for the copy event (you pressing ⌘C on a selection) and reads the same selection — same 300-character threshold. If the threshold is hit, it shows the toast you see in the bottom-right corner.

Neither script reads anything else from the page. Not the URL beyond location.hostname. Not your form input. Not your cookies. Not the rest of the DOM. Not your scroll position. Not the content you didn't copy.

What happens to your copied text

When you click "Review" on the toast, the extension opens passbackai.com in a new tab and hands the text to that tab through the browser's normal page-injection mechanism. The handoff is the only moment the extension and the passbackai.com tab talk to each other. The extension's in-memory copy of the text is cleared the instant the passbackai.com tab acknowledges it. passbackai.com itself runs entirely client-side: your annotations live in your browser's localStorage, on your machine, and nowhere else.

If you don't click "Review" — if you let the toast time out, or click ✕ — the captured text is dropped on the floor and never leaves the source tab.

The only thing PassbackAI remembers

One boolean per origin: whether you've clicked ✕ on the toast on this site. If you have, the toast stays quiet on that site for the rest of your browser session, then forgets. That's the entire persistent state of the extension.

We don't store: your copied text, your refined prompts, your annotations, your IP address, your browsing history, your tab state, your account (because there is no account), or which LLMs you use most. In the review tool, none of that touches a server. Vercel Analytics does aggregate page-view frequency and usage counts — cookieless, no fingerprinting — but those numbers are never tied to you or your content. (The server-side features — document routing and private-link sharing — are opt-in and only ever receive the document you choose to send: routing keeps a copy we can read; a private link keeps only ciphertext, its key never leaving your link. Never the rest of this list.)

Sharing: the link is the document

Share a doc and the whole document — text and annotations — is compressed and encoded into the link's # hash fragment. Browsers never send the fragment to any server, ours included, so even our hosting provider's access logs structurally cannot contain your document. There is no shortener, no lookup table, no copy held anywhere.

One honest caveat: the link text itself is the document. Send it over Slack or WhatsApp and it sits in that chat's history like any other message — on their servers, not ours. That is exactly what the password option is for. A password-protected link is encrypted end to end: AES-256-GCM via WebCrypto, the key derived from your password with PBKDF2-SHA-256 at 600,000 iterations, and a fresh random salt and IV for every link. The password is never stored in the link or anywhere else — without it, the link is opaque bytes.

A private link (a /r/… address, the kind a reviewer opens to respond) is different in kind: it does put a copy on our server. But your browser encrypts the document before it uploads, and the decryption key rides in the link's # fragment — the same fragment browsers never send — so it never reaches us. So even though it's server-stored, it's end-to-end encrypted: we hold ciphertext we can't read. That's the opposite of a routed document, which is stored under keys we manage precisely so it can be read.

What would have to change for PassbackAI to start collecting data on you

Source code edits in three places, plus a Chrome Web Store re-review (which exposes the change publicly), plus a public reversal of the privacy commitments above. None of those things can happen quietly. If they happen at all, you'll see them in the listing's update notes and in the extension's request for new permissions.

The hedge

"Don't you have to trust us anyway?" Sort of, yes. But the most important thing about the PassbackAI privacy model isn't a promise we make — it's a structural fact: the review tool has no server to send your content to. The backend we run exists only for two opt-in moves — routing a document to a reviewer, and private-link sharing — and it only ever receives a document you deliberately send. A routed doc is stored under keys we manage, so we can read it; a private-link doc is encrypted in your browser, so we hold only ciphertext. For everything else, we could not collect your data even if we wanted to, because we did not build the thing that would do the collecting. The whole project is shaped around making it expensive to ever break that. That's the design.