What we keep,
and what we don't.
A tool that audits other people's privacy practices should be unusually clear about its own. Here is the complete picture.
The short version
No accounts, no cookies
There is nothing to sign up for, and this site sets no cookies — which is why you are not being asked to dismiss a banner. That describes what we do; it is not legal advice about your own site.
No third parties
No analytics service, no tag manager, no advertising pixel, no CDN-hosted fonts or scripts. Every asset is served from this origin. Nobody else observes your visit.
Page content is never stored
The HTML fetched during an audit is analysed in memory and discarded when the request ends. It is never written to disk, never logged and never used for anything else.
Hostnames only
For the public statistics we keep the hostname of audited sites — example.com, never
example.com/private/page?token=…. Paths and query strings are discarded before
anything is written.
Exactly what is recorded
One row per event, containing these fields and no others:
| Field | Example | Why |
|---|---|---|
| timestamp | 1755331200 | Traffic over time |
| kind | audit | Separates page views, audits, API calls and badge loads |
| host | example.com | Unique-site counts and public averages. Never the path or query. |
| score, grade | 83.0, B+ | Public averages and the distribution chart |
| category scores | security: 96 | Per-category averages across all audits |
| failed check ids | sec.csp | The "most common problems" list |
| client | Chrome, ClaudeBot | Coarse browser or bot label. Not the full user-agent string. |
| referrer host | news.ycombinator.com | Where visitors arrive from. Host only. |
| visitor hash | a3f9… | Unique-visitor counts. See below — this is the important one. |
The visitor hash, in detail
Counting unique visitors normally means
storing something stable about each person. We do not. The hash is
sha256(secret_salt + today's_date + IP + user-agent), truncated. Because the date is
part of the input, the same person produces a completely different hash tomorrow. That makes visits
countable within a day and impossible to link across days — and since raw IP addresses are never
written to disk at any point, there is nothing to correlate even if the file were obtained.
What is never recorded
- Raw IP addresses.
- Full URLs, paths or query strings of audited pages.
- The content of any page audited.
- Full user-agent strings.
- Anything resembling a persistent identifier, cookie or device fingerprint.
Audit history
Separate from the aggregate statistics above, a point-in-time
snapshot is kept per site so /api/v1/changes can report what moved
between two audits. This is the one thing on this site that is retained per-site rather than only in
aggregate, so it is set out in full.
| Field | Example | Note |
|---|---|---|
| host | example.com | Hostname only, and the host the audit ended on after redirects. Never a path or query string. |
| ts, day | 1755331200 | When the snapshot was taken |
| score, grade | 83.0, B+ | Overall result |
| cats | {"seo": 91, …} | Score per category |
| failed | {"sec.csp": "fail"} | Check ids that failed or warned, and which. No evidence, no page content. |
| counts | {"pass": 120, …} | Verdict tallies |
| source | audit | api | cron | What triggered it |
The honest answers
- Keyed on hostname. Snapshots are not linked to whoever requested the audit. There is no association between a snapshot and a visitor.
- Yes, a third party can cause one. Anyone auditing a public site creates a snapshot of it. That is inherent to a tool anyone can point at any public URL, and it is worth stating plainly rather than leaving implied.
- At most one per site every six hours, whatever the number of audits.
- Retention: the most recent 365 snapshots per host. Nothing is expired on a timer beyond that, and nothing here contains page content.
- Deletion: there is no self-service route yet. Ask via the contact in security.txt and the snapshots for a host will be removed.
- It contains only what the table above lists — scores, check ids and a hostname. The HTML of the audited page is never written to disk at any point.
Security of the engine itself
An endpoint that fetches arbitrary user-supplied URLs is, by construction, a server-side request forgery surface. It is treated as the primary risk:
Every resolved address must be public
The target hostname is resolved and every returned address — IPv4 and IPv6 — is checked against private and reserved ranges. A hostname with one public and one loopback record is rejected, so split-horizon DNS cannot be used to reach internal services.
Scheme and port restrictions
Only http and https, and only ports 80, 443, 8080 and 8443. Cloud
metadata endpoints such as 169.254.169.254 are blocked by the address rules above.
Hard limits on every fetch
Response bodies are capped at 3 MB, redirects at six hops, and the whole audit runs to a global time and request budget. A hostile target cannot exhaust the server by responding slowly or endlessly.
Read-only, always
The engine issues GET requests. It never submits a form, never attempts authentication, and never sends a payload designed to trigger behaviour. The exposed-path probe requests conventional locations and reports whether they are publicly served — it does not exploit what it finds.
Secrets found in your page
If the audit spots something that looks like a live credential in your HTML — an API key, a token, a private key block — it is reported redacted: enough to identify what it found, never the full value. The finding lives only in the report returned to you. It is not stored, and it is not included in the aggregate statistics.
The badge and your visitors
If you embed the badge, it is a plain SVG image with a link. No JavaScript executes on your page, no cookie is set on your visitors, and nothing is read from their browser. Loading the image tells our server the same thing loading any image tells any server — an IP and a user-agent — which is processed exactly as described above and never written in raw form.
Auditing sites you don't own
The engine reads only what a site publicly serves, in the same way any browser, search crawler or link preview does. It identifies itself honestly in its user-agent rather than impersonating a browser, and it respects the response it is given. It does not attempt to log in, bypass a challenge page, or reach anything not publicly available.
Reporting a problem
Security contact details are published at /.well-known/security.txt, which is the convention this tool checks other sites for and therefore ought to follow itself.