Your data and privacy

Remixlet has no backend, no account, and no telemetry today. This page describes where each kind of data actually goes, what the extension does to limit how much of a page reaches the AI model, and where that limit ends. The privacy policy states the same facts formally, and the security architecture explains the mechanisms behind them.

What stays in your browser#

Your remixlets, their full version history, your conversations with the agent, and your settings live in your browser's local storage. There is no Remixlet server for them to reach.

Two of those deserve a closer look. Conversations are stored as plain log files, and a log includes what the agent read from the page during that chat. Screenshots are left out of the log. Separately, the extension keeps a copy of each page capture the agent took, up to 20 per site, deleting the oldest as new ones arrive. Both sit on your disk unencrypted, like the rest of your browser profile. Deleting a conversation deletes its log. Uninstalling the extension removes everything, captures and keys included.

What leaves your machine#

One kind of data leaves your machine: what the agent reads from the page you are working on, while you are chatting with it. It goes to the AI provider you configured, under your own key or account, and nowhere else. Once a remixlet is built it runs locally and never contacts the provider.

A remixlet's own code can request network access, but only to hosts named in its manifest and approved by you. There is no general "access the internet" grant.

How much of the page the model sees#

When the agent looks at a page it takes a capture. A capture is the page's markup, its title and URL, a list of the frames on it, and usually a screenshot of the part you can see. Afterwards the agent can ask narrower questions, such as "find the elements matching this selector" or "read the JSON this page embeds", and each answer is a slice of the same page.

Remixlet does not inspect that content for sensitive material before sending it. If a page shows your bank balance, the model sees your bank balance. There is no filter that recognises account numbers or medical records, and we don't think one could be trusted to catch enough to be worth promising. So the first measure is a rule for you rather than for the software: if a page shows something you would not paste into a chat with your provider, don't point the agent at it.

What we do to keep the amount small#

Given that, here is what the extension does. Each of these is enforced in code, not left to the model's judgement.

Nothing is sent unless you are chatting. A capture happens only when the agent calls its capture tool during a turn you started. Nothing is read on install, when you switch tabs, or in the background. The extension makes one kind of request of its own besides provider traffic: when a chat starts on a site, and when the control center lists a site it has no icon for, it fetches that site's front page and favicon to show the site's icon. Those requests carry no cookies and nothing from your pages.

The agent works on one tab. Each conversation is bound to the tab you started it on. If you switch tabs while the agent works, it keeps reading the original tab. If that tab closes, the agent stops rather than picking up whatever tab is active now.

Screenshots are narrow. A screenshot covers the visible viewport, never the whole page. It is taken only when that tab is the active one in its window, so a tab you are not looking at is never photographed. And it is sent only to models that accept images. For a text-only model the image is dropped before the request leaves your browser.

Big pages are outlined, not dumped. Above roughly 40,000 characters of markup, the raw markup is not sent at all. The model gets a structural outline instead, with short text samples, and the outline says the raw page was withheld. Each follow-up question the agent asks the page has its own size cap.

Some details are trimmed on purpose. Embedded frames are reported by origin only, never by full address, so tracking parameters in frame URLs stay out of the model's context. The page's own background requests are reported as hostnames and counts, not URLs or bodies.

Storage and credentials are refused outright. The agent's tool for reading page state rejects cookies, local storage, session storage, IndexedDB, caches, and the credential store, and tells the agent why.

The powerful reads need a click. Reading what the page fetched from its own API requires your approval, in a card that says what it means in plain words. That grant is scoped to the chat and the site, and it expires after an hour. Running arbitrary JavaScript on the page opens a dialog every time, and you can read the code before saying yes.

Repeat captures are skipped. If the page has not changed since the last capture in the same chat, the model gets a one-line note instead of the page again.

What the model never sees#

Some things are out of reach by construction rather than by policy:

• What you typed. Live input values, including a password you entered or a password manager filled in, are not part of the page's serialised markup.
• Cookies, local storage, session storage, and IndexedDB. The capture reads the document, not the browser's storage.
• Request and response headers. No session tokens, no authorisation headers.
• The contents of frames from other origins, and closed shadow roots. The extension cannot reach them from where it runs.

Where the edges are#

A few things are worth stating plainly, because the list above could read as more than it is.

• Values the server rendered into the page are in the markup. That includes hidden form fields, CSRF tokens, and prefilled values. So are inline data blobs some frameworks embed in the page, which the agent can read on request and which often carry account details for the signed-in user.
• The list of resources the page loaded includes full URLs with their query strings, and query strings sometimes carry one-time tokens.
• The model is told to treat page content as data rather than instructions. It is not given a rule about avoiding sensitive content. A rule that lives only in a prompt is not a protection we want to advertise.

What you are trusting, in the end, is your provider and the model you chose. Remixlet keeps the amount of page you hand over as small as the job allows and makes sure nothing is handed over without you.

API keys#

Provider API keys are stored in the side panel's local storage and are sent to exactly one place: the provider they belong to. They never pass through the pages you visit. The extension's linter fails the build if code ever tries to route a key through the worker or the page bridge.

What a server would mean#

A server may exist one day. Syncing your remixlets between machines is the obvious reason. If it does, it will be opt-in. Nothing will leave your machine unless you turn syncing on, and the local-only setup described here stays the default.