What we store, and what the users may never do

Buying, paying, subscribing, booking, sending a message, deleting anything, uploading a file and submitting personal data are refused before they execute. They are not discouraged in a prompt and then hoped for — the action is blocked in the browser layer, and the user is told why so it records the boundary and carries on instead of looping against it.

Navigation off your domain is refused and reverted. A scan stays on the product it was pointed at.

On a free scan the users never fill a password field at all, under any circumstances.

Two ways, and only two. Either a throwaway identity we generate for the scan, or credentials you supply for a test account you control. Never both, and never anything belonging to a real person.

The permission the browser agent gets is not “you may now fill password fields”. It is a comparison against the exact values for this session: the agent can type that address and that password and nothing else. It cannot substitute a real address, and it cannot type a card number, because the allowance is a value check rather than a category of field being unlocked.

Payment fields are never unlocked by anything. A signup is reversible and costs nobody anything; a purchase is not.

Where a product needs a CAPTCHA, an SMS code, single sign-on, a card before access, or an invitation, we report that we could not get past it rather than quietly stopping early and writing up the pages before it.

They are encrypted with AES-GCM before they are stored, under a key that lives only in the server environment. If no key is configured the feature refuses to run rather than writing plaintext somebody would later assume was encrypted.

They are decrypted only for the life of a single scan session. They are redacted from agent narration, from the report and from stored evidence before any of it is written down, so a password cannot reach a screenshot caption or a shared link.

Use a test account, not your own. We ask for the least access that lets a user see what a new customer sees.

The pages the users visited, what they did, what they expected, what happened, page screenshots, and the report drawn from them. That is what lets you check the evidence yourself instead of taking a conclusion on trust — a report you cannot audit is an opinion.

Scans are kept so you can reopen them from your account and compare a re-test against the original. Ask us to delete a scan and we delete it, along with its sessions, evidence and screenshots.

We do not sell data, and we do not use one customer’s product as an example to another without asking first.

A scan run without an account is reachable by its link, and by nobody else, because nothing else knows the link exists. A scan attached to an account is reachable only by that account.

A share link exists only if you create one, and revoking it takes effect immediately. Search engines are told not to index report pages, and report pages send no referrer off-site, so the link cannot leak into a third party’s logs when somebody clicks out of it.

A shared report carries the findings, the evidence, the recommendations and the desired outcomes, because the person you sent it to is usually the one who has to do the work. Two things do not travel with it: your coding-agent fix prompts, and anything a user saw after signing in. That second one is not about value — once a synthetic user is inside your product it may be looking at your own customers’ data, and you cannot consent to publishing that on their behalf.

Running a free scan needs no account. An account is only asked for if you decide to buy, because an account before then is a tax on finding out whether this is any good.

Sign in with an email and password or with Google. Both end at the same server-side session held in an HttpOnly, host-only cookie. No token is exposed to JavaScript in your browser. We store no Google access or refresh token: sign-in is the only thing we ask Google for, and it is finished the moment your account is identified.

Signing out revokes the session on the server, not just in the browser, so a copy of the cookie kept anywhere else is already dead.

Card details are entered on Lemon Squeezy’s own hosted checkout and never touch StrangerTest. We receive a signed notification that an order was paid, and that signed notification is the only thing that grants anything.

A refund revokes what it paid for. A failure on our side does not: if a paid scan stops because of a problem at our end, the purchase is not consumed and you can run it again.

First-party only. No third-party analytics script, no advertising pixel, no cross-site tracking. A random identifier in your browser’s local storage distinguishes one visitor’s path from another’s and tells us nothing about who you are.