Privacy Notice

LatchKey is an accessibility testing and remediation tool. To do its job it loads websites, screenshots them, stores what it found, and runs an accessibility menu on the sites of customers who install it. That means three different kinds of people appear in this notice, and they are owed different things:

• Customers and people who visit this site. We are the controller. We hold your account details, what you scanned, and the email we exchanged.
• The websites you ask us to audit. We are your processor. We load and store copies of pages you told us we may test, on your instructions.
• The people who visit a site running our widget. The site owner is the controller and we are their processor. The widget sets no cookies, stores a visitor’s preferences in their own browser, and sends us a cookie-free beacon with no IP address, no user agent, no assistive-technology signal and no page content in it.

We do not sell personal information, we do not share it for advertising, and we run no advertising or cross-site tracking on any surface. The cookie policy lists every cookie there is; browsing this site while signed out sets none at all.

We do not ask for special-category data, and there is no field in the product for it. If you put it into a support email or a page we audit, it will be in what we hold, which is a reason to think twice before pasting a production database into a bug report.

This is the section most worth reading, because it is the one where someone else’s data is involved and where the industry’s reputation is poor.

A visitor’s choices — larger text, higher contrast, a reading profile — are stored in their own browser, in localStorage, under a single key, per origin. Nothing about those choices is sent to us. Clearing site data or using a private window resets them.

The widget sets no cookie, on your site or ours. The endpoint that receives its telemetry is forbidden from setting one, and there is a test asserting the header is absent from every response it can produce.

What may never be in a beacon payload, as a matter of what the code accepts:

• no cookie, and no identifier for the device or the visitor;
• no IP address stored against the event;
• no user agent, and no assistive-technology signal — we do not detect screen readers;
• no page text and no form values;
• no search query — only its length, because how long a query is tells us whether search is being used and what it says does not;
• no full URL: path-shaped values are redacted in the browser, before transmission, which is the difference between a policy and a control.

An event that is not in the registry below is rejected at the boundary with a 400 rather than accepted and quietly dropped, and so is a key that is not listed against its event. Most events are sampled rather than sent every time; the rate is in the table.

One event, the report that a fix no longer matched its page, can start a re-audit of that page type. So we count it only when the request names your own site, and we count how many different networks sent it rather than how many reports arrived. Each network sets one of 64 marks for that page type that day, chosen by a keyed hash of the network, the site, the page type and the date, so the same network lands on an unrelated mark on another page type, another day or another site. The marks are cleared once their day is over, and the address itself is never stored.

Every event also carries the envelope: the site key, the event name, the redacted path, the widget version and a timestamp.

Because none of this is a cookie and none of it identifies a person, installing the widget does not, by itself, give you something to add to a consent banner. That is our reading and not legal advice about your jurisdiction — the cookie policy sets out the facts you would need to make that call.

The LatchKey app for Shopify puts the same widget on your storefront through a theme app embed. Installing it gives us a small, fixed set of things about your store, and nothing about the people who buy from it:

• The store’s domains: its myshopify.com address and its primary domain, so the widget’s licence answers on both.
• The permission you granted: read_themes, which lets us read your published theme’s settings to see whether the app embed is switched on. The site key the embed loads is written to the app’s own data on your store, which needs no further permission.
• An access token from Shopify: it expires, it is refreshed only while the app is in use, and it is held encrypted in our secret store. It is never shown to anyone, returned in a response or written to a log.

No customer or order data. The app does not ask for access to your customers, orders or products, and so it cannot read them. When Shopify forwards a shopper’s request to see or erase their data, we have none from Shopify to return or erase, and we record that the request arrived. The notice Shopify sends us when the app is removed carries the store owner’s contact details; we read which store it is and keep nothing else from it.

When you uninstall, the access token is deleted first and the installation is suspended. When Shopify then asks us to erase the store’s data (it sends that request 48 hours after an uninstall), we erase what came from Shopify: the store’s myshopify.com address and the domains the app registered on its licence, the store’s details on our installation record and any token that is left, and we record the request as completed.

If you had connected the store to a LatchKey account, the licence and the website, with their settings and history, belong to that account and stay with it, as the rest of this notice describes. They keep the store’s primary domain as their name, because a licence and a website are named by the domain they serve. We also keep a record that the domain has had its one free trial, which is kept even if the licence is deleted, so that the trial cannot be taken twice. Ask privacy@thelatchkey.in to delete the licence and the website too.

On the storefront, the widget is the one described in what the widget records about your visitors: no cookie, choices kept in the shopper’s own browser, and only the beacons in that table.

The LatchKey app for Wix puts the same widget on your published site through an embedded script, and shows its status in your Wix dashboard. Installing it gives us a small, fixed set of things about your site, and nothing about its visitors or members:

• The site’s Wix identifier: the id Wix gives the app on your site, and, for a site you duplicated, the id of the site it was copied from, so its settings can start from the original’s.
• The site’s published addresses: its primary domain and its other connected domains, so the widget’s licence answers on them. We read the free Wix address too, and do not keep it: it is shared by every free site on a Wix account.
• The permissions you granted: SCOPE.DC-SITES.READ-URLS, SCOPE.DC-APPS.MANAGE-EMBEDDED-SCRIPTS, SCOPE.DC.MANAGE-YOUR-APP, which let us read the site’s addresses, add the widget’s script with your site key, and hear when the app is installed or removed.
• Who opened the dashboard: Wix signs each visit to the app’s dashboard page, naming the site, whether the visitor is its owner, and Wix’s ids for that person and for the site’s owner. We check the signature and whether it is the owner, and keep none of it.

No Wix token is stored. When we need to call Wix for your site, the app’s own credentials and the site’s id get a short-lived access token, which expires within hours and is kept only in our server’s memory. It is never written to our database, never shown to anyone, never returned in a response and never written to a log.

When you remove the app, Wix tells us and the installation is suspended. Its record, the identifiers and addresses above, is kept for at least 90 days after the removal, so that adding the app back in that time restores everything, and the owner of the LatchKey account the site was connected to is emailed that date. The record is not yet deleted by itself when the date passes: write to privacy@thelatchkey.in and we delete it, before that date or after it. A connected site’s licence and website belong to the account, as they do for a Shopify store above, and stay with it until you ask us to delete them too.

On the published site, the widget is the one described in what the widget records about your visitors, and it does not run in the Wix editor or its preview.

Where the GDPR or the UK GDPR applies, we rely on:

• Performance of a contract — running your account, scanning the sites you asked us to scan, serving the widget, and taking payment.
• Legitimate interests — security, abuse prevention, debugging, and counting usage against your plan. We have balanced these against your interests; the data involved is minimal and none of it is used to profile anybody.
• Legal obligation — keeping the records tax and accounting law require.
• Consent — only for marketing email, which you can withdraw from any message.

For the sites we audit on your instructions, you are the controller and your legal basis is yours. Our contract with you is the instruction.

One list, covering everyone. It is generated from the same registry the product uses, so a vendor cannot be introduced without appearing here.

Dodo Payments is not merely our processor. Dodo Payments is our merchant of record and the legal seller of your subscription. They take the payment, calculate and remit any tax, and issue your invoice and receipt. They decide their own purposes for the tax and invoicing data they collect as the seller, which makes them an independent controller and their privacy notice the one that governs it.

If you run inference on your own hardware, the inference row disappears from your set entirely: your image bytes never leave your infrastructure, and that is a property of the deployment rather than a promise in a document.

One row is outstanding: the company that hosts the application database. It is set per deployment and this page will name it once it is filled in, which is why the notice at the top of the page lists it.

We will tell customers before adding a sub-processor that changes where their data goes. Ask privacy@thelatchkey.in for a data processing agreement.

Our hosted deployment runs in the United States by default, and data reaches the sub-processors above under Standard Contractual Clauses where a transfer needs a mechanism.

An account can be pinned to the EU, which moves storage of screenshots and artefacts to an EU bucket. Pinning is per account and it is honest about its edges: it applies to the stages that are actually pinned, and the product derives the sentence describing that rather than letting a reader complete “EU region option” for themselves.

Region pinning applies from the date it was enabled. Data captured before then stays where it was written until it is migrated or reaches its retention ceiling.

Billing is its own answer, because some of it survives the account on purpose. After an account is erased we keep the identifiers and amounts needed to reconcile what we were paid, and nothing that describes the person:

Dodo Payments retains its own seller-of-record records, your invoices and receipts, for the statutory tax period. Those are outside what we can erase, and we forward that part of a request to them.

Everything travels over TLS. Passwords are hashed, never stored or recoverable. Sign-in details for a site behind a login are encrypted, held for the run and discarded, and they live in the memory of one machine for the duration of the crawl rather than being written somewhere convenient.

Access to production data is limited to the people who need it, staff actions on customer accounts are written to an append-only audit log, and a staff session expires after twelve hours rather than the thirty days a customer session lasts.

We never log full URLs, credentials or page contents. Report a vulnerability to security@thelatchkey.in; we will acknowledge it and we will not pursue anybody for a good-faith report.

Depending on where you live, you can ask for a copy of your data, ask us to correct it, ask us to delete it, ask us to restrict or stop a particular use, object to processing based on legitimate interests, and ask for it in a portable form. You can complain to your data protection authority, and we would rather you told us first.

Write to privacy@thelatchkey.in. We will acknowledge within a few days and answer within 30 days, and we will tell you if we need longer and why.

An erasure request gets a specific answer, not a reassurance. We work through each subsystem in order, and the reply names anything we kept, which subsystem it is in, and the reason — a legal retention period, an active dispute, or a litigation hold. Where the thing you want erased is held by our merchant of record rather than by us, we forward that part of the request to them and tell you we have.

If you are a visitor to a site that runs our widget and you want to exercise a right, ask the site owner: they are the controller, and we act on their instructions. If you cannot reach them, write to us and we will try to put you in touch.

If you are in California or another US state with a privacy law: we do not sell personal information and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of. The rights to know, delete, correct and not be discriminated against are exercised at the same address as everyone else’s.

Nothing here makes an automated decision with a legal or similarly significant effect on a person. The product decides what to fix on a web page, not anything about you.

Where you have asked for AI-generated fixes, what reaches the inference provider is image bytes and URLs from the site being audited plus the surrounding page text used as context. Your account details are not sent, and the provider does not train on it under our agreement. A self-hosted deployment sends nothing outside your own infrastructure.

This is a product for the people who build and maintain websites. It is not directed at children, we do not knowingly collect data from anyone under 16, and if you think we have, write to privacy@thelatchkey.in and we will delete it.

The date at the top of this page is when it last changed. If a change materially affects how we use data we already hold, we will email account owners before it takes effect rather than relying on you to re-read the page.