Privacy policy

Who we are

Excuto audits websites with automated browser agents. {{LEGAL_ENTITY}} runs Excuto. In this policy, "we" means {{LEGAL_ENTITY}}. Our address is {{LEGAL_ADDRESS}}.

This policy uses these terms.

• An audit is a run of our browser agents on one site.
• A finding is a problem that an audit reports.
• Evidence is the screenshots, video, and request records of a finding.
• A customer is a person or company that holds an account.
• An organization is the group that owns the audits and credits of an account.
• AI review is a step where a model reads page text and screenshots.

We have two roles.

• For account data and billing data, we are the controller. Under Indian law, we are the Data Fiduciary. We decide why and how we use this data.
• For audit data, the customer is the controller and we are the processor. The customer decides which site to audit. We process audit data on the instructions of the customer.

We also use counts and review times from audits to measure the quality of the service. For that use, we are the controller.

What we collect

Account data

When you sign up and use the service, we collect this data.

• Your email address, from the sign-up form or from Google sign-in.
• A user id that Firebase Authentication creates.
• The name of your organization (the default is "My organization"), your role, and your credit balance.
• The name, a 12-character prefix, and the SHA-256 hash of each API key that you create. We never store the full key.
• The address of each site that you add, and the token that you use to prove that you own the site.
• The address of each site that you audit, and the goal text that you type, up to 500 characters.

Firebase Authentication, a Google product, handles your password. Our database does not hold it. If you sign in with Google, Google can pass your name and photo to Firebase Authentication. If you sign up with email, you can give a name to Firebase Authentication. We read your name to show it in the menu. We do not store it in our own database.

Billing data

When you buy credits, we keep a record of each order and each credit change.

• Our order id and the Razorpay order id.
• The pack, the number of credits, the currency, the amount, and the status.
• The dates of the order and of the payment.

Razorpay shows its own form for card details. Our code does not store a card number, a card token, or the name, email, or phone number of the payer. When you press pay, your browser sends your account email to Razorpay to fill in the form. Razorpay sends us a signed message about each payment. That message can hold more data than we keep. We keep only the event name, the order id, the payment id, the amount, and the currency.

Audit data

An audit opens pages of the site in a new browser. The browser starts empty and does not sign in to the site. An audit can record this data.

• A screenshot and a video of each finding that the audit reproduces.
• A live picture of the page while the audit runs. We delete this picture when the audit ends.
• Request records: failed requests to the audited site (status 400 or higher, up to 50). For a failed API call, we keep up to the first 4,096 characters of the answer. We also keep console errors and page errors with their stack.
• The first four and last four characters of a secret key that a page exposes, if the audit finds one. The audit scans the scripts and the JSON answers of the site for such keys.
• The addresses of the pages that the audit visited, without query text.
• The text of each finding: title, summary, steps to repeat, and fix hint.
• Staff notes on a finding, as staff type them.

If AI review is on, the model provider also receives page text and screenshots. See Where your data goes.

Before we keep request records, and the text of finding titles, summaries, and error lines, our code removes or hides this data.

• Everything after the question mark in a page address.
• Bearer tokens and JSON web tokens.
• Email addresses.
• Card numbers that pass the Luhn check.
• In JSON, the value of each field whose name contains password, token, secret, key, auth, session, card, cvv, or ssn.
• All headers, except eight harmless ones such as content-type. Cookie and authorization headers are dropped.
• The whole answer body, if it contains a secret such as a live Stripe key, an AWS access key, or a private key.

Our code does not remove this data.

• Screenshots, videos, and the live picture. We do not blur or mask any image. Faces, names, addresses, orders, and other text appear as the page shows them.
• Names, phone numbers, postal addresses, IP addresses, and ID numbers inside text. Card numbers that fail the Luhn check also stay.
• The path of a page address. A path such as /users/12345 stays.
• The names of page elements. A name can hold the name of a person.
• The goal text that a customer types and the notes that our staff type.

Technical logs

Our worker writes a log line for each audit step. A line holds a page address without query text, the title of a possible problem, or an error text. Error texts pass the redaction above. The title of a possible problem in a log line does not. Google Cloud Logging keeps the logs of our functions. For API calls, our function logs the method, the path, and the status. It never logs a header or an API key.

Our code does not read or store IP addresses. Google, and Vercel once the web app is deployed there, log request data on their side. That data can include IP addresses.

Data from the sites we audit

A customer who audits a site must have the right to audit it. The customer must own the site or have the permission of the owner. An active audit also needs proof of ownership with a DNS record. Read our acceptable use page.

Screenshots and video show what the page shows. A page can show names, faces, addresses, and orders of other people. Our code does not blur this data. We do not sign in to sites. Even so, a public page or a test page can show personal data.

In an active audit, our agents fill forms with fixed test values, such as qa.user@example.com. They can create records on the site. These values are not data of a person.

The customer is the controller of audit data. If a page shows your personal data and you want to exercise a right, ask the customer first. We help the customer act on the request.

Why we use data

The table shows each purpose, the data that we use, and the legal basis under GDPR and UK GDPR.

In India, we use account data and billing data for the legitimate uses that the Digital Personal Data Protection Act, 2023 (DPDP Act) lists. These uses include data that you give us for a stated purpose, and duties under law.

Our web app has no analytics, advertising, or tracking tools.

Where your data goes

Companies process data for us. They are on the subprocessors page. We also give data to the people and authorities that the law requires.

The model provider

The worker sends AI review data to the address in its model setting. Today, this address is for NVIDIA-hosted models at integrate.api.nvidia.com. AI review runs on every audit when the worker has a model key. You cannot switch it off for one audit or for your account today.

AI review sends this data, per call.

• Copy review, once per page: the visible text of the page, up to 200 blocks of up to 1,000 characters each. We skip code, inputs, text areas, and menus. We also send words that repeat on three or more pages, and the words of the page titles.
• Visual review: the path of the page without query text, the window size, and counts of links, inputs, and options. We also send one screenshot of the visible part of the page.
• Check of a claim: the text of the claim, facts about up to 10 page elements, and a cropped screenshot of the problem area. For a copy claim, we send the quoted text and the block of text.

We do not remove personal data from the page text or from the screenshots before we send them. We do not send your email, user id, organization id, API key, or payment data. A model only proposes a finding. A person must approve it before it appears in a customer report.

How long the model provider keeps this data, and whether it uses the data to train models: {{MODEL_PROVIDER_RETENTION}}.

Other recipients

• Share links. If you create a share link for an audit, anyone who holds the link can read the approved findings and evidence of that audit. The link has no end date. You can revoke it on the audit page.
• Our staff. Staff can read every audit, finding, and evidence file, to review findings and to support customers.
• Razorpay. It receives your account email when you press pay, and it receives the order data.

Cookies and browser storage

Our code sets no cookie. These items use your browser storage or send requests from your browser.

• Sign-in. The Firebase Authentication code stores your signed-in user, with a refresh token, so that you stay signed in. It uses the IndexedDB database firebaseLocalStorageDb, object store firebaseLocalStorage, under a key that starts with firebase:authUser:. If IndexedDB is not available, it uses localStorage, then sessionStorage.
• Google sign-in pop-up. It can use storage under xenon-qa.firebaseapp.com for the sign-in step.
• Payment. Razorpay Checkout loads only after you press pay. It runs on its own domain and can set its own cookies and storage. We do not control them.
• Sample report. The sample report page loads a demo video from commondatastorage.googleapis.com. Your browser contacts Google to get it.
• Command line tool. It writes your API key to ~/.config/qa-swarm/credentials with file mode 0600.

We do not use storage for analytics or advertising. Our fonts load from our own host. You can clear the stored items in your browser settings. If you do, you sign in again.

How long we keep data

After we delete a file, Google keeps it recoverable for up to 7 days. After we delete a database record, Google keeps the earlier version recoverable for up to one hour. We keep no other backup.

Security

Our security page lists the controls that we use and tells you how to report a security problem. No system is fully secure.

Your rights

In India, the DPDP Act gives you, as a Data Principal, these rights.

• To get a summary of your personal data and of the parties that receive it.
• To correct, complete, or update your personal data.
• To ask us to delete your personal data.
• To get your complaint handled by our grievance officer.
• To name a person who can act for you if you die or cannot act.

If GDPR or UK GDPR applies to you, you have these rights.

• To access your data, and to correct it.
• To ask us to delete it, or to restrict how we use it.
• To receive your data in a portable format.
• To object to uses that rely on legitimate interests.
• To withdraw consent at any time, where we rely on consent.

To use a right, follow these steps.

1. Write to {{PRIVACY_EMAIL}} from the email address of your account.
2. State the right that you want to use.

We have no self-service tool to delete an account, to correct data, or to export data. A member of our staff handles each request by hand. If you ask us to delete your account, we list in our answer each record that we keep, and why. We answer within {{REQUEST_RESPONSE_DAYS}} days.

Our grievance officer is {{GRIEVANCE_NAME}}. Write to {{GRIEVANCE_EMAIL}}. If we do not resolve your complaint, you can complain to the Data Protection Board of India. If GDPR or UK GDPR applies to you, you can also complain to your data protection authority. In the United Kingdom, this is the Information Commissioner's Office.

Children

Excuto is not for people under {{MINIMUM_AGE}}. We do not check age at sign-up. If you think that a person under {{MINIMUM_AGE}} has an account, write to {{PRIVACY_EMAIL}}. If we learn that an account belongs to a person under {{MINIMUM_AGE}}, we close it.

International transfers

We store data in the United States, with Google. Cloud Firestore uses the nam5 multi-region in the United States. Cloud Storage for Firebase uses the US-CENTRAL1 region. Cloud Functions run in the us-central1 region.

Google decides where it keeps sign-in records and logs. We have not confirmed those locations. For the other providers, see the subprocessors page.

If you live outside the United States, your data moves to the United States. The DPDP Act allows transfers out of India, except to countries that the Indian government restricts. If GDPR or UK GDPR applies to you, each transfer needs a legal safeguard. The subprocessors page names the safeguard for each provider.

Changes to this policy

If we change this policy, we post the new version on this page and change the date at the top.

Contact

{{LEGAL_ENTITY}}, {{LEGAL_ADDRESS}}. Privacy email: {{PRIVACY_EMAIL}}.