Two people, not one.
Last updated 2026-10-04. The free check at /check has two subjects: the person who types a domain, and the party whose server is contacted because of it. This notice covers both. It covers only the free checker — the platform privacy policy covers accounts and the paid product.
Who Operates This
The operator of this deployment is Yasseen Nandally, based in Mauritius. Contact for anything on this page, including an opt-out or a request about your own data: no abuse address is configured on this deployment, so the only route is the contact page.
For counsel: no registered address, company details or data-protection representative are stated here because none have been supplied. If a published postal address or an EU representative is required, that is for the operator to add before this page goes live.
Part One: If You Are The Person Asking
What is recorded when you run a check
One row per attempt, including refusals: the domain you typed, the time in UTC, a salted SHA-256 hash of your IP address truncated to 128 bits, the outcome, a short detail such as an error code, and how long the check took. Your IP address itself is not written to this log, and the hash cannot be reversed to recover it. Two rows with the same hash came from the same address; that is all this log supports.
Separately from the check log, this server journals ordinary request metadata for every route, including these ones: the source IP address in the clear, the method, the path, the status code, the duration and a browser category. It is visible to platform administrators only and is kept for 7 days by default (configurable). This is the same journal described on the data boundary page, and it is the reason this notice does not claim that your address is never stored.
No account, no cookie set by these pages, no analytics, no advertising identifier, and no third-party request from the page itself. Results are not stored against any customer account, and a check never reads or writes any customer's workspace.
Why
The check log exists so that an abuse report about a domain can be investigated, and so the per-address, per-domain and service-wide limits can be enforced. Without it, a complaint from a domain owner could not be answered with facts. The request journal exists to operate and secure the service.
How long
Check-log rows older than the retention window are deleted. The window is 30 days by default on this deployment. One honest detail: the pruning runs when the next check is logged, so on a quiet service a row can outlive its window by as long as it takes for somebody to run another check.
What leaves this server
The domain you typed is sent to a public Certificate Transparency search service — crt.sh by default, which is a third party — and to the hostname itself as the SNI of a TLS handshake. Your IP address is not sent to either: the CT service sees this server, and the checked host sees this server. The hostname you typed is also published, as a URL, in the result.
Your rights, and a real limit on them
Depending on where you are, you may have rights to access, correct, erase, restrict or object to the processing of your personal data, and to complain to a supervisory authority. There is a practical limit worth stating plainly: because the check log holds a salted hash rather than your address, the operator cannot find “your” rows without the address they came from. You would have to supply it, which means handing over the very thing the log avoids storing. The request journal is searchable by address and is the place a request about your own data can actually be answered, within its 7-day window.
Results are public and kept, so think before you type
A result is published at /r/{domain} and can be read by anyone with that URL, as JSON and as a CBOM. Two different things happen to it, and the difference matters: it is cached for about 60 minutes, which is what stops repeated visits turning into repeated connections to the endpoint; and it is recorded in an append-only register that is kept indefinitely, so a link, a citation or a README badge still resolves years later. The register also holds what changed and when, because a posture that improved is the useful part of a record.
So do not type a hostname you need to keep private. Submitting it makes the name part of a permanent public URL, and the page will say what that endpoint negotiated. There is no undo you can run yourself: removal is an operator action, through the abuse and opt-out page, and it is available to whoever operates the domain rather than to whoever typed it.
Opening a record does not start a check and is not written to the check log; only submitting a check is. A crawler or a link preview that follows a shared record reads stored data and contacts nobody. A record is served with a 5-minute public cache header, so an intermediary may hold a copy briefly.
Part Two: If You Are The Party Being Checked
Somebody who is not you can cause this service to make a connection to your host, without asking you first. That is the honest shape of this tool, and it is why this section exists and why the opt-out is unconditional.
What the connection is
At most two TCP connections to the hostname that was typed, on port 443 only. One ordinary verified TLS handshake — the same one a browser makes — and one single ClientHello that offers post-quantum key-exchange groups, whose ServerHello is read before the socket closes. No HTTP request is ever sent to your host, so there is nothing for your web access log to record and no User-Agent for it to hold. The scanner identity page sets this out in full, including what to look for in your logs.
What is recorded about you, and published
- The hostname that was checked, and the IP address it resolved to and was connected to. The address appears in the published result.
- From the handshake: the TLS version, the cipher suite, the ALPN protocol selected, the negotiated key-exchange group, and whether the certificate verified against public roots.
- From the certificate your server presented: subject, issuer, validity dates, days to expiry, public-key type, size and curve, and signature algorithm.
- From Certificate Transparency: how many unexpired certificates are logged for the name, the issuers, the key types in a small number of logged certificates, and the issuer, common name and validity of the ten most recent entries.
- A verdict and a set of findings derived from the above, plus model figures that are labelled as a model rather than a measurement.
All of it is configuration your server tells every client that connects, or data already published in public logs. None of it is content, and nothing inside your systems is read.
Your certificate data is already public
Certificates issued for your domain are published in Certificate Transparency: append-only public logs operated by other organisations, which browsers require. This service reads those logs; it does not write to them and cannot remove anything from them. An opt-out here stops this service reading and republishing them for your domain; it does not change what the logs themselves hold.
The result is linkable, indexable and kept
The result for your domain sits at a predictable, shareable URL, /r/{your-domain}, and can be read by anyone who has it or guesses it. It is deliberately indexable: a search engine may list it, and the page carries an embeddable badge anyone can put in a README. It is served from stored data rather than re-measured, so link traffic, crawling and badge views never turn into more connections to your server — none of those routes can start a check. Observations are kept indefinitely, including the record of a posture you have since fixed.
How to stop it
Ask, and your domain is refused before its name is resolved — not at the firewall, not after a connection, but before DNS. It covers every name under your domain. In the same operation the cached result is deleted and the permanent record is hidden: the page, the history, the JSON and the CBOM all answer with the refusal, and the domain drops out of anything that lists or advertises records. No reason is needed. The route and what to include is on the abuse and opt-out page.
Hidden, not erased. The observations stay in the operator's database, unreachable through every public route, because they are the evidence of what this service checked and what it saw — which is what makes a complaint about it answerable. If you want them erased rather than hidden, say so in the same request and it becomes a question for the operator, not an automatic outcome. The one exception to the refusal is the badge: it returns the same neutral grey image for an opted-out domain as for a domain nobody has ever checked, so that a README it was embedded in does not break and so that the image itself does not announce that you opted out.
Applicable Regimes
The regimes the operator believes are relevant, named without any claim of compliance:
The Data Protection Act 2017, because the operator is in Mauritius.
The GDPR, where a visitor or the operator of a checked host is in the EU or EEA. An IP address, and a hostname that identifies an individual, can be personal data.
For counsel: the lawful basis for each of the two processing activities above, whether the checked party is a data subject under either regime and on what basis, whether a legitimate-interests assessment is required and whether it survives one, retention periods, international-transfer analysis for the Certificate Transparency lookup, and whether a representative must be appointed are all open questions for review. This notice describes what the software does; it does not assert that doing it is lawful anywhere.
No automated decision with legal effect is made about anyone. The verdict is a statement about a TLS endpoint's configuration, not about a person.
Related
Terms of use, acceptable-use policy, abuse and opt-out, scanner identity, and the live guardrails on /check. For the platform and accounts, see the platform privacy policy and the data boundary.