Privacy Policy

OKShip is the operator of this service and is responsible for the personal data described on this page. For anything to do with privacy, your rights, or a legal notice, write to privacy@okship.dev and a person will answer.

For your own account details we are the controller: we decide what to collect and why. For the contents of the application you ask us to test, you are the controller and we act on your instructions as a processor. That split matters, because a page we screenshot may contain personal data about your users, and we have no relationship with them.

When you create an account, our authentication provider passes us a small set of fields and nothing more:

• An account identifier from the authentication provider.
• Your email address.
• Your first and last name, when you have given them.
• A single initial derived from your name or address, used as an avatar.
• The time you were last seen signed in, and who invited you if someone did.

We do not receive a profile photo, a username or a phone number. If you sign in with GitHub or Google, the authentication provider hands us the same fields as an email sign-up; we get nothing extra from those services.

When someone invites a colleague, we store the email address they typed and the role they chose before that person has an account. If you were invited and never accepted, your address is what we hold, and you can ask us to delete it.

Everything below is created because you asked us to run a scenario. It describes your application, and it can contain personal data about your own users if their data is on the pages we visit.

• The address of the application, its name, and whether you marked it as production.
• The scenarios you wrote: a label, a plain-English goal, and any steps you listed.
• A full-page screenshot of each scenario, captured as the browser saw it, including any signed-in state.
• A screenshot after each individual action the browser took.
• A page-health archive: the page title and meta tags, browser console messages, failed requests, HTTP errors, broken images, a sample of links, and an accessibility scan.
• The verdict for each scenario, the model's written judgment, what it expected, what it observed, and its recommendation.
• A step-by-step record of what the browser did: the intent, the action, the element it acted on, and what changed afterwards.
• A demo video assembled from those screenshots, with a spoken verdict for each scenario.
• A transcript of the demo video, holding each scenario's narration sentence, when it appears in the video, and whether it was spoken.
• A certificate PDF summarizing the run.

One thing is deliberately left out of that record. When the browser types into a field, we store that a value changed, not the value itself.

Two of those artifacts are stored so that anyone holding their web address can fetch them, with no sign-in: the per-scenario screenshot and the page-health archive. The report page at /report/ plus a run identifier is also open to anyone who has that address. Treat all three as shareable, because that is what they are. The demo video, its transcript, the per-action screenshots and the certificate PDF are stored privately and are reached through short-lived links or a signed-in request instead.

When a run finishes we email a report. It goes to the address recorded on the run if there is one, and otherwise to an owner of the organization the run belongs to. The email contains the verdicts, the written judgment, the hostname of the application, and images loaded from those public screenshot addresses. We store the address we sent it to, and our internal event log keeps a copy of it.

A proof link is a page you can send to someone who has no OKShip account. When they open it we record:

• A keyed hash of their IP address and browser user-agent string, shortened to 16 characters.
• Their browser user-agent string, cut to 500 characters.
• Whether the request looked like a bot.
• The time of the view.

We do not store the IP address itself. It is used to compute the hash and is then gone. The hash is pseudonymous rather than anonymous: the same browser on the same connection produces the same hash, which is exactly what makes it useful for spotting abuse and exactly what makes it linkable. We keep the user-agent string because it is our only means of telling a person opening a link from a mail scanner opening it for them.

If the person who created the link asked viewers for an email address, that address is placed in a signed cookie in the viewer's own browser so they do not have to type it again. It is not written to our database.

If the person who created the link enabled it, a viewer can press a button that starts a fresh run against the application. We record that a viewer did so, identified by the same hash.

If someone sends you a proof link and you have an OKShip account, you can keep it. Saving is a deliberate act: you press a button on the proof page itself, or paste a link you were given into a box on your dashboard. When you save one, we store:

• Which account saved it, so the link appears on your list and on nobody else's.
• The address of the link, and a reference to the link itself where we can match it to one we hold.
• Whether you saved it from the proof page or by pasting it in.
• The time you saved it.

Opening a proof link records nothing here. What we record when someone opens one is described in the section above, and it does not put the link on anyone's list. Only saving does that.

The person who sent you the link is never told that it was you. Their dashboard shows how many people have saved it, as a number, and nothing more: not your name, not your address, and not the time you saved it.

A saved link belongs to you and not to your organization. Colleagues in the same organization do not see what you have saved.

We store the address you saved even when it does not match a link we hold, because the link has been deleted or never existed. Your entry stays on your list either way, and answering the same way in both cases is what stops the save button being used to work out which links are real.

We use all of the above for these purposes and no others:

• Running the verification you asked for and producing its report, video, certificate and proof link.
• Letting you and your colleagues sign in, and enforcing who may do what inside your organization.
• Counting executions against your plan and taking payment.
• Sending the report and, where you have connected them, notifications to your own tools.
• Keeping an audit record of what happened, so a run and a shared link can be accounted for later.
• Detecting and limiting abuse of the service.
• Answering your questions and dealing with rights requests.

Where the UK GDPR or the EU GDPR applies, our legal bases are these:

• Performance of a contract, for your account, your runs, your artifacts and your billing. Without processing these we cannot provide the service you signed up for.
• Legitimate interests, for audit records, abuse prevention, security and service diagnostics. Our interest is in operating a service that can account for what it did; we have limited what we keep to what serves that.
• Legal obligation, where we must retain billing records.
• For personal data inside the pages we visit, we process on your instructions as your processor, and your own legal basis governs it.

Judging whether a scenario worked is done by a large language model. Each time the browser needs a decision, we send an AI model provider:

• The full-page screenshot, as an image.
• The address of the page.
• The plain-English goal of the scenario, and any steps you listed.
• A summary of the interactive elements on the page: each element's accessible name, its role, a selector for it, and what the control currently contains.
• The history of the current scenario, so the model can see what it already did.

We try to keep credentials out of that summary. Before reading what a control contains, we check whether it looks like a credential field: a password input, a field the page marks as a password with an autocomplete attribute, a field OKShip itself filled with a stored credential, or a field whose name, label or placeholder matches a list of credential words in about a dozen languages. When any of those matches, we send no contents for that field. Be aware of the limit: the first three checks are exact, but the last is a word list, not coverage. A password field that a reveal button has switched to plain text, carries no autocomplete attribute, and is labeled in a language or phrasing that list does not contain will have its contents sent. The same is true of an unlabeled text field with no signal at all. We state this rather than promise a guarantee we cannot keep.

You can supply your own AI provider key. Stored at the organization level it is encrypted with AES-256-GCM before it is written, and only the last few characters are kept in readable form so you can tell which key it is. Supplied on a single request instead, it is used for that run and not stored. Once a week we make a token-count call with a stored key to check it still works.

The demo video is narrated. The only thing we send the text-to-speech provider is one short sentence per scenario, in the form of your scenario label followed by the word passed, failed or ambiguous. No judgment text, no screenshot and no page content goes to that provider.

If you want us to test pages behind a sign-in, you connect the application by signing into it yourself in a browser we run for you. Read this section before you do.

• That browser is not on your machine. We rent it from a cloud browser provider and drive it in the cloud, so what you type into it, your password included, and the signed-in session it ends up holding both pass through that provider.
• We choose which of the provider's four regions to rent it in from the time zone your own browser reports, so that typing into it feels less laggy. The four are Oregon and Virginia in the United States, Frankfurt in Germany, and Singapore. You cannot choose, and we do not treat the choice as a promise about where your data is kept or whose law applies to it. If your browser reports nothing usable, we use Oregon.
• We do not store the time zone. Only the region we settled on is recorded, which is one of those four values.
• What we keep afterwards is the session cookies for the single host you declared, encrypted. We do not keep your password. We also discard the browser storage the sign-in left behind, keeping only a count of how much was thrown away.
• Those cookies are encrypted with a key that a cloud key management provider mints for that one connection and then wraps; the unwrapping key stays with that provider, so a copy of our database on its own does not open them. Encryption is bound to your organization and that specific connection, so a record cannot be decrypted in another organization's context.
• The part of our system that stores a credential can only encrypt. Only the worker that runs your scenarios can decrypt, and it does so at the moment it needs to fill the browser.
• You can disconnect at any time. Disconnecting erases the stored session and its wrapped key from our database, and for a captured session we also attempt to sign it out at your application.

We use other companies to run this service. We name them by what they do rather than by brand, because the brand may change and the category is what matters to you:

• An authentication provider, which holds your sign-in identity and sends invitation emails.
• An AI model provider, which receives what is listed under AI processing above.
• A text-to-speech provider, which receives the one narration sentence per scenario.
• A cloud storage provider, which holds screenshots, page-health archives, demo videos, their transcripts and certificate PDFs.
• A cloud browser provider, used only for connecting an application that needs a sign-in.
• A cloud key management provider, which holds the key that protects stored sessions.
• A cloud hosting provider, which runs our web service, our worker, our database and our queue.
• A transactional email provider, which delivers reports and notices.
• A payment processor, which handles checkout and subscriptions.

If you have connected your own tools, we also send them what you asked for. A chat notification carries the hostname of your application, the verdict counts and a link back to the run. Nothing is sent to a code-hosting service; that integration works the other way round, with your build calling us. We will name the specific companies behind any of these categories if you ask.

We make no statement here about how long any of these companies keeps what we send it, or what it does with it beyond providing the service to us. We have not verified those practices ourselves.

• Our hosting, database, queue, storage and email are provided by companies headquartered in the United States, and you should assume processing takes place there.
• The key management provider that protects stored sessions operates in Ohio, in the United States.
• Connecting an application uses a browser in one of four places, chosen as described above: Oregon, Virginia, Frankfurt or Singapore.
• We have not established the precise physical location of every storage bucket and service instance, and we do not claim one here.

If you need the details of the safeguards that apply to a particular transfer, write to privacy@okship.dev and we will tell you what is in place for that vendor rather than describe a mechanism in general terms.

These are commitments, not descriptions of an automatic process. They apply unless your plan, subscription or order says otherwise, in which case that term governs for your plan, whether it is longer or shorter. Section 2 of the Terms of Service sets out that order of precedence.

• Run files and proof links: we delete the screenshots, the demo video, its transcript, the certificate PDF and the proof link 90 days after the run.
• Verdict text: we keep it. The result, the judgment, what was expected and what was observed are the record of what happened, and they stay after the files are gone.
• Proof-link view records: we keep them for as long as the link exists, and they go when it does.
• Links you saved: we keep them until you remove them, or until your account data is deleted.
• Account data: we delete it 90 days after the account is closed.
• Billing records: we keep what we must for as long as the law requires.
• Our internal event log records that things happened, and it is append-only. Ask us and we will tell you what is in it about you.

This is what is actually in place, not a list of aspirations:

• Stored sessions for your application are encrypted with AES-256-GCM under a key held by a cloud key management provider, bound to your organization and connection.
• Your own AI provider key is encrypted with AES-256-GCM before it is stored.
• The part of our system that writes a credential cannot read one back; only the worker that runs scenarios can, and only when it fills the browser.
• Nothing in the credential path writes to a log. Failures there report an operation name and nothing else.
• API keys are stored as a SHA-256 hash. We cannot show you a key again after we issue it.
• Proof-link passwords are stored as a hash, not as text.
• Viewer IP addresses are turned into a keyed hash and the address is not written down.
• Private artifacts are reached through links that expire after ten minutes, or through a signed-in request scoped to your organization.
• Access inside your organization is checked against your role on every request, and a request for another organization's run is answered as though it does not exist.
• Values typed into a form during a run are not written into the permanent step record.

We hold no security certification and we are not audited against one. If a page anywhere claims otherwise, this sentence is the correct one.

Our worker writes a diagnostic line for each page it looks at, containing the names of the first ten elements and, where it read them, what those controls contained. Those lines are retained by our hosting provider. The same credential check described under AI processing applies to them, and so does the same limit.

Depending on where you live you have some or all of these rights. We extend them to everybody rather than checking your location first:

• Ask what we hold about you and get a copy of it.
• Have it corrected if it is wrong.
• Have it deleted.
• Ask us to restrict what we do with it, or object to processing we do on the basis of legitimate interests.
• Get it in a portable form, or ask us to send it somewhere else.
• Withdraw a consent you gave, where we relied on consent.
• Not be subject to a decision made solely by automated means that has a legal or similarly significant effect on you. We do not make such decisions about people. Our model judges whether a web page did what it was supposed to do, which is a decision about software.

If you are in a US state with its own privacy law, you can also ask us to confirm what categories we hold, to delete it, to correct it, and to tell you who we shared it with. We do not sell personal data, and we do not share it for cross-context behavioral advertising, so there is nothing to opt out of on that front. We will not treat you differently for exercising a right.

We endeavor to make access as easy as possible (e.g., self-service buttons). Where these are not available, please email privacy@okship.dev with your request. We will answer within 30 days, and sooner where the law requires it. If you are a viewer of a proof link rather than a customer, tell us the link and roughly when you opened it, so we can find the record. You also have the right to lodge a complaint with a data protection supervisory authority.

If your request concerns data that one of our customers is responsible for, we will ask you to contact that customer directly.

You must be at least 18 to use OKShip. We do not offer the service to anyone younger and we do not knowingly collect data about children. If you believe a child has given us data, email privacy@okship.dev and we will remove it.

We keep this short because there is little to say:

• Our authentication provider sets the cookies that keep you signed in. Without them the dashboard cannot work.
• When a proof link asks a viewer for a password or an email address, we set one cookie on that viewer's browser so they are not asked again. It is scoped to that single link, marked HttpOnly and Secure, signed so it cannot be edited, and expires after 24 hours.

If we change this page we will change the date at the top. If a change materially affects what we do with your data, we will email account owners before it takes effect. Older versions are kept in our source history and we will send you one on request.

Write to privacy@okship.dev for anything on this page, including a rights request. The Terms of Service set out the agreement between us, and section 2 there governs what happens when your plan says something different from this page.