Privacy Policy — Qiksy

Last updated: 10 August 2026

In one line: Qiksy is a manual-QA assistant that runs on your own machine. It has no telemetry and no analytics, and nothing about the pages you test is ever sent to us. It never sells or shares your data. Everything it captures stays in your browser's local storage unless you explicitly turn on the optional local agent bridge. The one exception is a paid licence: a key opens three installations, so when you paste a key — and once a day afterwards — Qiksy asks our licence server whether this installation still holds one of its three places. That request carries the key and a random installation id, and nothing else.

Who we are

This policy covers the Qiksy QA Copilot browser extension for manual QA engineers: exactly what data the extension handles, why, where it is stored, and when (if ever) it leaves your device. Other Qiksy products behave differently and have their own policies — Qiksy Legato, the browser, and MultiLogin Tabs. Contact: [email protected].

What Qiksy handles, and why

All processing happens locally in your browser. Qiksy is not the destination of any of this data — there is no Qiksy server.

Data	Why	Where it is stored	Leaves your device?
Authentication cookies (including HttpOnly session cookies), `localStorage`, `sessionStorage`	Only when you use Roles or Multi-login: to save a site login so you can switch between test users, or run several logins side-by-side. Shown to you first with an explicit consent prompt.	Your browser's `chrome.storage.local` (and, for multi-login, in-memory / `chrome.storage.session`), on this machine only.	No.
Website content & network activity — page structure, form fields, console messages, and captured request URLs/statuses/error bodies of the page you are testing	To produce QA findings, audits, the session recorder, and reports.	`chrome.storage.local` on this machine.	No, unless you enable the agent bridge (below).
Screenshots of pages you test	The session recorder / bug reports. Password, card and common secret input fields (incl. inside open shadow-DOM components) are masked before capture on a best-effort basis, and you can add your own redaction selectors. Masking cannot reach secrets rendered as plain page text or content inside cross-origin iframes — add a custom selector or avoid capturing those screens.	`chrome.storage.local` on this machine.	No.
Test data you enter (personas, saved datasets — may include names, emails, etc. you type)	To let you re-fill forms with saved test data.	`chrome.storage.local` on this machine.	No.

Where data can leave your browser

The first two are off by default and require an explicit consent prompt; the third runs only when you press it; the fourth happens only if you hold a paid licence key:

Local agent bridge (MCP) — if you switch it on and confirm the consent prompt, Qiksy makes a WebSocket connection to a program you run on 127.0.0.1 (your own machine, e.g. a coding agent) and lets it read: your QA findings, detected form structure, the URLs and titles of your open browser tabs (so the agent can pick which one to inspect), request URLs, basic browser/environment details (user-agent, viewport), and captured server response bodies. Query strings are stripped from URLs before sending, so tokens don't leak. It can also ask Qiksy to run its audit, build the exploratory tour, generate its session report (which may include page screenshots), open Qiksy's own panel, or spotlight an element. That program may forward what it reads to its own AI service — that is outside Qiksy and governed by that tool's policy. The bridge is loopback-only. On its own it drives only Qiksy's own interface and cannot fill, click, submit or navigate the app you are testing — that requires Agent control, below.
Agent control — a separate switch (Qiksy Pro) that lets the same local program act on the page you are testing: click an element, type into a field, press a key, navigate the tab, open or close an isolated login. It is off by default and needs its own confirmation, distinct from the bridge's, because it is a different promise: anything your agent does here is a real interaction with the real app under your real login — it can submit, spend and delete, and there is no undo. Turning it off withdraws that confirmation. It sends nothing new anywhere: the actions happen in your browser, and the only data leaving is what the bridge already described above. Opening an isolated login additionally requires the multi-login confirmation, because that one intercepts the site's cookies.
Broken-link scan — when you run it, Qiksy sends HEAD/GET requests to the links already on the page you are testing, to detect 404s. It transmits no personal data.
Licence check (paid keys only) — a licence key opens three installations, which cannot be counted on your machine alone: this installation has no way of knowing the same key was pasted on somebody else's computer. So when you paste a key, and once a day afterwards, Qiksy sends the key and a random identifier it generated for this installation to api.qiksy.app and receives one answer: whether this installation still holds a place. It carries no page data — no URLs, no findings, no form contents, no screenshots — and the identifier is random rather than derived from your machine: Qiksy deliberately does not fingerprint your device, browser or hardware. If the request fails (you are offline, or our server is down) Qiksy keeps working as Pro; only an explicit answer of “this place is gone” switches Pro off, and pasting the key again moves a place back to this installation. There is no request at all if you have no key, and none for keys sold before 10 August 2026 — those have no device limit.

Removed integrations

Earlier builds offered an optional Claude API (BYOK) feature and a Jira integration. Both were removed. Qiksy does not contact api.anthropic.com, Atlassian, or any third-party service. The only server it ever contacts is our own api.qiksy.app, and only for the licence check described above.

Limited Use

Qiksy’s access to and use of the data described above — page content, form fields, the cookies it captures for role/login switching, and screenshots — is limited to the single purpose above: helping you manually test the web app you are on, on your own machine. Qiksy does not transmit this data to any Qiksy or third-party server, does not sell, rent or share it, and does not use it for advertising, creditworthiness, or any purpose unrelated to that QA workflow; it is kept only in your browser’s local storage. The only data that ever leaves your machine is what you explicitly hand to your own local program through the optional loopback bridge — plus, if you hold a paid key, the licence check above, which carries the key and a random installation id and no page data whatsoever. This use complies with the Chrome Web Store User Data Policy, including its Limited Use requirements.

What we never do

No telemetry, usage analytics, or tracking of any kind. The licence check counts installations of a key; it does not report what you did with them.
No device or browser fingerprinting — the installation id is a random number we generate, not anything read from your machine.
No selling, renting, or sharing of your data with anyone.
No remote code — all logic ships inside the extension package.
No use of your data for any purpose other than the single purpose above (helping you test the site you are on).

Your control

All data is yours and local. Remove any of it at any time: delete a role/persona in the panel, clear the session, use "Clear all", or clear the extension's storage from chrome://extensions. Uninstalling the extension deletes everything it stored.

Changes

If this policy changes materially, the updated date above will change and the notes will describe what changed. Continued use after an update constitutes acceptance.