Privacy

What running an audit records

Each audit writes one line to a log file on the server. That line holds:

• the domain you audited, and the time you audited it
• which set of checks you ran, how long the run took, and how many checks completed
• the outcome: finished, timed out, failed, or abandoned before it finished
• your browser family and operating system family, as one short label like Firefox / Windows. No version numbers, and the full user-agent string your browser sends is not written down.
• whether the request looks like a bot rather than a person
• whether it came from the web form, the streaming endpoint, or a PDF download
• a daily visitor token, described below
• the hostname of the page that linked you here, if your browser sent one. The path and query string are dropped, so a link from a private forum thread records the forum, not the thread.

The domain you type is the whole point of the tool, so it is recorded. If a domain's existence is itself something you would rather keep private, audit it from a copy you run yourself.

Once a week a copy of this log is downloaded to my own computer and summarized into a private usage report that only I see. It is not published or shared.

Your IP address

Your IP address is not written to the audit log, and the application does not write it to any other file. It is used two ways, both of them in memory.

Rate limiting counts recent requests per IP so that one client cannot flood the service. Each address holds only the timestamps from the last 60 seconds, and the entry is dropped once that window empties.

The daily visitor token is a truncated SHA-256 hash of your IP address, your user agent, today's date, and a random value the server generates when it starts. That random value is not written anywhere and does not survive a restart, so the token cannot be turned back into an address. Because the date is part of the hash, the same visitor hashes to something different tomorrow. It exists so usage counts can tell one heavy user from twenty light ones inside a single day, and it deliberately cannot follow anyone across days.

The web server in front of the application keeps an access log of each page and audit request: the time, the method, the path, the status code, the size of the response, and how long it took. It leaves out your IP address and your user agent.

When the web server hits an error on a request, such as a file that does not exist, it writes a line to its error log that includes your IP address after the word client, and those lines are kept for 14 days.

What your browser stores

The site keeps two things in your browser's local storage. Neither is sent to the server, and neither is a cookie.

• theme: light or dark, so the site opens the way you left it.
• recentAudits: the last ten domains you audited in this browser, each with the time you audited it, offered back to you as shortcuts under the search box.

Both stay on your device. The Clear button beside the recent list removes recentAudits, and clearing site data in your browser removes both. The site sets no cookies and uses no session storage.

DNS snapshots

The server keeps a small database of DNS records it has looked up, so it can tell you when one of your records changed. Each row is a domain, a record type, the record's value, and when it was seen. All of it is public DNS data that anyone can query for themselves.

Third parties

The pages load nothing from anyone else. No analytics, no third-party scripts, no tag managers, no hosted fonts. The two typefaces are served from this domain.

Cloudflare provides DNS and CDN for the site, so your connection reaches it first and it sees the request the way any network in the path does.

Cloudflare also tells browsers that support it, such as Chrome and Edge, to send it a short report when a request to this site fails, whether the connection fails or the server returns an error. The report includes the address that was requested, which can contain the domain you audited, and Cloudflare sees your IP address when it arrives.

When something on the server breaks, it sends an error report to Sentry, an error tracking service, so the fault can be found and fixed. A report holds the error, where in the code it happened, which part of the site it came from, and the domain being audited. The address you requested, your IP address, your user agent, the page that linked you here, and every other request header are removed before a report leaves the server. Nothing in your browser talks to Sentry.

How long it is kept

• The audit log is limited by size, not by date: eleven files of 10 MB each, with the oldest file deleted when a new one starts. The oldest line in it today is from April 2026, when the log began. At current traffic, about 4 KB a day, it would take decades to fill, so nothing has been deleted from it yet.
• The web server's access log and error log are rotated daily and kept for 14 days.
• DNS snapshots older than 90 days are deleted, and that cleanup runs on every audit.
• Recent audits in your browser stay until you clear them.

Accounts

There are no accounts. Nothing to sign up for, nothing to log in to, no email address to hand over, and no payment. If that changes, this page gets a section saying what an account holds.

If you email [email protected], your message and address are kept in my mailbox like any other email.

Checking this yourself

You do not have to take any of this on trust. The server is open source under the MIT License: the log line is written in server.py, the browser and OS labels come from ua_classify.py, the snapshot database is dns_snapshots.py, the error report filtering is _init_sentry in server.py, and every use of local storage is in static/app.js and static/theme.js. You can read it or run it yourself.

Changes

This page describes the tool as it works today. When the tool changes, this page changes with it.

Last updated: 9 October 2026